如何实现两个依赖Deployment的滚动更新及有序初始化？

嘿，这个场景我之前在团队部署服务时碰到过，核心就是要在两个Deployment之间建立明确的启动依赖，同时保证滚动更新时的顺序也符合预期。下面一步步拆解可行的实现方案：

要让后端等LDAP初始化完成再启动，得靠Readiness探针+Init容器的组合：

• 给LDAP配置Readiness Probe，让K8s识别其就绪状态
  首先得让K8s准确知道LDAP真的准备好提供服务了——不能Pod刚启动就标记为就绪，毕竟LDAP初始化可能需要一点时间。给LDAP的Deployment加个Readiness Probe，用ldapsearch命令验证服务是否正常响应：

  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: ldap-deployment
  spec:
    replicas: 1
    selector:
      matchLabels:
        app: ldap
    template:
      metadata:
        labels:
          app: ldap
      spec:
        containers:
        - name: ldap
          image: openldap:latest
          ports:
          - containerPort: 389
          readinessProbe:
            exec:
              command: ["ldapsearch", "-x", "-b", "dc=example,dc=org", "-s", "base", "(objectClass=*)"]
            initialDelaySeconds: 10  # 给LDAP留足启动初始化时间
            periodSeconds: 5         # 每隔5秒检查一次
  

  只有当这个探针执行成功，K8s才会把LDAP Pod标记为就绪，并加入对应的Service端点。

• 给后端Deployment加Init容器，等待LDAP就绪
  后端启动前，先跑一个Init容器，一直检查LDAP的Service是否有就绪的端点（本质是等LDAP的Readiness探针通过）。用busybox的nc命令做端口连通检查就行：

  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: backend-deployment
  spec:
    replicas: 2
    selector:
      matchLabels:
        app: backend
    template:
      metadata:
        labels:
          app: backend
      spec:
        initContainers:
        - name: wait-for-ldap
          image: busybox:latest
          # 循环检查LDAP Service的389端口，连通成功才退出
          command: ['sh', '-c', 'until nc -z ldap-service 389; do echo waiting for ldap; sleep 2; done;']
        containers:
        - name: backend
          image: your-backend-image:latest
          ports:
          - containerPort: 8080
          readinessProbe:
            httpGet:
              path: /health
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 3
  

  这里的ldap-service是你给LDAP Deployment创建的Service名称，Init容器会一直阻塞到LDAP就绪，才会启动后端容器。

滚动更新时要先更LDAP，等LDAP完全就绪后再更后端，有两种实用方式：

1. 手动控制更新顺序（原生K8s即可实现）

   • 先更新LDAP Deployment：

     kubectl set image deployment/ldap-deployment ldap=openldap:new-version
     

   • 等待LDAP更新完成就绪（这条命令会一直阻塞到状态正常）：

     kubectl rollout status deployment/ldap-deployment
     

   • 再更新后端Deployment：

     kubectl set image deployment/backend-deployment backend=your-backend-image:new-version
     

2. 用Helm钩子实现自动化更新
   如果用Helm管理部署，可以通过钩子（Hook）的权重控制执行顺序：

   • 给LDAP的Deployment加注解，设置为先执行的钩子：

     annotations:
       "helm.sh/hook": post-install, post-upgrade
       "helm.sh/hook-weight": "1"  # 权重越小越先执行
       "helm.sh/hook-delete-policy": hook-succeeded
     

   • 给后端的Deployment加注解，设置为后执行的钩子：

     annotations:
       "helm.sh/hook": post-install, post-upgrade
       "helm.sh/hook-weight": "2"
     

   Helm会严格按照权重顺序执行，只有LDAP更新完成后，才会启动后端的更新。

• 给两个Deployment都配置Liveness Probe：比如LDAP的Liveness Probe可以复用Readiness的ldapsearch命令，后端用健康检查接口，确保服务运行异常时自动重启Pod。
• 单副本LDAP的滚动更新策略设置为maxSurge: 0、maxUnavailable: 0：避免更新时LDAP服务中断；后端可以用默认的滚动更新策略（比如maxSurge=25%、maxUnavailable=25%），保证服务不中断。

内容的提问来源于stack exchange，提问作者Сергей Татунов