Kubernetes ClusterIP 服务初始延迟或活跃度答案

【问题标题】：Kubernetes ClusterIP service initial delay or livenessKubernetes ClusterIP 服务初始延迟或活跃度
【发布时间】：2019-12-18 17:29:06
【问题描述】：

我在 GCP 上有一个 Kubernetes 部署和一个 ClusterIP 服务来发现这个部署中的 pod。部署包含多个副本集 pod，它们根据我们的水平 pod 标量配置（基于 CPU 利用率）来来去去。

现在，当创建新的副本集 pod 时，应用程序需要一些时间才能开始服务。但是 ClusterIP 在应用准备好之前就已经开始向新的副本集 pod 分发请求，导致请求没有被服务。

ClusterIP 服务 yaml：

apiVersion: v1
kind: Service
metadata:
  labels:
    app: service-name
    tier: backend
    environment: "dev"
    creator: internal
  name: service-name
spec:
  clusterIP: None
  ports:
  - name: https
    protocol: TCP
    port: 7070
    targetPort: 7070
  selector:
    app: dep-name
    tier: "backend"
    environment: "dev"
    creator: "ME"
  type: ClusterIP

如何告诉 ClusterIP 在应用程序启动后开始向新 pod 分发请求？是否可以为此目的设置任何初始延迟或活性探测？

【问题讨论】：

标签： kubernetes google-cloud-platform

【解决方案1】：

Kubernetes 为其提供就绪探测。使用就绪探测，Kubernetes 不会在探测成功之前将流量发送到 Pod。更新部署时，它还将使旧副本保持运行，直到对新副本的探测成功。这意味着，如果您的新 pod 以某种方式损坏，它们将永远不会看到流量，您的旧 pod 将继续为部署提供所有流量。

您需要使用以下就绪探测更新部署文件：

readinessProbe:
  exec:
    command:
    - cat
    - /tmp/healthy
  initialDelaySeconds: 5
  periodSeconds: 5

如果您的应用程序有 http 探测，那么您也可以在 HTTP 模式下设置就绪探测。

有关如何使用就绪探针的更多信息，请参阅：

https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#define-readiness-probes

【讨论】：

【解决方案2】：

您应该有一个在文档中定义的就绪探测 https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#define-readiness-probes.

按照文档中的定义，您应该能够使用 initialDelaySeconds 和 periodSeconds 进行配置。

您当前的行为可能是因为服务负载均衡器已经看到 pod 中的所有容器都已启动。您可以像下面从文档中挑选的示例一样定义您的就绪检查。

kind: Pod
metadata:
  name: goproxy
  labels:
    app: goproxy
spec:
  containers:
  - name: goproxy
    image: k8s.gcr.io/goproxy:0.1
    ports:
    - containerPort: 8080
    readinessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10
    livenessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 20

【讨论】：