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＆amp; maxUnavailable: 1但这似乎不起作用。

任何想法为什么这不起作用？

Answer 1

似乎是maxUnavailable: 1;我能够轻松地重现您设置该值的体验，并通过将其设置为maxUnavailable: 0

来轻松获得正确的体验

这是我的＆＃34;伪证明＆＃34;调度程序如何达到您遇到的行为：

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

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

Answer 2

如前所述，您可以将maxUnavailable设置为0以获得所需的结果。一些额外的说明：

在使用安装新pod要使用的单个特定卷的有状态服务时，您不应期望这样做。该卷将附加到即将更换的吊舱上，因此无法连接到新吊舱。
文档指出，如果已将.spec.strategy.rollingUpdate.maxSurge设置为0，则无法将其设置为0.

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

Answer 3

将策略类型设置为RollingUpdate的

，即使删除了一个副本，也将在删除旧pod之前创建一个新pod。策略类型Recreate在创建新吊舱之前先杀死旧吊舱 https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment

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

3 个答案: