Kubernetes postStart 似乎破坏了部署中的所有内容答案

【问题标题】：Kubernetes postStart seems to wreck shop for everything in deploymentKubernetes postStart 似乎破坏了部署中的所有内容
【发布时间】：2019-11-02 10:32:06
【问题描述】：

我们有以下部署yaml：

---
apiVersion: apps/v1beta2
kind: Deployment
metadata:
  name: {{DEP_ENVIRONMENT}}-{{SERVICE_NAME}}
  namespace: {{DEP_ENVIRONMENT}}
  labels:
    app: {{DEP_ENVIRONMENT}}-{{SERVICE_NAME}}
spec:
  replicas: {{NUM_REPLICAS}}
  selector:
    matchLabels:
      app: {{DEP_ENVIRONMENT}}-{{SERVICE_NAME}}
  template:
    metadata:
      labels:
        app: {{DEP_ENVIRONMENT}}-{{SERVICE_NAME}}
    spec:
      # [START volumes]
      volumes:
        - name: {{CLOUD_DB_INSTANCE_CREDENTIALS}}
          secret:
            secretName: {{CLOUD_DB_INSTANCE_CREDENTIALS}}
      # [END volumes]
      containers:
      # [START proxy_container]
      - name: cloudsql-proxy
        image: gcr.io/cloudsql-docker/gce-proxy:1.11
        command: ["/cloud_sql_proxy",
                  "-instances=<PROJECT_ID>:{{CLOUD_DB_CONN_INSTANCE}}=tcp:3306",
                  "-credential_file=/secrets/cloudsql/credentials.json"]
        # [START cloudsql_security_context]
        securityContext:
          runAsUser: 2  # non-root user
          allowPrivilegeEscalation: false
        # [END cloudsql_security_context]
        volumeMounts:
          - name: {{CLOUD_DB_INSTANCE_CREDENTIALS}}
            mountPath: /secrets/cloudsql
            readOnly: true
      # [END proxy_container]
      - name: {{DEP_ENVIRONMENT}}-{{SERVICE_NAME}}
        image: {{IMAGE_NAME}}
        ports:
        - containerPort: 80
        env:
        - name: CLOUD_DB_HOST
          value: 127.0.0.1
        - name: DEV_CLOUD_DB_USER
          valueFrom:
            secretKeyRef:
              name: {{CLOUD_DB_DB_CREDENTIALS}}
              key: username
        - name: DEV_CLOUD_DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: {{CLOUD_DB_DB_CREDENTIALS}}
              key: password
      # [END cloudsql_secrets]
        lifecycle:
          postStart:
            exec:
              command: ["/bin/sh", "-c", "supervisord"]

最后一个lifecycle 块是新的，导致数据库连接被拒绝。此配置在没有 lifecycle 块的情况下工作正常。我确信这里有一些我想念的愚蠢的东西，但我一生都无法弄清楚它是什么。

注意：我们只是尝试像这样启动 Supervisor 来解决尝试正常启动时出现的巨大问题。

【问题讨论】：

您好，钩子处理程序需要在完成阶段之后才能执行数据库连接。 supervisord 是否持续运行？
可以在容器的状态阶段查看处理程序的状态'kubectl get pods $POD -o yaml`
@SureshVishnoi Supervisord 将由该处理程序启动，然后从该点开始持续运行。我猜如果处理程序执行一个要运行的命令，那么对于生命周期处理程序来说，这不符合“完成”的条件？
> postStart 处理程序相对于容器的代码异步运行，但 Kubernetes 对容器的管理会阻塞，直到 postStart 处理程序完成。在 postStart 处理程序完成之前，容器的状态不会设置为 RUNNING，kubernetes.io/docs/tasks/configure-pod-container/…
是的，我认为它需要处于完成阶段，但是，supervisord 有什么意义？

标签： kubernetes dockerfile google-kubernetes-engine supervisord

【解决方案1】：

生命周期挂钩旨在成为简短的前台命令。您不能从它们启动后台守护程序，它必须是容器的主要 command。

【讨论】：