docker - 设置就绪、活跃度或启动探测

Question

我很难理解哪个最适合我的情况以及如何实际实现它。

简而言之，问题是这样的:

• 我正在使用 Skaffold 加速我的 DB (Postgres)、BE (Django) 和 FE (React) 部署
• 大约 50% 的时间 BE 在 DB 之前启动
• Django 尝试做的第一件事就是连接到数据库
• 它只尝试一次(设计使然，无法更改)，如果不能，则失败并且应用程序被破坏

---

• 因此，我需要确保每次启动部署时，DB 部署都在运行，然后再开始 BE 部署

我遇到了 readiness, liveness, and starup probes .我读了好几遍，就绪性探测听起来就像我需要的:我不希望 BE 部署在数据库部署准备好接受连接之前启动。

我想我不明白如何设置它。这是我尝试过的方法，但我仍然遇到一个先于另一个加载的情况。

postgres.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: postgres-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      component: postgres
  template:
    metadata:
      labels:
        component: postgres
    spec:
      containers:
        - name: postgres
          image: testappcontainers.azurecr.io/postgres
          ports:
            - containerPort: 5432
          env: 
            - name: POSTGRES_DB
              valueFrom:
                secretKeyRef:
                  name: testapp-secrets
                  key: PGDATABASE
            - name: POSTGRES_USER
              valueFrom:
                secretKeyRef:
                  name: testapp-secrets
                  key: PGUSER
            - name: POSTGRES_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: testapp-secrets
                  key: PGPASSWORD
            - name: POSTGRES_INITDB_ARGS
              value: "-A md5"
          volumeMounts:
            - name: postgres-storage
              mountPath: /var/lib/postgresql/data
              subPath: postgres
      volumes:
        - name: postgres-storage
          persistentVolumeClaim:
            claimName: postgres-storage
---
apiVersion: v1
kind: Service
metadata:
  name: postgres-cluster-ip-service
spec:
  type: ClusterIP
  selector:
    component: postgres
  ports:
    - port: 1423
      targetPort: 5432

api.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      component: api
  template:
    metadata:
      labels:
        component: api
    spec:
      containers:
        - name: api
          image: testappcontainers.azurecr.io/testapp-api
          ports:
            - containerPort: 5000
          env:
            - name: PGUSER
              valueFrom:
                secretKeyRef:
                  name: testapp-secrets
                  key: PGUSER
            - name: PGHOST
              value: postgres-cluster-ip-service
            - name: PGPORT
              value: "1423"
            - name: PGDATABASE
              valueFrom:
                secretKeyRef:
                  name: testapp-secrets
                  key: PGDATABASE
            - name: PGPASSWORD
              valueFrom:
                secretKeyRef:
                  name: testapp-secrets
                  key: PGPASSWORD
            - name: SECRET_KEY
              valueFrom:
                secretKeyRef:
                  name: testapp-secrets
                  key: SECRET_KEY
            - name: DEBUG
              valueFrom:
                secretKeyRef:
                  name: testapp-secrets
                  key: DEBUG
          readinessProbe:
            httpGet:
              host: postgres-cluster-ip-service
              port: 1423
            initialDelaySeconds: 10
            periodSeconds: 5
            timeoutSeconds: 2
---
apiVersion: v1
kind: Service
metadata:
  name: api-cluster-ip-service
spec:
  type: ClusterIP
  selector:
    component: api
  ports:
    - port: 5000
      targetPort: 5000

客户端.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: client-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      component: client
  template:
    metadata:
      labels:
        component: client
    spec:
      containers:
        - name: client
          image: testappcontainers.azurecr.io/testapp-client
          ports:
            - containerPort: 3000
          readinessProbe:
            httpGet:
              path: api-cluster-ip-service
              port: 5000
            initialDelaySeconds: 10
            periodSeconds: 5
            timeoutSeconds: 2
---
apiVersion: v1
kind: Service
metadata:
  name: client-cluster-ip-service
spec:
  type: ClusterIP
  selector:
    component: client
  ports:
    - port: 3000
      targetPort: 3000

我不认为 ingress.yaml 和 skaffold.yaml 会有帮助，但请告诉我是否应该添加它们。

那么我做错了什么？

---

编辑:

因此，我根据 David Maze 的回复尝试了一些方法。这有助于我更好地了解发生了什么，但我仍然遇到我不太了解如何解决的问题。

第一个问题是，即使使用默认的 restartPolicy: Always，即使 Django 失败，Pod 本身也不会失败。即使 Django 失败了，Pod 仍认为它们非常健康。

第二个问题显然是 Pod 需要知道 Django 的状态。这是我没有完全思考的部分，特别是探测器应该检查其他部署的状态还是检查它们自己的状态？

昨天我的想法是前者，但今天我的想法是后者:Pod 需要知道它包含的程序失败了。但是，我尝试过的所有方法都只会导致探测失败、连接被拒绝等:

# referring to itself
host: /health
port: 5000

host: /healthz
port: 5000

host: /api
port: 5000

host: /
port: 5000

host: /api-cluster-ip-service
port: 5000

host: /api-deployment
port: 5000

# referring to the DB deployment
host: /health
port: 1423 #or 5432

host: /healthz
port: 1423 #or 5432

host: /api
port: 1423 #or 5432

host: /
port: 1423 #or 5432

host: /postgres-cluster-ip-service
port: 1423 #or 5432

host: /postgres-deployment
port: 1423 #or 5432

很明显我设置的探测器是错误的，尽管它是一个“ super 简单”的实现(正如一些博客所描述的那样)。例如，/health 和 /healthz 路由:这些是内置在 Kubernetes 中还是需要设置？重新阅读文档以希望澄清这一点。

Answer 1

您只是等待的时间不够长。

您在此处显示的部署工件看起来很正常。如果您的应用程序无法访问数据库，那么它很快就会失败甚至是完全正常的，比如因为它还没有启动。每个 pod 都有一个 restart policy ，不过，它默认为 Always。所以，当 pod 出现故障时，Kubernetes 会重启它；当它再次失败时，它将再次重新启动；当它一直失败时，Kubernetes 将在重启之间暂停数十秒(可怕的 CrashLoopBackOff 状态)。

最终，如果您处于这个等待和重启循环中，数据库实际上会启动，然后 Kubernetes 将重启您的应用程序 pod，此时应用程序将正常启动。

我在这里唯一要更改的是，您对两个 pod 的就绪探测应该探测服务本身，而不是其他服务。您可能希望 path 类似于 / 或 /healthz 或服务中实际 HTTP 请求路径的其他内容。如果它检测到它的依赖项不可用，它可以返回 503 Service Unavailable，或者你可以直接崩溃。只是崩溃没关系。

这是 Kubernetes 中完全正常的设置；没有办法更直接地说在服务 B 准备好之前 pod A 无法启动。另一方面，该模式实际上非常通用:如果您的应用程序崩溃并在无法访问其数据库时重新启动，那么数据库是否托管在集群外部，或者它是否在一段时间后崩溃都没有关系启动时间;相同的逻辑将尝试重新启动您的应用程序，直到它再次工作。