kubernetes - GKE Kubernetes节点池升级非常慢

Question

我先在6个节点(在两个节点池中)的测试群集中尝试GKE群集升级，然后再在暂存或生产群集中尝试。当我只有12个副本nginx部署时进行升级时，每个节点池(3个节点)安装的nginx入口 Controller 和cert-manager(如 Helm 图)花费了10分钟。我感到非常满意。我决定尝试使用更像我们的设置的东西。我删除了nginx部署，并添加了2个node.js部署，以下掌 Helm chart :mongodb-0.4.27，mcrouter-0.1.0(作为状态集)，redis-ha-2.0.0和我自己的www-redirect- 0.0.1图表(执行重定向的简单nginx)。问题似乎出在微电脑上。一旦节点开始排空，该节点的状态将更改为Ready,SchedulingDisabled(这看起来很正常)，但以下 Pane 仍然存在:

mcrouter-memcached-0

fluentd-gcp-v2.0.9-4f87t

kube-proxy-gke-test-upgrade-cluster-default-pool-74f8edac-wblf

我不知道为什么仍然保留了这两个kube系统 pods ，但是那个微型计算机是我的，并且运行得不够快。如果我等待足够长的时间(超过1小时)，那么它最终会起作用，我不确定为什么。当前的节点池(共3个节点)在2h46分钟前开始升级，并且2个节点已升级，第3个节点池仍在升级，但什么都没有动...我想它将在接下来的1-2小时内完成...
我尝试使用 --ignore-daemonsets --force运行排水命令，但它告诉我它已经被排水了。
我尝试删除 pods ，但它们只是回来了，因此升级速度不会更快。
有什么想法吗？

更新＃1

mcrouter掌 Helm 表的安装如下:
helm install stable/mcrouter --name mcrouter --set controller=statefulset
它为微机部分创建的有状态集是:

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

Answer 1

这是一个有点复杂的问题，我绝对不确定这是我的想法，但是...让我们尝试了解正在发生的事情。

您有一个升级过程，并且集群中有6个节点。系统将使用Drain逐个升级它，以从Pod中删除所有工作负载。

排空过程本身会尊重您的设置和副本数，并且所需的工作负载状态的优先级高于节点本身的排空。

在耗尽过程中，Kubernetes将尝试在可用调度的资源上调度所有工作负载。在要耗尽系统的节点上禁用调度时，您可以在其状态Ready,SchedulingDisabled中看到它。

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

现在最重要的是。您设置为replicas: 5需要mcrouter-memcached。由于存在podAntiAffinity，它不能在每个节点上运行多个副本，并且要运行该节点的节点应具有足够的资源，这是使用resources:的ReplicaSet块计算得出的。

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

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

希望我对我的逻辑给出足够的解释，问我是否不清楚。但首先请尝试通过提供的解决方案解决问题:)