GKE Kubernetes节点池升级非常慢

我正在一个6节点（在两个节点池中）测试集群中试验GKE集群升级，然后在我们的登台或生产集群上进行试验。升级当我只有12个副本的nginx部署时，安装nginx入口控制器和cert管理器（如helm图表所示）需要每个节点池（3个节点）10分钟。我很满意。我决定用更像我们设置的东西再试一次。我删除了nginx部署并添加了2个node.js部署，以下是helm图表：mongodb-0.4.27、mcrouter-0.1.0（作为statefulset）、redis-ha-2.0.0和我自己的www-redirect-0.0.1图表（简单的nginx确实重定向）。问题似乎出在mcrouter上。一旦节点开始排水，该节点的状态将更改为

就绪，计划禁用

（这似乎正常），但仍保留以下POD：

• mcrouter-memcached-0
• fluentd-gcp-v2.0.9-4f87t
• kube-proxy-gke-test-upgrade-cluster-default-pool-74f8edac-wblf

我不知道为什么这两个kube系统吊舱还保留着，但那个mcrouter是我的，它不会运行得足够快。如果我等待足够长的时间（1小时以上），那么它最终会起作用，我不知道为什么。当前节点池（共3个节点）在2小时46分钟前开始升级，2个节点已升级，第3个节点仍在升级，但没有任何移动。。。我想它将在未来1-2小时内完成。。。 我试图用

--忽略守护进程--force

运行drain命令，但它告诉我它已经被排空了。 我试图删除pod，但它们只是返回，升级速度没有加快。 有什么想法吗

更新#1 mcrouter helm图表的安装方式如下：

helm install stable/mcrouter--name mcrouter--set controller=statefulset

它为mcrouter部件创建的状态集为：

apiVersion: apps/v1beta1
kind: StatefulSet
metadata:
  labels:
    app: mcrouter-mcrouter
    chart: mcrouter-0.1.0
    heritage: Tiller
    release: mcrouter
  name: mcrouter-mcrouter
spec:
  podManagementPolicy: OrderedReady
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: mcrouter-mcrouter
      chart: mcrouter-0.1.0
      heritage: Tiller
      release: mcrouter
  serviceName: mcrouter-mcrouter
  template:
    metadata:
      labels:
        app: mcrouter-mcrouter
        chart: mcrouter-0.1.0
        heritage: Tiller
        release: mcrouter
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchLabels:
                app: mcrouter-mcrouter
                release: mcrouter
            topologyKey: kubernetes.io/hostname
      containers:
      - args:
        - -p 5000
        - --config-file=/etc/mcrouter/config.json
        command:
        - mcrouter
        image: jphalip/mcrouter:0.36.0
        imagePullPolicy: IfNotPresent
        livenessProbe:
          failureThreshold: 3
          initialDelaySeconds: 30
          periodSeconds: 10
          successThreshold: 1
          tcpSocket:
            port: mcrouter-port
          timeoutSeconds: 5
        name: mcrouter-mcrouter
        ports:
        - containerPort: 5000
          name: mcrouter-port
          protocol: TCP
        readinessProbe:
          failureThreshold: 3
          initialDelaySeconds: 5
          periodSeconds: 10
          successThreshold: 1
          tcpSocket:
            port: mcrouter-port
          timeoutSeconds: 1
        resources:
          limits:
            cpu: 256m
            memory: 512Mi
          requests:
            cpu: 100m
            memory: 128Mi
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
        volumeMounts:
        - mountPath: /etc/mcrouter
          name: config
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30
      volumes:
      - configMap:
          defaultMode: 420
          name: mcrouter-mcrouter
        name: config
  updateStrategy:
    type: OnDelete

下面是memcached statefulset：

apiVersion: apps/v1beta1
kind: StatefulSet
metadata:
  labels:
    app: mcrouter-memcached
    chart: memcached-1.2.1
    heritage: Tiller
    release: mcrouter
  name: mcrouter-memcached
spec:
  podManagementPolicy: OrderedReady
  replicas: 5
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: mcrouter-memcached
      chart: memcached-1.2.1
      heritage: Tiller
      release: mcrouter
  serviceName: mcrouter-memcached
  template:
    metadata:
      labels:
        app: mcrouter-memcached
        chart: memcached-1.2.1
        heritage: Tiller
        release: mcrouter
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchLabels:
                app: mcrouter-memcached
                release: mcrouter
            topologyKey: kubernetes.io/hostname
      containers:
      - command:
        - memcached
        - -m 64
        - -o
        - modern
        - -v
        image: memcached:1.4.36-alpine
        imagePullPolicy: IfNotPresent
        livenessProbe:
          failureThreshold: 3
          initialDelaySeconds: 30
          periodSeconds: 10
          successThreshold: 1
          tcpSocket:
            port: memcache
          timeoutSeconds: 5
        name: mcrouter-memcached
        ports:
        - containerPort: 11211
          name: memcache
          protocol: TCP
        readinessProbe:
          failureThreshold: 3
          initialDelaySeconds: 5
          periodSeconds: 10
          successThreshold: 1
          tcpSocket:
            port: memcache
          timeoutSeconds: 1
        resources:
          requests:
            cpu: 50m
            memory: 64Mi
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30
  updateStrategy:
    type: OnDelete
status:
  replicas: 0

---

这是一个有点复杂的问题，我肯定不能确定这是我的想法，但。。。让我们试着了解发生了什么

您有一个升级过程，集群中有6个节点。系统将使用Drain逐个升级，以移除pod中的所有工作负载

根据您的设置和副本数量以及工作负载的所需状态，排出进程本身的优先级高于节点本身的排出

在流失过程中，Kubernetes将尝试在可用的资源上安排您的所有工作负载。系统要排出的节点上的调度已禁用，您可以看到它处于其状态-

就绪，调度已禁用

因此，Kubernetes调度器试图在所有可用节点上为您的工作负载找到合适的位置。只要需要将您描述的所有内容都放在集群配置中，它就会等待

现在最重要的是。您为

mcrouter memcached

设置了需要的

副本：5个。它不能在每个节点上运行多个复制副本，因为
podAntiAffinity
，并且运行它的节点应该有足够的资源，这是使用
resources:
块
ReplicaSet
计算的

因此，我认为您的集群没有足够的资源在剩余的5个节点上运行
mcrouter memcached
的新副本。例如，在最后一个节点上，由于其他工作负载的原因，该节点的副本仍然没有运行，因此内存不足

我认为，如果将
mcrouter memcached
的
replicaset
设置为4，就会解决问题。或者，您可以尝试为该工作负载使用更强大的实例，或者向集群添加一个节点，这也会有所帮助

希望我对我的逻辑做了足够的解释，如果你有什么不明白的，可以问我。但首先请尝试通过提供的解决方案解决一个问题：）
问题是来自PodDisruptionBudget的可用值（这是memcached helm图表的一部分，它是mcrouter helm图表的依赖项）和memcached replicaset的副本值的组合。两者都设置为5，因此在排放过程中无法删除它们。我试着把minAvailable改为4，但是。我所做的是移除头盔图表并替换它

helm delete --purge myproxy
helm install ./charts/mcrouter-0.1.0-croy.1.tgz --name myproxy --set controller=statefulset --set memcached.replicaCount=5 --set memcached.pdbMinAvailable=4

完成后，我就能够让集群正常升级

我应该做的（但只是在事后考虑）是将replicas值更改为6，这样我就不需要删除和替换整个图表

谢谢@AntonKostenko试图帮助我找到这个问题。
这也帮助了我。
多亏了巴黎的人们，特别是巴黎的人们，他们试图让我的问题更具知名度，还有巴黎的志愿者们（我很幸运！）也来看看。
最后，感谢您从中访问psycotica0，并给我一些建议。
您能分享
mcrouter-memcached-0
statefulset部署的配置吗？@AntonKostenko当然！我更新了上面的问题。谢谢你看：）你粘贴了2个StatefulSet，但把第二个标记为复制集：）@AntonKostenko掌舵图创建了2个StatefulSet，你要的是第二个，是的。谢谢：）@AntonKostenko哦，我明白你的意思了，我修正了我的问题！谢谢！：）啊,谢谢。这是一个非常清楚的解释，我会尝试你的建议，并在接受答案之前回复你。@roychri，现在可以了吗？你解决问题了吗？不幸的是，这没有帮助。我将副本从5个改为3个，但它仍然无法自行升级。我认为我的情况与此有关：您是从零开始更新过程，还是在当前工作期间更改了它？对于修复一个节点，您可以在更改副本后手动删除其中的POD。升级最终会通过，GKE在等待一个节点一个小时后强制执行。因此，我必须开始一个新的升级，因为上一个已经完成（b