设置就绪、活性或启动探针

Question

我很难理解哪种情况对我的情况是最好的，以及如何真正实现它。

简而言之，问题是：

• 我正在用Skaffold开发DB (Postgres)、BE (Django)和FE (React)部署
• 大约有50%的BE在DB之前出现。
• Django试图做的第一件事就是连接到DB。
• 它只尝试一次(通过设计，不能更改)，如果不能，它就会失败，应用程序也会中断。
• 因此，我需要确保每次我整理部署时，在启动BE部署之前，DB部署都在运行。

我偶然发现了准备好，有活力，和有活力的探针。我已经读过几次了，准备状态探测听起来就像我所需要的:在DB部署准备好接受连接之前，我不希望开始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

client.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会有帮助，但请告诉我是否应该添加这些内容。

那我在这里做错什么了？

编辑：

因此，我尝试了一些基于大卫·梅泽的回答的东西。这帮助我更好地理解了正在发生的事情，但我仍然遇到一些我不太了解如何解决的问题。

第一个问题是，即使使用默认的restartPolicy: Always，即使Django失败了，Pods本身也不会失败。虽然Django失败了，但是Pods认为他们是完全健康的。

第二个问题是，显然需要让Pods知道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中的还是需要设置这些路由？重读文档希望能澄清这一点。

Answer 1

实际上，我想我可能已经解决了。

部分问题是，尽管restartPolicy: Always是默认的，但是Pods并不知道Django失败了，所以它认为它们是健康的。

我的想法是错误的，因为我最初假设我需要参考DB部署，看看它在启动API部署之前是否已经启动。相反，我需要检查Django是否失败并重新部署它。

为我做了以下工作：

livenessProbe:
  tcpSocket:
    port: 5000
  initialDelaySeconds: 2
  periodSeconds: 2
readinessProbe:
  tcpSocket:
    port: 5000
  initialDelaySeconds: 2
  periodSeconds: 2

我正在学习Kubernetes，所以如果有更好的方法来做这件事，或者这是完全错误的，请纠正我。我只知道它能实现我想要的。

Answer 2

你只是等待得不够久。

您在这里显示的部署工件看起来非常正常。如果应用程序无法到达数据库，那么它甚至是完全正常的，因为它还没有启动。不过，每个pod都有一个重新启动策略，它默认为Always。因此，当吊舱失败时，Kubernetes将重新启动它；当它再次失败时，它将再次重新启动；当它继续失败时，Kubernetes将在重启之间暂停数十秒(可怕的CrashLoopBackOff状态)。

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

我在这里要做的唯一改变是，您对这两个吊舱的准备状态探测应该是探测服务本身，而不是其他服务。您可能希望path类似于/或/healthz，或者是服务中的实际HTTP请求路径。这可以返回503服务不可用，如果它检测到它的依赖是不可用的，或者你可以只是崩溃。只是撞车就行了。

在Kubernetes中，这是一个完全正常的设置；没有办法更直接地说，在B服务准备好之前，荚A无法启动。另一方面，这种模式实际上是相当通用的:如果应用程序在无法到达其数据库时崩溃并重新启动，那么数据库是否驻留在集群之外，或者在启动后某个时候崩溃并不重要；相同的逻辑将尝试重新启动应用程序，直到它再次工作为止。