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

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

接下來(lái)，我們聚焦討論以下四個(gè)方面:

資源的哪些屬性會(huì)對(duì)刪除操作產(chǎn)生影響？

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

方便起見(jiàn)，以下所有示例都將使用ConfigMaps和基本shell命令來(lái)演示該過(guò)程

詞匯表

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

基本刪除操作

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

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

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

$ kubectl create configmap mymap
configmap/mymap created

查看名為mymap的configmap對(duì)象：

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

刪除名為mymap的configmap對(duì)象：

$ kubectl delete configmap/mymap
configmap "mymap" deleted

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

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

Finalizers是什么？

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

當(dāng)要理解Kubernetes中的資源刪除原理時(shí)，了解finalizers（以下我們稱finalizers為終結(jié)器）的工作原理是很有幫助的，
可以幫助您理解為什么有些對(duì)象無(wú)法被刪除。

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

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

以下終結(jié)器您可能遇到過(guò)：

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

這兩個(gè)終結(jié)器作用于卷，以防止卷被意外刪除。

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

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

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

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

Kubernetes返回該對(duì)象已被刪除，然而它并沒(méi)有真正意義上被刪除，而是在刪除的過(guò)程中。
當(dāng)我們?cè)噲D再次獲取該對(duì)象時(shí)，我們發(fā)現(xiàn)該對(duì)象多了個(gè)deletionTimestamp(刪除時(shí)間戳)字段。

$ 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

簡(jiǎn)而言之，當(dāng)我們刪除帶有finalizers字段的對(duì)象時(shí)，該對(duì)象僅僅是被更新了，被標(biāo)記為待刪除狀態(tài)，而不是被刪除了。
這是因?yàn)镵ubernetes獲取到該對(duì)象包含終結(jié)器，通過(guò)添加deletionTimestamp（刪除時(shí)間戳）字段將其置于只讀狀態(tài)（刪除終結(jié)器鍵更新除外）。
換句話說(shuō)，在刪除該對(duì)象終結(jié)器之前，刪除都不會(huì)完成。

接下來(lái)我們嘗試通過(guò)patch命令刪除終結(jié)器，并觀察configmap/mymap是否會(huì)被’真正’刪除。

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

再次檢索該對(duì)象：

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

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

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

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

Owner References又是什么？

上面我們提到了兩個(gè)屬性：finalizers與owner references可能會(huì)干擾刪除操作，導(dǎo)致刪除阻塞或失敗。
并介紹了Finalizers，接下來(lái)我們聊聊Owner References.

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

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

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

我們通過(guò)下面的例子，來(lái)理解Owner References（所有者引用）的工作原理：

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

$ 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對(duì)象，并設(shè)置ownerReferences字段聲明所有者引用（通過(guò)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的父對(duì)象，此時(shí)我們刪除cm/mymap-parent對(duì)象并觀察cm/mymap-child對(duì)象狀態(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.

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

答案是: 可以的，刪除時(shí)通過(guò)添加–cascade=false參數(shù)實(shí)現(xiàn)，我們通過(guò)下面的例子來(lái)驗(yà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ù)實(shí)際改變了父-子資源的刪除順序，k8s中關(guān)于父-子資源刪除策略有以下三種：

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

下面這段內(nèi)容比較晦澀，沒(méi)太理解：

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

強(qiáng)制刪除命名空間

有一種情況可能需要強(qiáng)制刪除命名空間：

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

會(huì)話1：

$ kubectl proxy

會(huì)話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

我們應(yīng)該謹(jǐn)慎思考是否強(qiáng)制刪除命名空間，因?yàn)檫@樣做可能只刪除名稱空間，命名空間下的其他資源刪不完全，最終導(dǎo)致留下孤兒對(duì)象。
比如資源對(duì)象A存在于ddd命名空間，此時(shí)若強(qiáng)制刪除ddd命名空間, 且對(duì)象A又未被刪除，那么對(duì)象A便成了孤兒對(duì)象。

參考

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