在 Kubernetes 中，`readiness`、`startup` 和 `liveness` 探針可以同時定義，并且它們的生命周期和作用是不同的。以下是它們的詳細區別和生命周期：

---

### 1. **Readiness Probe**
- **作用**: 用于判斷容器是否已經準備好接收流量。
- **生命周期**: 
  - 當容器啟動后，Kubernetes 會定期執行 `readiness` 探針。
  - 如果探針失敗，容器會被標記為 "Not Ready"，并且不會接收流量（例如，Service 不會將流量路由到該容器）。
  - 如果探針成功，容器會被標記為 "Ready"，并開始接收流量。
- **典型場景**:
  - 應用需要一些初始化操作（例如加載配置文件或建立數據庫連接）才能正常工作。
  - 確保流量只發送到已經準備好的容器。

---

### 2. **Startup Probe**
- **作用**: 用于判斷容器是否已經成功啟動。
- **生命周期**:
  - `startup` 探針主要用于檢測容器的啟動過程是否完成。
  - 在 `startup` 探針定義的情況下，`liveness` 探針會被延遲執行，直到 `startup` 探針成功。
  - 如果 `startup` 探針失敗，容器會被認為啟動失敗，并被重啟。
  - 一旦 `startup` 探針成功，Kubernetes 不會再執行它。
- **典型場景**:
  - 應用啟動時間較長，可能需要執行復雜的初始化操作。
  - 避免在啟動過程中觸發 `liveness` 探針導致容器被錯誤地重啟。

---

### 3. **Liveness Probe**
- **作用**: 用于判斷容器是否仍然處于健康狀態。
- **生命周期**:
  - 當容器啟動后，Kubernetes 會定期執行 `liveness` 探針。
  - 如果探針失敗，容器會被認為已經崩潰或進入不可恢復的狀態，并被重啟。
- **典型場景**:
  - 應用可能會因為內部錯誤進入不可恢復的狀態。
  - 確保容器在出現問題時能夠自動恢復。

---

### 生命周期的關系
- 如果定義了 `startup` 探針，`liveness` 探針會被延遲執行，直到 `startup` 探針成功。
- `readiness` 探針和 `startup` 探針可以同時定義，但它們的作用不同：
  - `startup` 探針用于判斷容器是否啟動完成。
  - `readiness` 探針用于判斷容器是否準備好接收流量。
- 如果沒有定義 `startup` 探針，`liveness` 探針會在容器啟動后立即開始執行。

---

### 其他區別
| **探針類型** | **失敗后行為** | **成功后行為** | **主要用途** |
|--------------|----------------|----------------|--------------|
| `readiness`  | 容器被標記為 "Not Ready"，停止接收流量 | 容器被標記為 "Ready"，開始接收流量 | 控制流量路由 |
| `startup`    | 容器被重啟 | 探針停止執行 | 確保容器啟動完成 |
| `liveness`   | 容器被重啟 | 探針繼續執行 | 檢測容器健康狀態 |

Kubernetes uses health checks to ensure the availability and reliability of applications running within containers. These health checks continuously monitor the health status of containers and allow Kubernetes to take appropriate actions if an application becomes unresponsive or enters an unhealthy state.

The three types of health checks supported by Kubernetes are:

1. Liveness Probes

Liveness probes are responsible for determining whether a container is alive and running as expected. They help detect scenarios where an application is running, but it may not be able to handle requests correctly due to internal issues.

For instance, if the application is stuck in an infinite loop or suffering from a deadlock, a liveness probe can identify this condition and trigger a container restart to recover the application's functionality.

To implement a liveness probe, you define a periodic check that sends requests to a specified endpoint within the container. If the probe receives a successful response (HTTP status code 200-399) from the endpoint, the container is considered healthy.

However, if the probe does not receive a successful response within a predefined timeframe, the container is marked as unhealthy, prompting Kubernetes to take appropriate action based on the container's restart policy.

2. Readiness Probes

Readiness probes focus on determining whether a container is ready to handle incoming requests. They are particularly useful during the startup phase of an application when it needs some time to initialize and become fully operational.

Until the readiness probe indicates that the container is ready, Kubernetes will not send traffic to that particular pod.

Like liveness probes, readiness probes involve sending requests to a specified endpoint or executing a command within the container. If the probe receives a successful response, the container is marked as ready to receive traffic.

Conversely, if the probe fails to receive a successful response within a defined time period, the container is considered not ready, and Kubernetes removes it from the list of endpoints for the associated service, effectively stopping traffic to that container.

3. Startup Probes

Startup probes are a more recent addition to Kubernetes health checks. Their primary purpose is to determine when an application has started successfully during its startup phase.

The key difference between startup probes and readiness probes is that while a readiness probe starts as soon as the container begins running, a startup probe can be delayed, allowing the application more time to initialize.

Startup probes prove beneficial for applications that may take longer to start or need to perform time-consuming initialization tasks.

By utilizing a startup probe, you can ensure that Kubernetes only considers the container as ready when the application has successfully completed its startup process.

Kubernetes Liveness Probe Settings

Understanding the settings of a liveness probe in Kubernetes is crucial for effectively monitoring the health of your containers. The liveness probe configuration includes the following settings:

1. initialDelaySeconds: The number of seconds to wait before the first liveness probe is performed after the container starts.
2. periodSeconds: The number of seconds between consecutive liveness probes.
3. timeoutSeconds: The number of seconds after which the liveness probe times out. If the probe takes longer than this value to return, it is considered a failure.
4. successThreshold: The minimum number of consecutive successful probe results required to mark the container as healthy after having previously failed.
5. failureThreshold: The number of consecutive probe failures required to mark the container as unhealthy after having previously been healthy.
6. terminationGracePeriodSeconds: Defines the amount of time the kubelet (the Kubernetes node agent) should wait between triggering the shutdown of a failed container and forcefully terminating it. This period allows the container some time to clean up and terminate gracefully.

Other Liveness Probe Settings

1. Type (httpGet, tcpSocket, or exec)

• httpGet: Performs an HTTP GET request to a specified endpoint in the container. The probe considers the container healthy if it receives a successful HTTP response code (2xx or 3xx).
• tcpSocket: Attempts to open a TCP connection to a specified port on the container. The probe considers the container healthy if the connection is successful.
• exec: Executes a specified command inside the container. The probe considers the container healthy if the command exits with a success status code (0).

2. HTTP GET Probe Settings (if applicable)

• path: The URL path for the HTTP GET request. For example, /healthz.
• port: The port on which the HTTP server is listening inside the container.
• httpHeaders: Optional custom HTTP headers to include in the GET request.

3. TCP Socket Probe Settings (if applicable)

• port: The port to which the TCP socket should attempt to connect inside the container.

4. Exec Probe Settings (if applicable)

• command: The command to be executed inside the container. It should be specified as a list of strings.

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
    - name: my-app-container
      image: my-app-image
      ports:
        - containerPort: 8080
      livenessProbe:
        httpGet:
          path: /healthz
          port: 8080
          httpHeaders:
            - name: Custom-Header-1
              value: Value-1
            - name: Custom-Header-2
              value: Value-2
        initialDelaySeconds: 15
        periodSeconds: 10

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
    - name: my-app-container
      image: my-app-image
      ports:
        - containerPort: 8080
      livenessProbe:
        exec:
          command:
            - sh
            - -c
            - curl -sS http://localhost:8080/healthz || exit 1
        initialDelaySeconds: 15
        periodSeconds: 10

Protect slow starting containers with startup probes

Sometimes, you have to deal with applications that require additional startup time on their first initialization. In such cases, it can be tricky to set up liveness probe parameters without compromising the fast response to deadlocks that motivated such a probe. The solution is to set up a startup probe with the same command, HTTP or TCP check, with a failureThreshold * periodSeconds long enough to cover the worst case startup time.

So, the previous example would become:

ports:
- name: liveness-port
  containerPort: 8080

livenessProbe:
  httpGet:
    path: /healthz
    port: liveness-port
  failureThreshold: 1
  periodSeconds: 10

startupProbe:
  httpGet:
    path: /healthz
    port: liveness-port
  failureThreshold: 30
  periodSeconds: 10

Thanks to the startup probe, the application will have a maximum of 5 minutes (30 * 10 = 300s) to finish its startup. Once the startup probe has succeeded once, the liveness probe takes over to provide a fast response to container deadlocks. If the startup probe never succeeds, the container is killed after 300s and subject to the pod's restartPolicy.

Define readiness probes

Sometimes, applications are temporarily unable to serve traffic. For example, an application might need to load large data or configuration files during startup, or depend on external services after startup. In such cases, you don't want to kill the application, but you don't want to send it requests either. Kubernetes provides readiness probes to detect and mitigate these situations. A pod with containers reporting that they are not ready does not receive traffic through Kubernetes Services.

Readiness probes are configured similarly to liveness probes. The only difference is that you use the readinessProbe field instead of the livenessProbe field.

readinessProbe:
  exec:
    command:
    - cat
    - /tmp/healthy
  initialDelaySeconds: 5
  periodSeconds: 5

Configuration for HTTP and TCP readiness probes also remains identical to liveness probes.

Readiness and liveness probes can be used in parallel for the same container. Using both can ensure that traffic does not reach a container that is not ready for it, and that containers are restarted when they fail