使用Helm部署时groundnuty/k8s-wait-for作为init容器启动失败排查

问题根因排查与解决方案 #

• 第一个高频错误：缺少RBAC权限
  groundnuty/k8s-wait-for需要调用Kubernetes API查询Job运行状态，因此Pod绑定的ServiceAccount必须具备对应命名空间下jobs.batch资源的get、list、watch权限，缺少权限会直接导致容器异常退出。你可以先执行kubectl logs -n development <报错Pod名称> -c os-init查看init容器的具体运行日志，确认是否是权限报错。
  参考RBAC配置示例：

  apiVersion: rbac.authorization.k8s.io/v1
  kind: Role
  metadata:
    name: job-waiter-role
    namespace: development
  rules:
  - apiGroups: ["batch"]
    resources: ["jobs"]
    verbs: ["get", "list", "watch"]
  ---
  apiVersion: rbac.authorization.k8s.io/v1
  kind: RoleBinding
  metadata:
    name: job-waiter-binding
    namespace: development
  roleRef:
    apiGroup: rbac.authorization.k8s.io
    kind: Role
    name: job-waiter-role
  subjects:
  - kind: ServiceAccount
    name: <你的Deployment使用的ServiceAccount名称> # 默认是default
    namespace: development
  

• 第二个常见错误：跨命名空间找不到资源
  你的配置中Deployment的命名空间取值为{{ .Values.namespace }}，Job的命名空间取值为{{ .Values.migration.namespace }}，如果两个配置值不一致，init容器默认只会查询自身所在命名空间的Job，必然找不到目标资源。
  解决方案：在init容器的args中新增第三个参数指定Job所在的命名空间即可：

  args:
    - "job"
    - "{{ .Release.Name }}-os-server-migration-{{ .Release.Revision }}"
    - "{{ .Values.migration.namespace }}"
  

• 第三个问题：旧版本镜像兼容性问题
  你使用的v1.3版本镜像发布时间较早，对Kubernetes 1.21+之后正式启用的batch/v1版本Job API兼容性不佳，你可以升级镜像到最新稳定版本解决兼容性问题。
• 关于你提到的参数配置思路：你的理解是正确的，第二个参数必须和Job的metadata.name完全匹配，从你提供的kubectl查询结果来看，这部分的渲染结果符合要求，配置没有问题。

内容的提问来源于stack exchange，提问作者Miloš Stojanović