首页 文章

GKE Kubernetes节点池升级非常慢

提问于
浏览
1

我正在试验集群或 生产环境 集群上的6个节点(在两个节点池中)测试集群中进行GKE集群升级 . 升级时,我只有12个副本nginx部署,nginx入口控制器和cert-manager(作为helm图表)安装每个节点池需要10分钟(3个节点) . 我很满意 . 我决定再试一次看起来更像我们设置的东西 . 我删除了nginx部署并添加了2个node.js部署,以下是头盔图:mongodb-0.4.27,mcrouter-0.1.0(作为statefulset),redis-ha-2.0.0,以及我自己的www-redirect- 0.0.1图表(进行重定向的简单nginx) . 问题似乎与mcrouter有关 . 节点开始耗尽后,该节点的状态将更改为 Ready,SchedulingDisabled (这似乎正常),但仍保留以下窗格:

  • mcrouter-memcached-0

  • fluentd-gcp-v2.0.9-4f87t

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

我不知道为什么这两个kube系统吊舱仍然存在,但那个mcrouter是我的,并且它不会足够快 . 如果我等待足够长的时间(1小时),那么它最终会起作用,我不知道为什么 . 当前节点池(3个节点)在2h46分钟前开始升级,2个节点升级,第3个节点仍在升级,但没有任何动态......我认为它将在接下来的1-2个小时内完成...我试过了使用 --ignore-daemonsets --force 运行排水命令,但它告诉我它已经耗尽了 . 我试图删除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

2 回答

  • 0

    这是一个有点复杂的问题,我绝对不确定这是我的想法,但是......让我们试着去了解发生了什么 .

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

    排水过程本身尊重您的设置和副本数量 desired state 工作负载 higher priority 比节点本身的排放量多 .

    在排水过程中,Kubernetes将尝试在可用调度的资源上安排所有工作负载 . 要禁用系统要排空的节点,您可以在其状态中查看它 - Ready,SchedulingDisabled .

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

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

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

    我想如果你将 mcrouter-memcachedmcrouter-memcached 设置为4,它将解决一个问题 . 或者您可以尝试为该工作负载使用更强大的实例,或者向群集添加一个以上的节点,它也应该有所帮助 .

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

  • 2

    问题是来自PodDisruptionBudget的minAvailable值(它是memcached helm图表的一部分,它是mcrouter helm图表的依赖关系)和memcached复制集的replicas值的组合 . 两者都被设置为5,因此在排水期间没有一个被删除 . 我尝试将minAvailable更改为4但PDB are immutable at this time . 我做的是删除头盔图并替换它 .

    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
    

    完成后,我就可以让集群正常升级 .

    我应该做的(但之后只考虑它)是将副本值更改为6,这样我就不需要删除和替换整个图表 .

    谢谢@AntonKostenko试图帮我找到这个问题 . 这个issue也帮助了我 . 感谢Slack@Kubernetes中的人们,特别是巴黎人,他们试图让我的问题更具知名度,并且Kubernetes Office Hours的志愿者(恰好是yesterday,幸运的)我!)也看看 . 最后,感谢来自Kubernetes Canada的psycotica0也给了我一些指示 .

相关问题