如何确保Kubernetes CronJob在Cloud SQL Proxy就绪后启动容器

方法1：在业务容器启动命令中添加端口等待逻辑 #

直接修改业务容器的启动命令，先等待Cloud SQL Proxy监听的5432端口就绪，再执行应用的实际启动命令。这种方法无需额外镜像或组件，适配大多数场景。

修改后的CronJob配置片段：

containers:
- name: cloud-sql-proxy
  image: gcr.io/cloudsql-docker/gce-proxy:1.33.5
  command:
    - "/cloud_sql_proxy"
    - "-instances=taxiq-stage-app:europe-west3:taxiq-stage=tcp:5432"
  securityContext:
    runAsNonRoot: true
- name: taxiq-cronjob-reminder
  image: europe-west3-docker.pkg.dev/brantpoint-artifacts/taxiq/cronjob-reminder:beta09.7
  # 替换为带等待逻辑的启动命令
  command:
    - /bin/sh
    - -c
    - |
      # 使用bash原生方法检查端口，无需额外工具
      until timeout 1 bash -c "echo > /dev/tcp/127.0.0.1/5432"; do
        echo "等待Cloud SQL Proxy就绪，当前端口5432未连通..."
        sleep 2
      done
      # 执行你的应用实际启动命令，替换成容器原本的启动命令
      # 例如：npm start 或者 ./reminder-app
      your-application-start-command
  env:
    - name: PGURL
      valueFrom:
        secretKeyRef:
          name: secrets
          key: PGURL

注意事项： #

• 将your-application-start-command替换为容器原本的启动命令（比如镜像默认的npm start或二进制启动命令）。
• 若容器镜像不支持/dev/tcp（极少数情况），可改用预装netcat的镜像，用nc命令检查：

  until nc -z 127.0.0.1 5432; do
    echo "等待Cloud SQL Proxy就绪..."
    sleep 2
  done
  

方法2：新增init容器验证代理连通性 #

如果希望在业务容器启动前完全确保代理就绪，可以添加一个额外的init容器，专门检查5432端口的连通性，检查通过后才启动业务容器。

修改后的CronJob配置片段：

initContainers:
  - image: gcr.io/google.com/cloudsdktool/cloud-sdk:326.0.0-alpine
    name: workload-identity-initcontainer
    command:
      - '/bin/bash'
      - '-c'
      - "curl -s -H 'Metadata-Flavor: Google' 'http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/token' --retry 30 --retry-connrefused --retry-max-time 30 > /dev/null || exit 1"
  # 新增检查代理端口的init容器
  - image: alpine:3.18
    name: wait-for-sql-proxy
    command:
      - /bin/sh
      - -c
      - |
        until nc -z 127.0.0.1 5432; do
          echo "等待Cloud SQL Proxy就绪..."
          sleep 2
        done
containers:
# 保持原代理和业务容器配置不变
- name: cloud-sql-proxy
  ...
- name: taxiq-cronjob-reminder
  ...

注意事项： #

• 该init容器使用alpine镜像（自带nc工具），会在workload identity初始化完成后启动，持续重试直到代理的5432端口就绪。
• 由于sidecar容器和init容器并行启动，init容器会阻塞业务容器启动，直到代理完全就绪。

为什么不推荐readinessProbe？ #

readinessProbe仅用于告知Kubernetes容器是否就绪可接收流量，不会阻止容器启动。你的业务容器启动后会立即尝试连接数据库，此时代理可能还未就绪，因此readinessProbe无法解决启动时的连接拒绝问题，仅适用于运行中的状态标记，不符合当前场景需求。

内容的提问来源于stack exchange，提问作者code4God