Kubernetes - 滚动更新杀掉老吊舱而不提出新吊舱

Question

我目前正在使用Deployments来管理我的K8S群集中的pod.

我的一些部署需要2个pod /副本,有些需要3个pod /副本,其中一些只需要1个pod /副本.我遇到的问题是有一个pod /副本的问题.

我的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应该调出新的pod,同时保持旧的pod工作,只有当新的pod已经准备好接收流量时,如果旧的pod被删除了.但我看到的是,旧的pod立即被删除并且新的pod已经创建,然后开始占用流量需要时间,这意味着我必须放弃流量.

# 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

这是我对调度程序如何达到您遇到的行为的"伪证明":

因为replicas: 1,k8s的所需状态恰好是一个Pod Ready.在滚动更新操作期间,这是您请求的策略,它将创建一个新的Pod,使总数达到2.但您授予k8s权限以使一个Pod处于不可用状态,并且您指示它保持所需的数量Pods为1.因此,它实现了所有这些约束:1个Pod,即所需的计数,处于不可用状态,由RU策略允许.

通过设置maxUnavailable为零,您正确地指示k8s永远不会让任何Pod不可用,即使这意味着replica在短时间内超过计数的飙升Pod