时间戳

首页 > 解决方案 > 设置就绪、活跃度或启动探测

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

问题描述

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

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

我遇到了readiness、liveness 和 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 的回应尝试了一些方法。这有助于我更好地了解正在发生的事情，但我仍然遇到一些我不太了解如何解决的问题。

第一个问题是，即使使用 default 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

所以显然我设置了错误的探针，尽管它是一个“超级简单”的实现（正如一些博客所描述的那样）。例如，/health和/healthz路由：这些是内置在 Kubernetes 中还是需要设置？重读文档以希望澄清这一点。

标签： dockerkubernetesskaffoldreadinessprobe

解决方案

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

您在此处显示的部署工件看起来很正常。如果您的应用程序无法访问数据库，例如因为它还没有启动，那么它快速失败甚至是完全正常的。但是，每个 pod 都有一个重启策略，默认为Always. 所以，当 pod 发生故障时，Kubernetes 会重新启动它；当它再次失败时，它将再次重新启动；当它持续失败时，Kubernetes 将在重启之间暂停数十秒（可怕的CrashLoopBackOff状态）。

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

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

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

推荐阅读