Kubernetes postStart 生命周期总是失败答案

【问题标题】：Kubernetes postStart lifecycle always failingKubernetes postStart 生命周期总是失败
【发布时间】：2021-09-27 22:38:06
【问题描述】：

尝试使用 postStart 生命周期解决 pod 之间的依赖关系。

用例：微服务A应该在微服务B启动后启动。

为此，我们添加了一个容器（curl），它将使用 curl 命令检查相关服务是否已启动。

但是当我们在 postStart 生命周期钩子中添加任何命令时，Pod 会不断重启并进入 crashlookbackoff 状态

部署.yaml：

kind: Deployment
metadata:
 name: Microservice-A-deployment
spec:
 replicas: 1
 selector:
   matchLabels:
     app: Microservice-A
 template:
   metadata:
     labels:
       app: Microservice-A
       date: 20thJune2021
     annotations:
       sidecar.istio.io/rewriteAppHTTPProbers: "false"
       proxy.istio.io/config: '{ "holdApplicationUntilProxyStarts": true }'
   spec:
     containers:
       - name: curl
         image: ewoutp/docker-nginx-curl
         imagePullPolicy: IfNotPresent
         command: [ 'sh', '-c', 'touch /tmp/healthy; echo The Pod is running && sleep 50' ]
         livenessProbe:
           exec:
             command:
               - cat
               - /tmp/healthy
           initialDelaySeconds: 15
           periodSeconds: 5
         lifecycle:
           postStart:
             exec:
               command: [ "/bin/sh", "-c", 'sleep 10;until [ $(eval curl -o -I -L -s -w "%{http_code}" http://microservice-B-api-service:9439/manage/health) -eq 200 ]; do echo "Waiting for microservice-B API";sleep 10;  done; exit 0' ]
       - name: Microservice-A
         image: microserviceA:latest
         imagePullPolicy: Always
         ports:[![enter image description here][1]][1]
           - name: port
             containerPort: 8080
         livenessProbe:
           httpGet:
             path: /actuator/health
             port: 8080
           initialDelaySeconds: 120
           periodSeconds: 30
           timeoutSeconds: 30
     imagePullSecrets:
       - name: dockersecret

注意：不使用 init-container 的原因：因为我们已经使用严格的 MTLS 策略实现了 Istio。 https://github.com/istio/istio/issues/32039

在互联网上搜索此问题时在下面找到。

【问题讨论】：

希望微服务的端口是开放的，并且在同一个命名空间中，如果可能的话，请分享更多关于服务端口配置的细节，或者验证一个它是正确的。
服务端口正确。我检查了那个。如果您在重启后挂钩中添加一个简单的睡眠语句，它也会继续重启。
为什么要使用多个容器？理想情况下，您还可以使现有单个应用程序的一部分仅在映像中需要 curl ，并且一旦执行生命周期挂钩并且 curl 获得 200 响应，您的主容器就会启动。
@HarshManvar 不是健康检查。我们正在为具有严格 MTLS 的 Istio 寻找 init-container 的替代解决方案
如果你想在微服务 B 启动后启动容器......将你的生命周期钩子添加到微服务 A 容器中，它只会在你从微服务 B 获得 200 res 时启动。

标签： kubernetes istio istio-sidecar mtls istio-gateway

【解决方案1】：

这是因为您在 postStart 中的命令休眠了 10 秒，而您的 LivenessProbe 配置为在 5 秒后失败。

可能增加initialDelaySeconds 或添加failureThreshold。

【讨论】：

移除 LivenessProbe 并将 initialDelaySeconds 增加到 15 秒后出现同样的错误
嗯，正如Paul linchpiner 所述（在本文档的底部），Kubernetes 似乎正在并行执行容器。 Init-Containers 将按顺序执行并且仅在成功时执行，但您已经说过您的环境不允许 init-containers..

【解决方案2】：

您也可以像这样将 readinessProbe 与 livenessProbe 一起使用：

        readinessProbe:
            httpGet:
                path: /api/health
                port: 8080
        initialDelaySeconds: 10
        periodSeconds: 5
        failureThreshold: 8

        // for tcpSocket use:
            readinessProbe:
                tcpSocket:
                    port: 3306

【讨论】：