容器编排 Kubernetes Helm
容器引擎 Containerd Rocket
容器镜像仓库 TUF Harbor Notarv
容器网络CNI
服务网格&服务发现 CoreDNS Linkerd Envoy
容器监控运维 Prometheus Fluentd Jaeger QpenTracing
K8S南向-多样化的环境:
容器、网络、存储插件;镜像仓库;多云插件;集群管理配置;认证系统
K8S北向-多样化的服务和工具:
日志&监控、-配置语言、编排部署、持续集成、Paas、工作流、函数服务、数据处理服务、-对象事务服务(数据库、存储)、互联网应用
组件
Master节点:负责整个集群的管理和控制
- etcd
- kube-apiserver
- kube-controller-manager
- kube-scheduler
Node节点:
- kubelet
- kube-proxy
- docker.cni插件
Kubelet manifest部署控制节点组件,system 安装kubelet,其他组件manifest方式拉起
Liveness、readiness配置组件健康检查
kubeadm init --pod-network-cidr=10.244.0.0/16
初始化完成会自动拉取镜像,初始化配置,节点加入的命令等等
(--dry-run >init.yaml ???)
生成kubecfg文件
...
[kubeconfig] Mrote KubeConfig file to disk: "/etc/kubernetes/admin.conf"
[kubeconfig] wrote KubeConfig file to disk: "/etc/kubernetes/kubelet.conf"
[kubeconfig] wrote KubeConfig file to disk: "/etc/kubernetes/controller-manager"
[kubeconfig] wrote KubeConfig file to disk: "/etc/kubernetes/scheduler.conf"
[controlplane] wrote Static Pod manifest for component kube-apiserver to "/etc/kubernetes/manifests/kube-apiserver.yaml"
监听/etc/kubernetes/mainfests目录(自动生成的目录及文件),你也可以写一些资源文件放进去,集群会自动拉起放进去的配置文件
cat /var/lib/kubelet/config.yaml 里staticPodPath项 定义了这个路径
root@ecs-master:# ls /etc/ kubernetes/manifests #这里的yaml就是定义的pod的资源信息
etcd.yaml kube-apiserver.yaml kube-controller-manager.yaml kube-scheduler.yaml
API SERVER
/api/v1 核心API
/healthz 健康检查
/logs 日志
/ui Dashboard
/swaggerapi OpenAPI
/metrics 性能度量
集群升级流程
控制节点滚动升级:升级kubelet,通过更新manifest升级控制组件
计算节点升级:kubectl drain --ignore-daemonsets=true 10.10.11.12 (驱逐,并cordon)
kubectl uncordon 10.10.11.12
容器分类
Infrastructure Container:基础容器 用户不可见,无需感知 维护整个Pod网络空间
InitContainers:初始化容器,一般用于服务等待处理以及注册Pod信息等.先于业务容器开始执行、顺序执行,执行成功退出 (exit 0 ),全部执行成功后开始启动业务容器
Containers :业务容器 并行启动,启动成功后一直Running
镜像部分:镜像地址和拉取策略 拉取镜像的认证凭据spec.imagepullsercret -name: serret名字
计算资源: 请求值:调度依据。 限制值︰容器最大能使用的规格
健康检查:分命令行方式、httpGet请求方式以及TCPSocket三种方式
业务探针(readinessProbe) ·探测不正常后,不会重启容器,只会拿掉服务后端的endpoints
存活探针(LivenessProbe) 探测不正常后,会重启容器
Pod可以接收的外部输入方式:环境变量、配置文件以及密钥。
环境变量:使用简单,但一旦变更后必须重启容器。 Key-value自定义
From配置文件(configmap)、From密钥(Secret)以卷形式挂载到容器内使用,权限可控。
域名解析的策略
dnsPolicy : Pod内域名解析的策略
ClusterFirst:使用kube-dns作为域名解析服务器
Default:使用节点( kubelet)指定的域名服务器解析域名
ClusterFirstWithHostNet : 当Pod使用主机网络部署时使用
用户可自定义资源类型,可扩展行强∶ 需实现自己的controller进行自定义资源的管理,高段位使用
kind: CustomResourceDefinition
无状态模式
·不必为你的应用保持状态/持久化数据典型应用代表:Nginx,Tomcat·
Replication Controller ReplicaSet Deployment
默认情况下,删除RC会级联删除Pod:
$ kubectl delete rc --cascade=false #只删RC,不影响Pod
滚动升级,需要两个RC(不同label selector)来配合实现:旧的Rc副本数-1,新的RC副本数+1,逐步完成。
ReplicaSet ,基于集合,功能更强,支持matchexpressions
Deployment提供了声明式、自定义策略的Pod升级支持
kubectl set images deployment/nginx nginx=1.17 #升级
kubecrtl rollout status deployment/nginx #查询升级状态
kubecrtl rollout history deployment/nginx #查看升级历史
kubectl scal deployment nginx --replicas=10 #弹性扩缩容
升级/回滚
kubectI set resources deployment nginx-deployment-c=nginx --limits=cpu=200m,memory=512Mi
kubect rollout history deployment/nginx-deployment--revision=2
kubectl rollout undo deployment/nginx-deployment --to-revision=2
暂停/恢复
kubectl rollout pause deployment/nginx-deployment
kubectl rollout resume deploy/nginx-deployment
弹性、按比例扩/缩容
kubect scale deployment nginx-deployment --replicas=10
kubectl autoscale deployment nginx-deployment --min=10 --max=15 --cpu-percent=80#需要和HPA联动
(maxSurge=3;25%A maxUnavailable=2;,25% #可以为数值,也可以为百分比)
有状态模式
典型应用:Zookeeper, MongoDB, MySQL, etcd
StatefulSet (曾用名: PetSet)
StatefulSet的Pod和普通Pod区别:有身份的!
StatefulSet身份三要素: 域名(网络)<-容器IP易变、PVC(存储)、Pod Name(主机名)
配合headless service , PVC一起使用,严格的启动/删除顺序:0,1,2...
资源文件特殊的地方:有个servicename
守护进程模式
典型应用:fluentd,linkderd, ceph, kube-proxy
DaemonSet:保证每个节点总是运行一个Pod实例,支持滚动升级,支持级联/非级联删除
可以配个NodeSelector或NodeAffinity指定Node,配合硬亲和,已经不建议了
批处理模式
=典型应用:并发执行的作业- batch job
-相关但独立的工作项:发邮件、数据扫描、文件转码
Job
-保证指定数量Pod成功运行结束-completions
-支持并行-parallelism
-支持错误自动试(10s,20s, 40s... 6min)最久6分钟间隔,达到后,一直按这个间隔重试
-除Job会触发对应Pod删除
backoffLimit: 5
activeDeadlineSeconds:100
CronJob
-基于时间调度的Job (cron格式)
-用户可以暂停/恢Job的周期性调度.spec.suspend=ftue,false}
管理Job -> Pod
做不同的事情
-扩展Job Expansion,传入参数、环境变量做同样的事情
-工作队列形式,与Work Queue ( RabbitMQ)结合
无状态模式:使用Deployment提供高可用、弹性扩/缩容、升级/回滚
有状态模式:使用StatefulSet提供一致性,Pod的唯一/粘性的身份标识、存储,按序部署、扩缩容
守护进程模式:一个节点部署一个(可自定义节点范围)批处理模式:并行跑多个Pod,并且保证都成功返回
通过label-selector相关联,通过服务实现Pod的负载均衡能力:
Service:实现TCP/UDP 4层负载均衡能力
Ingress:实现HTTP7层负载均衡能力
prot service的服务端口
clusterip vip,service的IP,服务将通过这个clusterip,轮询转发给后端的pod ip,如果你不想要这种轮询效果,你可以将它写成none,这样就成了headless服务
targetport 容器端口
endpoints 创建service时,自动创建出的,endpoints-controller会根据pod的readness探测,增删里面的pod ip。
nodeport 对外发布服务,任意节点的ip:端口,都可以访问到服务,不对外发布可以不定义
LoadBalancer类型Service
同时是Cluster Ip类型,需要跑在特定的cloud provider上
- Service Controller自动创建一个外部LB并配置安全组
-对集群内访问, kube-proxy用iptables或pvs实现了云服务提供商LB的部分功能: L4转发。安全组规则等。
kind: Service
apiVersion: v1
metadata:
name: my-service
spec:
selector:
app: MyApp
ports:
- protocol: TCP
port: 80
targetPort: 9376
cluxterlP: 10.0.171.239
loadBalancerP.78.1124.19 #外部LB-IP
type:LoadBalancer
Ingress
Ingress是授权入站连接到达集群服务的规则集合
-支持通过URL方式将Service暴露到K8S集群外,Service之上的7访问入口
-支持自定义Service的访问策略
-提供按域名访问的虚拟主机功能
-支持TLS
普通存储卷(volume)
容器启动时依赖数据 configmap、 secret
临时数据存储 emptyDir、hostPath
持久化数据存储: nfs、cephfs、GlutserFS 、Cloud
存储没有单独资源对象,与Pod的生命周期一起
持久化存储卷(PersistentVolume)
Provisioning : PV的预制创建有两种模式:静态模式和动态模式
静态模式:除创建PVC外,还需手动创建PV
动态模式:创建PVC外,系统跟库PVC自动创建PV
认证(Authentication)和鉴权(Authorization)
认证支持多种方式,其中一种认证方式认证通过即通过,输出userinfo
基于认证输出的userinfo进行鉴权,鉴权也支持多种方式,常用方式为RBAC
认证(Authentication)
认证方式有:X509、service account、Authenticating Proxy、WebHook、username/password...
常用认证方式介绍:
X509:
- Kube-apiserver的启动参数'一client-ca-file=ca.crt'指定X509根证书,请求中需带有由该根证书签名的证书,才能认证通过
- 客户端签署的证书里包含user、group信息,具体为证书的subject.CommonName
(user name)以及subject.Organization (group)
Service Account(为k8s必选认证方式):
- Kube-apiserver的启动参数'--service-account-key-file=key.pem'指定pem文件,用以生成。bearer token; '--service-account-lookup=true/false'表示在删除service account后其token是否被吊销
- Serviceaccount Admission默认给Pod打上service account,当然用户也可以自行指定所需要的service account
安全的持久化保存键值(etcd )
etcd支持备份恢复机制,防止数据被误删导致数据丢失
用户的敏感信息建议存放在secret类型的资源中,该类型资源是加密存储在etcd中
etcd支持https , kube-apiserver访问etcd使用https协议
安全上下文(Pod SecurityContext )
分为Pod级别和容器级别,容器级别的会覆盖Pod级别的相同设置。
在有PodSecurityPolicy策略的情况下,两者需要配合使用。
是否使用特权容器 privileged: false
指定容器启动UID runAsUser: 1000
指定Pod中容器文件所属组GID fsGroup:2000
容器的文件系统是否是只读 readOnlyRootFilesystem: false
容器系统调用能力配置 capabilities:
Network Policy
分为Ingress和Egress策略控制,都为白名单。Ingress为入口请求控制,Egress为出口请求控制。
细节多学习Network Policy
资源调度
资源调度依据 pod的requests:
执行调度的调度器 schedulerName: default-scheduler
调度结果 nodeName: node1 #创建Pod时直接指定nodeName
高级调度策略 nodeselector: affinity: tolerations:
Pod所需资源的计算:最终取以下两者中的极大值
InitContainers :
逐个运行并退出,之后才拉起containers资源需求取单个容器的最大值
Containers :
同时运行,资源需求为所有容器累加
通过NodeLister获取所有节点信息;
整合scheduled pods和assume pods,合并到pods,作为所有已调度Pod信息;
从pods中整理出node-pods的对应关系表nodeNameToinfo;
过滤掉不合适的节点;给剩下的节点依次打分;
在分数最高的nodes中随机选择一个节点用于绑定。这是为了避免分数最高的节点被几次调度撞车。
通过Predicate策略筛选符合条件的Node。滤除“不合格”节点,避免资源冲突、节点超载
GeneralPredicates 包含3项基本检查:节点、端口和规则
NoDiskConflict 检查Node是否可以满足Pod对硬盘的需求
NoVolumeZoneConflict 单集群跨AZ部署时,检查node所在的zone是否能满足Pod对硬盘的需求
PodToleratesNodeTaints 检查Pod是否能够容忍node上所有的taints
CheckNodeMemoryPressur 当Pod QoS为besteffort时,检查node是否有剩余内存,排除内存压力过大的node
MatchinterPodAffinity 检查node是否满足pod的亲和性、反亲和性需求
通过Priority策略给剩余的Node评分,挑选最优的节点:挑选“优质”节点、优化资源分配、应用分布
LeastRequestedPriority
按node计算资源(CPU/MEM)剩余量排序,挑选最空闲的node
BalancedResourceAllocation 补充LeastRequestedPriority在cpu和mem的剩余量取平衡
SelectorSpreadPriority
同一个Service/RC下的Pod尽可能的分散在集群中。Node上运行的同个Service/RC下的Pod数目越少,分数越高。
NodeAffinityPriority
按soft(preferred)NodeAffinity规则匹配情况排序,规则命中越多,分数越高
TaintTolerationPriority
按pod tolerations与node taints的匹配情况排序,越多的taints不匹配,分数越低
InterPodAffinityPriority
按soft(preferred) Pod Affinity/Anti-Affinity规则匹配情况排序,规则命中越多,分数越高
nodeselector 将 Pod调度到特定的Node 上
匹配node.labels,排除不包含nodeSelector中指定label的所有node,匹配机制:完全匹配
nodeAffinity : nodeSelector 升级版
与nodeSelector关键差异
引入运算符:In, Notin ( labelselectot语法)
支持枚举label可能的取值,如zone in [az1, az2, a3..]
支持硬性过滤和软性评分
硬性过滤规则支持指定多条件之间的逻辑或运算
软性评分规则支持设置条件权重值
硬性过滤: 排除不吴备指定label的node
软性评分: 不具备指定label的node打低分,降低node被选中的几率
podAffinity:让某些Pod分布在同一组Node 上
与nodeAffinity的关键差异
-定义在PodSpec中,亲和与反亲和规则具有对称性,即双向性
-labelSelector的匹配对象为Pod
-对node分组,依据label-key = topologyKey,每个label-value取值为一组
硬性过滤规则,条件间只有逻辑与运算
硬性过滤: 排除不具备指定pod的node组
软性评分: 不具备指定pod的node组打低分.降低该组node被选中的几率
podAntiAffinity:避免某些Pod分布在同一组 Node 上
与podAffinity的差异
-匹配过程相同
-最终处理调度结果时取反
即
podAffinity中可调度节点,在podAntiAffinity中为不可调度
podAffinity中高分节点,在podAntiAffinity中为低分
Taints:避免Pod调度到特定Node 上
带effect的特殊label,对Pod有排斥性:硬性排斥NoSchedule 、软性排斥PreferNoSchedule
系统创建的taint附带时间戳-effect为NoExecute,便于触发对Pod的超时驱逐。用法:预留特殊节点做特殊用途
kubect1 taint node node-n1 foo=bar:NoSchedule #给node添加taint
kubect1 taint node node-n1 foo:NoSchedule- #删除taint
Tolerations:允许Pod调度到有特定taints的 Node上
多调度器 使用scheduleName指定调度器
适用场景: 集群中存在多个调度器,分别处理不同类型的作业调度
使用限制: 建议对node做资源池划分,避免调度结果写入冲突
自定义调度器配置
--policy-config-file自定义调度器加载的算法,或者调整排序算法权重
执行kube-scheduler --help查看更多调度器配置项
Annotations
顾名思义,就是注释的意思。有两个功能:
- 注释性信息,不影响调度,主要是后台用于查询的。类似于label,但没有label使用度高
- 工具和库等客户端可以检索Annotation数据