Pod在多可用区worker节点上的高可用部署

23次阅读

共计 1374 个字符,预计需要花费 4 分钟才能阅读完成。

一、需求分析
当前 kubernetes 集群中的 worker 节点可以支持添加多可用区中的 ECS,这种部署方式的目的是可以让一个应用的多个 pod(至少两个)能够分布在不同的可用区,起码不能分布在同一个可用区,已达到高可用或者同城灾备的部署。
二、效果图

三、实现原理
为了实现上述的效果,kubernetes 提供了 pod 的亲和性和反亲和性来保证 pod 在节点级别,可用区级别的高可用部署;具体的值为 topologyKey:failure-domain.beta.kubernetes.io/zone。
四、实现步骤
在 ACK 上创建完集群后,不论从哪个可用区添加节点,都会对该节点打上对应的可用区标签,比如,一个节点是属于北京可用区 a 的,那么在加入到 kubernetes 集群后,该节点上会有一个这样的标签:failure-domain.beta.kubernetes.io/zone: cn-beijing-a。
在有了上述标签后,对应用进行多可用区部署时,我们就可以使用一下 yaml 文件来使不同的 pod 分配到不同的可用区。
     Yaml 文件示例:
apiVersion: apps/v1
kind: Deployment
metadata:
name: redis-cache
spec:
selector:
matchLabels:
app: store
replicas: 3
template:
metadata:
labels:
app: store
spec:
affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
– labelSelector:
matchExpressions:
– key: app
operator: In
values:
– store
topologyKey: “failure-domain.beta.kubernetes.io/zone”
containers:
– name: redis-server
image: redis:3.2-alpine
上面 yaml 文件中的 podAntiAffinity: 部分规定了 node 的反亲和性,并且由于使用了 topologyKey: “failure-domain.beta.kubernetes.io/zone”,如果 failure-domain.beta.kubernetes.io/zone 这个 key 有三种 value,比如 cn-beijing-a,cn-beijing-b,cn-beijing-c;那么 pod 会被分配在这三个不同的可用区。并且由于使用了 preferredDuringSchedulingIgnoredDuringExecution,所以如果 pod 个数大于可用区个数的话,pod 会尽可能的放在不同的可用区,最后会出现多出来的 pod 会与原有 pod 在同一个可用区。
上面的使用方式还有很多种,包括 node 级别的,详细请参考:https://kubernetes.io/docs/co…

由于云盘不能跨可用区挂载,如果有 pod 使用了存储卷,该 pod 需要被调度到与存储卷相同的可用区的机器上。
其他存储卷比如 NAS,OSS 是可以采用上述部署方式的。

本文作者:朱延生阅读原文
本文为云栖社区原创内容,未经允许不得转载。

正文完
 0