设置就绪、活跃度或启动探测
Setting up a readiness, liveness or startup probe
我很难理解哪个最适合我的情况以及如何实际实施它。
简而言之，问题是这样的：
- 我正在使用 Skaffold 加速我的 DB (Postgres)、BE (Django) 和 FE (React) 部署
- 大约 50% 的时间 BE 在 DB 之前启动
- Django 尝试做的第一件事就是连接到数据库
- 它只尝试一次（设计使然，无法更改），如果不能，则失败并破坏应用程序
- 因此，我需要确保每次启动我的部署时，DB 部署都是运行ning，然后再开始 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
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 不会有帮助，但如果我应该添加它们，请告诉我。
那么我做错了什么？
编辑：
因此，我根据 David Maze 的回复尝试了一些方法。这帮助我更好地了解发生了什么，但我仍然 运行 陷入我不太了解如何解决的问题。
第一个问题是，即使使用默认的 restartPolicy: Always，即使 Django 失败，Pods 本身也不会失败。 Pods 认为他们非常健康，即使 Django 失败了。
第二个问题显然是 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
所以很明显我设置的探测器是错误的，尽管它是一个 "super-easy" 实现（正如一些博客所描述的那样）。例如，/health 和 /healthz 路由：这些是内置在 Kubernetes 中还是需要设置？重新阅读文档以希望澄清这一点。
您只是等待的时间不够长。
您在此处显示的部署工件看起来很正常。如果您的应用程序无法访问数据库，那么它很快就会失败甚至是完全正常的，比如因为它还没有启动。不过，每个 pod 都有一个 restart policy，默认为 Always。所以，当 pod 出现故障时，Kubernetes 会重启它；当它再次失败时，它将再次重新启动；当它一直失败时，Kubernetes 将在重启之间暂停数十秒（可怕的 CrashLoopBackOff 状态）。
最终，如果您处于等待重启循环中，数据库实际上会启动，然后 Kubernetes 将重启您的应用程序 pods，此时应用程序将正常启动。
我在这里唯一要更改的是，您对这两个 pods 的就绪探测应该探测服务本身，而不是其他服务。您可能希望 path 类似于 / 或 /healthz 或其他服务中的实际 HTTP 请求路径。如果它检测到它的依赖项不可用，那可以 return 503 Service Unavailable ，或者你可以崩溃。崩溃就好了。
这是 Kubernetes 中完全正常的设置；没有办法更直接地说在服务 B 准备好之前 pod A 无法启动。另一方面，该模式实际上非常通用：如果您的应用程序崩溃并在无法访问其数据库时重新启动，那么数据库是否托管在集群外部，或者它是否在一段时间后崩溃都没有关系启动时间;相同的逻辑将尝试重新启动您的应用程序，直到它再次工作。
实际上，我想我可能已经解决了。
部分问题在于，即使 restartPolicy: Always 是默认设置，Pods 也不知道 Django 已失败，因此它认为它们是健康的。
我的想法是错误的，因为我最初认为我需要在开始 API 部署之前参考数据库部署以查看它是否已启动。相反，我需要检查 Django 是否失败并重新部署它。
为我完成以下操作：
livenessProbe:
tcpSocket:
port: 5000
initialDelaySeconds: 2
periodSeconds: 2
readinessProbe:
tcpSocket:
port: 5000
initialDelaySeconds: 2
periodSeconds: 2
我正在学习 Kubernetes，所以如果有更好的方法或者这是完全错误的，请指正我。我只知道它实现了我想要的。
我很难理解哪个最适合我的情况以及如何实际实施它。
简而言之，问题是这样的：
- 我正在使用 Skaffold 加速我的 DB (Postgres)、BE (Django) 和 FE (React) 部署
- 大约 50% 的时间 BE 在 DB 之前启动
- Django 尝试做的第一件事就是连接到数据库
- 它只尝试一次（设计使然，无法更改），如果不能，则失败并破坏应用程序
- 因此，我需要确保每次启动我的部署时，DB 部署都是运行ning，然后再开始 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
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 不会有帮助，但如果我应该添加它们，请告诉我。
那么我做错了什么？
编辑：
因此，我根据 David Maze 的回复尝试了一些方法。这帮助我更好地了解发生了什么，但我仍然 运行 陷入我不太了解如何解决的问题。
第一个问题是，即使使用默认的 restartPolicy: Always，即使 Django 失败，Pods 本身也不会失败。 Pods 认为他们非常健康，即使 Django 失败了。
第二个问题显然是 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
所以很明显我设置的探测器是错误的，尽管它是一个 "super-easy" 实现（正如一些博客所描述的那样）。例如，/health 和 /healthz 路由：这些是内置在 Kubernetes 中还是需要设置？重新阅读文档以希望澄清这一点。
您只是等待的时间不够长。
您在此处显示的部署工件看起来很正常。如果您的应用程序无法访问数据库，那么它很快就会失败甚至是完全正常的，比如因为它还没有启动。不过，每个 pod 都有一个 restart policy，默认为 Always。所以，当 pod 出现故障时，Kubernetes 会重启它；当它再次失败时，它将再次重新启动；当它一直失败时，Kubernetes 将在重启之间暂停数十秒（可怕的 CrashLoopBackOff 状态）。
最终，如果您处于等待重启循环中，数据库实际上会启动，然后 Kubernetes 将重启您的应用程序 pods，此时应用程序将正常启动。
我在这里唯一要更改的是，您对这两个 pods 的就绪探测应该探测服务本身，而不是其他服务。您可能希望 path 类似于 / 或 /healthz 或其他服务中的实际 HTTP 请求路径。如果它检测到它的依赖项不可用，那可以 return 503 Service Unavailable ，或者你可以崩溃。崩溃就好了。
这是 Kubernetes 中完全正常的设置；没有办法更直接地说在服务 B 准备好之前 pod A 无法启动。另一方面，该模式实际上非常通用：如果您的应用程序崩溃并在无法访问其数据库时重新启动，那么数据库是否托管在集群外部，或者它是否在一段时间后崩溃都没有关系启动时间;相同的逻辑将尝试重新启动您的应用程序，直到它再次工作。
实际上，我想我可能已经解决了。
部分问题在于，即使 restartPolicy: Always 是默认设置，Pods 也不知道 Django 已失败，因此它认为它们是健康的。
我的想法是错误的，因为我最初认为我需要在开始 API 部署之前参考数据库部署以查看它是否已启动。相反，我需要检查 Django 是否失败并重新部署它。
为我完成以下操作：
livenessProbe:
tcpSocket:
port: 5000
initialDelaySeconds: 2
periodSeconds: 2
readinessProbe:
tcpSocket:
port: 5000
initialDelaySeconds: 2
periodSeconds: 2
我正在学习 Kubernetes，所以如果有更好的方法或者这是完全错误的，请指正我。我只知道它实现了我想要的。