Kubernetes: 「終了」状態でスタックした名前空間の削除

/ sigapi-machinery

@ shean-guangchangこれを再現する方法はありますか？

そして好奇心から、CRDを使用していますか？ 以前、TPRでこの問題に直面しました。

/種類のバグ

私はルークデプロイメントでこの問題を経験しているようです：

➜  tmp git:(master) ✗ kubectl delete namespace rook
Error from server (Conflict): Operation cannot be fulfilled on namespaces "rook": The system is ensuring all content is removed from this namespace.  Upon completion, this namespace will automatically be purged by the system.
➜  tmp git:(master) ✗ 

私はそれが彼らのCRDと関係があると思います、私はこれをAPIサーバーログで見ます：

E0314 07:28:18.284942       1 crd_finalizer.go:275] clusters.rook.io failed with: timed out waiting for the condition
E0314 07:28:18.287629       1 crd_finalizer.go:275] clusters.rook.io failed with: Operation cannot be fulfilled on customresourcedefinitions.apiextensions.k8s.io "clusters.rook.io": the object has been modified; please apply your changes to the latest version and try again

rookを別の名前空間にデプロイしましたが、クラスターCRDを作成できません。

➜  tmp git:(master) ✗ cat rook/cluster.yaml 
apiVersion: rook.io/v1alpha1
kind: Cluster
metadata:
  name: rook
  namespace: rook-cluster
spec:
  dataDirHostPath: /var/lib/rook-cluster-store
➜  tmp git:(master) ✗ kubectl create -f rook/
Error from server (MethodNotAllowed): error when creating "rook/cluster.yaml": the server does not allow this method on the requested resource (post clusters.rook.io)

CRDがクリーンアップされなかったようです。

➜  tmp git:(master) ✗ kubectl get customresourcedefinitions clusters.rook.io -o yaml
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  creationTimestamp: 2018-02-28T06:27:45Z
  deletionGracePeriodSeconds: 0
  deletionTimestamp: 2018-03-14T07:36:10Z
  finalizers:
  - customresourcecleanup.apiextensions.k8s.io
  generation: 1
  name: clusters.rook.io
  resourceVersion: "9581429"
  selfLink: /apis/apiextensions.k8s.io/v1beta1/customresourcedefinitions/clusters.rook.io
  uid: 7cd16376-1c50-11e8-b33e-aeba0276a0ce
spec:
  group: rook.io
  names:
    kind: Cluster
    listKind: ClusterList
    plural: clusters
    singular: cluster
  scope: Namespaced
  version: v1alpha1
status:
  acceptedNames:
    kind: Cluster
    listKind: ClusterList
    plural: clusters
    singular: cluster
  conditions:
  - lastTransitionTime: 2018-02-28T06:27:45Z
    message: no conflicts found
    reason: NoConflicts
    status: "True"
    type: NamesAccepted
  - lastTransitionTime: 2018-02-28T06:27:45Z
    message: the initial names have been accepted
    reason: InitialNamesAccepted
    status: "True"
    type: Established
  - lastTransitionTime: 2018-03-14T07:18:18Z
    message: CustomResource deletion is in progress
    reason: InstanceDeletionInProgress
    status: "True"
    type: Terminating
➜  tmp git:(master) ✗ 

私は同様の状態の核分裂名前空間を持っています：

➜  tmp git:(master) ✗ kubectl delete namespace fission
Error from server (Conflict): Operation cannot be fulfilled on namespaces "fission": The system is ensuring all content is removed from this namespace.  Upon completion, this namespace will automatically be purged by the system.
➜  tmp git:(master) ✗ kubectl get pods -n fission     
NAME                          READY     STATUS        RESTARTS   AGE
storagesvc-7c5f67d6bd-72jcf   0/1       Terminating   0          8d
➜  tmp git:(master) ✗ kubectl delete pod/storagesvc-7c5f67d6bd-72jcf --force --grace-period=0
warning: Immediate deletion does not wait for confirmation that the running resource has been terminated. The resource may continue to run on the cluster indefinitely.
Error from server (NotFound): pods "storagesvc-7c5f67d6bd-72jcf" not found
➜  tmp git:(master) ✗ kubectl describe pod -n fission storagesvc-7c5f67d6bd-72jcf
Name:                      storagesvc-7c5f67d6bd-72jcf
Namespace:                 fission
Node:                      10.13.37.5/10.13.37.5
Start Time:                Tue, 06 Mar 2018 07:03:06 +0000
Labels:                    pod-template-hash=3719238268
                           svc=storagesvc
Annotations:               <none>
Status:                    Terminating (expires Wed, 14 Mar 2018 06:41:32 +0000)
Termination Grace Period:  30s
IP:                        10.244.2.240
Controlled By:             ReplicaSet/storagesvc-7c5f67d6bd
Containers:
  storagesvc:
    Container ID:  docker://3a1350f6e4871b1ced5c0e890e37087fc72ed2bc8410d60f9e9c26d06a40c457
    Image:         fission/fission-bundle:0.4.1
    Image ID:      docker-pullable://fission/fission-bundle<strong i="6">@sha256</strong>:235cbcf2a98627cac9b0d0aae6e4ea4aac7b6e6a59d3d77aaaf812eacf9ef253
    Port:          <none>
    Command:
      /fission-bundle
    Args:
      --storageServicePort
      8000
      --filePath
      /fission
    State:          Terminated
      Exit Code:    0
      Started:      Mon, 01 Jan 0001 00:00:00 +0000
      Finished:     Mon, 01 Jan 0001 00:00:00 +0000
    Ready:          False
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /fission from fission-storage (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from fission-svc-token-zmsxx (ro)
Conditions:
  Type           Status
  Initialized    True 
  Ready          False 
  PodScheduled   True 
Volumes:
  fission-storage:
    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:  fission-storage-pvc
    ReadOnly:   false
  fission-svc-token-zmsxx:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  fission-svc-token-zmsxx
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:          <none>
➜  tmp git:(master) ✗ 

FissionもCRDを使用していますが、クリーンアップされているようです。

@ shean-guangchang-同じ問題が発生しました。 名前空間の下にあるすべてのものを手動で削除し、「helm」からすべてを削除してパージし、マスターノードを1つずつ再起動すると、問題が修正されました。

私が遭遇したことは、「ark」、「tiller」、およびKuberenetsがすべて一緒に機能していることと関係があると思います（ヘルムを使用してブートストラップし、arkを使用してバックアップしました）。一方、関連するログがないため、トラブルシューティングを行うことはほとんど不可能でした。

それがルークのものである場合は、これを見てください： //github.com/rook/rook/issues/1488#issuecomment -365058080

それは理にかなっていると思いますが、名前空間を削除できない状態にする可能性があるのはバグのようです。

@barakAtSolutoと同様の環境（Ark＆Helm）があり、同じ問題が発生します。 マスターをパージして再起動しても、修正されませんでした。 まだ終了に固執しています。

問題を再現しようとしたときにもそれがありました。 最終的には、新しいクラスターを作成する必要がありました。
除外-デフォルト、kube-system / public、およびすべてのark関連の名前空間をバックアップと復元から除外して、これが発生しないようにします...

1.8.4から1.9.6にアップグレードされたクラスターでも、これが発生しています。 どのログを見るかさえわかりません

1.10.1の同じ問題:(

1.9.6の同じ問題

編集：一部のポッドがハングしているため、名前空間を削除できませんでした。 それらすべてに--grace-period = 0 --forceを指定して削除を行い、数分後に名前空間も削除されました。

ねえ、

私はこれを何度も繰り返しており、ほとんどの場合、ファイナライザーに問題があります。

名前空間がスタックしている場合は、 kubectl get namespace XXX -o yamlを試して、ファイナライザーがあるかどうかを確認してください。 その場合は、名前空間を編集してファイナライザーを削除すると（空の配列を渡すことにより）、名前空間が削除されます

@xetysは安全ですか？ 私の場合、「kubernetes」という名前のファイナライザーは1つだけです。

それは奇妙です、私はそのようなファイナライザーを見たことがありません。 私は自分の経験に基づいて話すことができます。 私は本番クラスターでそれを数回行いましたが、それはまだ生きています

1.10.5でも同じ問題。 私はこの問題のすべてのアドバイスを結果なしで試しました。 ポッドを取り除くことができましたが、名前空間はまだハングしています。

実際、nsもしばらくして削除されました。

この動作の原因を理解しておくとよいでしょう。私が持っていたファイナライザーはkubernetesだけです。 動的なWebhookもありますが、これらを関連付けることはできますか？

@xetysさて、ついに私はその名前空間内のレプリカであなたのトリックを使用しました。 おそらく存在しなくなったカスタムファイナライザーがいくつかあったので、削除できませんでした。 そのファイナライザーへの参照を削除すると、それらは消え、名前空間も消えました。 ありがとう！ :)

EKS 1.10.3クラスターでの同じ問題：

Server Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.3", GitCommit:"2bba0127d85d5a46ab4b778548be28623b32d0b0", GitTreeState:"clean", BuildDate:"2018-05-28T20:13:43Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}

ベアメタルクラスターでも同じ問題が発生します。

Client Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.0", GitCommit:"91e7b4fd31fcd3d5f436da26c980becec37ceefe", GitTreeState:"clean", BuildDate:"2018-06-27T20:17:28Z", GoVersion:"go1.10.2", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.1", GitCommit:"b1b29978270dc22fecc592ac55d903350454310a", GitTreeState:"clean", BuildDate:"2018-07-17T18:43:26Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}

私の名前空間は次のようになります。

apiVersion: v1
kind: Namespace
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","kind":"Namespace","metadata":{"annotations":{},"name":"creneaux-app","namespace":""}}
  name: creneaux-app
spec:
  finalizers:
  - kubernetes

これは実際、私がこの問題を抱えていた2番目の名前空間です。

これを試して、名前空間内のすべてのものの実際のリストを取得してください： https ：

次に、オブジェクトごとにkubectl deleteまたはkubectl editを実行して、ファイナライザーを削除します。

イニシャライザを削除することは私のためにトリックをしました...

kubectl edit namespace annoying-namespace-to-deleteを実行してファイナライザーを削除すると、 kubectl get -o yaml確認すると、ファイナライザーが再度追加されます。

また、 @ adamplの提案を--ignore-not-found削除すると、どのタイプの名前空間にもリソースが見つからないことが確認されます）。

@ManifoldFR 、私はあなたと同じ問題を抱えていて、jsonファイルでAPI呼び出しを行うことでそれを機能させることができました。
kubectl get namespace annoying-namespace-to-delete -o json > tmp.json
次に、tmp.jsonを編集して、 "kubernetes"を削除します

curl -k -H "Content-Type: application/json" -X PUT --data-binary @tmp.json https://kubernetes-cluster-ip/api/v1/namespaces/annoying-namespace-to-delete/finalize

名前空間が削除されます。

@slasshうまくいきました！ API呼び出しを行うことを考えるべきでした：どうもありがとう！ 私たちはあなたの賛美を永遠に歌います

問題はv1.11.1に存在します。 dokuwikiのランチャー/ヘルムの展開が滞っていました。 @siXorの提案必要があり、次に@slasshのアドバイスに従い

@slassh kubernetes-cluster-ipの表示方法は？ kubernetesクラスターreplaceをデプロイしたノードIPの1つを使用すると、404が報告されます。

こんにちは@ jiuchongxiao 、kubernetes-cluster-ipによって私はあなたのノードマスターIPの1つを意味しました。
紛らわしい場合はごめんなさい！

最初に「kubectlproxy」を開始すると、curlをhttp://127.0.0.1：8001 / api / v1 / namespaces / annoying-namespace-to-delete / finalizeに送信できます。 そのようにするまで、認証を機能させることができませんでした。

良いヒント@ 2stacks。 httpsをhttp置き換えるだけです。

1.11.2でもこの問題が発生しています。

再現するためのより多くのコンテキストを与えるために、私はこれをCRDでのみ見ました。 CRDオブジェクトを削除すると、CRDオブジェクトが所有するオブジェクトが削除されないという奇妙な状態になりました。 気づかなかったので、名前空間の削除を発行しました。 次に、 kubectl delete all --all -n my-namespaceして名前空間内のすべてのオブジェクトを削除しました。 その時点で、名前空間の削除がスタックしました。 これが何らかの形で役立つことを願っています。

ログを見ると、この特定の問題はコントローラーマネージャーが異常であることに関連していることがわかりました。 私の場合、それはおそらくバグではありませんでした。 コントローラマネージャが再び起動すると、すべてが正しくクリーンアップされました。

@slassh完璧なソリューション！ どうもありがとうございました！！！！

1.10.xでもこの問題が発生します。 @slasshのコメントは、実際の問題を隠すだけの回避策だと思います。 名前空間がTerminatingスタックしているのはなぜですか？

私たちの場合、名前空間を削除する理由がスタックしていることがわかりました（@palmerabollo）

名前空間にファイナライザーkubernetes場合、それはAPIサーバーの内部問題を意味します。

kubectl api-resources実行します。次のように返される場合は、カスタムAPIに到達できないことを意味します。

error: unable to retrieve the complete list of server APIs: metrics.k8s.io/v1beta1: the server is currently unable to handle the request

kubectl get apiservices v1beta1.metrics.k8s.io -o yaml実行して、ステータス条件を確認します。

status:
  conditions:
  - lastTransitionTime: 2018-10-15T08:14:15Z
    message: endpoints for service/metrics-server in "kube-system" have no addresses
    reason: MissingEndpoints
    status: "False"
    type: Available

上記のエラーは、metrics-serverに影響を与えるcrashloopbackoffが原因で発生するはずです。 Kubernetesに登録されている他のカスタムAPIについても同様です。

名前空間の削除などのクラスターランタイム操作を復元するには、 kube-systemでサービスの状態を確認してください。

私はv1.11.3でこの問題に直面しています。 ファイナライザーでは、問題のある名前空間に存在するkubernetesのみが表示されます。

spec:
  finalizers:
  - kubernetes

@slassh百万ありがとう、あなたのソリューションはうまく機能します！
アーク、ティラー、クベドのクラスターでも同じ問題が発生します。 別の名前空間の削除に影響を与える理由はわかりませんが、問題はエラーを発生させているkubedのAPIである可能性があります。

@javierprovechoメトリックサーバーで遊んでいただけで、機能していなかったため、サービスを削除しようとしましたが、名前空間は削除されません。エラーは

status:
  conditions:
  - lastTransitionTime: 2018-08-24T08:59:36Z
    message: service/metrics-server in "kube-system" is not present
    reason: ServiceNotFound
    status: "False"
    type: Available

この状態から回復する方法を知っていますか？

編集：わかった...メトリック/ HPAにリモートで関連する_すべて_を削除してから、コントロールプレーン全体を再起動する必要がありました（再起動する前に、すべてのレプリカを削除する必要がありました）。これには、 apiservice削除が含まれます。 v1beta1.metrics.k8s.io自体。

@ 2rs2ts

$ kubectl delete apiservice v1beta1.metrics.k8s.io

機能していないmetrics APIサービスを取り除くことにより、コントローラーマネージャーは古い名前空間を削除できるようになります。

コントロールプレーンを再起動する必要はありません。

@antoinecoいいえ、必要でした。 apiserviceを削除してしばらく待ちましたが、コントロールプレーンを再起動するまで名前空間は削除されませんでした。

まず、小さなコーヒーを飲んでリラックスしてから、k8sマスターノードに移動します

1. kubectlcluster-info
   Kubernetesマスターはhttps：// localhost ：6443で実行されてい
   KubeDNSはhttps：// localhost ：6443 / api / v1 / namespaces / kube-system / services / kube- dns：dns / proxyで実行されています

クラスタの問題をさらにデバッグおよび診断するには、「kubectlcluster-infodump」を使用します。

1. kube-proxyを実行します
   kubectlプロキシ＆
   127.0.0.1:8001でサービスを開始

IDを保存して、後で削除します:)

1. 削除しないと決めた名前空間を見つけてください:)私たちにとっては牛システムになります
   kubectl get ns
   牛システムは1dを終了します

ファイルに入れます

1. kubectl get namespace cattle-system -o json> tmp.json

1. ファイルを編集し、ファイナライザーを削除します
   }、
   "仕様"：{
   「ファイナライザー」：[
   「kubernetes」
   ]
   }、
   編集後は次のようになります👍
   }、
   "仕様"：{
   「ファイナライザー」：[
   ]
   }、
   私たちはほとんどそこにいます👍

curl -k -H "Content-Type：application / json" -X PUT --data-binary @ tmp.json http://127.0.0.1：8001 / api / v1 / namespaces / $ {NAMESPACE} / finalize

そしてそれはなくなった👍

ねえ、ファイナライザーkubernetesは理由があります。 私たちにとって、それは誤って構成されたメトリックAPIサービス名でした。 たぶんあなたにとっては何か他のものであり、それはあなたのコントロールプレーンログを見ることによって発見することができます。 バグの確認なしに、ファイナライザーを削除すると、削除の目的で再びアクセスできなくなったものが作成されたままになるなど

この問題はまだ開いているため：
「none」で実行されているminikubeクラスター内で、これはホストが休止状態から復帰した後に発生しました。

私の仮定：
私の場合、休止状態が同じ問題を引き起こしましたが、有効なスワップで問題が発生します。

これは仮定をもたらします：
影響を受けるクラスターでスワップが有効になっている可能性がありますか？

しかし、これは単なる推測です。 私にとって重要なことであり、私のローカル設定でこのバグに遭遇した人は誰でも：

まず、小さなコーヒーを飲んでリラックスしてから、k8sマスターノードに移動します

1. kubectlcluster-info
   Kubernetesマスターはhttps：// localhost ：6443で実行されてい
   KubeDNSはhttps：// localhost ：6443 / api / v1 / namespaces / kube-system / services / kube- dns：dns / proxyで実行されています

クラスタの問題をさらにデバッグおよび診断するには、「kubectlcluster-infodump」を使用します。

1. kube-proxyを実行します
   kubectlプロキシ＆
   127.0.0.1:8001でサービスを開始

IDを保存して、後で削除します:)

1. 削除しないと決めた名前空間を見つけてください:)私たちにとっては牛システムになります
   kubectl get ns
   牛システムは1dを終了します

ファイルに入れます

1. kubectl get namespace cattle-system -o json> tmp.json

1. ファイルを編集し、ファイナライザーを削除します
   }、
   "仕様"：{
   「ファイナライザー」：[
   「kubernetes」
   ]
   }、
   編集後は次のようになります👍
   }、
   "仕様"：{
   「ファイナライザー」：[
   ]
   }、
   私たちはほとんどそこにいます👍

curl -k -H "Content-Type：application / json" -X PUT --data-binary @ tmp.json http://127.0.0.1：8001 / api / v1 / namespaces / $ {NAMESPACE} / finalize

そしてそれはなくなった👍

すごい！！
作品

gcloudインスタンスを変更すると（ノードのアップグレードなど）、この問題が定期的に発生します。 これにより、 gcloud instances listの古いノードが新しいノードに置き換えられますが、k8s名前空間のポッドはハングしたままになります。

Reason:                    NodeLost
Message:                   Node <old node> which was running pod <pod> is unresponsive

これにより、ポッドは不明な状態のままになります。

$ kubectl get po
NAME                               READY     STATUS    RESTARTS   AGE
<pod>                              2/2       Unknown   0          39d

このため、名前空間が終了することはありません。 これがファイナライザーを変更する必要があることを意味するのか、それともUNKNOWN状態でポッドを処理する必要がある終了に関連する実際のバグがあるのか​​（またはこのような場合に名前空間を強制的に終了する方法があるべきかどうか）はわかりません）。

gcloudインスタンスを変更すると（ノードのアップグレードなど）、この問題が定期的に発生します。 これにより、 gcloud instances listの古いノードが新しいノードに置き換えられますが、k8s名前空間のポッドはハングしたままになります。

Reason:                    NodeLost
Message:                   Node <old node> which was running pod <pod> is unresponsive

これにより、ポッドは不明な状態のままになります。

$ kubectl get po
NAME                               READY     STATUS    RESTARTS   AGE
<pod>                              2/2       Unknown   0          39d

このため、名前空間が終了することはありません。 これがファイナライザーを変更する必要があることを意味するのか、それともUNKNOWN状態でポッドを処理する必要がある終了に関連する実際のバグがあるのか​​（またはこのような場合に名前空間を強制的に終了する方法があるべきかどうか）はわかりません）。

かっこいいそれは同じ問題ではありません
ノードをメンテナンスモードにする必要があります。メンテナンスモードにすると、すべてのポッドが退避し、削除/アップグレードできます。

見てください、
リソースを編集してmetadata.finalizersを削除し、不要なcrdを削除します。強制的に削除できます。

しかし、 kubernetesファイナライザーは正確に何をしますか？ このハッキングでリソースが正しくクリーンアップされないリスクはありますか？

ルークがスタックして終了した場合、これはhttps://github.com/rook/rook/blob/master/Documentation/ceph-teardown.mdに役立ちました

curl -k -H "Content-Type：application / json" -X PUT --data-binary @ tmp.json https：// kubernetes-cluster-ip / api / v1 / namespaces / annoying-namespace-to-delete /ファイナライズ

サーバーからのエラー（NotFound）：名前空間 "annoying-namespace-to-delete"が見つかりません

まず、小さなコーヒーを飲んでリラックスしてから、k8sマスターノードに移動します

1. kubectlcluster-info
   Kubernetesマスターはhttps：// localhost ：6443で実行されてい
   KubeDNSはhttps：// localhost ：6443 / api / v1 / namespaces / kube-system / services / kube- dns：dns / proxyで実行されています

クラスタの問題をさらにデバッグおよび診断するには、「kubectlcluster-infodump」を使用します。

1. kube-proxyを実行します
   kubectlプロキシ＆
   127.0.0.1:8001でサービスを開始

IDを保存して、後で削除します:)

1. 削除しないと決めた名前空間を見つけてください:)私たちにとっては牛システムになります
   kubectl get ns
   牛システムは1dを終了します

ファイルに入れます

1. kubectl get namespace cattle-system -o json> tmp.json

1. ファイルを編集し、ファイナライザーを削除します
   }、
   "仕様"：{
   「ファイナライザー」：[
   「kubernetes」
   ]
   }、
   編集後は次のようになります👍
   }、
   "仕様"：{
   「ファイナライザー」：[
   ]
   }、
   私たちはほとんどそこにいます👍

curl -k -H "Content-Type：application / json" -X PUT --data-binary @ tmp.json http://127.0.0.1：8001 / api / v1 / namespaces / $ {NAMESPACE} / finalize

そしてそれはなくなった👍

無効な値：「編集されたファイルは検証に失敗しました」：ValidationError（Namespace.spec）：io.k8s.api.core.v1.NamespaceSpecのタイプが無効です：「文字列」を取得しました。「マップ」が必要です。

終了時に多くの名前空間がスタックしている場合は、これを自動化できます。

kubectl get ns | grep Terminating | awk '{print $1}' | gxargs  -n1 -- bash -c 'kubectl get ns "$0" -o json | jq "del(.spec.finalizers[0])" > "$0.json"; curl -k -H "Content-Type: application/json" -X PUT --data-binary @"$0.json" "http://127.0.0.1:8001/api/v1/namespaces/$0/finalize" '

ファイナライザーを削除するすべての名前空間が実際にTerminatingことを確認してください。

上記を機能させるには、 kubectl proxy実行し、 jqを実行する必要があります。

私たちの場合、メトリックAPIサービスがダウンしており、詳細ログからこのエラーログを確認できます

kubectl delete ns <namespace-name> -v=7
.......
I0115 11:03:25.548299   12445 round_trippers.go:383] GET https://<api-server-url>/apis/metrics.k8s.io/v1beta1?timeout=32s
I0115 11:03:25.548317   12445 round_trippers.go:390] Request Headers:
I0115 11:03:25.548323   12445 round_trippers.go:393]     Accept: application/json, */*
I0115 11:03:25.548329   12445 round_trippers.go:393]     User-Agent: kubectl/v1.11.3 (darwin/amd64) kubernetes/a452946
I0115 11:03:25.580116   12445 round_trippers.go:408] Response Status: 503 Service Unavailable in 31 milliseconds

メトリックapiserviceを修正した後、メトリックの終了が完了します。
削除がメトリクスapiserviceに依存する理由がよくわかりません。また、メトリクスapiserviceがクラスターにインストールされていない場合にどのように機能するかを知りたいと考えています。

削除がメトリックapiserviceに依存する理由がよくわかりません。

@manojbadamメトリックはAPIサーバーに登録されているため、名前空間の削除を実行するときに、その名前空間に関連付けられている（名前空間が設定された）リソース（存在する場合）を外部APIに照会する必要があります。 拡張サーバーが利用できない場合、Kubernetesはすべてのオブジェクトが削除されたことを保証できません。また、ルートオブジェクトが削除されているため、後で調整するための永続的なメカニズム（メモリまたはディスク内）がありません。 これは、登録済みのAPI拡張サービスで発生します。

私は常にこれに遭遇していたので、小さなシェルスクリプトでこれを自動化しました：

https://github.com/ctron/kill-kube-ns/blob/master/kill-kube-ns

プロジェクトをフェッチし、JSONを修正し、「kubectlプロキシ」を開始して適切に停止します…

私を正しい方向に向けてくれたみんなに感謝します！

私は常にこれに遭遇していたので、小さなシェルスクリプトでこれを自動化しました：

https://github.com/ctron/kill-kube-ns/blob/master/kill-kube-ns

プロジェクトをフェッチし、JSONを修正し、「kubectlプロキシ」を開始して適切に停止します…

私を正しい方向に向けてくれたみんなに感謝します！

私のヒーロー！ <3

私もこの問題に遭遇しました。 私はGoogleKubernetes Engineを使用しており、Terraformを使用してKubernetesクラスターを起動し、クラスター内に名前空間とポッドを作成しています。 terraform destroy実行した後、しばらくして問題が発生しました。

私の場合、これはTerraformが破棄を実行する順序の問題であることが判明しました。 Terraformは、最初にノードプールを削除してから、名前空間とポッドを削除します。 しかし、（唯一の）ノードプールを削除したため、Kubernetesクラスターが壊れ、名前空間の削除が永久に「終了」してスタックする原因になりました。

@FooBarWidget私にとって同じ問題:(

私は常にこれに遭遇していたので、小さなシェルスクリプトでこれを自動化しました：

https://github.com/ctron/kill-kube-ns/blob/master/kill-kube-ns

プロジェクトをフェッチし、JSONを修正し、「kubectlプロキシ」を開始して適切に停止します…

私を正しい方向に向けてくれたみんなに感謝します！

[root@k8s-master ~]# curl -k -H "Content-Type: application/json" -X PUT --data-binary @tmp.json https://172.*****:6443/api/v1/namespaces/rook-ceph/finalize
{
"kind": "Status",
"apiVersion": "v1",
"metadata": {

},
"status": "Failure",
"message": "namespaces "rook-ceph" is forbidden: User "system:anonymous" cannot update namespaces/finalize in the namespace "rook-ceph"",
"reason": "Forbidden",
"details": {
"name": "rook-ceph",
"kind": "namespaces"
},
"code": 403

リターンコード403を受け取りました。どうすればよいですか:(

私は常にこれに遭遇していたので、小さなシェルスクリプトでこれを自動化しました：
https://github.com/ctron/kill-kube-ns/blob/master/kill-kube-ns
プロジェクトをフェッチし、JSONを修正し、「kubectlプロキシ」を開始して適切に停止します…
私を正しい方向に向けてくれたみんなに感謝します！

[root@k8s-master ~]# curl -k -H "Content-Type: application/json" -X PUT --data-binary @tmp.json https://172.*****:6443/api/v1/namespaces/rook-ceph/finalize
{
"kind": "Status",
"apiVersion": "v1",
"metadata": {

},
"status": "Failure",
"message": "namespaces "rook-ceph" is forbidden: User "system:anonymous" cannot update namespaces/finalize in the namespace "rook-ceph"",
"reason": "Forbidden",
"details": {
"name": "rook-ceph",
"kind": "namespaces"
},
"code": 403

リターンコード403を受け取りました。どうすればよいですか:(

神よ、終了する名前空間はついになくなりました。 次の方法は私にとってトリックです。

NAMESPACE=rook-ceph
kubectl proxy &
kubectl get namespace $NAMESPACE -o json |jq '.spec = {"finalizers":[]}' >temp.json
curl -k -H "Content-Type: application/json" -X PUT --data-binary @temp.json 127.0.0.1:8001/api/v1/namespaces/$NAMESPACE/finalize

同じ問題がありますが、metrics-serviceが表示されません。

私はdigitaloceanとgitlabautodevopsのk8sで遊んでいます。 私の仮定はいくつかのデジタルオーシャンブロブストレージですが、それを分析または修正する方法に迷っています。

@mingxingshitx 。 トリックを行わなかった名前空間を編集しました。 あなたのスクリプトはそれをしました。

うわー、ついにそれを取り除きました。 コマンド@mingxingshiをありがとう！

私にとっての解決策は次のとおりです。

kubectl delete apiservice v1beta1.metrics.k8s.io

私はこれの私の経験をここに残すべきだと考えました：

私は次のリソースでterraform applyしていました：

resource "helm_release" "servicer" {
  name      = "servicer-api"
  // n.b.: this is a local chart just for this terraform project
  chart     = "charts/servicer-api"
  namespace = "servicer"
  ...
}

しかし、私は舵取りの初心者で、 servicerという名前空間を作成するテンプレートを含むテンプレートを持っていました。 これにより、terraformとk8sがこの悪い状態になり、terraformが失敗し、k8sはservicer名前空間をTerminating状態のままにします。 @mingxingshiが上記で提案したことを実行すると、リソースがアタッチされていないため、名前空間が終了しました。

この問題は、名前空間を作成したテンプレートを削除し、それを作成するために舵取りに任せたときに発生しなくなりました。

問題は私にとって完全に再現可能です。 まず、 prometheus-operatorのクローンを作成します。 次に：

cd prometheus-operator/contrib/kube-prometheus
kubectl create -f manifests/ --validate=false
 ... wait ...
kubectl delete namespace monitoring

ハングします。 ただし、 kubectl delete -f manifests/を使用すると、クリーンアップは成功します。

ええ、プロメテウス-オペレーターと同じハングをしました。 スタックを解除するには、 kubectl delete -f manifests/する必要があります。
プロメテウスCRDには、誤動作しているファイナライザーがいくつかあると思います。この特定のシナリオでは、kubernetesの障害はほとんどありません。 ただし、kubernetesを使用すると、原因を簡単に見つけることができます。このスレッドの長さは、多くの原因が考えられることを示しており、特定のシナリオごとにその原因を突き止めるのは簡単ではないためです。

私はkubernetesnoobなので、ここでは多くの情報を提供できませんが、2つの名前空間が終了ステータスでスタックしています。 私のkubernetesセットアップはIBMCloud Private 3.1.2 CommunityEditionを使用しています

kubectl version
Client Version: version.Info{Major:"1", Minor:"12", GitVersion:"v1.12.4+icp", GitCommit:"3f5277fa129f05fea532de48284b8b01e3d1ab4e", GitTreeState:"clean", BuildDate:"2019-01-17T13:41:02Z", GoVersion:"go1.10.4", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"12", GitVersion:"v1.12.4+icp", GitCommit:"3f5277fa129f05fea532de48284b8b01e3d1ab4e", GitTreeState:"clean", BuildDate:"2019-01-17T13:41:02Z", GoVersion:"go1.10.4", Compiler:"gc", Platform:"linux/amd64"}

kubectl cluster-info
Kubernetes master is running at https://ip
catalog-ui is running at https://ip/api/v1/namespaces/kube-system/services/catalog-ui:catalog-ui/proxy
Heapster is running at https://ip/api/v1/namespaces/kube-system/services/heapster/proxy
image-manager is running at https://ip/api/v1/namespaces/kube-system/services/image-manager:image-manager/proxy
CoreDNS is running at https://ip/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
metrics-server is running at https://ip/api/v1/namespaces/kube-system/services/https:metrics-server:/proxy
platform-ui is running at https://ip/api/v1/namespaces/kube-system/services/platform-ui:platform-ui/proxy

kubectl get nodes
NAME          STATUS                     ROLES                          AGE   VERSION
ip1    Ready,SchedulingDisabled   etcd,management,master,proxy   23h   v1.12.4+icp
ip2   Ready                      worker                         23h   v1.12.4+icp
ip3   Ready                      worker                         23h   v1.12.4+icp

2つの名前空間が終了状態でスタックしています

kubectl get ns
NAME           STATUS        AGE
my-apps       Terminating   21h
cert-manager   Active        23h
default        Active        23h
istio-system   Active        23h
kube-public    Active        23h
kube-system    Active        23h
platform       Active        22h
psp-example    Terminating   18h
services       Active        22h

このコメントで説明されているようにファイナライザーを確認すると、 kubernetesしか表示されません。

kubectl get ns my-apps -o yaml
apiVersion: v1
kind: Namespace
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","kind":"Namespace","metadata":{"annotations":{},"name":"my-apps"}}
  creationTimestamp: 2019-04-10T18:23:55Z
  deletionTimestamp: 2019-04-11T15:24:24Z
  name: my-apps
  resourceVersion: "134914"
  selfLink: /api/v1/namespaces/my-apps
  uid: ccb0398d-5bbd-11e9-a62f-005056ad5350
spec:
  finalizers:
  - kubernetes
status:
  phase: Terminating

ファイナライザーからkubernetesを削除しようとしましたが、機能しませんでした。 また、このコメントで説明されているjson / apiアプローチを使用してみました。 また、動作しませんでした。 すべてのノードを再起動しようとしましたが、それも機能しませんでした。

また、強制削除を実行しようとしましたが、それも機能しません

kubectl delete namespace my-apps --force --grace-period 0
warning: Immediate deletion does not wait for confirmation that the running resource has been terminated. The resource may continue to run on the cluster indefinitely.
Error from server (Conflict): Operation cannot be fulfilled on namespaces "my-apps": The system is ensuring all content is removed from this namespace.  Upon completion, this namespace will automatically be purged by the system.

私の場合、名前空間はrook-cephで、 kubectl -n rook-ceph patch cephclusters.ceph.rook.io rook-ceph -p '{"metadata":{"finalizers": []}}' --type=merge機能します。 それ以外の場合も機能するはずです。

差出人： https ：

@ManifoldFR 、私はあなたと同じ問題を抱えていて、jsonファイルでAPI呼び出しを行うことでそれを機能させることができました。
kubectl get namespace annoying-namespace-to-delete -o json > tmp.json
次に、tmp.jsonを編集して、 "kubernetes"を削除します

curl -k -H "Content-Type: application/json" -X PUT --data-binary @tmp.json https://kubernetes-cluster-ip/api/v1/namespaces/annoying-namespace-to-delete/finalize

名前空間が削除されます。

あなたのアプローチを使用しているときに問題が発生しました。次のステップのトラブルシューティングのために何をすればよいですか？

~ curl -k -H "Content-Type: application/json" -X PUT --data-binary @tmp.json https://39.96.4.11:6443/api/v1/namespaces/istio-system/finalize
{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {

  },
  "status": "Failure",
  "message": "namespaces \"istio-system\" is forbidden: User \"system:anonymous\" cannot update resource \"namespaces/finalize\" in API group \"\" in the namespace \"istio-system\"",
  "reason": "Forbidden",
  "details": {
    "name": "istio-system",
    "kind": "namespaces"
  },
  "code": 403

@ManifoldFR 、私はあなたと同じ問題を抱えていて、jsonファイルでAPI呼び出しを行うことでそれを機能させることができました。
kubectl get namespace annoying-namespace-to-delete -o json > tmp.json
次に、tmp.jsonを編集して、 "kubernetes"を削除します
curl -k -H "Content-Type: application/json" -X PUT --data-binary @tmp.json https://kubernetes-cluster-ip/api/v1/namespaces/annoying-namespace-to-delete/finalize
名前空間が削除されます。

あなたのアプローチを使用しているときに問題が発生しました。次のステップのトラブルシューティングのために何をすればよいですか？

~ curl -k -H "Content-Type: application/json" -X PUT --data-binary @tmp.json https://39.96.4.11:6443/api/v1/namespaces/istio-system/finalize
{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {

  },
  "status": "Failure",
  "message": "namespaces \"istio-system\" is forbidden: User \"system:anonymous\" cannot update resource \"namespaces/finalize\" in API group \"\" in the namespace \"istio-system\"",
  "reason": "Forbidden",
  "details": {
    "name": "istio-system",
    "kind": "namespaces"
  },
  "code": 403

私の問題は次のスクリプトで解決できます： https://github.com/ctron/kill-kube-ns/blob/master/kill-kube-ns 。

うんhttps://github.com/ctron/kill-kube-ns/blob/master/kill-kube-nsはトリックを行います

set -eo pipefail

die() { echo "$*" 1>&2 ; exit 1; }

need() {
    which "$1" &>/dev/null || die "Binary '$1' is missing but required"
}

# checking pre-reqs

need "jq"
need "curl"
need "kubectl"

PROJECT="$1"
shift

test -n "$PROJECT" || die "Missing arguments: kill-ns <namespace>"

kubectl proxy &>/dev/null &
PROXY_PID=$!
killproxy () {
    kill $PROXY_PID
}
trap killproxy EXIT

sleep 1 # give the proxy a second

kubectl get namespace "$PROJECT" -o json | jq 'del(.spec.finalizers[] | select("kubernetes"))' | curl -s -k -H "Content-Type: application/json" -X PUT -o /dev/null --data-binary @- http://localhost:8001/api/v1/namespaces/$PROJECT/finalize && echo "Killed namespace: $PROJECT"

名前空間は実際には削除されていないようです。
私の場合、 kubectl get nsは削除された名前空間を表示しませんが、 kubectl get all -n <namespace>はすべてのリソースが安全で健全であることを示します。
ノードを確認しましたが、Dockerコンテナはまだ実行されていました...

@glouisは、上記の方法を使用してファイナライザーをバイパスしたため、Kubernetesにはこれらの重要な削除タスクをすべて実行する時間がありませんでした。

多くの人がその結果を理解せずにこの方法を盲目的に主張しているのを見るのは本当に悲しいことです。 それは非常に醜く、クラスターに大量の残り物を残す可能性があります。 @javierprovechoはすでに上記で言及しており、 @ liggittは別のGitHubの問題でも言及しています。

壊れたv1beta1.metrics.k8s.io APIサービスを修正するか、不要な場合は削除することをお勧めします。

＃73405も参照してください

2番目の@antoinecoメッセージ。 名前空間が常にスタックしているため、サンドボックス環境の1つでこれをテストしました。 約1か月後、すべてのDockerデーモンが理由もなくフリーズしました。 リソースを残しておくことで、大量のメモリリークが発生したことがわかりました。

多くの試行錯誤の末、これらのコメントを読んだ結果、名前空間のcoreosgrafanaスタックのカスタムリソース定義であることが判明しました。 CRDを一覧表示すると、その名前空間の特定のリソースが表示されました。 CRDの名前に名前空間が詰まっているのはとても幸運でした。

また、スタックした名前空間が1つあると、削除する名前空間がそれ以上停止することも判明しました。 したがって、CRDがスタックしていない名前空間Aがあり、CRDがスタックしている名前空間Bがある場合でも、AのすべてのリソースはBがなくなるまで残ります。 名前空間Aで上記の修正を行ったに違いないと思いますが、毎回大量のリソースが残っています。

まだ私を殺しているのは、CRDの削除に失敗した名前空間のクリーンアップ、または現在実行していることを示すログを一生見つけることができないことです。 私はそれがどのCRDに固執しているかを理解するためだけに1時間を費やさなければなりませんでした。 誰かがより多くの情報を取得する方法についてアイデアを持っているので、私は素晴らしいだろうスタックされたリソースを理解するために膨大な時間を費やす必要はありません。

@jecafarelli本番クラスターの良いヒント。 しかし、私にとって残念なことに、私はそれ以外の方法でそれを殺すことができませんでした。 また、後でクラスター全体を再作成することもわかっていました。

私は問題を分析しようとしましたが、このスレッドでは他の方法で問題を解決するのに役立ちませんでした。

この公式ソリューションは私を助けました： https ：
これはkubectl edit namespace rook-cephと同じではありません。 _ "finalizers" _を削除してPUTリクエストするまで、この問題を解決できませんでした。

さて、coreosでこれに再び遭遇し、もう少し深く掘り下げました。 これは、名前空間が設定されたクラスター全体のリソース定義が原因であることが最も確実であり、さらに、coreosの情報を照会できないため、削除できなかった可能性があります。 apiグループに関する情報を取得しようとしたときにエラーを示したエラーをapiserverログで見つけました。 上記の問題を使用して、nsがスタックする原因となったリソースを一覧表示する簡単なスクリプトを作成しました。

私が再びそれに遭遇し、私が遭遇した他の名前空間リソースを追加し続ける場合、おそらく将来これを使用するだけです。

for ns in `kubectl get ns --field-selector status.phase=Terminating -o name | cut -d/ -f2`; 
do
  echo "apiservice under namespace $ns"
  kubectl get apiservice -o json |jq --arg ns "$ns" '.items[] |select(.spec.service.namespace != null) | select(.spec.service.namespace == $ns) | .metadata.name ' --raw-output
  echo "api resources under namespace $ns"
  for resource in `kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get -o name -n $ns`; 
  do 
    echo $resource
  done;
done

どうもありがとう

cert-manager名前空間内のOpenShiftクラスターにcert-managerをインストールしましたが、この名前空間を削除しようとすると、終了状態でスタックしました。 oc delete apiservices v1beta1.admission.certmanager.k8s.io実行すると問題が解決したようで、名前空間はなくなりました。

どうもありがとう

cert-manager名前空間内のOpenShiftクラスターにcert-managerをインストールしましたが、この名前空間を削除しようとすると、終了状態でスタックしました。 oc delete apiservices v1beta1.admission.certmanager.k8s.io実行すると問題が解決したようで、名前空間はなくなりました。

ここでも同じですが、 kubectl delete -f https://raw.githubusercontent.com/jetstack/cert-manager/release-0.8/deploy/manifests/00-crds.yamlを実行すると役に立ちました

GKEのバージョン1.13.6でもこのエラーが発生したと言って、チャイムを鳴らします。 これは、完全に制御するために手動でインストールすることを目的として、GKEのIstioアドオンを無効にした後に発生しました。
これは私がこれまで読んだ中で最も長い問題のスレッドであり、この問題の根本に真のコンセンサスや再現手順がないことに驚いています。 それは非常に多くの異なる方法でつまずく可能性があるようです:(

上記で何度も言及され、 https：//success.docker.com/article/kubernetes-namespace-stuck-in-terminationに文書化されているJSONおよびcurl / proxyメソッドは、私を救ったものです。

https://success.docker.com/article/kubernetes-namespace-stuck-in-terminationでのアドバイスは積極的に有害であり、同じ名前の名前空間が後で再作成された場合、孤立したリソースがクリーンアップされて再表示されない可能性があります。

ハングした削除の特定の原因を明らかにするための作業が進行中ですが、根本的な問題は、クリーンアップされたことを確認できないAPIタイプがあるため、名前空間の削除は確認されるまでブロックされることです。

また、この名前空間付きapiserviceをインストールするKnativeでこれをヒットしました。

---
apiVersion: apiregistration.k8s.io/v1beta1
kind: APIService
metadata:
  labels:
    autoscaling.knative.dev/metric-provider: custom-metrics
    serving.knative.dev/release: v0.7.1
  name: v1beta1.custom.metrics.k8s.io
spec:
  group: custom.metrics.k8s.io
  groupPriorityMinimum: 100
  insecureSkipTLSVerify: true
  service:
    name: autoscaler
    namespace: knative-serving
  version: v1beta1
  versionPriority: 100
---

それを削除した後、knative-servingnsと他のスタックした名前空間の束の両方がクリーンアップされました。 上記のbashスクリプトを提供してくれた
これはひどいPowerShellバージョンです。

$api = kubectl get apiservice -o json  | convertfrom-json
#list out the namespaced api items can ignore kube-system
$api.items | % { $_.spec.service.namespace }
#repalce knative-serving with whatever namespace you found
$api.items | ? { $_.spec.service.namespace -eq 'knative-serving'  } | ConvertTo-Json
#replace v1beta1.custom.metrics.k8s.io with whatever you found. 
k delete apiservice v1beta1.custom.metrics.k8s.io

私は今日同じ問題を抱えていました、そしてこのスクリプトは私のために働きました。

@ kubernetes / sig-api-machinery-misc

このバグは1年以上存在し、まだ問題です...このようなインバウンドの問題に対処するための計画は何ですか？

これは、少なくとも何が起こっているのかを理解するのに役立ちます： //github.com/kubernetes/kubernetes/pull/80962

私は同じ問題にぶつかっています

k get ns cdnamz-k8s-builder-system  -o yaml 
apiVersion: v1
kind: Namespace
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","kind":"Namespace","metadata":{"annotations":{},"labels":{"control-plane":"controller-manager"},"name":"cdnamz-k8s-builder-system"}}
  creationTimestamp: "2019-08-05T18:38:21Z"
  deletionTimestamp: "2019-08-05T20:37:37Z"
  labels:
    control-plane: controller-manager
  name: cdnamz-k8s-builder-system
  resourceVersion: "5980028"
  selfLink: /api/v1/namespaces/cdnamz-k8s-builder-system
  uid: 3xxxxxxx
spec:
  finalizers:
  - kubernetes
status:
  phase: Terminating

 k get ns 
NAME                        STATUS        AGE
cdnamz-k8s-builder-system   Terminating   4h20m

名前空間コントローラーは名前空間ステータスに条件を報告する必要があり、クライアントはそれを報告する必要があります。 KEPが必要ですが、誰かがそれを取得して検証できるのであれば、かなり簡単なはずです。

@timothyscは、 @ smarterclaytonの言うことを正確に実行しているPRが（どこかで）飛行中です（またはありました）。

これについても別のgithubの問題があると確信していますか？

ええ、PRはここにあります： https ：

私が標準と考える問題はここにあります： https ：

これが私を助けたリソースです： https ：

これは@slasshによって提案されたソリューションに似ていますが、 kubectl proxyを使用してローカルプロキシを作成し、 curlコマンドのターゲットIPを予測可能にします。

-

編集：この回答の下で数回述べたように、このソリューションはダーティハックであり、クラスター内にいくつかの依存リソースを残す可能性があります。 ご自身の責任で使用してください。おそらく、開発クラスターでの迅速な方法としてのみ使用してください（本番クラスターでは使用しないでください）。

上記のドキュメントで説明されているようにファイナライザーを直接削除すると、結果が生じる可能性があります。 削除を保留していたリソースは、名前空間が解放された後もクラスター内で定義されます。 これがファイナライザーの目的です。 nsの削除を許可する前に、すべての依存関係が削除されていることを確認します。

同様の質問で回避策が見つかりました：

NAMESPACE=<namespace-name>
kubectl proxy &
kubectl get namespace $NAMESPACE -o json |jq '.spec = {"finalizers":[]}' >temp.json
curl -k -H "Content-Type: application/json" -X PUT --data-binary @temp.json 127.0.0.1:8001/api/v1/namespaces/$NAMESPACE/finalize

同様の質問で回避策が見つかりました：

NAMESPACE=<namespace-name>
kubectl proxy &
kubectl get namespace $NAMESPACE -o json |jq '.spec = {"finalizers":[]}' >temp.json
curl -k -H "Content-Type: application/json" -X PUT --data-binary @temp.json 127.0.0.1:8001/api/v1/namespaces/$NAMESPACE/finalize

ありがとうございました！
それはうまくいきます。
この回避策を使用して簡単なアプリを作成します： https ：
私はそれを迅速な削除に使用し、誰かに役立つことを願っています。

Kubernetes1.12.2名前空間は終了状態です。 nsのyamlを変更することで、ファイナライザーを削除できる場合があります。 APIで削除することはできません。 削除できますか？ どのような状況ですか？ 具体的に追跡しましたか（前提条件：このnsにはリソースがありません）、ポインターを取得できることを願っています、ありがとうございます！

繰り返しになりますが、ファイナライザーを削除しないでください。理由があります。 代わりに、NS内のどのリソースが削除を保留しているかを確認してください。

• 利用できないためにリソースを提供していないapiserviceがあるかどうかを確認します： kubectl get apiservice|grep False
• kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get -n $your-ns-to-deleteを介してまだ存在するすべてのリソースを検索する

この問題の解決策は、クリーンアップメカニズムを短絡することではなく、クリーンアップが成功しない原因を見つけることです。

繰り返しになりますが、ファイナライザーを削除しないでください。理由があります。 代わりに、NS内のどのリソースが削除を保留しているかを確認してください。

• 利用できないためにリソースを提供していないapiserviceがあるかどうかを確認します： kubectl get apiservice|grep False
• kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get -n $your-ns-to-deleteを介してまだ存在するすべてのリソースを検索する

この問題の解決策は、クリーンアップメカニズムを短絡することではなく、クリーンアップが成功しない原因を見つけることです。

あなたはどれほど正しいか。
私の場合、Operator Framework apiserviceのポッドが削除され、終了プロセスがブロックされました。
未使用のapiserviceを削除します（kubectl delete apiservice） 問題を解決しました。

みなさん、こんにちは。コードのフリーズはほんの数日（木曜日、1日の終わり、PST）で発生するため、この問題がv1.16で解決されるか、v1.17に移行されることを確認する必要があります。 その状況についてコメントできますか？

これは現在のGKEリリースにバックポートされますか？ まだ「終了」している名前空間がいくつかあるクラスターがあります。

これを行った後でも@squarelover ？ https://github.com/kubernetes/kubernetes/issues/60807#issuecomment -524772920

@josiahbjorgaard私はPRを承認しました。これは、1.16でこれに対して行うすべてのことです。

https://github.com/kubernetes/kubernetes/pull/73405は前述のPRです

統合されました。 もっとできることはあると思いますが、今後のコメントは＃70916までどうぞ。

繰り返しになりますが、ファイナライザーを削除しないでください。理由があります。 代わりに、NS内のどのリソースが削除を保留しているかを確認してください。

• 利用できないためにリソースを提供していないapiserviceがあるかどうかを確認します： kubectl get apiservice|grep False
• kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get -n $your-ns-to-deleteを介してまだ存在するすべてのリソースを検索する

この問題の解決策は、クリーンアップメカニズムを短絡することではなく、クリーンアップが成功しない原因を見つけることです。

多くの場合、Metric-Serverがインストールされている可能性があります。 特定の名前空間にデプロイするポッドがメトリック収集を探す場合。 Metric-serverでハングします。 したがって、その名前空間内のすべてのリソースを削除した後でも、metric-serverは何らかの形でその名前空間にリンクされます。 これにより、名前空間を削除できなくなります。
この投稿は、ネームスペースを削除できない理由を特定するのに役立ちます。 だから儀式の方法。

これを試して、名前空間内のすべてのものの実際のリストを取得してください： kubernetes / kubectl＃151（コメント）

次に、オブジェクトごとにkubectl deleteまたはkubectl editを実行して、ファイナライザーを削除します。

このソリューションは私にとって役に立ちました、ありがとう。

こんにちは、みんな、

終了ステータスの名前空間を簡単に削除できるようにするスクリプトを作成しました： https ：

ありがとう。

同じ問題が発生しました。名前空間を削除すると、「終了」状態のままになります。 上記の手順に従って、yamlファイルのファイナライザーの「kubernetes」を削除しました。 できます。

ただし、なぜ追加の手順を実行する必要があるのか​​わかりません。 kubectl delete ns foonamespaceを実行し、削除する必要があります。 誰か私に理由を教えてもらえますか？ ありがとうございました！

こんにちは@ xzhang007 、

名前空間の削除が終了状態のままになる理由を発見した場合は、お知らせください。 私はしばらくの間良い答えを試しましたが、何もしませんでした。 次に、原因を見つけて修正するまで、自分の生活を楽にするスクリプトを作成しました。

ありがとうございました。

@thyales今まで答えが見つからなかったようです。

私たちの場合、私たちがいたwebhhoksとファイナライザーの1つを発見しました
使用することは、取得した名前空間に住んでいたポッドに手を差し伸べることでした
削除されました。
ポッドが削除されると、終了がスタックしました。

>>

@ xzhang007あなたが提供する回答@alvaroalemanで見たことがありますか？ 私たちにとって、それは原因が何であるかを見つけるのに十分でした。

繰り返しになりますが、ファイナライザーを削除しないでください。理由があります。 代わりに、NS内のどのリソースが削除を保留しているかを確認してください。

• 利用できないためにリソースを提供していないapiserviceがあるかどうかを確認します： kubectl get apiservice|grep False
• kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get -n $your-ns-to-deleteを介してまだ存在するすべてのリソースを検索する

この問題の解決策は、クリーンアップメカニズムを短絡することではなく、クリーンアップが成功しない原因を見つけることです。

また、この問題が解決されたときに、名前空間が終了時にスタックしている理由を明確にする方法を説明するために参照される新しいチケットがありました。 このクローズドな問題の代わりに、そこで会話をすることをお勧めします。

統合されました。 もっとできることはあると思いますが、今後のコメントは＃70916までどうぞ。

@ jeff-knurekそれは正しい方法であるはずです。 ありがとうございました。

私たちの場合、ファイナライザーを壊したのはcert-manager失敗したアップグレードでした。 https://github.com/jetstack/cert-manager/issues/1582

$ kube get apiservice

NAME                                   SERVICE                                                     AVAILABLE                  AGE
v1.                                    Local                                                       True                       43d
v1.apps                                Local                                                       True                       43d
v1.authentication.k8s.io               Local                                                       True                       43d
v1.authorization.k8s.io                Local                                                       True                       43d
v1.autoscaling                         Local                                                       True                       43d
v1.batch                               Local                                                       True                       43d
v1.coordination.k8s.io                 Local                                                       True                       43d
v1.networking.k8s.io                   Local                                                       True                       43d
v1.rbac.authorization.k8s.io           Local                                                       True                       43d
v1.scheduling.k8s.io                   Local                                                       True                       43d
v1.storage.k8s.io                      Local                                                       True                       43d
v1alpha1.certmanager.k8s.io            Local                                                       True                       3d22h
v1alpha1.crd.k8s.amazonaws.com         Local                                                       True                       43d
v1beta1.admission.certmanager.k8s.io   cert-manager/cointainers-cointainers-cert-manager-webhook   False (MissingEndpoints)   60m
v1beta1.admissionregistration.k8s.io   Local                                                       True                       43d
v1beta1.apiextensions.k8s.io           Local                                                       True                       43d
v1beta1.apps                           Local                                                       True                       43d
v1beta1.authentication.k8s.io          Local                                                       True                       43d
v1beta1.authorization.k8s.io           Local                                                       True                       43d
v1beta1.batch                          Local                                                       True                       43d
v1beta1.certificates.k8s.io            Local                                                       True                       43d
v1beta1.coordination.k8s.io            Local                                                       True                       43d
v1beta1.events.k8s.io                  Local                                                       True                       43d
v1beta1.extensions                     Local                                                       True                       43d
v1beta1.networking.k8s.io              Local                                                       True                       43d
v1beta1.node.k8s.io                    Local                                                       True                       43d
v1beta1.policy                         Local                                                       True                       43d
v1beta1.rbac.authorization.k8s.io      Local                                                       True                       43d
v1beta1.scheduling.k8s.io              Local                                                       True                       43d
v1beta1.storage.k8s.io                 Local                                                       True                       43d
v1beta1.webhook.cert-manager.io        cert-manager/cointainers-cointainers-cert-manager-webhook   False (MissingEndpoints)   3d22h
v1beta2.apps                           Local                                                       True                       43d
v2beta1.autoscaling                    Local                                                       True                       43d
v2beta2.autoscaling                    Local                                                       True                       43d

こんにちは。
https://github.com/rancher/rancher/issues/21546#issuecomment -553635629の場合、私のケースの名前空間が終了でスタックします

多分それは役立つでしょう。

https://medium.com/@newtondev/how -to-fix-kubernetes-namespace-deleting-stuck-in-termination-state-5ed75792647e

これは私にとってチャンピオンのように機能しました

私も同じ問題に直面しましたが、今は問題なく機能しています。 次のドキュメントを参照して、問題を解決してください

@zerkmsよく、時々、それは正当なアドバイスですよね？ 多くの場合、待機中のファイナライザーは、名前空間の削除の一部として削除されたオブジェクトによって提供されていました。 この場合、もう待つ意味がないので（ファイナライズを行うことができるものはもうありません）、記事で説明されている方法でオブジェクトにパッチを適用することが唯一のオプションです。

この記事は、記事の上部にリンクされている[既知の問題]ページにリストされている適用手順によって問題が_解決されなかった_場合にのみ適用されることに注意してください。これは基本的に、リンクしたコメントが繰り返すアドバイスです。

@zerkmsよく、時々、それは正当なアドバイスですよね？ 多くの場合、待機中のファイナライザーは、名前空間の削除の一部として削除されたオブジェクトによって提供されていました。

名前空間のspec.finalizerにこれが当てはまるのを見たことがありません。 私が見たすべてのインスタンスは、名前空間クリーンアップコントローラーに関係しており、名前空間内の永続オブジェクト（そのアドバイスはetcdに取り残される）、または応答しない集約API（名前空間spec.finalizerを削除するとスキップする）のいずれかが原因で発生しました待って、そのAPIから永続化されたリソースを取り残します）

この記事では、名前空間のファイナライズをバイパスすると、名前空間のリソースがストレージに取り残されるリスクがあることを警告していないため、お勧めしません。

名前空間のspec.finalizerに当てはまるのを見たことがありません

はい、そうです。これは、このファイナライザーがkubernetes自体によって実装されているためですが、その名前空間内のオブジェクトに他のファイナライザーが存在する可能性があり、その名前空間内のオブジェクトによって実装される可能性があります。 私が最近遭遇した1つの例は、 https://appscode.com/products/stash/ 。

stash-operatorデプロイメントによってサービスされるCRDの一部にファイナライザーを配置します。 ただし、stash-operatorがすでに削除されているため、これらのCRDからファイナライザーマークを削除できるものはなく、名前空間の削除がスタックします。 この場合、それらのファイナライザー（名前空間自体ではなく、それらのオブジェクト）にパッチを適用することが唯一の賢明なことです。

それが理にかなっていることを願っています。

この場合、それらのファイナライザー（名前空間自体ではなく、それらのオブジェクト）にパッチを適用することが唯一の賢明なことです。

正しい。 「すべてのリソースを削除する」クリーンアップシナリオではこれに反対しませんが、リンクされた記事では説明していません...名前空間からspec.finalizerを削除する方法について説明しています。

まず、小さなコーヒーを飲んでリラックスしてから、k8sマスターノードに移動します

kubectlcluster-info
Kubernetesマスターはhttps：// localhost ：6443で実行されてい
KubeDNSはhttps：// localhost ：6443 / api / v1 / namespaces / kube-system / services / kube- dns：dns / proxyで実行されています
クラスタの問題をさらにデバッグおよび診断するには、「kubectlcluster-infodump」を使用します。

kube-proxyを実行します
kubectlプロキシ＆
127.0.0.1:8001でサービスを開始
IDを保存して、後で削除します:)

1. 削除しないと決めた名前空間を見つけてください:)私たちにとっては牛システムになります
   kubectl get ns
   牛システムは1dを終了します

ファイルに入れます

1. kubectl get namespace cattle-system -o json> tmp.json

ファイルを編集し、ファイナライザーを削除します
}、
"仕様"：{
「ファイナライザー」：[
「kubernetes」
]
}、
編集後は次のようになります👍
}、
"仕様"：{
「ファイナライザー」：[
]
}、
私たちはほとんどそこにいます👍
curl -k -H "Content-Type：application / json" -X PUT --data-binary @ tmp.json http://127.0.0.1：8001 / api / v1 / namespaces / $ {NAMESPACE} / finalize

そしてそれはなくなった👍

繰り返しになりますが、ファイナライザーを削除しないでください。理由があります。 代わりに、NS内のどのリソースが削除を保留しているかを確認してください。

• 利用できないためにリソースを提供していないapiserviceがあるかどうかを確認します： kubectl get apiservice|grep False
• kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get -n $your-ns-to-deleteを介してまだ存在するすべてのリソースを検索する

この問題の解決策は、クリーンアップメカニズムを短絡することではなく、クリーンアップが成功しない原因を見つけることです。

ねえ、みんな！ @alvaroalemanから提供されたヒントに従い、た名前空間のハード削除を行う前に、クリーンな削除を検査して

スクリプトhttps://github.com/thyarles/knskの機能：

1. 利用できないapiresourcesを確認し、削除するように依頼します
2. 名前空間で保留中のリソースを確認し、削除するように依頼します
3. スクリプトが削除を行う場合、Kubernetesが完全な削除を行うかどうかを確認するために約5分待ちます
4. スタックした名前空間の強制削除

それが役に立てば幸い。

@thyarlesありがとうございます。 私はあなたのやり方で問題を解決しました。

$ kubectlはapiservicesを取得して、使用できないサービスを確認します。$ kubectl delete apiservice [service-name]によって、使用可能なサービスを削除するとfalseになります。その後、名前空間の削除に関する問題は発生しません。

私たちのチームには、v1beta1.admission.certmanager.k8s.io、v1beta1.metrics.k8s.io、v1beta1.webhook.certmanager.k8s.ioの3つの利用できないapiserviceがあります。

メトリックapiserverが実行されていない場合、クラスターは多少壊れていることに注意してください。APIServiceを削除しただけでは、根本的な原因は実際には修正されません。

@lavalampメトリックは利用できないapiserviceです。

はい。これは、メトリックapiserverが実行されていないことを意味します。つまり、HPAがクラスターで機能しないことを意味し、おそらく他のことも同様です。

はい。 HPAは現在機能していません。 メトリックを削除して修正する方法を見つけるべきではありません。

@thyarlesありがとうございます。 私はあなたのやり方で問題を解決しました。

$ kubectlはapiservicesを取得して、使用できないサービスを確認します。$ kubectl delete apiservice [service-name]によって、使用可能なサービスを削除するとfalseになります。その後、名前空間の削除に関する問題は発生しません。

私たちのチームには、v1beta1.admission.certmanager.k8s.io、v1beta1.metrics.k8s.io、v1beta1.webhook.certmanager.k8s.ioの3つの利用できないapiserviceがあります。

@ xzhang007聞いてうれしい！ 次に、v1beta1.metrics.k8s.ioが壊れた理由を確認する必要があります。 それがどのように望むかを確認してください：

`` `
$ kubectl -n kube-system get all | grepメトリック

pod / metrics-server-64f74f8d47-r5vcq2 / 2実行中9119d
service / metrics-サーバーClusterIPxx.xx.xx.xx443 / TCP 201d
Deployment.apps / metrics-サーバー1/11 1 201d
Replicaset.apps / metrics-server-55c7f68d94 0 0 0 165d
Replicaset.apps / metrics-server-5c696bb6d7 0 0 0 201d
およびreplicaset.apps / metrics-server-5cdb8bb4fb0 0 0 201d
Replicaset.apps / metrics-server-64f74f8d47 1 1 1 119d
Replicaset.apps / metrics-server-686789bb4b 0 0 0 145d```

$ kubectl -n kube-system get all | grepメトリック

pod / metrics-server-5dcfd4dd9f-m2v9k1 / 1実行中02d20h

service / metrics-サーバーClusterIPxx.xx.xx.xx443 / TCP 27d

Deployment.apps / metrics-サーバー1/11 1 27d

およびreplicaset.apps / metrics-server-5dcfd4dd9f1 1 1 27d
Replicaset.apps / metrics-server-7fcf9cc98b 0 0 0 27d

はい。 HPAは現在機能していません。 メトリックを削除して修正する方法を見つけるべきではありません。

@ xzhang007実際、問題に気付く前は機能しません。削除された名前空間がスタックモードになっているため、気づいただけです。 ヘルムパッケージマネージャーを使用してメトリックサーバーを再デプロイするか、次のコマンドを呼び出して修正します（適用する前にデプロイメントファイルを確認してください）。

$ curl https://raw.githubusercontent.com/kubernetes/kubernetes/master/cluster/addons/metrics-server/metrics-server-deployment.yaml | kubectl apply -f -

@slasshソリューションはKubernetes1.15で私のために働いた

v1beta1.metrics.k8s.ioAPIServiceを削除します

kubectl get ns ns-to-delete -o yaml

...
status:
  conditions:
  - lastTransitionTime: "2020-01-08T05:36:52Z"
    message: 'Discovery failed for some groups, 1 failing: unable to retrieve the
      complete list of server APIs: metrics.k8s.io/v1beta1: the server is currently
      unable to handle the request'
...

kubectl get APIService
...
v1beta1.metrics.k8s.io                 kube-system/metrics-server   False (ServiceNotFound)

 kubectl delete v1beta1.metrics.k8s.io APIService

cert-managerは、正しく設定されていないために使用できませんでした。 たとえば、入力コントローラで間違った構文を使用します。 私たちのシステムでは、

"certmanager.k8s.io/cluster-issuer": "letsencrypt-prod"

そしてそれはに変更されました

"cert-manager.io/cluster-issuer": "letsencrypt-prod"

それを利用可能にします。

この号で前述したように、 kubectl replace --rawが利用可能な最新バージョンのkubectlを使用して、kubectlによって公開されていないAPIを使用して名前空間を終了する別の方法があります（どのバージョンからかはわかりません）。 この方法は、あなたが出現する必要はありませんkubectl proxyでのプロセスと回避の依存関係をcurl （busyboxのようないくつかの環境では利用できないこと）。 これが他の誰かを助けることを願って、私はこれをここに残しました：

kubectl get namespace "stucked-namespace" -o json \
            | tr -d "\n" | sed "s/\"finalizers\": \[[^]]\+\]/\"finalizers\": []/" \
            | kubectl replace --raw /api/v1/namespaces/stucked-namespace/finalize -f -

これが修正可能な問題であるかどうかは確認されていますか？ ここでは多くのハッキーな解決策のようですが、名前空間を削除できないという根本的な問題に対処するものは何もありません。
私はEKSv1.14クラスターにこれを持っています

これが修正可能な問題であるかどうかは確認されていますか？ ここでは多くのハッキーな解決策のようですが、名前空間を削除できないという根本的な問題に対処するものは何もありません

基本的な問題は、クラスター内の集約されたAPIグループが使用できないことです。 名前空間クリーンアップコントローラーは、すべてのAPIが使用可能になるまでブロックすることを意図しているため、すべてのAPIグループのすべてのリソースがその名前空間に対してクリーンアップされていることを確認できます。

APIをカールさせようとしているpplの場合：

# Check all possible clusters, as your .KUBECONFIG may have multiple contexts:
kubectl config view -o jsonpath='{"Cluster name\tServer\n"}{range .clusters[*]}{.name}{"\t"}{.cluster.server}{"\n"}{end}'

# Select name of cluster you want to interact with from above output:
export CLUSTER_NAME="some_server_name"

# Point to the API server referring the cluster name
APISERVER=$(kubectl config view -o jsonpath="{.clusters[?(@.name==\"$CLUSTER_NAME\")].cluster.server}")

# Gets the token value
TOKEN=$(kubectl get secrets -o jsonpath="{.items[?(@.metadata.annotations['kubernetes\.io/service-account\.name']=='default')].data.token}"|base64 --decode)

# Explore the API with TOKEN
curl -X GET $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure

https://kubernetes.io/docs/tasks/administer-cluster/access-cluster-api/#without -kubectl-proxy

これを自動的に行うスクリプトを次に示します。 jq ：

#!/bin/bash

if [ -z "${1}" ] ; then
  echo -e "\nUsage: ${0} <name_of_the_namespace_to_remove_the_finalizer_from>\n"
  echo "Valid cluster names, based on your kube config:"
  kubectl config view -o jsonpath='{"Cluster name\tServer\n"}{range .clusters[*]}{.name}{"\t"}{.cluster.server}{"\n"}{end}'
  exit 1
fi

kubectl proxy --port=8901 &
PID=$!
sleep 1

echo -n 'Current context : '
kubectl config current-context 
read -p "Are you sure you want to remove the finalizer from namespace ${1}? Press Ctrl+C to abort."

kubectl get namespace "${1}" -o json \
            | jq '.spec.finalizers = [ ]' \
            | curl -k \
            -H "Content-Type: application/json" \
            -X PUT --data-binary @- "http://localhost:8901/api/v1/namespaces/${1}/finalize"

kill -15 $PID

全員：ファイナライザーの削除を自動化するスクリプトは、良いことよりも害を及ぼします。 それらは、利用できない集約されたapiserverに時限爆弾を残す可能性があります。 誰かが名前空間を再作成すると、突然、古いオブジェクトの束が再表示される場合があります。

本当の解決策は次のとおりです。

$ kubectl get api-services

# something in the list is unavailable. Figure out what it is and fix it.

# ... the namespace lifecycle controller will finish deleting the namespace.

全員：ファイナライザーの削除を自動化するスクリプトは、良いことよりも害を及ぼします。 それらは、利用できない集約されたapiserverに時限爆弾を残す可能性があります。 誰かが名前空間を再作成すると、突然、古いオブジェクトの束が再表示される場合があります。

本当の解決策は次のとおりです。

$ kubectl get api-services

# something in the list is unavailable. Figure out what it is and fix it.

# ... the namespace lifecycle controller will finish deleting the namespace.

https://github.com/thyarles/knsk

このスクリプトはすべてのチェックを実行し、孤立したリソースの検索を含め、完全な削除を試みます。 ユーザーがリスクを冒したい場合、スクリプトは、推奨されない削除方法を実行するための--forceオプションを提供します。

タイプミス、apiservicesである必要があります

このコマンドは、使用できないAPIを表示します。

kubectl get apiservices --template='{{range $api := .items}}{{range $api.status.conditions}}{{if eq .type "Available"}}{{$api.metadata.name}} {{.status}}{{"\n"}}{{end}}{{end}}{{end}}' | grep -i false

この記事はきっとあなたに役立つでしょう：

https://access.redhat.com/solutions/5038511

実際に存在するのはAPIサービスの競合であり、openshiftでAPIのヘルスステータスを検証できます。

oc get apiservices -o = custom-columns = " name：.metadata.name 、 status：.status.conditions [0] .status"

失敗したAPIは、それを再起動し、そのAPIに属するポッドまたはデプロイを再起動する必要があります。その後、名前空間を削除しようとします。

$ oc delete namspace

そして準備ができて、ビジネスは修正されました!!

誰もが英語を話すことに同意する場所であなた自身の言語を使用することはかなり失礼です。 👎

誰もが英語を話すことに同意するのはどこですか？

17時58分theAkitoの木、2020年4月30日に[email protected]書きました：

みんながいる場所で自分の言語を使うのはかなり無礼です
英語を話すことに同意します。 👎

—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/kubernetes/kubernetes/issues/60807#issuecomment-622137770 、
または購読を解除する
https://github.com/notifications/unsubscribe-auth/ALGMKB6K4OU4X3XOYMALOBLRPHYCDANCNFSM4ETUOEPA
。

>>

クリス、リードアーキテクト@ brace.ai

-

守秘義務の通知：このメールは、
意図された受信者であり、機密、専有、または
特権情報。 あなたが意図された受信者でない場合、あなたは
使用、レビュー、配布、コピー、または実行されたアクションに基づいて通知された
このメッセージまたはその添付ファイルがある場合は、それを禁止します。 そうでない場合
目的の受信者は、返信メールで送信者に連絡し、
元のメッセージと添付ファイルのすべてのコピーを破棄または削除します。

準備ができて、すみません、それは私のスピードのためでした、それは修正されました

私たちは多言語のユーザーベースを持っています、それは私たちのツールのどれも国際化されていないのに十分悪いです、私たちは少なくともここgithubでいいことができます。

@teoincontatto

この号で前述したように、 kubectl replace --rawが利用可能な最新バージョンのkubectlを使用して、kubectlによって公開されていないAPIを使用して名前空間を終了する別の方法があります（どのバージョンからかはわかりません）。 この方法は、あなたが出現する必要はありませんkubectl proxyでのプロセスと回避の依存関係をcurl （busyboxのようないくつかの環境では利用できないこと）。 これが他の誰かを助けることを願って、私はこれをここに残しました：

kubectl get namespace "stucked-namespace" -o json \
            | tr -d "\n" | sed "s/\"finalizers\": \[[^]]\+\]/\"finalizers\": []/" \
            | kubectl replace --raw /api/v1/namespaces/stucked-namespace/finalize -f -

これは完璧に機能しました！

私たちは多言語のユーザーベースを持っています、それは私たちのツールのどれも国際化されていないのに十分悪いです、私たちは少なくともここgithubでいいことができます。

私たちは多言語のユーザーベースを持っています、それは私たちのツールのどれも国際化されていないのに十分悪いです、私たちは少なくともここgithubでいいことができます。

まだ理解しようとしています。 私を許して。 誤って親指を下にクリックした可能性があります。
はい、確かに、ツールは完璧に行われていません。
説明なしで親指を下に向けるそれらは、意味がありません。

私がこの問題を経験するほとんどの場合、それはCRD次第です。 CRDがその名前空間でのみ使用されている場合は削除してから、ファイナライザーと名前空間の削除に進むことができます。

この号で前述したように、 kubectl replace --rawが利用可能な最新バージョンのkubectlを使用して、kubectlによって公開されていないAPIを使用して名前空間を終了する別の方法があります（どのバージョンからかはわかりません）。 この方法は、あなたが出現する必要はありませんkubectl proxyでのプロセスと回避の依存関係をcurl （busyboxのようないくつかの環境では利用できないこと）。 これが他の誰かを助けることを願って、私はこれをここに残しました：

kubectl get namespace "stucked-namespace" -o json \
            | tr -d "\n" | sed "s/\"finalizers\": \[[^]]\+\]/\"finalizers\": []/" \
            | kubectl replace --raw /api/v1/namespaces/stucked-namespace/finalize -f -

@teoincontattoありがとうございます！ これはついにうまくいきました！

オンラインでリソースマニフェストを編集するだけではうまく機能しない場合があります（つまり、提出されたfinalizers削除して保存します）。
それで、私は他の人からいくつかの新しい方法を得ました。

kubectl get namespace linkerd -o json > linkerd.json

# Where:/api/v1/namespaces/<your_namespace_here>/finalize
kubectl replace --raw "/api/v1/namespaces/linkerd/finalize" -f ./linkerd.json

そのコマンドを実行した後、名前空間は名前空間リストに存在しないはずです。そしてそれは私のために働きます。

namespaceだけでなく、他のリソースもサポートします。

kubectl edit annoying-nsを使用してファイナライザー行を削除することで問題を修正しました

うーん...私は今この問題を抱えています:)
今日、eksクラスターを1.15から1.16に更新しました。
これまでのところ、すべてが正常に見えます。
しかし、私の開発ns「configcluster」は一種の「損傷」でした。
だから私はそれをきれいにすることにしました。

k nsconfigclusterを削除します
...。
今これはハングします（3時間+）：/

$ kubectl get namespace configcluster -o yaml
apiVersion: v1
kind: Namespace
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","kind":"Namespace","metadata":{"annotations":{},"name":"configcluster"}}
  creationTimestamp: "2020-06-19T06:40:15Z"
  deletionTimestamp: "2020-06-19T09:19:16Z"
  name: configcluster
  resourceVersion: "22598109"
  selfLink: /api/v1/namespaces/configcluster
  uid: e50f0b53-b21e-4e6e-8946-c0a0803f031b
spec:
  finalizers:
  - kubernetes
status:
  conditions:
  - lastTransitionTime: "2020-06-19T09:19:21Z"
    message: 'Discovery failed for some groups, 1 failing: unable to retrieve the
      complete list of server APIs: metrics.k8s.io/v1beta1: the server is currently
      unable to handle the request'
    reason: DiscoveryFailed
    status: "True"
    type: NamespaceDeletionDiscoveryFailure
  - lastTransitionTime: "2020-06-19T09:19:22Z"
    message: All legacy kube types successfully parsed
    reason: ParsedGroupVersions
    status: "False"
    type: NamespaceDeletionGroupVersionParsingFailure
  - lastTransitionTime: "2020-06-19T09:19:22Z"
    message: All content successfully deleted
    reason: ContentDeleted
    status: "False"
    type: NamespaceDeletionContentFailure
  phase: Terminating

足の問題でこのとげにもっとさらされるにはどうすればよいですか？

4時46分AMアンドレアス・ホーマンで金、2020年6月19日には[email protected]
書きました：

うーん...私は今この問題を抱えています:)
今日、eksクラスターを1.15から1.16に更新しました。
これまでのところ、すべてが正常に見えます。
しかし、私の開発ns「configcluster」は一種の「損傷」でした。
だから私はそれをきれいにすることにしました。

k nsconfigclusterを削除します
...。
今これはハングします（3時間+）：/

$ kubectl get namespace configcluster -o yaml
apiVersion：v1
種類：名前空間
メタデータ：
注釈：
kubectl.kubernetes.io/last-applied-configuration：|
{"apiVersion"： "v1"、 "kind"： "Namespace"、 "metadata"：{"annotations"：{}、 "name"： "configcluster"}}
CreationTimestamp： "2020-06-19T06：40：15Z"
deleteTimestamp： "2020-06-19T09：19：16Z"
名前：configcluster
resourceVersion： "22598109"
selfLink：/ api / v1 / namespaces / configcluster
uid：e50f0b53-b21e-4e6e-8946-c0a0803f031b
スペック：
ファイナライザー：

• kubernetes
  状態：
  条件：
• lastTransitionTime： "2020-06-19T09：19：21Z"
  メッセージ： '一部のグループで検出に失敗しました。1つ失敗しました：を取得できません
  サーバーAPIの完全なリスト：metrics.k8s.io/v1beta1：サーバーは現在
  リクエストを処理できません」
  理由：DiscoveryFailed
  ステータス：「True」
  タイプ：NamespaceDeletionDiscoveryFailure
• lastTransitionTime： "2020-06-19T09：19：22Z"
  メッセージ：すべてのレガシーkubeタイプが正常に解析されました
  理由：ParsedGroupVersions
  ステータス：「False」
  タイプ：NamespaceDeletionGroupVersionParsingFailure
• lastTransitionTime： "2020-06-19T09：19：22Z"
  メッセージ：すべてのコンテンツが正常に削除されました
  理由：ContentDeleted
  ステータス：「False」
  タイプ：NamespaceDeletionContentFailure
  フェーズ：終了

—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/kubernetes/kubernetes/issues/60807#issuecomment-646543073 、
または購読を解除する
https://github.com/notifications/unsubscribe-auth/AFLKRCLHIZ77X2Z3F5GAOCTRXMXVTANCNFSM4ETUOEPA
。

@bobhenkelまあ、この問題はクローズされているので、事実上、これは問題がないことを意味します（実行可能な項目に関する限り）。 同様の状況に対処するための実際的な支援が必要な場合は、上記のスレッドをお読みください。そこにはいくつかの良いアドバイスがあります（また、いくつかの悪いアドバイスもあります）。

私の場合、GCPネットワークサービスコンソールから入力ロードバランサーを手動で削除する必要がありました。 ロードバランサーのフロントエンドをコンソールで直接手動で作成しました。 ロードバランサーを削除すると、名前空間は自動的に削除されました。

ロードバランサーの状態がマニフェストの状態と異なっていたため、Kubernetesは削除したくないと考えています。

次にアノテーションを使用して入力フロントエンドの作成を自動化し、この問題を解決できるかどうかを確認します。

オンラインでリソースマニフェストを編集するだけではうまく機能しない場合があります（つまり、提出されたfinalizers削除して保存します）。
それで、私は他の人からいくつかの新しい方法を得ました。

kubectl get namespace linkerd -o json > linkerd.json

# Where:/api/v1/namespaces/<your_namespace_here>/finalize
kubectl replace --raw "/api/v1/namespaces/linkerd/finalize" -f ./linkerd.json

そのコマンドを実行した後、名前空間は名前空間リストに存在しないはずです。そしてそれは私のために働きます。

namespaceだけでなく、他のリソースもサポートします。

あなたはそれが働いたスターです

オンラインでリソースマニフェストを編集するだけではうまく機能しない場合があります（つまり、提出されたfinalizers削除して保存します）。
それで、私は他の人からいくつかの新しい方法を得ました。

kubectl get namespace linkerd -o json > linkerd.json

# Where:/api/v1/namespaces/<your_namespace_here>/finalize
kubectl replace --raw "/api/v1/namespaces/linkerd/finalize" -f ./linkerd.json

そのコマンドを実行した後、名前空間は名前空間リストに存在しないはずです。そしてそれは私のために働きます。

namespaceだけでなく、他のリソースもサポートします。

多くの解決策を試しましたが、これは私のために働いたものです。 ありがとうございました！

curl -k -H "Content-Type：application / json" -X PUT --data-binary @ tmp.json https：// kubernetes-cluster-ip / api / v1 / namespaces / annoying-namespace-to-delete /ファイナライズ

より良いhttps://stackoverflow.com/a/59667608/429476

これは本当に「受け入れられた」答えであるはずです-それはこの問題の根本を完全に解決しました！

上記のリンクから取得します。

これは、特に実稼働環境では正しい方法ではありません。

今日、私は同じ問題に直面しました。 ファイナライザーを削除すると、さまざまな状態で残り物ができてしまいます。 実際に、削除が完了しない原因を見つける必要があります。

https://github.com/kubernetes/kubernetes/issues/60807#issuecomment-524772920を参照して

（また、残念ながら、「kubetctl getall」はすべてを報告するわけではありません。リンクのように同様のコマンドを使用する必要があります）

私の場合—「cert-manager」名前空間を削除します。 'kubectl get apiservice -o yaml'の出力で、status = FalseのAPIService'v1beta1.admission.certmanager.k8s.io 'が見つかりました。 このapiserviceは、削除したcert-managerの一部でした。 そのため、「kubectl delete apiservice v1beta1.admission.certmanager.k8s.io」から10秒で、名前空間が消えました。

お役に立てば幸いです。

そうは言っても、終了する名前空間を自動的に削除するCronJobとして1時間ごとに実行する小さなマイクロサービスを作成しました。

ここで見つけることができます： https ：

終了する名前空間を自動的に削除するCronJobとして1時間ごとに実行する小さなマイクロサービスを作成しました。

ここで見つけることができます： https ：

さらに別のワンライナー：

for ns in $(kubectl get ns --field-selector status.phase=Terminating -o jsonpath='{.items[*].metadata.name}'); do  kubectl get ns $ns -ojson | jq '.spec.finalizers = []' | kubectl replace --raw "/api/v1/namespaces/$ns/finalize" -f -; done

しかし、スタックした名前空間を削除することは良い解決策ではありません。 正しい方法は、それが動かなくなった理由を見つけることです。 非常に一般的な理由は、クラスターが名前空間をファイナライズするのを妨げる利用できないAPIサービスがあることです。
たとえば、ここではKnativeを適切に削除していません。

$ kubectl get apiservice|grep False
NAME                                   SERVICE                             AVAILABLE   AGE
v1beta1.custom.metrics.k8s.io          knative-serving/autoscaler          False (ServiceNotFound)   278d

それを削除すると問題は解決しました

k delete apiservice v1beta1.custom.metrics.k8s.io
apiservice.apiregistration.k8s.io "v1beta1.custom.metrics.k8s.io" deleted

$  k create ns test2
namespace/test2 created
$ k delete ns test2
namespace "test2" deleted
$ kgns test2
Error from server (NotFound): namespaces "test2" not found  

終了する名前空間を自動的に削除するCronJobとして1時間ごとに実行する小さなマイクロサービスを作成しました。

ここで見つけることができます： https ：

よくやった。

ラボk8sクラスターの1.18で同様の問題が発生し、他の人を助けるためにメモを追加しました。 私はメトリクスAPI、特にカスタムメトリクスを使用していました。 それらのk8sオブジェクトを削除して再作成した後、名前空間の削除で停止し、メトリックAPIエンドポイントが見つからないというエラーが発生しました。 それを別の名前空間に戻すと、すべてがすぐにクリアされました。

これは、status.conditions.messageの下の名前空間にありました。

Discovery failed for some groups, 4 failing: unable to retrieve the
complete list of server APIs: custom.metrics.k8s.io/v1beta1: the server is currently
unable to handle the request, custom.metrics.k8s.io/v1beta2: the server is currently
unable to handle the request, external.metrics.k8s.io/v1beta1: the server is
currently unable to handle the request, metrics.k8s.io/v1beta1: the server is

さらに別のワンライナー：

for ns in $(kubectl get ns --field-selector status.phase=Terminating -o jsonpath='{.items[*].metadata.name}'); do  kubectl get ns $ns -ojson | jq '.spec.finalizers = []' | kubectl replace --raw "/api/v1/namespaces/$ns/finalize" -f -; done

しかし、スタックした名前空間を削除することは良い解決策ではありません。 正しい方法は、それが動かなくなった理由を見つけることです。 非常に一般的な理由は、クラスターが名前空間をファイナライズするのを妨げる利用できないAPIサービスがあることです。
たとえば、ここではKnativeを適切に削除していません。

$ kubectl get apiservice|grep False
NAME                                   SERVICE                             AVAILABLE   AGE
v1beta1.custom.metrics.k8s.io          knative-serving/autoscaler          False (ServiceNotFound)   278d

それを削除すると問題は解決しました

k delete apiservice v1beta1.custom.metrics.k8s.io
apiservice.apiregistration.k8s.io "v1beta1.custom.metrics.k8s.io" deleted

$  k create ns test2
namespace/test2 created
$ k delete ns test2
namespace "test2" deleted
$ kgns test2
Error from server (NotFound): namespaces "test2" not found  

間違いなく最もきれいなワンライナー！ これらの「解決策」のどれも実際には根本的な問題を解決しないことに注意することが重要です。

正しい解決策については、こちらをご覧ください

つまり、メッセージは「まだもう1つのライナー」ではなく：smile：を広める必要があります。

間違いなく最もきれいなワンライナー！ これらの「解決策」のどれも実際には根本的な問題を解決しないことに注意することが重要です。

このソリューションは、すべての可能性の1つを解決します。 考えられるすべての根本原因を探して修正するには、次のスクリプトを使用します： https ：

@thyarlesとても素敵です！

名前空間の削除にmodify finalizeを使用しないでください。 エラーが発生します

名前空間が終了する原因を調べてください。 現在知られているトラブルシューティングの方向

• ポッドの終了
• cert-managerwebhookブロックセクション

私は同じ問題に遭遇します：

# sudo kubectl get ns
NAME                   STATUS        AGE
cattle-global-data     Terminating   8d
cattle-global-nt       Terminating   8d
cattle-system          Terminating   8d
cert-manager           Active        8d
default                Active        10d
ingress-nginx          Terminating   9d
kube-node-lease        Active        10d
kube-public            Active        10d
kube-system            Active        10d
kubernetes-dashboard   Terminating   4d6h
local                  Active        8d
p-2sfgk                Active        8d
p-5kdx9                Active        8d
# sudo kubectl get all -n kubernetes-dashboard
No resources found in kubernetes-dashboard namespace.
# sudo kubectl get namespace kubernetes-dashboard  -o json 
{
    "apiVersion": "v1",
    "kind": "Namespace",
    "metadata": {
        "annotations": {
            "cattle.io/status": "{\"Conditions\":[{\"Type\":\"ResourceQuotaInit\",\"Status\":\"True\",\"Message\":\"\",\"LastUpdateTime\":\"2020-09-29T01:15:46Z\"},{\"Type\":\"InitialRolesPopulated\",\"Status\":\"True\",\"Message\":\"\",\"LastUpdateTime\":\"2020-09-29T01:15:46Z\"}]}",
            "kubectl.kubernetes.io/last-applied-configuration": "{\"apiVersion\":\"v1\",\"kind\":\"Namespace\",\"metadata\":{\"annotations\":{},\"name\":\"kubernetes-dashboard\"}}\n",
            "lifecycle.cattle.io/create.namespace-auth": "true"
        },
        "creationTimestamp": "2020-09-29T01:15:45Z",
        "deletionGracePeriodSeconds": 0,
        "deletionTimestamp": "2020-10-02T07:59:52Z",
        "finalizers": [
            "controller.cattle.io/namespace-auth"
        ],
        "managedFields": [
            {
                "apiVersion": "v1",
                "fieldsType": "FieldsV1",
                "fieldsV1": {
                    "f:metadata": {
                        "f:annotations": {
                            "f:cattle.io/status": {},
                            "f:lifecycle.cattle.io/create.namespace-auth": {}
                        },
                        "f:finalizers": {
                            ".": {},
                            "v:\"controller.cattle.io/namespace-auth\"": {}
                        }
                    }
                },
                "manager": "Go-http-client",
                "operation": "Update",
                "time": "2020-09-29T01:15:45Z"
            },
            {
                "apiVersion": "v1",
                "fieldsType": "FieldsV1",
                "fieldsV1": {
                    "f:metadata": {
                        "f:annotations": {
                            ".": {},
                            "f:kubectl.kubernetes.io/last-applied-configuration": {}
                        }
                    }
                },
                "manager": "kubectl-client-side-apply",
                "operation": "Update",
                "time": "2020-09-29T01:15:45Z"
            },
            {
                "apiVersion": "v1",
                "fieldsType": "FieldsV1",
                "fieldsV1": {
                    "f:status": {
                        "f:phase": {}
                    }
                },
                "manager": "kube-controller-manager",
                "operation": "Update",
                "time": "2020-10-02T08:13:49Z"
            }
        ],
        "name": "kubernetes-dashboard",
        "resourceVersion": "3662184",
        "selfLink": "/api/v1/namespaces/kubernetes-dashboard",
        "uid": "f1944b81-038b-48c2-869d-5cae30864eaa"
    },
    "spec": {},
    "status": {
        "conditions": [
            {
                "lastTransitionTime": "2020-10-02T08:13:49Z",
                "message": "All resources successfully discovered",
                "reason": "ResourcesDiscovered",
                "status": "False",
                "type": "NamespaceDeletionDiscoveryFailure"
            },
            {
                "lastTransitionTime": "2020-10-02T08:11:49Z",
                "message": "All legacy kube types successfully parsed",
                "reason": "ParsedGroupVersions",
                "status": "False",
                "type": "NamespaceDeletionGroupVersionParsingFailure"
            },
            {
                "lastTransitionTime": "2020-10-02T08:11:49Z",
                "message": "All content successfully deleted, may be waiting on finalization",
                "reason": "ContentDeleted",
                "status": "False",
                "type": "NamespaceDeletionContentFailure"
            },
            {
                "lastTransitionTime": "2020-10-02T08:11:49Z",
                "message": "All content successfully removed",
                "reason": "ContentRemoved",
                "status": "False",
                "type": "NamespaceContentRemaining"
            },
            {
                "lastTransitionTime": "2020-10-02T08:11:49Z",
                "message": "All content-preserving finalizers finished",
                "reason": "ContentHasNoFinalizers",
                "status": "False",
                "type": "NamespaceFinalizersRemaining"
            }
        ],
        "phase": "Terminating"
    }

#  sudo kubectl version

Client Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.2", GitCommit:"f5743093fd1c663cb0cbc89748f730662345d44d", GitTreeState:"clean", BuildDate:"2020-09-16T13:41:02Z", GoVersion:"go1.15", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.2", GitCommit:"f5743093fd1c663cb0cbc89748f730662345d44d", GitTreeState:"clean", BuildDate:"2020-09-16T13:32:58Z", GoVersion:"go1.15", Compiler:"gc", Platform:"linux/amd64"}

etcdctlを使用して、削除されていないリソースを見つけることができます

ETCDCTL_API=3 etcdctl --cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/peer.crt \
--key=/etc/kubernetes/pki/etcd/peer.key \
get /registry --prefix | grep <namespace>

ターミナルにコピーして貼り付けるだけです

for NS in $(kubectl get ns 2>/dev/null | grep Terminating | cut -f1 -d ' '); do
  kubectl get ns $NS -o json > /tmp/$NS.json
  sed -i '' "s/\"kubernetes\"//g" /tmp/$NS.json
  kubectl replace --raw "/api/v1/namespaces/$NS/finalize" -f /tmp/$NS.json
done

/tmp/$NS.json

これは私にとってはうまくいき、nsにぶら下がっているk8sオブジェクトがないことを確認してから実行しました。 ありがとう！

これを使用して、終了時にスタックした名前空間を削除しました

例：

kubectl get namespace openebs -o json | jq -j '.spec.finalizers=null' > tmp.json 
kubectl replace --raw "/api/v1/namespaces/openebs/finalize" -f ./tmp.json

ランチャー固有の名前空間（例：cattle-system）での終了時にスタックした名前空間にぶつかったすべてのグーグルにとって、次の変更されたコマンド（greboisのオリジナル）が私のために機能しました：

for NS in $(kubectl get ns 2>/dev/null | grep Terminating | cut -f1 -d ' '); do
  kubectl get ns $NS -o json > /tmp/$NS.json
  sed -i "s/\"controller.cattle.io\/namespace-auth\"//g" /tmp/$NS.json
  kubectl replace --raw "/api/v1/namespaces/$NS/finalize" -f /tmp/$NS.json
done

皆さん、参考までに、このたら、それと上記の役立​​つコメントのいくつかにリンクして、この問題をロックする予定です。

何が起こっているのかについての10分間の説明を記録し、このSIG DeepDiveセッションで発表しました。

これが65の賛成票を含む正しいコメントです

上で数回言及されたこの中程度の投稿は、物事を正しい方法で行う例です。 壊れたAPIサービスを見つけて修正します。

名前空間のファイナライザーを削除するだけのすべてのワンライナーは根本原因に対処し、クラスターを微妙に壊れたままにします。これは後であなたを噛みます。 だから、そうしないでください。 とにかく、根本原因の修正は通常簡単です。 スレッドにはすでに多数の正解がありますが、人々はこのテーマのバリエーションを投稿することを好むようです。このコメントが一番下にとどまるように、今すぐ問題をロックします。