GKE 在高负载期间忽略来自 pod 的就绪探测

问题描述

我有一个在 kubernetes 中运行的应用程序，在几个 Pod 上。我正在努力改善我们的部署体验（我们正在使用滚动部署），这目前正在造成痛苦。

我想要达到的目标：

• 每个 Pod 首先没有准备好，所以它没有更多的流量
• 然后它将完成当前正在处理的请求
• 然后它可以被删除

这一切都应该是可能的并且可以正常工作 - 您创建了一个包含就绪和活跃度探测器的部署。负载均衡器将选择这些并相应地路由流量。但是，当我测试我的部署时，即使切换到未准备好，我也会看到 pod 收到请求。具体来说，当有大量流量进入时，负载均衡器似乎不会更新。当我向它们发出信号时，我可以看到 pod“未准备好” - 如果它们在切换状态时没有获得流量，它们将不会之后接收流量。但是如果他们在切换时获得流量，负载均衡器就会忽略状态变化。

我开始想知道如何处理这个问题，因为我看不到我遗漏了什么 - 必须有可能在 Kubernetes 上托管一个高流量应用程序，而 pod“未准备好”而不会丢失大量请求.

我的配置

部署

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: my-service
  name: my-service
  namespace: mine
spec:
  replicas: 2
  selector:
    matchLabels:
      app: my-service
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      labels:
    app: my-service
    env: production
    spec:
      containers:
      - name: my-service
    image: IMAGE ID
    imagePullPolicy: Always
    volumeMounts:
    - name: credentials
      mountPath: "/run/credentials"
      readOnly: true
    securityContext:
      privileged: true
    ports:
    - containerPort: 8080
      protocol: TCP
    lifecycle:
      preStop:
        exec:
          command: ["/opt/app/bin/graceful-shutdown.sh"]
    readinessProbe:
      httpGet:
         path: /ready
         port: 8080
      periodSeconds: 1
      initialDelaySeconds: 5
      failureThreshold: 1
    livenessProbe:
      httpGet:
         path: /alive
         port: 8080
      periodSeconds: 1
      failureThreshold: 2
      initialDelaySeconds: 60
    resources:
      requests:
        memory: "500M"
        cpu: "250m"
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      terminationGracePeriodSeconds: 60
      nodeSelector:
    cloud.google.com/gke-nodepool: stateful

服务/负载均衡器

apiVersion: v1
kind: Service
metadata:
  name: stock-service-loadbalancer
  namespace: stock
spec:
  selector:
    app: stock-service
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: LoadBalancer

解决方法

结果证明这是一种效果或持久的连接，而不是流量。原因似乎是负载均衡器不会关闭打开的连接 - 对于我们的服务，我们使用的是使用长时间运行连接池的测试设置。因此，负载均衡器正在更新它的路由，但现有连接不断向终止 Pod 发送数据。

结果是这种零停机时间的策略确实有效：

• 使用 preStop 钩子使您的 pod 无法通过就绪探测
• 请务必等待几秒钟
• 然后让您的 Pod 通过 SIGTERM 优雅地终止
• 确保您的 terminateGracePeriodSeconds 足够大以涵盖 preStop 和实际终止期