Kubernetes: suppression de l'espace de noms bloqué à l'état "Terminating"

/ sig api-machines

@ shean-guangchang Avez-vous un moyen de reproduire cela?

Et par curiosité, utilisez-vous des CRD? Nous avons déjà rencontré ce problème avec les TPR.

/ genre bug

Il semble que je rencontre ce problème avec un déploiement de rook:

➜  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) ✗ 

Je pense que cela a quelque chose à voir avec leur CRD, je vois cela dans les journaux du serveur 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

J'ai déployé rook dans un espace de noms différent maintenant, mais je ne suis pas en mesure de créer le cluster 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)

On dirait que le CRD n'a jamais été nettoyé:

➜  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) ✗ 

J'ai un espace de noms de fission dans un état similaire:

➜  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) ✗ 

La fission utilise également des CRD, cependant, ils semblent être nettoyés.

@ shean-guangchang - J'ai eu le même problème. J'ai tout supprimé manuellement sous les espaces de noms, supprimé et purgé tout de "helm" et redémarré les nœuds maîtres un par un et cela a résolu le problème.

J'imagine que ce que j'ai rencontré a quelque chose à voir avec "ark", "tiller" et Kuberenets travaillant tous ensemble (j'ai démarré avec helm et sauvegardé avec ark) donc ce n'est peut-être pas un problème de Kuberenets par exemple, de l'autre main, il était pratiquement impossible de résoudre les problèmes car il n'y a pas de journaux pertinents.

si c'est la tour, jetez un œil à ceci: https://github.com/rook/rook/issues/1488#issuecomment -365058080

Je suppose que cela a du sens, mais il semble bogué qu'il soit possible de mettre un espace de noms dans un état indélébile.

J'ai un environnement similaire (Ark & Helm) avec @barakAtSoluto et j'ai le même problème. La purge et le redémarrage des maîtres ne l'ont pas résolu pour moi. Toujours coincé à la fin.

J'avais ça aussi en essayant de recréer le problème. J'ai finalement dû créer un nouveau cluster ...
Exclure - par défaut, kube-system / public et tous les espaces de noms liés à arche de la sauvegarde et de la restauration pour éviter que cela ne se produise ...

Je vois aussi cela sur un cluster mis à niveau de 1.8.4 à 1.9.6. Je ne sais même pas quels journaux regarder

Le même problème sur 1.10.1 :(

Même problème sur 1.9.6

Modifier: l'espace de noms n'a pas pu être supprimé en raison du blocage de certains pods. J'ai fait une suppression avec --grace-period = 0 --force sur eux tous et après quelques minutes, l'espace de noms a également été supprimé.

Hey,

J'ai ça encore et encore et c'est la plupart du temps des problèmes avec les finaliseurs.

Si un espace de noms est bloqué, essayez de kubectl get namespace XXX -o yaml et vérifiez s'il y a un finaliseur dessus. Si tel est le cas, modifiez l'espace de noms et supprimez le finaliseur (en passant un tableau vide), puis l'espace de noms est supprimé

@xetys est-ce sécuritaire? dans mon cas, il n'y a qu'un seul finaliseur nommé "kubernetes".

C'est étrange, je n'ai jamais vu un tel finaliseur. Je peux simplement parler en fonction de mon expérience. J'ai fait ça plusieurs fois dans un cluster de production et c'est toujours vivant

Même problème sur 1.10.5. J'ai essayé tous les conseils dans ce numéro sans résultat. J'ai pu me débarrasser des pods, mais l'espace de noms est toujours suspendu.

En fait, les ns ont également été supprimés après un certain temps.

Il serait bon de comprendre ce qui cause ce comportement, le seul finaliseur que j'avais est kubernetes. J'ai également des webhooks dynamiques, peuvent-ils être liés?

@xetys Enfin, j'ai utilisé votre astuce sur les répliques à l'intérieur de cet espace de noms. Ils avaient un finaliseur personnalisé qui n'existait probablement plus, donc je ne pouvais pas les supprimer. Lorsque j'ai supprimé les références à ce finaliseur, elles ont disparu, tout comme l'espace de noms. Merci! :)

Même problème sur un cluster 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"}

Avoir le même problème sur un cluster bare metal:

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"}

Mon espace de noms ressemble à ceci:

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

C'est en fait le deuxième espace de noms que j'ai eu ce problème.

Essayez ceci pour obtenir la liste réelle de toutes les choses dans votre espace de noms: https://github.com/kubernetes/kubectl/issues/151#issuecomment -402003022

Ensuite, pour chaque objet, faites kubectl delete ou kubectl edit pour supprimer les finaliseurs.

la suppression de l'initialiseur a fait l'affaire pour moi ...

Lorsque je fais kubectl edit namespace annoying-namespace-to-delete et que je supprime les finaliseurs, ils sont rajoutés lorsque je vérifie avec un kubectl get -o yaml .

De plus, en essayant ce que vous avez suggéré @adampl, je n'obtiens aucune sortie (la suppression de --ignore-not-found confirme qu'aucune ressource n'est trouvée dans l'espace de noms, quel que soit son type).

@ManifoldFR , j'ai eu le même problème que le vôtre et j'ai réussi à le faire fonctionner en faisant un appel API avec un fichier json.
kubectl get namespace annoying-namespace-to-delete -o json > tmp.json
puis éditez tmp.json et supprimez "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

et il devrait supprimer votre espace de noms,

@slassh Cela a fonctionné! J'aurais dû penser à faire un appel API: merci beaucoup! Nous chanterons vos louanges pour toujours

Le problème existe dans la v1.11.1. J'ai eu un déploiement d'éleveur / barre coincé de dokuwiki. J'ai d'abord dû forcer la suppression des pods comme suggéré par @siXor , puis j'ai suivi les conseils de

@slassh comment voir le kubernetes-cluster-ip? J'utilise l'un des noeuds ip déployés le remplacement du cluster kubernetes, et il rapporte 404.

salut @jiuchongxiao , par kubernetes-cluster-ip je voulais dire l'un de vos maîtres de nœud ip.
désolé si c'est déroutant!

Si vous démarrez d'abord 'kubectl proxy', vous pouvez diriger le curl vers http://127.0.0.1 : 8001 / api / v1 / namespaces / ennoying-namespace-to-delete / finalize. Je ne pouvais pas faire fonctionner l'authentification avant de l'avoir fait de cette façon.

bons conseils @ 2stacks. Il suffit de remplacer https par http .

Je vois toujours ce problème dans 1.11.2.

Pour donner plus de contexte à la reproduction, je n'ai vu cela qu'avec les CRD. En supprimant l'objet CRD, je me suis retrouvé dans un état étrange où les objets qui lui appartenaient n'étaient pas supprimés. Je n'ai pas remarqué alors j'ai émis une suppression pour l'espace de noms. Ensuite, j'ai supprimé tous les objets de l'espace de noms avec kubectl delete all --all -n my-namespace . À ce stade, la suppression de l'espace de noms est restée bloquée. J'espère que cela aide d'une certaine manière.

En regardant les journaux, je viens de découvrir que ce problème particulier était lié au fait que le gestionnaire de contrôleur était malsain. Dans mon cas, ce n'était probablement pas un bug. Lorsque le gestionnaire de contrôleur est remonté, tout a été nettoyé correctement.

@slassh Solution parfaite! Merci beaucoup!!!!

Je vois également ce problème avec 1.10.x. Je trouve que le commentaire de Terminating ?

Nous avons découvert que la suppression des espaces de noms était bloquée dans notre cas (@palmerabollo)

Lorsqu'un espace de noms a un finaliseur kubernetes , cela signifie que c'est un problème interne avec le serveur API.

Exécutez kubectl api-resources , s'il renvoie un comme ce qui suit, cela signifie que l'API personnalisée n'est pas accessible.

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

Exécutez kubectl get apiservices v1beta1.metrics.k8s.io -o yaml , pour vérifier ses conditions d'état.

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

L'erreur ci-dessus doit être causée par un crashloopbackoff affectant le serveur de métriques. Ce serait similaire pour les autres API personnalisées enregistrées dans Kubernetes.

Vérifiez la santé de vos services dans kube-system pour restaurer les opérations d'exécution du cluster comme la suppression des espaces de noms.

Je suis confronté à ce problème sur la v1.11.3. Aux finaliseurs, seuls les kubernetes sont présents pour les espaces de noms problématiques.

spec:
  finalizers:
  - kubernetes

@slassh Merci
J'ai le même problème dans mon cluster avec ark, tiller et kubed. Je soupçonne que les problèmes pourraient être l'api de kubed qui donne une erreur, mais je ne sais pas pourquoi cela a un impact sur la suppression d'un autre espace de noms.

@javierprovecho Je

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

Savez-vous comment vous remettre de cet état?

edit: j'ai découvert ... j'ai dû supprimer _tout ce qui était lié aux métriques / HPA, puis redémarrer tout le plan de contrôle (j'ai dû en supprimer toutes mes répliques, avant de les redémarrer.) cela comprenait la suppression du apiservice v1beta1.metrics.k8s.io lui-même.

@ 2rs2ts

$ kubectl delete apiservice v1beta1.metrics.k8s.io

En se débarrassant du service API metrics fonctionne pas, le contrôleur-gestionnaire pourra supprimer le ou les espaces de noms périmés.

Il n'est pas nécessaire de redémarrer le plan de contrôle.

@antoineco non, c'était nécessaire; J'ai supprimé l'apiservice et j'ai attendu un bon moment, mais l'espace de noms ne serait pas supprimé tant que je n'ai pas redémarré le plan de contrôle.

d'abord, prenez un petit café et détendez-vous, allez maintenant aux nœuds maîtres de votre k8

1. kubectl cluster-info
   Le maître Kubernetes s'exécute sur https: // localhost : 6443
   KubeDNS s'exécute sur https: // localhost : 6443 / api / v1 / namespaces / kube-system / services / kube- dns: dns / proxy

Pour déboguer et diagnostiquer davantage les problèmes de cluster, utilisez «kubectl cluster-info dump».

1. maintenant lancez le kube-proxy
   proxy kubectl &
   Commencer à servir sur 127.0.0.1:8001

enregistrez l'ID pour le supprimer plus tard :)

1. trouvez votre nom-espace qui a décidé de ne pas être supprimé :) pour nous ce sera le système de bétail
   kubectl obtenir ns
   Système de bétail Terminating 1d

le mettre dans un fichier

1. kubectl obtenir l'espace de noms bétail-system -o json> tmp.json

1. éditer le fichier et supprimer les finaliseurs
   },
   "spec": {
   "finaliseurs": [
   "kubernetes"
   ]
   },
   après l'édition, cela devrait ressembler à ceci 👍
   },
   "spec": {
   "finaliseurs": [
   ]
   },
   nous y sommes presque 👍

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

et c'est parti 👍

Hey, le finalizer kubernetes est là pour une raison. Pour nous, il s'agissait d'un nom de service d'API de métriques mal configuré. Peut-être que pour vous, il y a autre chose que vous pouvez découvrir en regardant les journaux de votre plan de contrôle. Sans confirmation d'un bogue, la suppression du finaliseur peut produire des conséquences indésirables comme laisser des éléments créés qui ne peuvent plus être à nouveau accessibles à des fins de suppression.

car ce problème est toujours ouvert:
dans mon cluster de minikube fonctionnant avec "aucun", cela s'est produit après que l'hôte se soit réveillé de la mise en veille prolongée.

mon hypothèse:
dans mon cas, la mise en veille prolongée a déclenché les mêmes problèmes, un swap activé ferait l'affaire.

ce qui conduit à l'hypothèse:
le swap pourrait être activé dans les clusters affectés?

mais ce n'est qu'une conjecture. la chose importante pour moi, et pour quiconque atterrit dans ce bogue avec ma configuration locale: hibernate est mauvais pour kubernetes .

d'abord, prenez un petit café et détendez-vous, allez maintenant aux nœuds maîtres de votre k8

1. kubectl cluster-info
   Le maître Kubernetes s'exécute sur https: // localhost : 6443
   KubeDNS s'exécute sur https: // localhost : 6443 / api / v1 / namespaces / kube-system / services / kube- dns: dns / proxy

Pour déboguer et diagnostiquer davantage les problèmes de cluster, utilisez «kubectl cluster-info dump».

1. maintenant lancez le kube-proxy
   proxy kubectl &
   Commencer à servir sur 127.0.0.1:8001

enregistrez l'ID pour le supprimer plus tard :)

1. trouvez votre nom-espace qui a décidé de ne pas être supprimé :) pour nous ce sera le système de bétail
   kubectl obtenir ns
   Système de bétail Terminating 1d

le mettre dans un fichier

1. kubectl obtenir l'espace de noms bétail-system -o json> tmp.json

1. éditer le fichier et supprimer les finaliseurs
   },
   "spec": {
   "finaliseurs": [
   "kubernetes"
   ]
   },
   après l'édition, cela devrait ressembler à ceci 👍
   },
   "spec": {
   "finaliseurs": [
   ]
   },
   nous y sommes presque 👍

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

et c'est parti 👍

Génial!!
Travaux

Je rencontre ce problème périodiquement si nous changeons nos instances gcloud (par exemple, la mise à niveau des nœuds). Cela remplace l'ancien nœud de gcloud instances list par un nouveau mais laisse les pods dans l'espace de noms k8s en suspens:

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

Cela laisse alors les pods dans un état inconnu:

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

Pour cette raison, l'espace de noms ne finira jamais de se terminer. Je ne sais pas si cela signifie que nous devrions changer nos finaliseurs ou s'il y a un bogue réel lié à la terminaison qui devrait gérer les pods dans un état UNKNOWN (ou s'il devrait y avoir un moyen de forcer la fin d'un espace de noms pour des cas comme celui-ci ).

Je rencontre ce problème périodiquement si nous changeons nos instances gcloud (par exemple, la mise à niveau des nœuds). Cela remplace l'ancien nœud de gcloud instances list par un nouveau mais laisse les pods dans l'espace de noms k8s en suspens:

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

Cela laisse alors les pods dans un état inconnu:

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

Pour cette raison, l'espace de noms ne finira jamais de se terminer. Je ne sais pas si cela signifie que nous devrions changer nos finaliseurs ou s'il y a un bogue réel lié à la terminaison qui devrait gérer les pods dans un état UNKNOWN (ou s'il devrait y avoir un moyen de forcer la fin d'un espace de noms pour des cas comme celui-ci ).

cool ce n'est pas le même problème
vous devez mettre les nœuds en mode maintenance, puis après qu'il soit en mode maintenance, tous les pods seront évacués et vous pourrez ensuite supprimer / mettre à niveau

regardez-le ， https://kubernetes.io/docs/concepts/workloads/controllers/garbage-collection/ ,
modifier la ressource et supprimer metadata.finalizers ， et supprimer les crd inutiles ， vous pouvez le supprimer forcer

Mais que fait exactement le finaliseur kubernetes ? Y a-t-il un risque que les ressources ne soient pas correctement nettoyées avec ce hack?

Pour la tour coincée, mettre fin à cela a aidé 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 / ennoying-namespace-to-delete / finaliser

Erreur du serveur (NotFound): espaces de noms "espace de noms ennuyeux à supprimer" non trouvés

d'abord, prenez un petit café et détendez-vous, allez maintenant aux nœuds maîtres de votre k8

1. kubectl cluster-info
   Le maître Kubernetes s'exécute sur https: // localhost : 6443
   KubeDNS s'exécute sur https: // localhost : 6443 / api / v1 / namespaces / kube-system / services / kube- dns: dns / proxy

Pour déboguer et diagnostiquer davantage les problèmes de cluster, utilisez «kubectl cluster-info dump».

1. maintenant lancez le kube-proxy
   proxy kubectl &
   Commencer à servir sur 127.0.0.1:8001

enregistrez l'ID pour le supprimer plus tard :)

1. trouvez votre nom-espace qui a décidé de ne pas être supprimé :) pour nous ce sera le système de bétail
   kubectl obtenir ns
   Système de bétail Terminating 1d

le mettre dans un fichier

1. kubectl obtenir l'espace de noms bétail-system -o json> tmp.json

1. éditer le fichier et supprimer les finaliseurs
   },
   "spec": {
   "finaliseurs": [
   "kubernetes"
   ]
   },
   après l'édition, cela devrait ressembler à ceci 👍
   },
   "spec": {
   "finaliseurs": [
   ]
   },
   nous y sommes presque 👍

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

et c'est parti 👍

Valeur non valide: "Le fichier modifié a échoué à la validation": ValidationError (Namespace.spec): type non valide pour io.k8s.api.core.v1.NamespaceSpec: obtenu "string", "map" attendu

Si vous avez de nombreux espaces de noms bloqués dans Terminating, vous pouvez automatiser ceci:

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" '

assurez-vous que tous les espaces de noms que vous souhaitez supprimer sont effectivement Terminating .

Vous avez besoin de kubectl proxy cours d'exécution et de jq pour que ce qui précède fonctionne.

Dans notre cas, le service API de métriques est en panne et je peux voir ce journal des erreurs à partir de la journalisation détaillée

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

Après avoir corrigé les métriques apiservice, les terminaisons sont terminées.
Je ne sais pas vraiment pourquoi la suppression dépend de l'apiservice de métriques, également intéressé de savoir comment cela fonctionne si l'apiservice de métriques n'est pas installé sur le cluster

Je ne sais pas vraiment pourquoi la suppression dépend du service de métriques,

@manojbadam parce que les métriques sont enregistrées sur le serveur api, lors de la suppression d'un espace de noms, il doit interroger cette API externe pour les ressources (espacées de noms) à supprimer (si elles existent) associées à cet espace de noms. Si le serveur d'extension n'est pas disponible, Kubernetes ne peut pas garantir que tous les objets ont été supprimés, et il ne dispose pas d'un mécanisme persistant (en mémoire ou sur disque) pour se réconcilier plus tard car l'objet racine aurait été supprimé. Cela se produit avec n'importe quel service d'extension d'API enregistré.

Comme je rencontrais constamment cela, j'ai automatisé cela avec un petit script shell:

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

Il récupère le projet, corrige le JSON, démarre et arrête correctement "kubectl proxy",…

Merci à tous qui m'ont pointé dans la bonne direction!

Comme je rencontrais constamment cela, j'ai automatisé cela avec un petit script shell:

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

Il récupère le projet, corrige le JSON, démarre et arrête correctement "kubectl proxy",…

Merci à tous qui m'ont pointé dans la bonne direction!

mon héros! <3

J'ai aussi rencontré ce problème. Je suis sur Google Kubernetes Engine et j'utilise Terraform pour faire tourner des clusters Kubernetes et créer des espaces de noms et des pods à l'intérieur du cluster. Le problème a commencé un certain temps après l'exécution d'un terraform destroy .

Dans mon cas, cela s'avère être un problème d'ordre dans lequel Terraform exécute la destruction. Terraform supprime d'abord le pool de nœuds, puis supprime les espaces de noms et les pods. Mais en raison de la suppression du (seul) pool de nœuds, le cluster Kubernetes s'est cassé, et c'est ce qui a empêché la suppression de l'espace de noms de se "terminer" pour toujours.

@FooBarWidget même problème pour moi :(

Comme je rencontrais constamment cela, j'ai automatisé cela avec un petit script shell:

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

Il récupère le projet, corrige le JSON, démarre et arrête correctement "kubectl proxy",…

Merci à tous qui m'ont pointé dans la bonne direction!

[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

J'ai reçu un code retour 403, que dois-je faire :(

Comme je rencontrais constamment cela, j'ai automatisé cela avec un petit script shell:
https://github.com/ctron/kill-kube-ns/blob/master/kill-kube-ns
Il récupère le projet, corrige le JSON, démarre et arrête correctement "kubectl proxy",…
Merci à tous qui m'ont pointé dans la bonne direction!

[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

J'ai reçu un code retour 403, que dois-je faire :(

Thx mon Dieu, l'espace de noms de terminaison est enfin parti. La méthode suivante me convient.

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

J'ai le même problème mais je ne vois aucun service de métriques.

Je joue avec les k8 de digitalocean et gitlab auto devops. Mon hypothèse est un stockage blob digitalocean, mais je ne sais pas comment l'analyser ou le réparer.

@mingxingshi tx. A fait un espace de noms d'édition qui n'a pas fait l'affaire. Votre script l'a fait.

Wow, je m'en suis enfin débarrassé. Merci pour les commandes @mingxingshi !

La solution pour moi était:

kubectl delete apiservice v1beta1.metrics.k8s.io

je me suis juste dit que je devrais laisser mon expérience ici:

je faisais terraform apply avec la ressource suivante:

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"
  ...
}

mais je suis un helm newb et j'avais un modèle contenant un modèle qui créait un espace de noms appelé servicer . Cela a amené terraform et k8 à entrer dans ce mauvais état où terraform échouerait, puis k8s laisserait l'espace servicer noms Terminating . Faire ce que @mingxingshi suggère ci-dessus a mis fin à l'espace de noms, car il n'y avait aucune ressource attachée.

ce problème a cessé de se produire pour moi lorsque j'ai supprimé ce modèle qui a créé l'espace de noms et l'ai laissé à la barre pour le créer.

Le problème est tout à fait reproductible pour moi. Tout d'abord, clonez l' opérateur prometheus . Ensuite:

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

Bloque. Si, cependant, j'utilise kubectl delete -f manifests/ , le nettoyage est réussi.

Ouais, a eu le même coup avec l'opérateur de prométhée. Besoin de kubectl delete -f manifests/ pour décoller.
Je pense qu'il y a des finaliseurs dans les CRD prometheus qui se comportent mal, dans ce scénario particulier, ce n'est pas la faute de Kubernetes. Cependant, kubernetes devrait faciliter la recherche du coupable, car les longueurs de ce fil montrent qu'il peut y avoir de nombreuses causes et qu'il n'est pas facile d'aller au fond des choses dans chaque scénario particulier.

Je suis un noob de kubernetes, donc je ne peux pas offrir beaucoup d'informations ici, mais j'ai aussi 2 espaces de noms bloqués dans l'état de terminaison. Ma configuration kubernetes utilise IBM Cloud Private 3.1.2 Community Edition

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

J'ai deux espaces de noms bloqués dans l'état final

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

Lorsque je vérifie les finaliseurs comme décrit dans ce commentaire, je ne vois que 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

Quoi qu'il en soit, j'ai essayé de supprimer kubernetes des finaliseurs et cela n'a pas fonctionné. J'ai également essayé d'utiliser l'approche json / api décrite dans ce commentaire . Cela n'a pas fonctionné non plus. J'ai essayé de redémarrer tous les nœuds et cela n'a pas fonctionné non plus.

J'ai aussi essayé de faire la suppression forcée et cela ne fonctionne pas non plus

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.

Dans mon cas, l'espace de noms est rook-ceph, kubectl -n rook-ceph patch cephclusters.ceph.rook.io rook-ceph -p '{"metadata":{"finalizers": []}}' --type=merge fonctionne pour moi. Pour d'autres cas, cela devrait également fonctionner.

De: https://github.com/rook/rook/blob/master/Documentation/ceph-teardown.md

@ManifoldFR , j'ai eu le même problème que le vôtre et j'ai réussi à le faire fonctionner en faisant un appel API avec un fichier json.
kubectl get namespace annoying-namespace-to-delete -o json > tmp.json
puis éditez tmp.json et supprimez "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

et il devrait supprimer votre espace de noms,

J'ai un problème lors de l'utilisation de votre approche, que dois-je faire pour le dépannage de la prochaine étape?

~ 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 , j'ai eu le même problème que le vôtre et j'ai réussi à le faire fonctionner en faisant un appel API avec un fichier json.
kubectl get namespace annoying-namespace-to-delete -o json > tmp.json
puis éditez tmp.json et supprimez "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
et il devrait supprimer votre espace de noms,

J'ai un problème lors de l'utilisation de votre approche, que dois-je faire pour le dépannage de la prochaine étape?

~ 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

Mon problème peut être résolu par ce script: https://github.com/ctron/kill-kube-ns/blob/master/kill-kube-ns .

yup https://github.com/ctron/kill-kube-ns/blob/master/kill-kube-ns fait l'affaire

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"

Il semble que les espaces de noms ne soient en fait pas supprimés.
Dans mon cas, kubectl get ns n'affiche pas l'espace de noms supprimé mais un kubectl get all -n <namespace> affiche toutes les ressources saines et sauves.
J'ai vérifié les nœuds et les conteneurs docker fonctionnaient toujours ...

@glouis c'est parce que vous avez contourné les finaliseurs en utilisant la méthode ci-dessus, donc Kubernetes n'a pas eu le temps d'exécuter toutes ces tâches de suppression essentielles.

C'est vraiment triste de voir autant de gens plaider aveuglément pour cette méthode sans en comprendre les conséquences. C'est extrêmement moche et peut potentiellement laisser des tonnes de restes dans le cluster. @javierprovecho l'a déjà mentionné ci- dessus, et @liggitt l'a également mentionné dans un autre numéro de GitHub.

Vous feriez mieux de réparer le service API v1beta1.metrics.k8s.io cassé ou de le supprimer si vous n'en avez pas besoin.

Voir aussi # 73405

Je seconde le message @antoineco . J'ai testé cela sur l'un de nos environnements sandbox car nous étions constamment bloqués par des espaces de noms. après environ un mois, tous les démons docker se figeaient sans raison. Il s'avère que nous avons créé d'énormes fuites de mémoire en laissant des ressources derrière nous.

Après de nombreux essais et erreurs, et en lisant ces commentaires, il s'est avéré qu'il s'agissait d'une définition de ressource personnalisée pour la pile coreos grafana pour les espaces de noms. La liste des CRD a montré des ressources spécifiques pour cet espace de noms. J'ai eu beaucoup de chance que le nom du CRD contienne l'espace de noms qui était bloqué.

Il s'est également avéré que le fait d'avoir un espace de noms bloqué arrête tout autre espace de noms à supprimer. Donc, même si vous avez un espace de noms A qui n'a pas de CRD qui le bloque, et qu'il y a un espace de noms B avec un CRD bloqué, toutes les ressources de A resteront dans les parages jusqu'à ce que B soit parti. Je pense que j'ai dû faire le correctif décrit ci-dessus sur l'espace de noms A en laissant une tonne de ressources à chaque fois.

Ce qui me tue encore, c'est que je ne peux pas pour la vie de moi trouver un journal mentionnant un échec de nettoyage d'espace de noms lors de la suppression d'un CRD, ou même ce qu'il est en train de faire. J'ai dû passer une heure à comprendre sur quel CRD il était collé. Si quelqu'un a une idée sur la façon d'obtenir plus d'informations, je n'ai pas à passer beaucoup de temps à déterminer la ressource bloquée, ce serait génial.

@jecafarelli bon indice pour les clusters de production. Mais malheureusement pour moi, je n'ai tout simplement pas pu le tuer autrement. Je savais aussi que je recréerais le cluster entier plus tard.

J'ai essayé d'analyser le problème, mais rien dans ce fil ne m'a aidé à le résoudre par d'autres moyens.

Cette solution officielle m'a aidé: https://success.docker.com/article/kubernetes-namespace-stuck-in-terminating
Ce n'est pas la même chose que kubectl edit namespace rook-ceph . Je n'ai pas pu résoudre ce problème jusqu'à ce que je PUT demande avec _ "finalizers" _ supprimés

ok donc je suis tombé dessus à nouveau avec coreos, et j'ai creusé un peu plus profondément. c'est très certainement à cause d'une définition de ressource à l'échelle du cluster qui est espacée de noms, et de plus, il ne pourrait peut-être pas la supprimer car elle ne peut pas interroger les informations sur coreos. J'ai trouvé des erreurs dans les journaux apiserver qui montraient des erreurs en essayant d'obtenir des informations sur un groupe api. J'ai utilisé le problème référencé ci-dessus pour créer un script rapide qui répertorie les ressources qui ont bloqué les ns pour moi.

Je vais probablement l'utiliser à l'avenir si je le rencontre à nouveau et que je continue d'ajouter d'autres ressources d'espacement de noms que je rencontre.

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

Merci beaucoup @jecafarelli , vous m'avez aidé à résoudre mon problème de la bonne manière ;-)

J'avais installé cert-manager sur un cluster OpenShift dans l'espace de noms cert-manager et quand j'ai essayé de supprimer cet espace de noms, il est resté bloqué dans l'état de terminaison. L'exécution de oc delete apiservices v1beta1.admission.certmanager.k8s.io semble avoir résolu le problème, l'espace de noms a disparu.

Merci beaucoup @jecafarelli , vous m'avez aidé à résoudre mon problème de la bonne manière ;-)

J'avais installé cert-manager sur un cluster OpenShift dans l'espace de noms cert-manager et quand j'ai essayé de supprimer cet espace de noms, il est resté bloqué dans l'état de terminaison. L'exécution de oc delete apiservices v1beta1.admission.certmanager.k8s.io semble avoir résolu le problème, l'espace de noms a disparu.

Idem ici, exécuter kubectl delete -f https://raw.githubusercontent.com/jetstack/cert-manager/release-0.8/deploy/manifests/00-crds.yaml aidé

Je viens de dire que j'ai également rencontré cette erreur sur la version 1.13.6 avec GKE. Cela s'est produit après que j'ai désactivé l'addon Istio de GKE dans le but de l'installer manuellement pour un contrôle total.
C'est le fil de discussion le plus long que j'ai jamais pris le temps de lire, et je suis époustouflé de constater qu'il n'y a pas de véritable consensus ou d'étapes de reproduction à la racine de ce problème. Il semble qu'il puisse être déclenché de tellement de manières différentes :(

La méthode JSON et curl / proxy mentionnée à plusieurs reprises ci-dessus et documentée à https://success.docker.com/article/kubernetes-namespace-stuck-in-terminating est ce qui m'a sauvé.

Le conseil sur https://success.docker.com/article/kubernetes-namespace-stuck-in-terminating est activement nuisible et peut entraîner le nettoyage et la resurfaçage des ressources orphelines si un espace de noms avec un nom identique est recréé ultérieurement .

Il y a un travail en cours pour découvrir la cause spécifique de la suppression bloquée, mais le problème fondamental est qu'il existe des types d'API dont le nettoyage ne peut pas être vérifié, de sorte que la suppression de l'espace de noms se bloque jusqu'à ce qu'ils soient vérifiés.

Nous avons également frappé cela avec Knative qui installe cet apiservice à espace de noms.

---
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
---

Après l'avoir supprimé, les ns de service knative et un tas d'autres espaces de noms bloqués ont été nettoyés. Merci à @jecafarelli pour le script bash ci-dessus.
Voici une terrible version 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

J'ai eu le même problème aujourd'hui et ce script a fonctionné pour moi.

@ kubernetes / sig-api-machines-misc

Ce bogue existe depuis> un an et est toujours un problème ... Quel est votre plan pour résoudre les problèmes entrants comme celui-ci?

Cela pourrait aider au moins à comprendre ce qui se passe: https://github.com/kubernetes/kubernetes/pull/80962

Je rencontre le même problème

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

Le contrôleur d'espace de noms doit signaler les conditions à l'état de l'espace de noms et les clients doivent le signaler. Nécessite un KEP, mais devrait être assez simple si quelqu'un peut le prendre et le valider.

@timothysc il y a (ou était) un PR en vol (quelque part) faisant exactement ce que @smarterclayton dit.

Je suis presque sûr qu'il y a un autre problème de github à ce sujet également?

Ouais le PR est ici: https://github.com/kubernetes/kubernetes/pull/73405

Le problème que je considère comme canonique est ici: https://github.com/kubernetes/kubernetes/issues/70916

Voici une ressource qui m'a aidé: https://www.ibm.com/support/knowledgecenter/en/SSBS6K_3.1.1/troubleshoot/ns_terminating.html

C'est similaire à la solution proposée par @slassh , mais elle utilise kubectl proxy pour créer un proxy local et rendre l'IP cible de la commande curl prévisible.

-

Edit: comme indiqué plusieurs fois ci-dessous cette réponse, cette solution est un sale hack et laissera éventuellement des ressources dépendantes dans le cluster. Utilisez-le à vos risques et périls, et ne l'utilisez éventuellement que comme moyen de sortie rapide dans un cluster de développement (ne l'utilisez pas dans un cluster de production).

la suppression directe du finaliseur comme décrit dans la documentation ci-dessus peut avoir des conséquences. Les ressources qui étaient en attente de suppression seront toujours définies dans le cluster même après la libération de l'espace de noms. C'est le but du finaliseur. Pour s'assurer que toutes les personnes à charge sont supprimées avant d'autoriser la suppression des ns.

Solution de contournement trouvée dans des questions similaires:

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

Solution de contournement trouvée dans des questions similaires:

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

Je vous remercie!
Cela fonctionne bien.
Je crée une application simple, utilisez cette solution de contournement: https://github.com/jenoOvchi/k8sdelns
Je l'utilise pour une suppression rapide et j'espère que cela sera utile pour quelqu'un.

Les espaces de noms Kubernetes 1.12.2 sont à l'état Terminating. Parfois, les finaliseurs peuvent être supprimés en modifiant le yaml de ns. Il ne peut pas être supprimé par api. Peut-il être supprimé? Quelle est la situation? Avons-nous fait un suivi spécifique (condition préalable: il n'y a pas de ressources dans ce ns), j'espère pouvoir obtenir des pointeurs, merci!

Encore une fois, veuillez ne pas supprimer le finaliseur, il est là pour une raison. Essayez plutôt de savoir quelles ressources du NS sont en attente de suppression en:

• Vérifier si un apiservice n'est pas disponible et ne dessert donc pas ses ressources: kubectl get apiservice|grep False
• Trouver toutes les ressources qui existent encore via kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get -n $your-ns-to-delete (Bravo à la Jordanie pour celle-là)

La solution à ce problème n'est pas de court-circuiter le mécanisme de nettoyage, c'est de découvrir ce qui empêche le nettoyage de réussir.

Encore une fois, veuillez ne pas supprimer le finaliseur, il est là pour une raison. Essayez plutôt de savoir quelles ressources du NS sont en attente de suppression en:

• Vérifier si un apiservice n'est pas disponible et ne dessert donc pas ses ressources: kubectl get apiservice|grep False
• Trouver toutes les ressources qui existent encore via kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get -n $your-ns-to-delete (Bravo à la Jordanie pour celle-là)

La solution à ce problème n'est pas de court-circuiter le mécanisme de nettoyage, c'est de découvrir ce qui empêche le nettoyage de réussir.

Comme tu as raison.
Dans mon cas, le pod de l'apiservice Operator Framework a été supprimé et bloque le processus de fin.
Suppression d'un apiservice inutilisé (kubectl delete apiservice) résolu le problème.

Salut à tous, le gel du code arrive dans quelques jours (jeudi, fin de journée, PST), nous devons donc nous assurer que ce problème sera résolu pour la v1.16 ou déplacé vers la v1.17. Pouvez-vous commenter son statut?

Cela sera-t-il rétroporté dans une version actuelle de GKE? J'ai un cluster qui a une poignée d'espaces de noms qui sont toujours en cours de "terminaison".

@squarelover même après avoir fait cela? https://github.com/kubernetes/kubernetes/issues/60807#issuecomment -524772920

@josiahbjorgaard Je viens d'approuver le PR, c'est tout ce que nous allons faire à ce sujet pour la 1.16.

https://github.com/kubernetes/kubernetes/pull/73405 est le PR susmentionné

C'est fusionné. Je pense qu'il y a peut-être plus que nous pouvons faire, mais s'il vous plaît prendre les futurs commentaires au # 70916.

Encore une fois, veuillez ne pas supprimer le finaliseur, il est là pour une raison. Essayez plutôt de savoir quelles ressources du NS sont en attente de suppression en:

• Vérifier si un apiservice n'est pas disponible et ne dessert donc pas ses ressources: kubectl get apiservice|grep False
• Trouver toutes les ressources qui existent encore via kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get -n $your-ns-to-delete (Bravo à la Jordanie pour celle-là)

La solution à ce problème n'est pas de court-circuiter le mécanisme de nettoyage, c'est de découvrir ce qui empêche le nettoyage de réussir.

Dans de nombreux cas, Metric-Server peut être installé. Lorsque les pods que vous déployez dans des espaces de noms spécifiques recherchent une collecte de métriques. Il se bloque avec le serveur métrique. Ainsi, même après avoir supprimé toutes les ressources de cet espace de noms, metric-server est en quelque sorte lié à cet espace de noms. Ce qui vous évitera de supprimer l'espace de noms.
Cet article vous aide à identifier la raison pour laquelle vous ne pouvez pas supprimer l'espace de noms. Donc la voie du rite.

Essayez ceci pour obtenir la liste réelle de toutes les choses dans votre espace de noms: kubernetes / kubectl # 151 (commentaire)

Ensuite, pour chaque objet, faites kubectl delete ou kubectl edit pour supprimer les finaliseurs.

Cette solution utile pour moi, merci.

Salut les gars,

J'ai créé un script pour faciliter la suppression des espaces de noms dans l'état de terminaison: https://github.com/thyarles/knsk.

Merci.

Nous avons rencontré le même problème, lors de la suppression d'un espace de noms, il restera bloqué dans l'état «Terminating». J'ai suivi les étapes ci-dessus pour supprimer «kubernetes» dans le finaliseur dans le fichier yaml. Ça marche.

Cependant, nous ne savons pas pourquoi nous devons faire des étapes supplémentaires. Il devrait faire kubectl delete ns foonamespace et il devrait supprimer. Quelqu'un peut-il me donner une raison? Je vous remercie!

Bonjour @ xzhang007 ,

Si vous découvrez pourquoi la suppression de l'espace de noms reste dans l'état de terminaison, faites-le moi savoir. J'ai essayé pendant un moment une bonne réponse, mais rien. Ensuite, j'ai fait un script pour me faciliter la vie jusqu'à découvrir et réparer la cause.

Je vous remercie.

@thyales il semble que je n'ai pas trouvé de réponse jusqu'à présent.

Dans notre cas, nous avons découvert que l'un des webhoks et finaliseurs que nous étions
utiliser consistait à atteindre un pod qui vivait dans les espaces de noms qui
supprimé.
Une fois le pod supprimé, la résiliation était bloquée.

>

@ xzhang007 avez-vous regardé la réponse fournie par @alvaroaleman ? Pour nous, cela suffisait pour découvrir quelle était la cause.

Encore une fois, veuillez ne pas supprimer le finaliseur, il est là pour une raison. Essayez plutôt de savoir quelles ressources du NS sont en attente de suppression en:

• Vérifier si un apiservice n'est pas disponible et ne dessert donc pas ses ressources: kubectl get apiservice|grep False
• Trouver toutes les ressources qui existent encore via kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get -n $your-ns-to-delete (Bravo à la Jordanie pour celle-là)

La solution à ce problème n'est pas de court-circuiter le mécanisme de nettoyage, c'est de découvrir ce qui empêche le nettoyage de réussir.

De plus, lorsque ce problème a été résolu, un nouveau ticket a été référencé pour expliquer comment expliquer clairement pourquoi l'espace de noms est bloqué dans Terminating. Je vous suggère de prendre la conversation là-bas au lieu de ce problème fermé.

C'est fusionné. Je pense qu'il y a peut-être plus que nous pouvons faire, mais s'il vous plaît prendre les futurs commentaires au # 70916.

@ jeff-knurek Cela devrait être la bonne manière. Je vous remercie.

Dans notre cas, c'était une mise à jour bâclée de cert-manager qui a cassé le finaliseur. 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

Salut.
Mon espace de noms de cas est bloqué dans la terminaison lorsque https://github.com/rancher/rancher/issues/21546#issuecomment -553635629

Cela aidera peut-être.

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

Cela a fonctionné comme un champion pour moi

J'ai également rencontré le même problème maintenant que cela fonctionne très bien pour moi. Veuillez vous référer au document suivant et résoudre votre problème

@zerkms bien, parfois, c'est un conseil légitime, n'est-ce pas? Souvent, les finaliseurs en attente étaient servis par des objets supprimés dans le cadre de la suppression de l'espace de noms. Dans ce cas, comme il ne sert à rien d'attendre plus longtemps - il n'y a plus rien qui puisse faire la finalisation -, patcher les objets comme l'article décrit est la seule option.

Notez que l'article ne s'applique que si le problème _n'a pas été résolu_ par les étapes d'application répertoriées dans la page Problèmes connus, liée en haut de l'article, qui est essentiellement le conseil que le commentaire que vous avez lié répète.

@zerkms bien, parfois, c'est un conseil légitime, n'est-ce pas? Souvent, les finaliseurs en attente étaient servis par des objets supprimés dans le cadre de la suppression de l'espace de noms

Je n'ai jamais vu cela vrai pour un spec.finalizer sur un espace de noms. Chaque instance que j'ai vue a impliqué le contrôleur de nettoyage de l'espace de noms, et a été soit causée par un objet persistant dans l'espace de noms (que ce conseil serait bloqué dans etcd), soit par une API agrégée qui ne répond pas (qui supprimerait la spécification d'espace de noms. en attente, bloquant également les ressources persistantes de cette API)

L'article ne prévient pas que le contournement de la finalisation de l'espace de noms risque de laisser les ressources de l'espace de noms bloquées dans le stockage et n'est pas recommandé.

Je n'ai jamais vu cela vrai pour un spec.finalizer sur un espace de noms

Oui, c'est vrai, c'est parce que ce finaliseur est implémenté par le kubernetes lui-même, mais il pourrait y avoir d'autres finaliseurs sur des objets à l'intérieur de cet espace de noms, qui pourraient être implémentés par des objets dans cet espace de noms. Un exemple que j'ai rencontré récemment était https://appscode.com/products/stash/ .

Il place des finaliseurs sur certains de ses CRD qui doivent être pris en charge par le déploiement de l'opérateur stash. Mais avec l'opérateur stash déjà supprimé, rien ne peut supprimer la marque de finaliseur de ces CRD et la suppression de l'espace de noms reste bloquée. Dans ce cas, corriger ces finaliseurs (pas sur l'espace de noms lui-même, mais sur ces objets) est la seule chose sensée à faire.

J'espère que cela a du sens.

Dans ce cas, corriger ces finaliseurs (pas sur l'espace de noms lui-même, mais sur ces objets) est la seule chose sensée à faire.

Correct. Je ne m'opposerais pas à cela dans un scénario de nettoyage «supprimer toutes les ressources», mais ce n'est pas ce que l'article lié parcourt ... il décrit comment supprimer un spec.finalizer de l'espace de noms.

d'abord, prenez un petit café et détendez-vous, allez maintenant aux nœuds maîtres de votre k8

kubectl cluster-info
Le maître Kubernetes s'exécute sur https: // localhost : 6443
KubeDNS s'exécute sur https: // localhost : 6443 / api / v1 / namespaces / kube-system / services / kube- dns: dns / proxy
Pour déboguer et diagnostiquer davantage les problèmes de cluster, utilisez «kubectl cluster-info dump».

maintenant lancez le kube-proxy
proxy kubectl &
Commencer à servir sur 127.0.0.1:8001
enregistrez l'ID pour le supprimer plus tard :)

1. trouvez votre nom-espace qui a décidé de ne pas être supprimé :) pour nous ce sera le système de bétail
   kubectl obtenir ns
   Système de bétail Terminating 1d

le mettre dans un fichier

1. kubectl obtenir l'espace de noms bétail-system -o json> tmp.json

éditer le fichier et supprimer les finaliseurs
},
"spec": {
"finaliseurs": [
"kubernetes"
]
},
après l'édition, cela devrait ressembler à ceci 👍
},
"spec": {
"finaliseurs": [
]
},
nous y sommes presque 👍
curl -k -H "Content-Type: application / json" -X PUT --data-binary @ tmp.json http://127.0.0.1 : 8001 / api / v1 / namespaces / $ {NAMESPACE} / finalize

et c'est parti 👍

Encore une fois, veuillez ne pas supprimer le finaliseur, il est là pour une raison. Essayez plutôt de savoir quelles ressources du NS sont en attente de suppression en:

• Vérifier si un apiservice n'est pas disponible et ne dessert donc pas ses ressources: kubectl get apiservice|grep False
• Trouver toutes les ressources qui existent encore via kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get -n $your-ns-to-delete (Bravo à la Jordanie pour celle-là)

La solution à ce problème n'est pas de court-circuiter le mécanisme de nettoyage, c'est de découvrir ce qui empêche le nettoyage de réussir.

Salut les gars! Je suis les conseils fournis par @alvaroaleman et j'ai créé un script qui inspecte et essaie la suppression propre avant de faire une suppression définitive de l'espace de noms bloqué .

Ce que fait le script https://github.com/thyarles/knsk :

1. Vérifiez les sources d'air indisponibles et demandez à les supprimer
2. Vérifiez les ressources en attente dans l'espace de noms et demandez à les supprimer
3. Attendez environ 5 minutes pour voir si Kubernetes effectue une suppression propre si le script effectue une suppression
4. Forcer la suppression de l'espace de noms bloqué

J'espère que cela aide.

@thyarles Merci beaucoup. J'ai utilisé votre façon de résoudre le problème.

$ kubectl obtenir des apiservices pour vérifier quel service est indisponible, supprimer ceux disponibles est faux par $ kubectl delete apiservice [nom-service], et après cela, il n'y aurait plus de problème pour supprimer un espace de nom.

Pour notre équipe, il existe 3 apiservices indisponibles, v1beta1.admission.certmanager.k8s.io, v1beta1.metrics.k8s.io et v1beta1.webhook.certmanager.k8s.io.

Notez que votre cluster est quelque peu cassé si l'apiserver de métriques n'est pas en cours d'exécution, le simple fait de supprimer APIService ne corrige pas la cause première.

@lavalamp la métrique est un service après-vente non disponible.

Oui, ce qui signifie que les métriques apiserver ne sont pas en cours d'exécution, ce qui signifie que HPA ne fonctionne pas sur votre cluster, et probablement d'autres choses aussi.

Oui. HPA ne fonctionne pas maintenant. Je ne devrais pas supprimer les métriques et trouver un moyen de les corriger.

@thyarles Merci beaucoup. J'ai utilisé votre façon de résoudre le problème.

$ kubectl obtenir des apiservices pour vérifier quel service est indisponible, supprimer ceux disponibles est faux par $ kubectl delete apiservice [nom-service], et après cela, il n'y aurait plus de problème pour supprimer un espace de nom.

Pour notre équipe, il existe 3 apiservices indisponibles, v1beta1.admission.certmanager.k8s.io, v1beta1.metrics.k8s.io et v1beta1.webhook.certmanager.k8s.io.

@ xzhang007 heureux d'entendre! Vous devez maintenant vérifier pourquoi votre v1beta1.metrics.k8s.io est tombé en panne. Vérifiez comment il aimerait:

''
$ kubectl -n kube-system obtenir tout | métriques grep

pod / metrics-server-64f74f8d47-r5vcq 2/2 Exécution de 9 119d
service / serveur de métriques ClusterIP xx.xx.xx.xx443 / TCP 201d
deployment.apps / metrics-server 1/1 1 1 201d
replicaset.apps / metrics-server-55c7f68d94 0 0 0 165d
replicaset.apps / metrics-server-5c696bb6d7 0 0 0 201d
replicaset.apps / metrics-server-5cdb8bb4fb 0 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 obtenir tout | métriques grep

pod / metrics-server-5dcfd4dd9f-m2v9k 1/1 Exécution 0 2d20h

service / serveur de métriques ClusterIP xx.xx.xx.xx443 / TCP 27d

deployment.apps / metrics-server 1/1 1 1 27d

replicaset.apps / metrics-server-5dcfd4dd9f 1 1 1 27d
replicaset.apps / metrics-server-7fcf9cc98b 0 0 0 27d

Oui. HPA ne fonctionne pas maintenant. Je ne devrais pas supprimer les métriques et trouver un moyen de les corriger.

@ xzhang007 en fait cela ne fonctionne pas avant que vous ayez remarqué le problème .... vous venez de le remarquer car il a mis vos espaces de noms supprimés en mode bloqué. Utilisez simplement un gestionnaire de packages helm pour redéployer votre serveur métrique ou appelez simplement la commande ci-dessous pour le réparer ( vérifiez le fichier de déploiement avant d'appliquer ):

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

La solution

Supprimer v1beta1.metrics.k8s.io APIService

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

Le gestionnaire de certificats n'était peut-être pas disponible car il a été configuré de manière incorrecte. Par exemple, utilisez une syntaxe incorrecte dans le contrôleur d'entrée. Pour notre système, c'était

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

et il a été changé en

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

le rendre disponible.

Comme mentionné précédemment dans ce numéro, il existe une autre façon de mettre fin à un espace de noms en utilisant une API non exposée par kubectl en utilisant une version moderne de kubectl où kubectl replace --raw est disponible (pas sûr de quelle version). De cette façon, vous n'aurez pas à générer un processus kubectl proxy et éviter les dépendances avec curl (cela dans certains environnements comme busybox n'est pas disponible). Dans l'espoir que cela aidera quelqu'un d'autre, j'ai laissé ceci ici:

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

A-t-il été établi s'il s'agit d'un problème réparable? Cela semble être beaucoup de solutions piratées ici, mais rien ne résout le problème sous-jacent qui est qu'aucun de nous ne peut supprimer nos espaces de noms ...
J'ai ceci sur le cluster EKS v1.14

A-t-il été établi s'il s'agit d'un problème réparable? Cela semble être beaucoup de solutions piratées ici, mais rien ne résout le problème sous-jacent qui est qu'aucun de nous ne peut supprimer nos espaces de noms

Le problème fondamental est qu'un groupe d'API agrégé dans votre cluster n'est pas disponible. Il est intentionnel que le contrôleur de nettoyage de l'espace de noms se bloque jusqu'à ce que toutes les API soient disponibles, afin de pouvoir vérifier que toutes les ressources de tous les groupes d'API sont nettoyées pour cet espace de noms.

pour les personnes qui essaient de boucler l'API:

# 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

Voici un script pour le faire automatiquement. Besoins 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

Tout le monde: les scripts pour automatiser la suppression du finaliseur font plus de mal que de bien . Ils peuvent laisser des bombes à retardement dans le (s) apiserver (s) agrégé (s) qui ne sont pas disponibles; si quelqu'un recrée l'espace de noms, tout à coup un tas d'anciens objets peuvent réapparaître.

La vraie solution est:

$ 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.

Tout le monde: les scripts pour automatiser la suppression du finaliseur font plus de mal que de bien . Ils peuvent laisser des bombes à retardement dans le (s) apiserver (s) agrégé (s) qui ne sont pas disponibles; si quelqu'un recrée l'espace de noms, tout à coup un tas d'anciens objets peuvent réapparaître.

La vraie solution est:

$ 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

Ce script effectue toutes les vérifications et tente d'effectuer une suppression propre, y compris la recherche de ressources orphelines. Si l'utilisateur veut prendre un risque, le script propose une option --force pour effectuer une méthode de suppression non recommandée.

faute de frappe, devrait être apiservices

Cette commande affiche les API non disponibles:

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

Cet article vous sera sûrement utile:

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

En fait, ce qui existe est un conflit dans les apiservices, ils pourraient valider l'état de santé des apis en openshift:

oc get apiservices -o = custom-columns = " nom: .metadata.name , statut: .status.conditions [0] .status"

l'API qui échoue devra la redémarrer, redémarrer le pod ou le déploiement qui appartient à cette API, après cela, essayez de supprimer l'espace de noms.

$ oc supprimer namspace

et prêt, affaires réglées !!

Plutôt irrespectueux d'utiliser sa propre langue dans un endroit où tout le monde accepte de parler anglais. 👎

Où tout le monde est-il d'accord pour parler anglais?

Le jeu.30 avril 2020 à 17:58, theAkito [email protected] a écrit:

Plutôt irrespectueux d'utiliser sa propre langue dans un endroit où tout le monde
accepte de parler anglais. 👎

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/kubernetes/kubernetes/issues/60807#issuecomment-622137770 ,
ou se désinscrire
https://github.com/notifications/unsubscribe-auth/ALGMKB6K4OU4X3XOYMALOBLRPHYCDANCNFSM4ETUOEPA
.

>

Chris, architecte principal @ brace.ai

-

Avis de confidentialité: cet e-mail est destiné à l'usage exclusif du
destinataire (s) prévu (s) et peuvent contenir des informations confidentielles, exclusives ou
des informations privilégiées. Si vous n'êtes pas le destinataire prévu, vous êtes
notifié que toute utilisation, examen, diffusion, copie ou action entreprise
sur ce message ou ses pièces jointes, le cas échéant, est interdit. Si tu n'es pas
le destinataire prévu, veuillez contacter l'expéditeur par e-mail de réponse et
détruire ou supprimer toutes les copies du message d'origine et toutes les pièces jointes.

prêt, excusez-moi c'était pour ma vitesse, c'était corrigé

Nous avons une base d'utilisateurs multilingues, c'est déjà assez grave qu'aucun de nos outils ne soit internationalisé, nous pouvons au moins être gentils ici sur github, s'il vous plaît.

@teoincontatto

Comme mentionné précédemment dans ce numéro, il existe une autre façon de mettre fin à un espace de noms en utilisant une API non exposée par kubectl en utilisant une version moderne de kubectl où kubectl replace --raw est disponible (pas sûr de quelle version). De cette façon, vous n'aurez pas à générer un processus kubectl proxy et éviter les dépendances avec curl (cela dans certains environnements comme busybox n'est pas disponible). Dans l'espoir que cela aidera quelqu'un d'autre, j'ai laissé ceci ici:

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

Cela a parfaitement fonctionné!

Nous avons une base d'utilisateurs multilingues, c'est déjà assez grave qu'aucun de nos outils ne soit internationalisé, nous pouvons au moins être gentils ici sur github, s'il vous plaît.

Nous avons une base d'utilisateurs multilingues, c'est déjà assez grave qu'aucun de nos outils ne soit internationalisé, nous pouvons au moins être gentils ici sur github, s'il vous plaît.

J'essaye toujours de comprendre. Pardonne-moi. J'ai peut-être cliqué sur les pouces vers le bas par erreur.
Oui, en effet, les outils n'ont pas été réalisés à la perfection.
Celles-ci, donner un pouce vers le bas sans explication, n'a aucun sens.

Presque tout le temps que je rencontre ce problème, cela dépend de CRD. Supprimez les CRD s'ils ne sont utilisés que dans cet espace de noms, puis vous pouvez procéder à la suppression du finaliseur et de l'espace de noms.

Comme mentionné précédemment dans ce numéro, il existe une autre façon de mettre fin à un espace de noms en utilisant une API non exposée par kubectl en utilisant une version moderne de kubectl où kubectl replace --raw est disponible (pas sûr de quelle version). De cette façon, vous n'aurez pas à générer un processus kubectl proxy et éviter les dépendances avec curl (cela dans certains environnements comme busybox n'est pas disponible). Dans l'espoir que cela aidera quelqu'un d'autre, j'ai laissé ceci ici:

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 Merci! Cela a finalement fonctionné!

Parfois, seule la modification du manifeste de ressources en ligne ne fonctionnerait pas très bien (je veux dire supprimer le fichier finalizers et enregistrer).
Donc, j'ai eu une nouvelle façon de faire des autres.

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

Après avoir exécuté cette commande, l'espace de noms devrait maintenant être absent de votre liste d'espaces de noms. Et cela fonctionne pour moi.

Non seulement namespace mais prend également en charge les autres ressources.

J'ai résolu le problème en supprimant les lignes des finaliseurs en utilisant le: kubectl edit annoying-ns

Hmm ... j'ai ce problème en ce moment :)
Aujourd'hui, j'ai fait une mise à jour de mon cluster eks de 1.15 à 1.16.
Tout va bien jusqu'à présent.
Mais mon développement ns "configcluster" était une sorte de "damangé".
Alors je décide de le nettoyer.

k supprimer le configcluster ns
....
maintenant cela se bloque (3h +): /

$ 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

Comment pouvons-nous être plus exposés à cette épine dans le problème du pied?

Le ven 19 juin 2020 à 04:46 Andreas Höhmann [email protected]
a écrit:

Hmm ... j'ai ce problème en ce moment :)
Aujourd'hui, j'ai fait une mise à jour de mon cluster eks de 1.15 à 1.16.
Tout va bien jusqu'à présent.
Mais mon développement ns "configcluster" était une sorte de "damangé".
Alors je décide de le nettoyer.

k supprimer le configcluster ns
....
maintenant cela se bloque (3h +): /

$ kubectl obtenir la configuration de l'espace de noms -o yaml
apiVersion: v1
kind: espace de noms
métadonnées:
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"
nom: configcluster
resourceVersion: "22598109"
selfLink: / api / v1 / namespaces / configcluster
uid: e50f0b53-b21e-4e6e-8946-c0a0803f031b
spec:
finaliseurs:

• kubernetes
  statut:
  conditions:
• lastTransitionTime: "2020-06-19T09: 19: 21Z"
  message: 'La découverte a échoué pour certains groupes, 1 échec: impossible de récupérer le
  liste complète des API du serveur: metrics.k8s.io/v1beta1: le serveur est actuellement
  incapable de gérer la demande '
  raison: DiscoveryFailed
  état: "Vrai"
  type: NamespaceDeletionDiscoveryFailure
• lastTransitionTime: "2020-06-19T09: 19: 22Z"
  message: Tous les types de kube hérités ont été analysés avec succès
  raison: ParsedGroupVersions
  statut: "Faux"
  type: NamespaceDeletionGroupVersionParsingFailure
• lastTransitionTime: "2020-06-19T09: 19: 22Z"
  message: tout le contenu a bien été supprimé
  raison: ContentDeleted
  statut: "Faux"
  type: NamespaceDeletionContentFailure
  phase: Terminer

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/kubernetes/kubernetes/issues/60807#issuecomment-646543073 ,
ou se désinscrire
https://github.com/notifications/unsubscribe-auth/AFLKRCLHIZ77X2Z3F5GAOCTRXMXVTANCNFSM4ETUOEPA
.

@bobhenkel eh bien, ce problème est clos, donc effectivement cela signifie qu'il n'y a pas de problème (en ce qui concerne les éléments exploitables). Si vous avez besoin d'aide pratique pour faire face à une situation similaire, veuillez lire le fil ci-dessus, il y a quelques bons conseils (et aussi quelques mauvais).

Dans mon cas, j'ai dû supprimer manuellement mon équilibreur de charge d'entrée de la console GCP Network Service. J'avais créé manuellement l'interface de l'équilibreur de charge directement dans la console. Une fois que j'ai supprimé l'équilibreur de charge, l'espace de noms a été automatiquement supprimé.

Je soupçonne que Kubernetes ne voulait pas supprimer car l'état de l'équilibreur de charge était différent de l'état du manifeste.

J'essaierai d'automatiser la création de l'interface d'entrée à l'aide d'annotations ensuite pour voir si je peux résoudre ce problème.

Parfois, seule la modification du manifeste de ressources en ligne ne fonctionnerait pas très bien (je veux dire supprimer le fichier finalizers et enregistrer).
Donc, j'ai eu une nouvelle façon de faire des autres.

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

Après avoir exécuté cette commande, l'espace de noms devrait maintenant être absent de votre liste d'espaces de noms. Et cela fonctionne pour moi.

Non seulement namespace mais prend également en charge les autres ressources.

tu es une star ça a marché

Parfois, seule la modification du manifeste de ressources en ligne ne fonctionnerait pas très bien (je veux dire supprimer le fichier finalizers et enregistrer).
Donc, j'ai eu une nouvelle façon de faire des autres.

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

Après avoir exécuté cette commande, l'espace de noms devrait maintenant être absent de votre liste d'espaces de noms. Et cela fonctionne pour moi.

Non seulement namespace mais prend également en charge les autres ressources.

J'ai essayé beaucoup de solutions mais c'est celle qui a fonctionné pour moi. Je vous remercie!

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

Mieux https://stackoverflow.com/a/59667608/429476

Cela devrait vraiment être la réponse «acceptée» - cela a complètement résolu la racine de ce problème!

Tirez du lien ci-dessus:

Ce n'est pas la bonne manière, en particulier dans un environnement de production.

Aujourd'hui, j'ai eu le même problème. En supprimant le finaliseur, vous vous retrouverez avec des restes dans divers états. Vous devriez en fait trouver ce qui empêche la suppression de se terminer.

Voir https://github.com/kubernetes/kubernetes/issues/60807#issuecomment -524772920

(aussi, malheureusement, 'kubetctl get all' ne signale pas tout, vous devez utiliser des commandes similaires comme dans le lien)

Mon cas - suppression de l'espace de noms 'cert-manager'. Dans la sortie de 'kubectl get apiservice -o yaml', j'ai trouvé APIService 'v1beta1.admission.certmanager.k8s.io' avec status = False. Cet apiservice faisait partie de cert-manager, que je viens de supprimer. Ainsi, dans 10 secondes après que je 'kubectl delete apiservice v1beta1.admission.certmanager.k8s.io', l'espace de noms a disparu.

J'espère que ça t'as aidé.

Cela étant dit, j'ai écrit un petit microservice à exécuter en tant que CronJob toutes les heures qui supprime automatiquement les espaces de noms de terminaison.

Vous pouvez le trouver ici: https://github.com/oze4/service.remove-terminating-namespaces

J'ai écrit un petit microservice à exécuter en tant que CronJob toutes les heures qui supprime automatiquement les espaces de noms de terminaison.

Vous pouvez le trouver ici: https://github.com/oze4/service.remove-terminating-namespaces

Encore un autre oneliner:

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

Mais la suppression des espaces de noms bloqués n'est pas une bonne solution. La bonne façon est de savoir pourquoi il est bloqué. La raison très courante est qu'il existe un ou plusieurs services d'API indisponibles qui empêchent le cluster de finaliser les espaces de noms.
Par exemple ici, je n'ai pas supprimé Knative correctement:

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

Le supprimer a résolu le problème

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  

J'ai écrit un petit microservice à exécuter en tant que CronJob toutes les heures qui supprime automatiquement les espaces de noms de terminaison.

Vous pouvez le trouver ici: https://github.com/oze4/service.remove-terminating-namespaces

bon travail.

J'ai eu un problème similaire sur 1.18 dans un cluster lab k8s et en ajoutant une note pour peut-être aider les autres. J'avais travaillé avec l'API de métriques et avec des métriques personnalisées en particulier. Après avoir supprimé ces objets k8s pour les recréer, il a bloqué la suppression de l'espace de noms avec une erreur indiquant que le point de terminaison de l'API des métriques n'a pas pu être trouvé. En remettant cela dans un autre espace de noms, tout s'est éclairci immédiatement.

C'était dans l'espace de noms sous 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

Encore un autre oneliner:

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

Mais la suppression des espaces de noms bloqués n'est pas une bonne solution. La bonne façon est de savoir pourquoi il est bloqué. La raison très courante est qu'il existe un ou plusieurs services d'API indisponibles qui empêchent le cluster de finaliser les espaces de noms.
Par exemple ici, je n'ai pas supprimé Knative correctement:

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

Le supprimer a résolu le problème

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  

Certainement la doublure la plus propre! Il est important de noter qu'aucune de ces «solutions» ne résout réellement le problème racine.

Voir ici pour la bonne solution

C'est le message qui devrait se répandre: sourire: pas "encore un autre liner".

définitivement la doublure la plus propre! Il est important de noter qu'aucune de ces «solutions» ne résout réellement le problème racine.

Cette solution résout l'une de toutes les possibilités. Pour rechercher toutes les causes profondes possibles et les corriger, j'utilise ce script: https://github.com/thyarles/knsk

@thyarles très gentil!

Veuillez ne pas utiliser modify finalize pour supprimer l'espace de noms. Cela provoquera une erreur

Veuillez trouver la cause de la fin de l'espace de noms. Instructions de dépannage actuellement connues

• fin du pod
• secret de bloc de webhook cert-manager

Je rencontre le même problème:

# 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"}

Vous pouvez utiliser etcdctl pour rechercher des ressources non supprimées

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>

Copiez et collez simplement dans votre terminal

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

cela a fonctionné pour moi, et j'ai couru après avoir vérifié qu'il n'y avait pas d'objets k8s suspendus dans le ns. Merci!

J'ai utilisé ceci pour supprimer un espace de noms bloqué à Terminé

exemple :

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

Pour tous les googleurs qui sont tombés sur des espaces de noms bloqués à Terminating on Rancher des espaces de noms spécifiques (par exemple, le système de bétail), la commande modifiée suivante (l'original de grebois) a fonctionné pour moi:

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

Folks, juste pour info , lorsque la vidéo de cette créer un lien vers elle et certains des commentaires utiles ci-dessus, et de verrouiller ce problème.

J'ai enregistré une explication de 10 minutes de ce qui se passe et je l'ai présentée lors de cette session SIG Deep Dive .

Voici un commentaire correct avec 65 votes positifs

Mentionné à plusieurs reprises ci-dessus, ce message médiatique est un exemple de la bonne manière de faire les choses. Trouvez et corrigez le service API cassé.

Tous les doublures qui suppriment simplement les finaliseurs de l'espace de noms traitent la cause première et laissent votre cluster subtilement cassé, ce qui vous mordra plus tard. Alors ne faites pas ça. Le correctif de la cause première est généralement plus facile de toute façon. Il semble que les gens aiment publier des variations sur ce thème même s'il y a déjà de nombreuses réponses correctes dans le fil, donc je vais verrouiller le problème maintenant, pour m'assurer que ce commentaire reste en bas.