由雲原生平臺管理的容器化應用，並不能控制其自身的生命週期。它們必須監聽由管理平臺發出的事件，再對生命週期做出相對應的變更。所謂的生命週期管理，即代表應用該如何讀取和響應這些由管理平臺發出的生命週期事件。
鑑於某些管理策略或者外部環境因素，在任意時間點，管理平臺都有可能需要啓動或者終止容器中的應用。容器化應用可以決定平臺發出的哪些事件是重要的，應該以怎樣的行爲去響應。這實際上是一個平臺用來同應用進行溝通、嚮應用發送命令的 API，應用可以選擇接受或者忽略。
僅僅使用進程模型來啓動和終止應用通常是不夠的，現實世界中的應用往往需要更細粒度的交互控制和生命週期管理。有些應用需要 warm up，有些需要一個平滑、乾淨的關閉流程。因而 Kubernetes 設計瞭如下幾種由平臺發出的事件，容器可以選擇監聽和響應這些事件。
SIGTERM Signal
當 Kubernetes 決定關閉某個容器時，該容器會收到一個 SIGTERM 信號，之後容器會嘗試儘快完成關閉流程。對於某些應用來說，乾淨的快速終止是可行的。但另外一些應用有可能需要完成處理中的請求，釋放打開的連接，清理臨時文件等。這會耗費更多的時間。
SIGKILL Signal
當某個容器進程在收到 SIGTERM 信號後並沒有關閉，接下來它會再收到一個 SIGKILL 信號強制終止進程。默認情況下，Kubernetes 會在發出 SIGTERM 信號 30 秒後再發送 SIGKILL。這個 30 秒的過渡時間可以通過 Pod 的 .spec.terminationGracePeriodSeconds 字段進行配置。
Poststart Hook
僅僅使用進程信號來管理生命週期有一定程度的限制。因而 Kubernetes 又提供了 postStart 和 postStop。
postStart 示例：
apiVersion: v1
kind: Pod
metadata:
name: post-start-hook
spec:
containers:
- image: k8spatterns/random-generator:1.0
name: random-generator
lifecycle:
postStart:
exec:
command:
- sh
- -c
- sleep 30 && echo "Wake up!" > /tmp/postStart_done
postStart 指定的命令會在容器創建後執行，與容器的基礎進程異步。postStart 是一種阻塞請求，其 handler 完成之前，容器會一直處於 Waiting 狀態，同時 Pod 處於 Pending 狀態。
postStart 的這種特性可以用來延遲容器的啓動，爲容器的主進程的初始化爭取時間。
另一個 postStart 的使用場景就是在 Pod 不滿足特定的前提條件時，阻止容器完成啓動。當 postStart 命令返回了一個非 0 的返回值，主進程會被 Kubernetes 殺掉。
類似於 Health Probe，postStart 和 preStop 有如下兩種 handler 類型：
- exec：在容器中直接運行一個命令
- httpGet：向容器開放的某個端口發送 HTTP GET 請求
對於 postStart 執行的邏輯，需要注意以下幾點：
- postStart 與容器進程是並行的關係，因而這個 hook 有可能在容器啓動前執行
- postStart 有至少執行一次的目標，需要考慮重複執行的情況
- 對於失敗的 HTTP 請求，postStart 不會重複嘗試
preStop
preStop hook 是一個在容器終止前發送給容器的阻塞請求。
apiVersion: v1
kind: Pod
metadata:
name: pre-stop-hook
spec:
containers:
- image: k8spatterns/random-generator:1.0
name: random-generator
lifecycle:
preStop:
httpGet:
port: 8080
path: /shutdown
雖然 preStop 是阻塞的，但若它掛起或者返回一個非成功的結果，並不會阻止進程被殺掉、容器被刪除。preStop 只是爲了能夠平滑地關閉應用，是除 SIGTERM 之外的另一種方便的選擇。
總結
雲原生平臺能提供的最大的好處之一，就是在不夠可靠的雲計算基礎設施上，可靠地運行和擴展應用。這類平臺設計了一系列應用必須遵守的協議和約束。處理和響應協議中的事件，能夠確保應用平穩地啓動和關閉，對接受服務的客戶端只有最小的影響。應用的生命週期不再由個人所控制，而是完全由平臺自動化管理。