目录
前言
一 List-Watch
1.1 list-watch概述
1.2 list-watch工作机制
二 集群调度
2.1 调度过程
2.2 Predicate 和 Priorities 的常见算法和优先级选项
2.3 调度方式
三 亲和性
3.1 节点亲和性
3.2 Pod 亲和性
3.3 键值运算关系
3.4 Pod亲和性与反亲和性
3.5 示例
四 污点(Taint) 和 容忍(Tolerations)
4.1 污点
4.2 容忍
前言
在 Kubernetes 中,List-Watch 是一种 API 操作模式,用于实时监视 Kubernetes 资源对象的变化。List-watch 模式结合了 List 操作和 Watch 操作,允许客户端首先列出(List)资源对象的初始状态,然后通过长连接(Watch)来实时获取这些资源对象的变化情况。
Kubernetes 是通过 List-Watch的机制进行每个组件的协作,保持数据同步的,每个组件之间的设计实现了解耦。
通过 List-Watch 组件,客户端可以实时地监视 Kubernetes 集群中资源对象的状态变化,而无需反复发送 List 请求来轮询资源状态。这种实时监控机制使客户端能够更加高效地响应资源对象的变化,并及时更新本地状态或执行相关操作。
一 List-Watch
1.1 list-watch概述
在 Kubernetes 中,List-watch 是一种机制,用于实现各个组件之间的协作和数据同步。它是 Kubernetes 中的核心概念之一,确保集群中的各个组件保持最新的状态,并能够及时响应变化。
以下是一个简要的概述,涉及了 Kubernetes 中的各个关键组件和它们之间的交互:
-
用户使用 kubectl:通过配置文件或命令行向 Kubernetes API Server 发送请求,以创建、更新或删除资源对象(如 Pod、Deployment 等)。
-
API Server:作为 Kubernetes 集群的控制面板,接收来自用户或其他组件的请求。它处理身份验证、授权和访问控制,并根据请求调用相应的资源对象操作。
-
etcd:Kubernetes 使用 etcd 作为分布式键值存储系统,用于持久化保存集群的状态信息。所有部署和配置信息都会写入 etcd,并通过 Watch 机制发送事件通知给 API Server。
-
Controller Manager:负责处理集群中的各种控制器,如 ReplicaSet、Deployment、DaemonSet 等。它监听(Watch) API Server 发出的事件,根据需要进行调整,以确保所管理的资源对象处于所需的状态。
-
Scheduler:负责将新创建的 Pod 分配到合适的 Node 节点上运行。它监听(Watch) API Server 发出的事件,根据调度策略和资源约束选择合适的节点,并将 Pod 分配给该节点。
-
kubelet:运行在每个 Node 节点上,负责管理节点上的容器和 Pod。它监听(Watch) API Server 发出的事件,确保节点上运行的 Pod 与 API Server 中的状态保持同步。
通过 List-watch 机制,API Server 监听 etcd 和其他组件发出的事件,并相应地发送事件通知给各个组件。这样,各个组件就能够根据事件的变化及时采取相应的操作,以保持集群中的资源对象处于最新的状态。
总之,List-watch 是 Kubernetes 中实现组件之间协作和数据同步的重要机制,通过事件监听和通知,实现了各个组件的解耦和高效的信息交换。这种机制保证了 Kubernetes 集群中各个组件之间的协作和整体的稳定性。
1.2 list-watch工作机制
Pod 是 Kubernetes 的基础单元,Pod 启动典型创建过程如下:
- 用户通过 kubectl 或其他 API 客户端向 APIServer 提交创建 Pod 对象的请求。
- APIServer 将 Pod 对象的元信息存入 etcd 中,并返回确认信息给客户端。
- etcd 发送 Create 事件给 APIServer。
- Controller Manager 监听 APIServer 发出的事件,并接收到 Create 事件。
- Controller Manager 使用 Replication Controller 确保 Node 上的副本数量符合定义,并创建缺少的副本。
- APIServer 在 etcd 中记录新创建的 Pod 的详细信息。
- etcd 发送创建 Pod 的信息事件给 APIServer。
- Scheduler 监听 APIServer 发出的事件,为新创建的 Pod 安排合适的 Node。
- Scheduler 更新 Pod 的信息,包括部署到哪个 Node 上。
- Scheduler 更新的信息通过 APIServer 更新至 etcd 中保存起来。
- etcd 发送更新成功的事件给 APIServer,APIServer 反映 Pod 对象的调度结果。
- kubelet 在 Node 上监听 APIServer 发送的 Pod 更新事件,尝试在当前节点上启动容器,并将结果状态回送至 APIServer。
- APIServer将 Pod 状态信息存入 etcd,并发送确认信息给相关的 kubelet。
注意: 在创建 Pod 的工作就已经完成了后,为什么 kubelet 还要一直监听呢?
这是因为 Kubernetes 是一个动态的容器编排系统,Pod 对象的状态可能会在运行时发生变化,例如副本数量的调整或者镜像文件的更新。因此,kubelet 在 Node 上一直监听 APIServer 发送的 Pod 更新事件,以便及时更新和调整 Node 上的资源,并确保 Pod 的状态始终与期望状态一致。这也是 Kubernetes 能够高效、可靠地管理容器化应用程序的重要原因之一。
二 集群调度
2.1 调度过程
Scheduler 是 kubernetes 的调度器,主要的任务是把定义的 pod 分配到集群的节点上。
Kubernetes Scheduler 的主要任务:
- 公平性:保证每个节点都能被分配到资源。
- 资源高效利用:最大化集群资源利用率。
- 效率:具有良好的调度性能,能够快速完成对大批量 Pod 的调度工作。
- 灵活性:允许用户根据需求控制调度逻辑。
Kubernetes Scheduler 的工作流程:
- Scheduler 作为单独的程序运行,持续监听 APIServer 获取未指定 nodeName 的 Pod。
- 对每个未指定 nodeName 的 Pod,Scheduler 创建一个 binding,指明该 Pod 应该放置在哪个节点上。
- 调度过程分为以下几个步骤:
①预算策略(predicate):过滤掉不满足条件的节点。
②优选策略(priorities):对通过预算策略的节点按优先级排序。
③选择节点:从经过优选策略排序的节点中选择优先级最高的节点。
- 如果在任何一步骤中出现错误,Scheduler 将直接返回错误信息。
2.2 Predicate 和 Priorities 的常见算法和优先级选项
Predicate 阶段常见的算法:
- PodFitsResources:检查节点上剩余资源是否大于 Pod 请求的资源,并检查节点名称是否与 NodeName 匹配。
- PodFitsHost:如果 Pod 指定了 NodeName,检查节点名称是否与 NodeName 匹配。
- PodFitsHostPorts:检查节点上已使用的端口是否与 Pod 请求的端口冲突。
- PodSelectorMatches:过滤掉与 Pod 指定标签不匹配的节点。
- NoDiskConflict:确保已挂载的卷和 Pod 指定的卷不冲突,除非它们都是只读的。
注意:在 Predicate 过程中,如果没有合适的节点,Pod 将一直处于 Pending 状态,直到有节点符合条件。如果有多个节点符合条件,将进入 Priorities 阶段进行节点排序。
Priorities 阶段常见的优先级选项:
- LeastRequestedPriority:根据 CPU 和内存使用率计算权重,使用率越低权重越高,倾向于选择资源使用较低的节点。
- BalancedResourceAllocation:根据节点上 CPU 和内存使用率的接近程度计算权重,使用率越接近权重越高,通常与 LeastRequestedPriority 一起使用。
- ImageLocalityPriority:倾向选择已经包含所需镜像的节点,镜像总大小越大,权重越高。
通过计算所有优先级项目和权重的算法,Scheduler 可以确定最终的节点选择结果,以完成 Pod 的调度工作。这些算法和优先级选项有助于实现资源高效利用、公平性和灵活性,确保集群的顺利运行和资源分配。
2.3 调度方式
#指定调度节点
①pod.spec.nodeName 将 Pod 直接调度到指定的 Node 节点上,会跳过 Scheduler 的调度策略,该匹配规则是强制匹配
vim myapp.yamlapiVersion: apps/v1
kind: Deployment
metadata:name: myapp
spec:replicas: 3selector:matchLabels:app: myapptemplate:metadata:labels:app: myappspec:nodeName: node01containers:- name: myappimage: soscscs/myapp:v1ports:- containerPort: 80kubectl apply -f myapp.yamlkubectl get pods -o wide
#查看详细事件(发现未经过 scheduler 调度分配)
kubectl describe pod nginx-6799fc88d8-9fsjc
②pod.spec.nodeSelector:通过 kubernetes 的 label-selector 机制选择节点,由调度器调度策略匹配 label,然后调度 Pod 到目标节点,该匹配规则属于强制约束。
#获取标签帮助
kubectl label --help
Usage:kubectl label [--overwrite] (-f FILENAME | TYPE NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--resource-version=version] [options]
#需要获取 node 上的 NAME 名称
#给对应的 node 设置标签分别为 test=a 和test=b
kubectl label nodes node01 test=akubectl label nodes node02 test=b
#查看标签
#修改成 nodeSelector 调度方式
vim myapp1.yamlapiVersion: apps/v1
kind: Deployment
metadata:name: myapp1
spec:replicas: 3selector:matchLabels:app: myapp1template:metadata:labels:app: myapp1spec:nodeSelector:kgc: acontainers:- name: myapp1image: soscscs/myapp:v1ports:- containerPort: 80kubectl apply -f myapp1.yaml
kubectl get pods -o wide
#查看详细事件(通过事件可以发现要先经过 scheduler 调度分配)
kubectl describe pod myapp1-6799fc88d8-rxjnz
#修改一个 label 的值,需要加上 --overwrite 参数
kubectl label nodes node02 test=a --overwrite
#删除一个 label,只需在命令行最后指定 label 的 key 名并与一个减号相连即可
kubectl label nodes node02 test-
#指定标签查询 node 节点
kubectl get node -l test=a
三 亲和性
3.1 节点亲和性
节点亲和性指的是将 Pod 调度到特定节点的策略。在 Kubernetes 中,通过在 Pod 的 spec 中指定 nodeAffinity 字段来实现节点亲和性。
在 preferredDuringSchedulingIgnoredDuringExecution 策略中,可以指定多个 preferred 节点亲和性项,表示希望将 Pod 调度到这些节点上,但如果没有可用的节点满足条件,则仍会调度到其他节点上运行。
在 requiredDuringSchedulingIgnoredDuringExecution 策略中,必须指定至少一个 required 节点亲和性项,如果没有可用的节点满足条件,Pod 将一直处于 Pending 状态,直到有节点符合条件。
pod.spec.nodeAffinity
●preferredDuringSchedulingIgnoredDuringExecution:软策略
●requiredDuringSchedulingIgnoredDuringExecution:硬策略
3.2 Pod 亲和性
Pod 亲和性指的是将 Pod 调度到与其他 Pod 相关的节点的策略。在 Kubernetes 中,通过在 Pod 的 spec 中指定 affinity 字段来实现 Pod 亲和性。
在 podAffinity 策略中,可以指定多个 preferredPodAffinity 和 requiredPodAffinity 项,表示希望将 Pod 调度到与这些 Pod 相关的节点上,但如果没有可用的节点满足条件,则仍会调度到其他节点上运行。
在 podAntiAffinity 策略中,可以指定多个 preferredDuringSchedulingIgnoredDuringExecution 和 requiredDuringSchedulingIgnoredDuringExecution 项,表示希望将 Pod 调度到与这些 Pod 不相关的节点上,以避免出现故障域的单点故障(SPOF)问题。
pod.spec.affinity.podAffinity/podAntiAffinity
●preferredDuringSchedulingIgnoredDuringExecution:软策略
●requiredDuringSchedulingIgnoredDuringExecution:硬策略
注意:节点亲和性和 Pod 亲和性都是在调度期间评估的,即在 Pod 分配给节点前进行评估。一旦 Pod 被调度到一个节点上,它就会一直在该节点上运行,即使后来该节点不再符合亲和性规则。
3.3 键值运算关系
键值对运算关系通常应用于 Kubernetes 中的 label selector 和 field selector,可以用来筛选出符合特定要求的 Pod、Service、Node 等 Kubernetes 对象。具体的键值对运算关系包括:
●In:label 的值在某个列表中
表示希望选择具有 app=label 的 Pod,其中 label 的值为 nginx 或 mysql。
matchExpressions:- {key: app, operator: In, values: [nginx, mysql]}
●NotIn:label 的值不在某个列表中
表示希望选择具有 app=label 的 Pod,其中 label 的值不为 redis。
matchExpressions:- {key: app, operator: NotIn, values: [redis]}
●Gt:label 的值大于某个值
表示希望选择具有 memory=label 的 Pod,其中 label 的值大于 500Mi。
matchExpressions:- {key: memory, operator: Gt, values: [500Mi]}
●Lt:label 的值小于某个值
表示希望选择具有 memory=label 的 Pod,其中 label 的值小于 500Mi。
matchExpressions:- {key: memory, operator: Lt, values: [500Mi]}
●Exists:某个 label 存在
表示希望选择具有 app=label 的 Pod,其中 label 存在。
matchExpressions:- {key: app, operator: Exists}
●DoesNotExist:某个 label 不存在
表示希望选择不具有 app=label 的 Pod,其中 label 不存在。
matchExpressions:- {key: app, operator: DoesNotExist}
3.4 Pod亲和性与反亲和性
调度策略 | 匹配标签 | 操作符 | 拓扑域支持 | 调度目标 |
---|---|---|---|---|
nodeAffinity | 主机 | In, NotIn, Exists,DoesNotExist, Gt, Lt | 否 | 指定主机 |
podAffinity | Pod | In, NotIn, Exists,DoesNotExist | 是 | Pod与指定Pod同一拓扑域 |
podAntiAffinity | Pod | In, NotIn, Exists,DoesNotExist | 是 | Pod与指定Pod不在同一拓扑域 |
kubectl label nodes node01 test=a pod1
kubectl label nodes node02 test=b pod2
#创建一个标签为 app=myapp01 的 Pod
vim pod3.yamlapiVersion: v1
kind: Pod
metadata:name: myapp01labels:app: myapp01
spec:containers:- name: with-node-affinityimage: soscscs/myapp:v1kubectl apply -f pod3.yamlkubectl get pods --show-labels -o wide
#使用 Pod 亲和性调度,创建多个 Pod 资源
vim pod4.yamlapiVersion: v1
kind: Pod
metadata:name: myapp02labels:app: myapp02
spec:containers:- name: myapp02image: soscscs/myapp:v1affinity:podAffinity:requiredDuringSchedulingIgnoredDuringExecution:- labelSelector:matchExpressions:- key: appoperator: Invalues:- myapp01topologyKey: test
#仅当节点和至少一个已运行且有键为“app”且值为“myapp01”的标签 的 Pod 处于同一拓扑域时,才可以将该 Pod 调度到节点上。 (更确切的说,如果节点 N 具有带有键 kgc 和某个值 V 的标签,则 Pod 有资格在节点 N 上运行,以便集群中至少有一个具有键 test 和值为 V 的节点正在运行具有键“app”和值 “myapp01”的标签的 pod。)
#topologyKey 是节点标签的键。如果两个节点使用此键标记并且具有相同的标签值,则调度器会将这两个节点视为处于同一拓扑域中。 调度器试图在每个拓扑域中放置数量均衡的 Pod。
#如果 test 对应的值不一样就是不同的拓扑域。比如 Pod1 在 test=a 的 Node 上,Pod2 在 test=b 的 Node 上,Pod3 在 test=a 的 Node 上,则 Pod2 和 Pod1、Pod3 不在同一个拓扑域,而Pod1 和 Pod3在同一个拓扑域。
#使用Pod反亲和性调度
vim pod5.yamlapiVersion: v1
kind: Pod
metadata:name: myapp10labels:app: myapp10
spec:containers:- name: myapp10image: soscscs/myapp:v1affinity:podAntiAffinity:preferredDuringSchedulingIgnoredDuringExecution:- weight: 100podAffinityTerm:labelSelector:matchExpressions:- key: appoperator: Invalues:- myapp01topologyKey: kubernetes.io/hostname
#如果节点处于 Pod 所在的同一拓扑域且具有键“app”和值“myapp01”的标签, 则该 pod 不应将其调度到该节点上。 (如果 topologyKey 为 kubernetes.io/hostname,则意味着当节点和具有键 “app”和值“myapp01”的 Pod 处于相同的拓扑域,Pod 不能被调度到该节点上。)
kubectl apply -f pod5.yamlkubectl get pods --show-labels -o wide
3.5 示例
kubectl get nodes --show-labels
#requiredDuringSchedulingIgnoredDuringExecution:硬策略
mkdir /opt/affinity
cd /opt/affinityvim pod1.yamlapiVersion: v1
kind: Pod
metadata:name: affinitylabels:app: node-affinity-pod
spec:containers:- name: with-node-affinityimage: soscscs/myapp:v1affinity:nodeAffinity:requiredDuringSchedulingIgnoredDuringExecution:nodeSelectorTerms:- matchExpressions:- key: kubernetes.io/hostname #指定node的标签operator: NotIn #设置Pod安装到kubernetes.io/hostname的标签值不在values列表中的node上values:- node02kubectl apply -f pod1.yamlkubectl get pods -o widekubectl delete pod --all && kubectl apply -f pod1.yaml && kubectl get pods -o wide
注意:#如果硬策略不满足条件,Pod 状态一直会处于 Pending 状态。
#preferredDuringSchedulingIgnoredDuringExecution:软策略
vim pod2.yamlapiVersion: v1
kind: Pod
metadata:name: affinitylabels:app: node-affinity-pod
spec:containers:- name: with-node-affinityimage: soscscs/myapp:v1affinity:nodeAffinity:preferredDuringSchedulingIgnoredDuringExecution:- weight: 1 #如果有多个软策略选项的话,权重越大,优先级越高preference:matchExpressions:- key: kubernetes.io/hostnameoperator: Invalues:- node03kubectl apply -f pod2.yamlkubectl get pods -o wide
#把values:的值改成node01,则会优先在node01上创建Pod
kubectl delete pod --all && kubectl apply -f pod2.yaml && kubectl get pods -o wide
#如果把硬策略和软策略合在一起使用,则要先满足硬策略之后才会满足软策略
apiVersion: v1
kind: Pod
metadata:name: affinitylabels:app: node-affinity-pod
spec:containers:- name: with-node-affinityimage: soscscs/myapp:v1affinity:nodeAffinity:requiredDuringSchedulingIgnoredDuringExecution: #先满足硬策略,排除有kubernetes.io/hostname=node02标签的节点nodeSelectorTerms:- matchExpressions:- key: kubernetes.io/hostnameoperator: NotInvalues:- node02preferredDuringSchedulingIgnoredDuringExecution: #再满足软策略,优先选择有kgc=a标签的节点- weight: 1preference:matchExpressions:- key: kgcoperator: Invalues:- a
四 污点(Taint) 和 容忍(Tolerations)
4.1 污点
节点亲和性,是Pod的一种属性(偏好或硬性要求),它使Pod被吸引到一类特定的节点。Taint 则相反,它使节点能够排斥一类特定的 Pod。
Taint 和 Toleration 相互配合,可以用来避免 Pod 被分配到不合适的节点上。每个节点上都可以应用一个或多个 taint ,这表示对于那些不能容忍这些 taint 的 Pod,是不会被该节点接受的。如果将 toleration 应用于 Pod 上,则表示这些 Pod 可以(但不一定)被调度到具有匹配 taint 的节点上。
使用 kubectl taint 命令可以给某个 Node 节点设置污点,Node 被设置上污点之后就和 Pod 之间存在了一种相斥的关系,可以让 Node 拒绝 Pod 的调度执行,甚至将 Node 已经存在的 Pod 驱逐出去。
污点的组成格式如下:
key=value:effect
每个污点有一个 key 和 value 作为污点的标签,其中 value 可以为空,effect 描述污点的作用。
当前 taint effect 支持如下三个选项:
●NoSchedule:表示 k8s 将不会将 Pod 调度到具有该污点的 Node 上
●PreferNoSchedule:表示 k8s 将尽量避免将 Pod 调度到具有该污点的 Node 上
●NoExecute:表示 k8s 将不会将 Pod 调度到具有该污点的 Node 上,同时会将 Node 上已经存在的 Pod 驱逐出去。
kubectl get nodes
#master 就是因为有 NoSchedule 污点,k8s 才不会将 Pod 调度到 master 节点上
kubectl describe node master
#设置污点
kubectl taint node node01 key1=value1:NoSchedule
# 节点说明中,查找 Taints 字段
kubectl describe node node-name
#去除污点
kubectl taint node node01 key1:NoSchedule-kubectl get pods -o widekubectl taint node node02 check=mycheck:NoExecute
#查看 Pod 状态,会发现 node02 上的 Pod 已经被全部驱逐(注:如果是 Deployment 或者 StatefulSet 资源类型,为了维持副本数量则会在别的 Node 上再创建新的 Pod)
kubectl get pods -o wide
4.2 容忍
设置了污点的 Node 将根据 taint 的 effect:NoSchedule、PreferNoSchedule、NoExecute 和 Pod 之间产生互斥的关系,Pod 将在一定程度上不会被调度到 Node 上。但我们可以在 Pod 上设置容忍(Tolerations),意思是设置了容忍的 Pod 将可以容忍污点的存在,可以被调度到存在污点的 Node 上。
#在两个 Node 上都设置了污点后,此时 Pod 将无法创建成功
kubectl get pods -o widevim pod3.yamlapiVersion: v1
kind: Pod
metadata:name: myapp01labels:app: myapp01
spec:containers:- name: with-node-affinityimage: soscscs/myapp:v1tolerations:- key: "check"operator: "Equal"value: "mycheck"effect: "NoExecute"tolerationSeconds: 3600kubectl apply -f pod3.yaml
#其中的 key、vaule、effect 都要与 Node 上设置的 taint 保持一致
#operator 的值为 Exists 将会忽略 value 值,即存在即可
#tolerationSeconds 用于描述当 Pod 需要被驱逐时可以在 Node 上继续保留运行的时间
#在设置了容忍之后,Pod 创建成功
kubectl get pods -o wide