库伯奈特斯-滚动更新杀死旧豆荚而不提新的。

Question

我目前正在使用部署来管理我的K8S集群中的吊舱。

我的一些部署需要2个豆荚/副本，有些需要3个豆荚/副本，有些只需要1个荚/副本。我遇到的问题是有一个豆荚/复制品。

我的YAML文件是：

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: user-management-backend-deployment
spec:
  replicas: 1
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 2
  selector:
    matchLabels:
      name: user-management-backend
  template:
    metadata:
      labels:
        name: user-management-backend
    spec:
      containers:
      - name: user-management-backend
        image: proj_csdp/user-management_backend:3.1.8
        imagePullPolicy: IfNotPresent
        ports:
          - containerPort: 8080
        livenessProbe:
          httpGet:
            port: 8080
            path: /user_management/health
          initialDelaySeconds: 300
          timeoutSeconds: 30
        readinessProbe:
          httpGet:
            port: 8080
            path: /user_management/health
          initialDelaySeconds: 10
          timeoutSeconds: 5
        volumeMounts:
          - name: nfs
            mountPath: "/vault"
      volumes:
        - name: nfs
          nfs:
            server: kube-nfs
            path: "/kubenfs/vault"
            readOnly: true

我有一个旧的版本运行良好。

# kubectl get po | grep  user-management-backend-deployment
user-management-backend-deployment-3264073543-mrrvl               1/1       Running        0          4d

现在我想更新图片：

# kubectl set image deployment  user-management-backend-deployment  user-management-backend=proj_csdp/user-management_backend:3.2.0

现在按照RollingUpdate的设计，K8S应该在保持旧吊舱工作的同时打开新的吊舱，并且只有在新吊舱准备就绪后，如果旧吊舱被删除的话，就应该打开新的吊舱。但我看到的是，旧吊舱被立即删除，新吊舱被创建，然后它需要时间开始接受流量，这意味着我必须减少流量。

# kubectl get po | grep  user-management-backend-deployment
user-management-backend-deployment-3264073543-l93m9               0/1       ContainerCreating   0          1s

# kubectl get po | grep  user-management-backend-deployment
user-management-backend-deployment-3264073543-l93m9               1/1       Running            0          33s

我使用过maxSurge: 2 & maxUnavailable: 1，但这似乎不起作用。

有什么想法吗?为什么这不起作用？

Answer 1

它似乎是maxUnavailable: 1；我能够将您的经验设置为maxUnavailable: 0，并通过将其设置为maxUnavailable: 0来获得正确的体验。

下面是我对调度程序如何到达您正在体验的行为的“伪验证”：

因为replicas: 1，k8s的期望状态正是Ready中的一个Pod。在滚动更新操作(您所请求的策略)期间，它将创建一个新的Pod，使总数达到2。但是您授予了k8s将一个Pod保持在不可用状态的权限，并指示它将所需的Pod数量保持在1。因此，它满足了所有这些限制:1 Pod，在不可用状态下的所需计数，这是R策略所允许的。

通过将maxUnavailable设置为零，您可以正确地指示k8s不要让任何Pod不可用，即使这意味着在短时间内将Pods超过replica计数。

Answer 2

将策略类型设置为RollingUpdate后，就会在删除旧的pod之前创建一个新的pod，即使只有一个副本。策略类型Recreate在创建新豆荚之前先杀死旧豆荚

Answer 3

如前所述，您可以将maxUnavailable设置为0以实现所需的结果。几个额外的笔记：

1. 当您使用一个有状态服务来挂载一个特定的卷时，您不应该期望它能够工作，该卷将由新的pod使用。体积将连接到即将被取代的吊舱，因此将无法连接到新的吊舱。
2. 文档指出，如果将.spec.strategy.rollingUpdate.maxSurge设置为0，则不能将其设置为0。

https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#max-unavailable