因為Pod作為在集群的節點上運行的進程，所以在不再需要的時候能夠優雅的終止掉是十分必要的（比起使用發送KILL信號這種暴力的方式）。用戶需要能夠放松刪除請求，並且知道它們何時會被終止，是否被正確的刪除。用戶想終止程序時發送刪除pod的請求，在pod可以被強制刪除前會有一個寬限期，會發送一個TERM請求到每個容器的主進程。一旦超時，將向主進程發送KILL信號並從API server中刪除。如果kubelet或者container manager在等待進程終止的過程中重啟，在重啟后仍然會重試完整的寬限期。
示例流程如下：
- 用戶發送刪除pod的命令，默認寬限期是30秒；
- 在Pod超過該寬限期后API server就會更新Pod的狀態為“dead”；
- 在客戶端命令行上顯示的Pod狀態為“terminating”；
- 跟第三步同時，當kubelet發現pod被標記為“terminating”狀態時，開始停止pod進程：
- 如果在pod中定義了preStop hook，在停止pod前會被調用。如果在寬限期過后，preStop hook依然在運行，第二步會再增加2秒的寬限期；
- 向Pod中的進程發送TERM信號；
- 跟第三步同時，該Pod將從該service的端點列表中刪除，不再是replication controller的一部分。關閉的慢的pod將繼續處理load balancer轉發的流量；
- 過了寬限期后，將向Pod中依然運行的進程發送SIGKILL信號而殺掉進程。
- Kublete會在API server中完成Pod的的刪除，通過將優雅周期設置為0（立即刪除）。Pod在API中消失，並且在客戶端也不可見。
刪除寬限期默認是30秒。 kubectl delete命令支持 —grace-period=<seconds> 選項，允許用戶設置自己的寬限期。如果設置為0將強制刪除pod。在kubectl>=1.5版本的命令中，你必須同時使用 --force 和 --grace-period=0 來強制刪除pod。
Pod的強制刪除是通過在集群和etcd中將其定義為刪除狀態。當執行強制刪除命令時，API server不會等待該pod所運行在節點上的kubelet確認，就會立即將該pod從API server中移除，這時就可以創建跟原pod同名的pod了。這時，在節點上的pod會被立即設置為terminating狀態，不過在被強制刪除之