Deployment 使用 拓扑分布约束 达到 DaemonSet 同样的功能

Deployment 使用 拓扑分布约束 达到 DaemonSet 同样的功能

亲和性和反亲和性的含义

首先在介绍拓扑分布约束之前，我们要知道 pod 的亲和性和反亲和性的概念，pod 的亲和性的本质都是 堆叠或打散 ，​​podAffinity​​ 和 ​​podAntiAffinity​​ 两个特性对 Pod 处于不同disk=ssd的分布进行了一些控制

​​podAffinity​​ 就是将一些 pod 调度在同一拓扑域之中，是堆叠的体现​​podAntiAffinity​​ 就是将 pod 调度在不同的拓扑域之中，使之只能被调度一个或者只能存在一个，是打散的体现

# 拓扑域的概念：拓扑域就是匹配节点的标签的 key 值，一般情况我们可以 explain 查看配置信息# 示例 affinity: podAffinity: requiredDuringSchedulingIgnoredDuringExecution: # 硬策略 - labelSelector: matchExpressions: - key: app operator: In values: - busybox-pod topologyKey: kubernetes.io/hostname # node节点标签带有 kubernetes.io/hostname 为一个拓扑域

拓扑域小练习：

k8s 集群分为磁盘为 ssd 和 hdd 两种规格的节点，通过做 反亲和 硬策略 判断是否可以部署三个实例，node-1 和 node-2 为 ssd 节点，node-3 和node-4 为 hdd 规格

[root@master-1 PodTop]# kubectl label nodes node-1 disk=ssdnode/node-1 labeled[root@master-1 PodTop]# kubectl label nodes node-2 disk=ssdnode/node-2 labeled[root@master-1 PodTop]# kubectl label nodes node-3 disk=hddnode/node-3 labeled[root@master-1 PodTop]# kubectl label nodes node-4 disk=hddnode/node-4 labeled[root@master-1 PodTop]# kubectl get nodes -l disk=ssdNAME STATUS ROLES AGE VERSIONnode-1 Ready worker 53d v1.21.5node-2 Ready worker 53d v1.21.5[root@master-1 PodTop]# kubectl get nodes -l disk=hddNAME STATUS ROLES AGE VERSIONnode-3 Ready worker 53d v1.21.5node-4 Ready worker 53d v1.21.5

反亲和示例 yaml

# podaffinity.yamlapiVersion: apps/v1kind: Deploymentmetadata: name: nginx labels: app: nginxspec: replicas: 2 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx ports: - containerPort: 80 name: nginxweb affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: # 硬策略 - labelSelector: matchExpressions: - key: app operator: In values: - nginx topologyKey: disk # 通过 disk 标签来判断不同的拓扑域

执行判断，查看示例部署节点

# 实例数量为 2 时，可以正常分布在 node-1 和 node-4 节点[root@master-1 PodTop]# kubectl get pod -l app=nginx -o wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATESnginx-6ddd9f758b-mslxd 0/1 ContainerCreating 0 16s node-1 nginx-6ddd9f758b-tj2kd 0/1 ContainerCreating 0 16s node-4 # 扩容至 3，查看分布情况，发现第三个实例为 Pending 状态[root@master-1 PodTop]# kubectl scale deployment nginx --replicas=3deployment.apps/nginx scaled[root@master-1 PodTop]# kubectl get pod -l app=nginx -o wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATESnginx-6ddd9f758b-dgrnx 0/1 Pending 0 2s nginx-6ddd9f758b-mslxd 1/1 Running 0 51s 10.233.112.5 node-1 nginx-6ddd9f758b-tj2kd 1/1 Running 0 51s 10.233.93.105 node-4 # 通过 describe 查看 pending 的事件信息# 提示我们，5个node 节点均不可用， 1个为master 有污点，另外4个node 不能满足反亲和的规则# 因为 node-1 和 node-2 为同一个 `ssd` 拓扑域# node-3 和 node-4 为同一个 `hdd` 拓扑域# 反亲和硬策略是相同的拓扑域之间只能有一个实例存在，这是打散的体现，所以无法调度第三个实例[root@master-1 PodTop]# kubectl describe pod nginx-6ddd9f758b-dgrnx ......Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedScheduling 38s (x6 over 4m56s) default-scheduler 0/5 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate, 4 node(s) didn't match pod affinity/anti-affinity rules, 4 node(s) didn't match pod anti-affinity rules.

拓扑分布约束

通过上述实验，我们发现反亲和特性虽然可以将我们的不同实例调度到不同的拓扑域，但是并不能满足我们同一个拓扑域内的容灾和高可用，因为策略限制，只能存在一个实例。

那么没有解决办法了吗？当然不是，k8s 还有一个 ​​拓扑分布约束​​ ​​topologySpreadConstraints​​ 的概念，官方解释如下：

可以使用 *拓扑分布约束（Topology Spread Constraints）* 来控制 ​​Pods​​ 在集群内故障域之间的分布，例如区域（Region）、可用区（Zone）、节点和其他用户自定义拓扑域。 这样做有助于实现高可用并提升资源利用率。

​​pod.spec.topologySpreadConstraints​​ 字段定义如下所示：

apiVersion: v1kind: Podmetadata: name: mypodspec: topologySpreadConstraints: - maxSkew: topologyKey: whenUnsatisfiable: labelSelector: