为每个节点分配特定数量的部署吊舱

Question

我有一个EKS节点组，其中有2个节点用于计算工作负载。我在这些节点上使用了污点，并在部署中使用了容忍度。我有一个带有2个副本的部署，我希望这两个pod像每个节点上的一个pod一样分布在这两个节点上。

我尝试使用：

affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 1
podAffinityTerm:
labelSelector:
matchExpressions:
- key: app
operator: In
values:
- appname

每个pod都放在每个节点上，但如果我像更改其映像名称一样更新部署文件，它将无法安排新的pod。

我也试过：

topologySpreadConstraints:
- maxSkew: 1
topologyKey: type
whenUnsatisfiable: DoNotSchedule
labelSelector:
matchLabels:
type: compute

但它们并不像一个节点上的两个吊舱那样均匀分布。

Answer 1

尝试添加：

spec:
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 0
maxUnavailable: 1

默认情况下，K8s在开始缩减旧复制副本之前，会先尝试扩展新的复制集。由于它无法安排新的副本(因为不具有关联性(，它们被困在挂起状态。

一旦您将部署的maxSurge设置为0，您就会告诉k8s，您不希望部署在更新期间首先扩大规模，因此它只能缩小规模，以便安排新的副本。

设置maxUnavailable=1告诉k8s一次只更换一个吊舱。

Answer 2

您可以使用DeamonSet而不是Deployment。DaemonSet确保所有(或一些(Nodes运行Pod的副本。随着节点被添加到集群中，Pod也被添加到其中。当节点从集群中移除时，这些Pod将被垃圾收集。删除DaemonSet将清理它创建的Pod。

参见Deamonset 的文档

Answer 3

我遇到了同样的问题，pods在推出新版本时无法调度，并陷入挂起状态，而我的目标是始终运行3个pods，3个可用节点中的每个节点上都有1个。

这意味着我不能使用maxUnavailable: 1，因为这将在推出期间暂时导致少于3个吊舱。

我没有使用应用程序名称标签来匹配反亲和性，而是在每次部署中使用了一个带有随机值("版本"(的标签。这意味着新的部署将愉快地将pod调度到以前版本仍在运行的节点，但新版本将始终均匀分布。

类似这样的东西：

apiVersion: apps/v1
kind: Deployment
spec:
replicas: 3
template:
metadata:
labels:
deploymentVersion: v1
spec:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: deploymentVersion
operator: In
values:
- v1
topologyKey: "kubernetes.io/hostname"

v1可以是任何有效标签，并且在每次部署尝试时都会更改。

我使用envsubst在yaml文件中拥有动态变量：

DEPLOYMENT_VERSION=$(date +%s) envsubst < deploy.yaml | kubectl apply -f -

然后配置看起来是这样的：

apiVersion: apps/v1
kind: Deployment
spec:
replicas: 3
template:
metadata:
labels:
deploymentVersion: v${DEPLOYMENT_VERSION}
spec:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: deploymentVersion
operator: In
values:
- v${DEPLOYMENT_VERSION}
topologyKey: "kubernetes.io/hostname"

我希望Kubernetes能提供一种更直接的方式来实现这一点。