Kubernetes中的三种探针：StartupProbe、ReadinessProbe和LivenessProbe，各自有不同的用途和优先级。
StartupProbe：用于检测应用是否成功启动和初始化。它会在Pod内程序完成所有必要的准备工作（如资源文件下载、数据库初始化等）后才会启动。启动探针会阻塞LivenessProbe和ReadinessProbe，直到它成功为止，成功后将不再进行探测
ReadinessProbe：用于检测容器是否准备好提供服务。如果检测失败，Service会将该Pod从endpoint列表中移除，防止流量转发到不可用的Pod上。就绪探针确保只有完全准备好的Pod才会接收流量，从而实现平滑的服务提供
LivenessProbe：用于检测容器是否存活。如果检测失败，Kubernetes会根据配置的重启策略决定是否重启容器。存活探针确保只有健康的容器才会继续运行，实现故障自愈
优先级和关系
优先级：由于StartupProbe在启动探针成功后不再进行探测，因此它不会影响LivenessProbe和ReadinessProbe的优先级。LivenessProbe和ReadinessProbe之间没有优先级关系，它们在StartupProbe成功后同时开始工作，任何一个失败都会触发相应的处理动作
关系：StartupProbe会阻塞LivenessProbe和ReadinessProbe，直到它成功为止。
Kubernetes 中的探针（Probes）用于检测容器的健康状态和生命周期状态。Kubernetes 提供了三种类型的探针：Liveness Probe、Readiness Probe 和 Startup Probe。每种探针都有其特定的使用场景。
- Liveness Probe
Liveness Probe 用于检测容器是否处于健康状态。如果探针失败，Kubernetes 会重新启动容器。
使用场景：
检测应用程序是否挂起：如果你的应用程序可能会在某些情况下挂起或进入死循环，Liveness Probe 可以帮助检测并重启该应用。
恢复不可恢复的错误状态：如果应用程序进入了一个不可恢复的错误状态（如内存泄漏导致的崩溃），Liveness Probe 可以通过重启容器来恢复应用。
示例：
apiVersion: v1
kind: Pod
metadata:
name: liveness-pod
spec:
containers:
- name: my-container
image: my-image
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 3
periodSeconds: 3
- Readiness Probe
Readiness Probe 用于检测容器是否已经准备好接受流量。如果探针失败，Kubernetes 会将该容器从服务的负载均衡池中移除。
使用场景：
初始化期间：在应用程序启动期间，可能需要进行一些初始化操作（如加载配置、建立数据库连接等）。Readiness Probe 确保在这些操作完成之前，流量不会被路由到该容器。
临时不可用状态：如果应用程序在运行过程中变得暂时不可用（如需要进行内部维护或重置），Readiness Probe 可以防止流量被路由到不可用的容器。
示例：
apiVersion: v1
kind: Pod
metadata:
name: readiness-pod
spec:
containers:
- name: my-container
image: my-image
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 5
periodSeconds: 5
- Startup Probe
Startup Probe 用于检测容器的启动状态。如果探针失败，Kubernetes 会重新启动容器。Startup Probe 专门用于检测容器的启动过程，与 Liveness Probe 和 Readiness Probe 不同，Startup Probe 只在容器启动时运行。
使用场景：
慢启动应用程序：对于启动时间较长的应用程序（如需要加载大量数据或进行复杂初始化的应用），Startup Probe 可以防止 Kubernetes 过早地认为容器启动失败并重启它。
复杂启动逻辑：如果应用程序在启动时需要执行复杂的逻辑，Startup Probe 可以确保这些逻辑在容器被认为已成功启动之前完成。
示例：
apiVersion: v1
kind: Pod
metadata:
name: startup-pod
spec:
containers:
- name: my-container
image: my-image
startupProbe:
httpGet:
path: /startup
port: 8080
initialDelaySeconds: 10
periodSeconds: 5
failureThreshold: 30
选择合适的探针
Liveness Probe：用于检测和恢复挂起或崩溃的容器。
Readiness Probe：用于确保只有准备好接收流量的容器才会被路由流量。
Startup Probe：用于检测启动时间较长或启动过程复杂的容器，确保它们在启动完成之前不会被过早地重启。
通过合理配置这三种探针，可以显著提高应用程序的稳定性和可靠性。
在 Kubernetes 中，容器的退出状态码（Exit Code）通常遵循 Unix/Linux 的标准退出码。以下是一些常见的退出状态码及其含义：
0: 正常退出。容器成功完成了其主要任务，并正常退出。
1: 一般错误。通常表示程序遇到了未处理的异常或错误。
2: 误用命令。命令行参数不正确或命令格式错误。
126: 命令不可执行。尝试执行的命令无法运行，可能因为权限问题。
127: 未找到命令。尝试执行的命令不存在。
128: 无效退出参数。通常是因为传递给 exit 命令的参数无效。
130: 通过 Ctrl+C（SIGINT）终止。用户手动中断程序执行。
137: 通过 SIGKILL 终止。通常是因为容器被系统强制终止，例如由于内存不足（OOM）。
139: 通过 SIGSEGV 终止。程序尝试访问非法内存地址，导致段错误（Segmentation Fault）。
143: 通过 SIGTERM 终止。通常是因为容器被正常终止，例如通过 kubectl delete pod。
这些退出状态码对诊断容器问题非常有用，因为它们可以帮助识别程序失败的原因。特别是在 Kubernetes 环境中，理解这些状态码可以帮助你更好地处理和调试 Pod 的问题。
