你有沒有在使用k8s過程中遇到過這種情況: 通過kubectl delete指令刪除一些資源時，一直處于Terminating狀態(tài)。
這是為什么呢？

本文將介紹當你執(zhí)行kubectl delete語句時，K8s內部都執(zhí)行了哪些操作。
以及為何有些資源’刪除不掉’(具體表現(xiàn)為一直Terminating，刪除namespace時很容易遇到這種情況)

接下來，我們聚焦討論以下四個方面:

資源的哪些屬性會對刪除操作產生影響？

• finalizers與owner references屬性是如何影響刪除操作的？
• 如何利用Propagation Policy（分發(fā)策略）更改刪除順序？
• 刪除操作的工作原理？

方便起見，以下所有示例都將使用ConfigMaps和基本shell命令來演示該過程

詞匯表

• 資源: k8s的資源對象（如configmap, secret, pod…）
• finalizers: 終結器，存放鍵的列表。列表內的鍵為空時資源才可被刪除
• owner references: 所有者引用（歸誰管理/父資源對象是誰）
• kubectl: K8s客戶端工具

基本刪除操作

Kubernetes提供了幾個不同的命令，您可以使用它們來創(chuàng)建、讀取、更新和刪除對象。
出于本文的目的，我們將重點討論四個kubectl命令:create、get、patch和delete.

下面是kubectl delete命令的基本示例

創(chuàng)建名為mymap的configmap對象：

$ kubectl create configmap mymap
configmap/mymap created

查看名為mymap的configmap對象：

$ kubectl get configmap/mymap
NAME    DATA   AGE
mymap   0      12s

刪除名為mymap的configmap對象：

$ kubectl delete configmap/mymap
configmap "mymap" deleted

基本delete命令的刪除操作狀態(tài)圖非常簡單:

刪除操作看似簡單，但是有很多因素可能會干擾刪除，包括finalizers與owner references屬性

Finalizers是什么？

上面我們提到了兩個屬性：finalizers與owner references可能會干擾刪除操作，導致刪除阻塞或失敗。
那Finalizers是什么？會對刪除有何影響呢？

當要理解Kubernetes中的資源刪除原理時，了解finalizers（以下我們稱finalizers為終結器）的工作原理是很有幫助的，
可以幫助您理解為什么有些對象無法被刪除。

終結器是資源發(fā)出預刪除操作信號的屬性，
控制著資源的垃圾收集，并用于提示控制器在刪除資源之前執(zhí)行哪些清理操作。

finalizers本質是包含鍵的列表，不具有實際意義。與annotations（注釋）類似，finalizers是可以被操作的（增刪改）。

以下終結器您可能遇到過：

• kubernetes.io/pv-protection
• kubernetes.io/pvc-protection

這兩個終結器作用于卷，以防止卷被意外刪除。

類似地，一些終結器可用于防止資源被刪除，但不由任何控制器管理。
下面是一個自定義的configmap，它沒有具體值，但包含一個終結器:

$ cat <<EOF | kubectl create -f -
apiVersion: v1
kind: ConfigMap
metadata:name: mymapfinalizers:- kubernetes
EOF

終結器通常用于名稱空間(namespace)，而管理configmap資源的控制器不知道該如何處理finalizers字段。
下面我們嘗試刪除這個configmap對象:

$ kubectl delete configmap/mymap &
configmap "mymap" deleted
$ jobs
[1]+  Running kubectl delete configmap/mymap

Kubernetes返回該對象已被刪除，然而它并沒有真正意義上被刪除，而是在刪除的過程中。
當我們試圖再次獲取該對象時，我們發(fā)現(xiàn)該對象多了個deletionTimestamp(刪除時間戳)字段。

$ kubectl get cm mymap -o yaml
apiVersion: v1
kind: ConfigMap
metadata:creationTimestamp: "2021-09-29T11:04:40Z"deletionGracePeriodSeconds: 0deletionTimestamp: "2021-09-29T11:04:55Z"finalizers:- kubernetesmanagedFields:- apiVersion: v1fieldsType: FieldsV1fieldsV1:f:metadata:f:finalizers:.: {}v:"kubernetes": {}manager: kubectloperation: Updatetime: "2021-09-29T11:04:40Z"name: mymapnamespace: defaultresourceVersion: "1378430"selfLink: /api/v1/namespaces/default/configmaps/mymapuid: 8d6ca0b1-4840-4597-8164-a63b526dbf5f

簡而言之，當我們刪除帶有finalizers字段的對象時，該對象僅僅是被更新了，被標記為待刪除狀態(tài)，而不是被刪除了。
這是因為Kubernetes獲取到該對象包含終結器，通過添加deletionTimestamp（刪除時間戳）字段將其置于只讀狀態(tài)（刪除終結器鍵更新除外）。
換句話說，在刪除該對象終結器之前，刪除都不會完成。

接下來我們嘗試通過patch命令刪除終結器，并觀察configmap/mymap是否會被’真正’刪除。

$ kubectl patch configmap/mymap \--type json \--patch='[ { "op": "remove", "path": "/metadata/finalizers" } ]'
configmap/mymap patched

再次檢索該對象：

$ kubectl get cm mymap
Error from server (NotFound): configmaps "mymap" not found

發(fā)現(xiàn)該對象已被真正刪除，下圖描述了帶有finalizers字段的對象刪除流程：

總結：當您試圖刪除一個帶有終結器的對象，它將一直處于預刪除只讀狀態(tài)，
直到控制器刪除了終結器鍵或使用Kubectl刪除了終結器。一旦終結器列表為空，Kubernetes就可以回收該對象，并將其放入要從注冊表中刪除的隊列中

• 對象存在finalizers，關聯(lián)的控制器故障未能執(zhí)行或執(zhí)行finalizer函數(shù)hang住: 比如namespace控制器無法刪除完空間內所有的對象，
  特別是在使用aggregated apiserver時，第三方apiserver服務故障導致無法刪除其對象。
  此時，需要會恢復第三方apiserver服務或移除該apiserver的聚合，具體選擇哪種方案需根據(jù)實際情況而定。
• 集群內安裝的控制器給一些對象增加了自定義finalizers，未刪除完fianlizers就下線了該控制器，導致這些fianlizers沒有控制器來移除他們。
  此時，需要恢復該控制器會手動移除finalizers(多出現(xiàn)于自定義operator)，具體選擇哪種方案根據(jù)實際情況而定。

Owner References又是什么？

上面我們提到了兩個屬性：finalizers與owner references可能會干擾刪除操作，導致刪除阻塞或失敗。
并介紹了Finalizers，接下來我們聊聊Owner References.

Owner References（所有者引用或所有者歸屬）描述了對象組之間的關系。
指定了資源彼此關聯(lián)的屬性，因此可以級聯(lián)刪除整個資源樹。

當存在所有者引用時，將處理終結器規(guī)則。所有者引用由名稱和UID組成

所有者引用相同名稱空間內的鏈接資源，它還需要UID以使該引用生效(確保唯一)。
Pods通常具有對所屬副本集的所有者引用。 因此，當Deloyment或有StatefulSet被刪除時，子ReplicaSet和Pod將在流程中被刪除。

我們通過下面的例子，來理解Owner References（所有者引用）的工作原理：

1.創(chuàng)建cm/mymap-parent對象

$ cat <<EOF | kubectl create -f -
apiVersion: v1
kind: ConfigMap
metadata:name: mymap-parent
EOF

2.獲取cm/mymap-parent的UID

CM_UID=$(kubectl get configmap mymap-parent -o jsonpath="{.metadata.uid}")

3.創(chuàng)建cm/mymap-child對象，并設置ownerReferences字段聲明所有者引用（通過kind、name、uid字段確保選擇器可以匹配到）

cat <<EOF | kubectl create -f -
apiVersion: v1
kind: ConfigMap
metadata:name: mymap-childownerReferences:- apiVersion: v1kind: ConfigMapname: mymap-parentuid: $CM_UID
EOF

即cm/mymap-parent為cm/mymap-child的父對象，此時我們刪除cm/mymap-parent對象并觀察cm/mymap-child對象狀態(tài)

$ kubectl get cm
NAME           DATA   AGE
mymap-child    0      2m44s
mymap-parent   0      3m$ kubectl delete cm mymap-parent
configmap "mymap-parent" deleted$ kubectl get cm
No resources found in default namespace.

即我們通過刪除父對象，間接刪除了父對象下的所有子對象。 這種刪除k8s中被稱為級聯(lián)刪除。我們可不可以只刪除父對象，而不刪除子對象呢？

答案是: 可以的，刪除時通過添加–cascade=false參數(shù)實現(xiàn)，我們通過下面的例子來驗證：

$ cat <<EOF | kubectl create -f -
apiVersion: v1
kind: ConfigMap
metadata:name: mymap-parent
EOF$ CM_UID=$(kubectl get configmap mymap-parent -o jsonpath="{.metadata.uid}")$ cat <<EOF | kubectl create -f -
apiVersion: v1
kind: ConfigMap
metadata:name: mymap-childownerReferences:- apiVersion: v1kind: ConfigMapname: mymap-parentuid: $CM_UID
EOF$ kubectl delete --cascade=false configmap/mymap-parent
configmap "mymap-parent" deleted$ kubectl get cm
NAME          DATA   AGE
mymap-child   0      107s

–cascade=false參數(shù)實際改變了父-子資源的刪除順序，k8s中關于父-子資源刪除策略有以下三種：

• Foreground: 子資源在父資源之前被刪除(post-order)
• Background: 父資源在子資源之前被刪除 (pre-order)
• Orphan: 忽略所有者引用進行刪除

下面這段內容比較晦澀，沒太理解：

Keep in mind that when you delete an object and owner references have been specified, finalizers will be honored in the process. 
This can result in trees of objects persisting, and you end up with a partial deletion. 
At that point, you have to look at any existing owner references on your objects,as well as any finalizers, to understand what’s happening

強制刪除命名空間

有一種情況可能需要強制刪除命名空間：

如果您已經(jīng)刪除了一個命名空間，并刪除了它下面的所有對象，但名稱空間仍然存在，一般為Terminating狀態(tài)。
則可以通過更新名稱空間的finalize屬性來強制刪除該名稱空間。

會話1：

$ kubectl proxy

會話2：

$ NAMESPACE_NAME=test
cat <<EOF | curl -X PUT \127.0.0.1:8001/api/v1/namespaces/$NAMESPACE_NAME/finalize \-H "Content-Type: application/json" \--data-binary @-
{"kind": "Namespace","apiVersion": "v1","metadata": {"name": "$NAMESPACE_NAME"},"spec": {"finalizers": null}
}
EOF

我們應該謹慎思考是否強制刪除命名空間，因為這樣做可能只刪除名稱空間，命名空間下的其他資源刪不完全，最終導致留下孤兒對象。
比如資源對象A存在于ddd命名空間，此時若強制刪除ddd命名空間, 且對象A又未被刪除，那么對象A便成了孤兒對象。

參考

使用Finalizers控制k8s資源刪除
[kubernetes]Finalizers和優(yōu)雅終止解析