Kubernetes: Löschen des Namespace im Status "Beenden"

/ sig api-maschinen

@ shean-guangchang Hast du eine Möglichkeit, dies zu reproduzieren?

Und verwenden Sie aus Neugier irgendwelche CRDs? Dieses Problem hatten wir zuvor mit TPRs.

/ Art Bug

Ich habe anscheinend dieses Problem bei einer Turmbereitstellung:

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

Ich denke, es hat etwas mit ihrer CRD zu tun. Ich sehe dies in den API-Serverprotokollen:

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

Ich habe Rook jetzt in einem anderen Namespace bereitgestellt, kann jedoch die Cluster-CRD nicht erstellen:

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

Scheint, als ob die CRD nie aufgeräumt wurde:

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

Ich habe einen Spalt-Namespace in einem ähnlichen Zustand:

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

Fission verwendet auch CRDs, sie scheinen jedoch bereinigt zu sein.

@ Shean-Guangchang - Ich hatte das gleiche Problem. Ich habe alles unter den Namespaces manuell gelöscht, alles aus "helm" gelöscht und gelöscht und die Masterknoten einzeln neu gestartet, und das Problem wurde behoben.

Ich stelle mir vor, dass das, was mir begegnet ist, etwas mit der Zusammenarbeit von "Arche", "Pinne" und Kuberenets zu tun hat (ich habe mit dem Helm gebootet und mit der Arche gesichert), so dass dies möglicherweise kein Kuberenets-Problem ist Andererseits war es so gut wie unmöglich, Fehler zu beheben, da es keine relevanten Protokolle gibt.

Wenn es sich um den Turm handelt, sehen Sie sich diesen an: https://github.com/rook/rook/issues/1488#issuecomment -365058080

Ich denke, das macht Sinn, aber es scheint fehlerhaft, dass es möglich ist, einen Namespace in einen nicht löschbaren Zustand zu versetzen.

Ich habe eine ähnliche Umgebung (Ark & Helm) mit @barakAtSoluto und habe das gleiche Problem. Das Löschen und Neustarten der Master hat es jedoch nicht für mich behoben. Immer noch beim Beenden stecken.

Ich hatte das auch, als ich versuchte, das Problem neu zu erstellen. Ich musste schließlich einen neuen Cluster erstellen ....
Ausschließen - Standardmäßig werden kube-system / public und alle archenbezogenen Namespaces gesichert und wiederhergestellt, um dies zu verhindern ...

Ich sehe dies auch auf einem Cluster, der von 1.8.4 auf 1.9.6 aktualisiert wurde. Ich weiß nicht einmal, welche Protokolle ich ansehen soll

Das gleiche Problem am 1.10.1 :(

Gleiches Problem am 1.9.6

Bearbeiten: Der Namespace konnte nicht gelöscht werden, da einige Pods hängen. Ich habe alle mit --grace-period = 0 --force gelöscht und nach ein paar Minuten wurde auch der Namespace gelöscht.

Hallo,

Ich habe das immer und immer wieder und es ist die meiste Zeit ein Problem mit Finalisierern.

Wenn ein Namespace nicht mehr funktioniert, versuchen Sie, kubectl get namespace XXX -o yaml und prüfen Sie, ob ein Finalizer vorhanden ist. Wenn ja, bearbeiten Sie den Namespace und entfernen Sie den Finalizer (indem Sie ein leeres Array übergeben). Anschließend wird der Namespace gelöscht

@xetys ist es sicher? In meinem Fall gibt es nur einen Finalizer namens "kubernetes".

Das ist seltsam, ich habe noch nie einen solchen Finalizer gesehen. Ich kann nur aufgrund meiner Erfahrung sprechen. Ich habe das mehrere Male in einem Produktionscluster gemacht und es lebt noch

Gleiches Problem am 1.10.5. Ich habe alle Ratschläge in dieser Ausgabe ohne Ergebnis ausprobiert. Ich konnte die Pods loswerden, aber der Namespace hängt immer noch.

Eigentlich wurden auch die ns nach einer Weile gelöscht.

Es wäre gut zu verstehen, was dieses Verhalten verursacht. Der einzige Finalizer, den ich hatte, sind Kubernetes. Ich habe auch dynamische Webhooks. Können diese in Beziehung gesetzt werden?

@xetys Nun, endlich habe ich deinen Trick für die Replikate in diesem Namespace verwendet. Sie hatten einen benutzerdefinierten Finalizer, der wahrscheinlich nicht mehr existierte, sodass ich sie nicht löschen konnte. Als ich die Verweise auf diesen Finalizer entfernte, verschwanden sie und auch der Namespace. Vielen Dank! :) :)

Gleiches Problem bei einem EKS 1.10.3-Cluster:

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

Das gleiche Problem bei einem Bare-Metal-Cluster:

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

Mein Namespace sieht so aus:

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

Es ist tatsächlich der zweite Namespace, bei dem ich dieses Problem hatte.

Versuchen Sie dies, um die aktuelle Liste aller Dinge in Ihrem Namespace zu erhalten: https://github.com/kubernetes/kubectl/issues/151#issuecomment -402003022

Führen Sie dann für jedes Objekt kubectl delete oder kubectl edit , um die Finalizer zu entfernen.

Das Entfernen des Initialisierers hat den Trick für mich getan ...

Wenn ich kubectl edit namespace annoying-namespace-to-delete mache und die Finalizer entferne, werden sie erneut hinzugefügt, wenn ich mit einem kubectl get -o yaml überprüfe.

Wenn ich versuche, was Sie erhalte ich keine Ausgabe (das Entfernen von --ignore-not-found bestätigt, dass im Namespace keinerlei Ressourcen gefunden wurden).

@ManifoldFR , ich hatte das gleiche Problem wie Sie und es gelang mir, es durch einen API-Aufruf mit der JSON-Datei zum
kubectl get namespace annoying-namespace-to-delete -o json > tmp.json
Bearbeiten Sie dann tmp.json und entfernen Sie "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

und es sollte Ihren Namespace löschen,

@slassh Es hat funktioniert! Hätte über einen API-Aufruf nachdenken sollen: Vielen Dank! Wir werden dein Lob für immer singen

Das Problem ist in Version 1.11.1 vorhanden. Ich hatte einen festgefahrenen Rancher / Helm-Einsatz von Dokuwiki. Ich musste zuerst das Löschen der Pods erzwingen, wie von @siXor vorgeschlagen, und dann den Ratschlägen von @slassh folgen. Alles gut jetzt.

@slassh wie sehe ich die kubernetes-cluster-ip? Ich benutze einen der Knoten IP bereitgestellt, die den Kubernetes Cluster ersetzen, und es berichtet 404.

hi @jiuchongxiao , mit kubernetes-cluster-ip meinte ich einen deiner Node Master IP.
Entschuldigung, wenn es verwirrend ist!

Wenn Sie zuerst 'kubectl proxy' starten, können Sie die Locke auf http://127.0.0.1 : 8001 / api / v1 / namespaces / nerviger-Namespace zum Löschen / Finalisieren richten. Ich konnte die Authentifizierung erst dann zum Laufen bringen, wenn ich es so gemacht hatte.

gute tipps @ 2stacks. Sie müssen nur https durch http ersetzen.

Ich sehe dieses Problem immer noch in 1.11.2.

Um mehr Kontext für die Reproduktion zu geben, habe ich dies nur bei CRDs gesehen. Durch das Löschen des CRD-Objekts geriet ich in einen seltsamen Zustand, in dem die Objekte, deren Eigentümer es war, nicht gelöscht wurden. Ich habe es nicht bemerkt und daher eine Löschung für den Namespace ausgegeben. Dann habe ich alle Objekte im Namespace mit kubectl delete all --all -n my-namespace gelöscht. Zu diesem Zeitpunkt blieb die Löschung des Namespace hängen. Ich hoffe das hilft irgendwie.

Beim Betrachten von Protokollen habe ich gerade herausgefunden, dass dieses spezielle Problem damit zusammenhängt, dass der Controller-Manager ungesund ist. In meinem Fall war es höchstwahrscheinlich kein Fehler. Als der Controller-Manager wieder hochfuhr, wurde alles korrekt aufgeräumt.

@slassh Perfekte Lösung! vielen Dank!!!!

Ich sehe dieses Problem auch mit 1.10.x. Ich finde, dass @slasshs Kommentar eine Terminating ?

Wir haben festgestellt, dass der Grund für das Löschen von Namespaces in unserem Fall stecken bleibt (@palmerabollo).

Wenn ein Namespace einen Finalizer kubernetes , bedeutet dies, dass es sich um ein internes Problem mit dem API-Server handelt.

Führen Sie kubectl api-resources . Wenn Folgendes zurückgegeben wird, bedeutet dies, dass die benutzerdefinierte API nicht erreichbar ist.

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

Führen Sie kubectl get apiservices v1beta1.metrics.k8s.io -o yaml , um die Statusbedingungen zu überprüfen.

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

Der obige Fehler sollte durch einen Crashloopbackoff verursacht werden, der den Metrics-Server beeinflusst. Ähnlich verhält es sich mit anderen in Kubernetes registrierten benutzerdefinierten APIs.

Überprüfen Sie den Zustand Ihrer Dienste in kube-system um Cluster-Laufzeitvorgänge wie das Löschen von Namespaces wiederherzustellen.

Ich bin mit diesem Problem auf v1.11.3 konfrontiert. Bei den Finalisierern sind nur Kubernetes für problematische Namespace vorhanden.

spec:
  finalizers:
  - kubernetes

@slassh Vielen Dank, Ihre Lösung funktioniert gut!
Ich habe das gleiche Problem in meinem Cluster mit Arche, Pinne und Kubed. Ich vermute, dass die Probleme möglicherweise die API von kubed sind, die einen Fehler ausgibt, obwohl ich nicht sicher bin, warum sich dies auf das Löschen eines anderen Namespace auswirkt.

@javierprovecho Ich habe nur mit dem Metrics Server

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

Wissen Sie, wie Sie sich von diesem Zustand erholen können?

Bearbeiten: Ich fand heraus ... Ich musste alles löschen, auch im Zusammenhang mit Metriken / HPA, und dann die gesamte Steuerebene neu starten (ich musste alle meine Replikate davon entfernen, bevor ich sie wieder hochfuhr). Dazu gehörte das Löschen des apiservice v1beta1.metrics.k8s.io selbst.

@ 2rs2ts

$ kubectl delete apiservice v1beta1.metrics.k8s.io

Durch Entfernen des nicht funktionierenden API-Dienstes metrics der Controller-Manager die veralteten Namespaces löschen.

Ein Neustart der Steuerebene ist nicht erforderlich.

@antoineco nein, es war notwendig; Ich habe den Apiservice gelöscht und eine Weile gewartet, aber der Namespace wurde nicht gelöscht, bis ich die Steuerebene neu gestartet habe.

Nehmen Sie zuerst einen kleinen Kaffee und entspannen Sie sich. Gehen Sie jetzt zu Ihren k8s-Masterknoten

1. kubectl cluster-info
   Der Kubernetes-Master wird unter https: // localhost : 6443 ausgeführt
   KubeDNS wird unter https: // localhost : 6443 / api / v1 / namespaces / kube-system / services / kube- dns: dns / proxy ausgeführt

Verwenden Sie 'kubectl cluster-info dump', um Clusterprobleme weiter zu debuggen und zu diagnostizieren.

1. Führen Sie nun den Kube-Proxy aus
   kubectl Proxy &
   Beginn des Dienstes am 127.0.0.1:8001

Speichern Sie die ID, um sie später zu löschen :)

1. Finden Sie Ihren Namensraum, der entschieden hat, nicht gelöscht zu werden :) Für uns wird es ein Viehsystem sein
   kubectl get ns
   Viehsystem Abschluss 1d

lege es in die Datei

1. kubectl get Namespace Viehsystem -o json> tmp.json

1. Bearbeiten Sie die Datei und entfernen Sie die Finalizer
   },
   "spec": {
   "Finalizer": [
   "kubernetes"
   ]]
   },
   Nach der Bearbeitung sollte es so aussehen 👍
   },
   "spec": {
   "Finalizer": [
   ]]
   },
   wir fast da 👍

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

und es ist weg 👍

Hey, der Finalizer kubernetes ist aus einem bestimmten Grund da. Für uns war es ein falsch konfigurierter Metrik-API-Dienstname. Vielleicht ist für Sie etwas anderes, das Sie anhand Ihrer Protokolle in der Steuerebene entdecken können. Ohne Bestätigung eines Fehlers kann das Entfernen des Finalizers unerwünschte Folgen haben, z. B. das Belassen von Inhalten, die zum Löschen nicht mehr zugänglich sind.

da diese Ausgabe noch offen ist:
In meinem Minikube-Cluster, der mit "none" ausgeführt wird, geschah dies, nachdem der Host aus dem Ruhezustand aufgewacht war.

meine Annahme:
In meinem Fall löste der Ruhezustand dieselben Probleme aus, ein aktivierter Swap würde ausreichen.

was die Annahme ergibt:
Der Swap ist möglicherweise in den betroffenen Clustern aktiviert.

aber das ist nur eine Vermutung. Das Wichtigste für mich und jeden, der mit meinem lokalen Setup in diesem Fehler landet : Der

Nehmen Sie zuerst einen kleinen Kaffee und entspannen Sie sich. Gehen Sie jetzt zu Ihren k8s-Masterknoten

1. kubectl cluster-info
   Der Kubernetes-Master wird unter https: // localhost : 6443 ausgeführt
   KubeDNS wird unter https: // localhost : 6443 / api / v1 / namespaces / kube-system / services / kube- dns: dns / proxy ausgeführt

Verwenden Sie 'kubectl cluster-info dump', um Clusterprobleme weiter zu debuggen und zu diagnostizieren.

1. Führen Sie nun den Kube-Proxy aus
   kubectl Proxy &
   Beginn des Dienstes am 127.0.0.1:8001

Speichern Sie die ID, um sie später zu löschen :)

1. Finden Sie Ihren Namensraum, der entschieden hat, nicht gelöscht zu werden :) Für uns wird es ein Viehsystem sein
   kubectl get ns
   Viehsystem Abschluss 1d

lege es in die Datei

1. kubectl get Namespace Viehsystem -o json> tmp.json

1. Bearbeiten Sie die Datei und entfernen Sie die Finalizer
   },
   "spec": {
   "Finalizer": [
   "kubernetes"
   ]]
   },
   Nach der Bearbeitung sollte es so aussehen 👍
   },
   "spec": {
   "Finalizer": [
   ]]
   },
   wir fast da 👍

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

und es ist weg 👍

Großartig!!
Funktioniert

Ich stoße regelmäßig auf dieses Problem, wenn wir unsere gcloud-Instanzen ändern (z. B. Knoten aktualisieren). Dies ersetzt den alten Knoten von gcloud instances list durch einen neuen, lässt jedoch die Pods im k8s-Namespace hängen:

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

Dadurch bleiben die Hülsen in einem unbekannten Zustand:

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

Aus diesem Grund wird der Namespace niemals beendet. Ich bin mir nicht sicher, ob dies bedeutet, dass wir unsere Finalizer ändern sollten oder ob es einen tatsächlichen Fehler im Zusammenhang mit dem Beenden gibt, der Pods in einem UNKNOWN -Zustand behandeln sollte (oder ob es eine Möglichkeit geben sollte, das Beenden eines Namespace für Fälle wie diesen zu erzwingen ).

Ich stoße regelmäßig auf dieses Problem, wenn wir unsere gcloud-Instanzen ändern (z. B. Knoten aktualisieren). Dies ersetzt den alten Knoten von gcloud instances list durch einen neuen, lässt jedoch die Pods im k8s-Namespace hängen:

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

Dadurch bleiben die Hülsen in einem unbekannten Zustand:

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

Aus diesem Grund wird der Namespace niemals beendet. Ich bin mir nicht sicher, ob dies bedeutet, dass wir unsere Finalizer ändern sollten oder ob es einen tatsächlichen Fehler im Zusammenhang mit dem Beenden gibt, der Pods in einem UNKNOWN -Zustand behandeln sollte (oder ob es eine Möglichkeit geben sollte, das Beenden eines Namespace für Fälle wie diesen zu erzwingen ).

cool, es ist nicht das gleiche Problem
Sie müssen die Knoten in den Wartungsmodus versetzen. Nachdem sie sich im Wartungsmodus befinden, werden alle Pods evakuiert und können dann gelöscht / aktualisiert werden

schau es dir an ， https://kubernetes.io/docs/concepts/workloads/controllers/garbage-collection/ ,
Bearbeiten Sie die Ressource und löschen Sie metadata.finalizers ， und löschen Sie nicht nützliche crd ， Sie können sie erzwingen

Aber was macht der kubernetes Finalizer genau? Besteht das Risiko, dass Ressourcen mit diesem Hack nicht korrekt bereinigt werden?

Für den Turm, der feststeckte, half dies https://github.com/rook/rook/blob/master/Documentation/ceph-teardown.md

curl -k -H "Inhaltstyp: application / json" -X PUT --data-binary @ tmp.json https: // kubernetes-cluster-ip / api / v1 / namespaces / nerviger-namespace zum löschen / finalisieren

Fehler vom Server (NotFound): Namespaces "nerviger Namespace zum Löschen" nicht gefunden

Nehmen Sie zuerst einen kleinen Kaffee und entspannen Sie sich. Gehen Sie jetzt zu Ihren k8s-Masterknoten

1. kubectl cluster-info
   Der Kubernetes-Master wird unter https: // localhost : 6443 ausgeführt
   KubeDNS wird unter https: // localhost : 6443 / api / v1 / namespaces / kube-system / services / kube- dns: dns / proxy ausgeführt

Verwenden Sie 'kubectl cluster-info dump', um Clusterprobleme weiter zu debuggen und zu diagnostizieren.

1. Führen Sie nun den Kube-Proxy aus
   kubectl Proxy &
   Beginn des Dienstes am 127.0.0.1:8001

Speichern Sie die ID, um sie später zu löschen :)

1. Finden Sie Ihren Namensraum, der entschieden hat, nicht gelöscht zu werden :) Für uns wird es ein Viehsystem sein
   kubectl get ns
   Viehsystem Abschluss 1d

lege es in die Datei

1. kubectl get Namespace Viehsystem -o json> tmp.json

1. Bearbeiten Sie die Datei und entfernen Sie die Finalizer
   },
   "spec": {
   "Finalizer": [
   "kubernetes"
   ]]
   },
   Nach der Bearbeitung sollte es so aussehen 👍
   },
   "spec": {
   "Finalizer": [
   ]]
   },
   wir fast da 👍

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

und es ist weg 👍

Ungültiger Wert: "Validierung der bearbeiteten Datei fehlgeschlagen": ValidationError (Namespace.spec): Ungültiger Typ für io.k8s.api.core.v1.NamespaceSpec: "string", erwartete "map"

Wenn in Terminating viele Namespaces stecken bleiben, können Sie dies automatisieren:

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

Stellen Sie sicher, dass alle Namespaces, für die der Finalizer entfernt werden soll, tatsächlich Terminating .

Sie benötigen kubectl proxy running und jq damit das oben genannte funktioniert.

In unserem Fall ist der Metrik-API-Dienst nicht verfügbar und ich kann dieses Fehlerprotokoll anhand der ausführlichen Protokollierung sehen

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

Nach dem Fixieren des Metrik-Apiservices sind die Beendigung abgeschlossen.
Ich bin mir nicht sicher, warum das Löschen vom Metrik-Apiservice abhängt. Ich bin auch daran interessiert zu wissen, wie es funktioniert, wenn der Metrik-Apiservice nicht im Cluster installiert ist

Ich bin mir nicht sicher, warum das Löschen vom Metrik-Service abhängt.

@manojbadam Da Metriken auf dem API-Server registriert sind, muss beim Ausführen eines Namespace-Löschvorgangs die externe API nach (Namespace-) Ressourcen abgefragt werden, die gelöscht werden sollen (falls vorhanden), die diesem Namespace zugeordnet sind. Wenn der Erweiterungsserver nicht verfügbar ist, kann Kubernetes nicht garantieren, dass alle Objekte entfernt wurden, und es gibt keinen dauerhaften Mechanismus (im Speicher oder auf der Festplatte), der später abgeglichen werden kann, da das Stammobjekt entfernt worden wäre. Dies geschieht bei jedem registrierten API-Erweiterungsdienst.

Da ich ständig darauf stieß, automatisierte ich dies mit einem kleinen Shell-Skript:

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

Es ruft das Projekt ab, repariert den JSON, startet und stoppt "kubectl proxy",…

Vielen Dank an alle, die mich in die richtige Richtung weisen!

Da ich ständig darauf stieß, automatisierte ich dies mit einem kleinen Shell-Skript:

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

Es ruft das Projekt ab, repariert den JSON, startet und stoppt "kubectl proxy",…

Vielen Dank an alle, die mich in die richtige Richtung weisen!

mein Held! <3

Ich bin auch auf dieses Problem gestoßen. Ich bin in der Google Kubernetes Engine und verwende Terraform, um Kubernetes-Cluster hochzufahren und Namespaces und Pods innerhalb des Clusters zu erstellen. Das Problem begann eine Weile, nachdem ein terraform destroy .

In meinem Fall stellt sich heraus, dass dies ein Problem mit der Reihenfolge ist, in der Terraform die Zerstörung ausführt. Terraform löscht zuerst den Knotenpool und dann die Namespaces und Pods. Aufgrund des Löschens des (einzigen) Knotenpools brach der Kubernetes-Cluster jedoch zusammen, und dies führte dazu, dass das Löschen des Namespaces beim "Beenden" für immer hängen blieb.

@FooBarWidget das gleiche Problem für mich :(

Da ich ständig darauf stieß, automatisierte ich dies mit einem kleinen Shell-Skript:

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

Es ruft das Projekt ab, repariert den JSON, startet und stoppt "kubectl proxy",…

Vielen Dank an alle, die mich in die richtige Richtung weisen!

[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

Ich habe einen Rückkehrcode 403, was soll ich tun :(

Da ich ständig darauf stieß, automatisierte ich dies mit einem kleinen Shell-Skript:
https://github.com/ctron/kill-kube-ns/blob/master/kill-kube-ns
Es ruft das Projekt ab, repariert den JSON, startet und stoppt "kubectl proxy",…
Vielen Dank an alle, die mich in die richtige Richtung weisen!

[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

Ich habe einen Rückkehrcode 403, was soll ich tun :(

Thx Gott, der abschließende Namespace ist endlich weg. Die folgende Methode macht einen Trick für mich.

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

Ich habe das gleiche Problem, aber ich sehe keinen Metrik-Service.

Ich spiele mit K8s von Digitalocean und Gitlab Auto Devops herum. Ich gehe davon aus, dass es sich um einen Digitalocean-Blob-Speicher handelt, aber ich weiß nicht, wie ich ihn analysieren oder beheben soll.

@mingxingshi tx. Hat einen Namespace bearbeitet, der den Trick nicht gemacht hat. Ihr Skript hat es geschafft.

Wow, endlich losgeworden. Danke für die Befehle @mingxingshi !

Die Lösung für mich war:

kubectl delete apiservice v1beta1.metrics.k8s.io

Ich dachte nur, ich sollte meine Erfahrung hier lassen:

Ich habe terraform apply mit der folgenden Ressource gemacht:

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

Aber ich bin ein Helm-Neuling und hatte eine Vorlage, die eine Vorlage enthielt, die einen Namespace namens servicer . Dies führte dazu, dass Terraform und k8s in diesen schlechten Zustand gerieten, in dem Terraform fehlschlagen würde. Dann ließen k8s den Namespace servicer dauerhaft im Zustand Terminating . Wenn Sie das tun, was

Dieses Problem trat für mich nicht mehr auf, als ich die Vorlage entfernte, die den Namespace erstellt hatte, und es dem Ruder überließ, sie zu erstellen.

Das Problem ist für mich völlig wiederholbar. Klonen Sie zuerst den Prometheus-Operator . Dann:

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

Hängt. Wenn ich jedoch kubectl delete -f manifests/ , ist die Bereinigung erfolgreich.

Ja, hatte den gleichen Hang mit Prometheus-Operator. Müssen kubectl delete -f manifests/ zu lösen.
Ich denke, es gibt einige Finalisierer in Prometheus-CRDs, die sich schlecht benehmen. In diesem speziellen Szenario ist es kaum ein Fehler von Kubernetes. Kubernetes sollten es jedoch einfacher machen, den Schuldigen zu finden, da die Länge dieses Threads zeigt, dass es viele Ursachen geben kann und es in jedem Szenario nicht einfach ist, dem auf den Grund zu gehen.

Ich bin ein Kubernetes Noob, daher kann ich hier nicht viele Informationen anbieten, aber ich habe auch 2 Namespaces, die im Beendigungsstatus stecken. Mein Kubernetes-Setup verwendet 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

Ich habe zwei Namespaces im Endzustand

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

Wenn ich die Finalisierer wie in diesem Kommentar beschrieben überprüfe, sehe ich nur 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

Unabhängig davon habe ich versucht, kubernetes aus den Finalisierern zu entfernen, und es hat nicht funktioniert. Ich habe auch versucht, den in diesem Kommentar beschriebenen json / api-Ansatz

Ich habe auch versucht, das Löschen zu erzwingen, und das funktioniert auch nicht

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.

In meinem Fall ist der Namespace rook-ceph, kubectl -n rook-ceph patch cephclusters.ceph.rook.io rook-ceph -p '{"metadata":{"finalizers": []}}' --type=merge funktioniert für mich. In anderen Fällen sollte es auch funktionieren.

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

@ManifoldFR , ich hatte das gleiche Problem wie Sie und es gelang mir, es durch einen API-Aufruf mit der JSON-Datei zum
kubectl get namespace annoying-namespace-to-delete -o json > tmp.json
Bearbeiten Sie dann tmp.json und entfernen Sie "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

und es sollte Ihren Namespace löschen,

Ich habe ein Problem bei der Verwendung Ihres Ansatzes. Was kann ich für die Fehlerbehebung im nächsten Schritt tun?

~ 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 , ich hatte das gleiche Problem wie Sie und es gelang mir, es durch einen API-Aufruf mit der JSON-Datei zum
kubectl get namespace annoying-namespace-to-delete -o json > tmp.json
Bearbeiten Sie dann tmp.json und entfernen Sie "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
und es sollte Ihren Namespace löschen,

Ich habe ein Problem bei der Verwendung Ihres Ansatzes. Was kann ich für die Fehlerbehebung im nächsten Schritt tun?

~ 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

Mein Problem kann mit diesem Skript gelöst werden: 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 macht den Trick

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"

Es scheint, dass Namespaces tatsächlich nicht gelöscht werden.
In meinem Fall zeigt kubectl get ns nicht den gelöschten Namespace an, sondern kubectl get all -n <namespace> zeigt alle Ressourcen sicher und zuverlässig an.
Ich habe die Knoten überprüft und Docker-Container wurden noch ausgeführt ...

@glouis , weil Sie die Finalizer mit der oben beschriebenen Methode umgangen haben, sodass Kubernetes keine Zeit hatte, alle wichtigen Löschaufgaben auszuführen.

Es ist wirklich traurig zu sehen, dass so viele Menschen blind für diese Methode eintreten, ohne ihre Konsequenzen zu verstehen. Es ist extrem hässlich und kann möglicherweise Tonnen von Resten im Cluster hinterlassen. @javierprovecho bereits erwähnte es oben und @liggitt auch erwähnte es in einer anderen GitHub Frage.

Sie sollten den defekten API-Service v1beta1.metrics.k8s.io besser löschen, wenn Sie ihn nicht benötigen.

Siehe auch # 73405

Ich zweite @antoineco Nachricht. Ich habe dies in einer unserer Sandbox-Umgebungen getestet, weil wir ständig feststeckende Namespaces hatten. Nach ungefähr einem Monat froren alle Docker-Dämonen ohne Grund. Es stellte sich heraus, dass wir große Speicherlecks verursacht haben, weil wir Ressourcen zurückgelassen haben.

Nach vielem Ausprobieren und Lesen dieser Kommentare stellte sich heraus, dass es sich um eine benutzerdefinierte Ressourcendefinition für den Coreos-Grafana-Stack für die Namespaces handelte. Das Auflisten der CRDs zeigte spezifische Ressourcen für diesen Namespace. Ich hatte großes Glück, dass der Name der CRD den Namespace enthielt, der feststeckte.

Es stellte sich auch heraus, dass ein festsitzender Namespace weitere zu löschende Namespaces stoppt. Selbst wenn Sie einen Namespace A haben, in dem keine CRDs hängen bleiben, und es einen Namespace B mit einer steckengebliebenen CRD gibt, bleiben alle Ressourcen in A erhalten, bis B weg ist. Ich denke, ich muss die oben beschriebene Korrektur für Namespace A durchgeführt haben und jedes Mal eine Menge Ressourcen übrig gelassen haben.

Die Sache, die mich immer noch umbringt, ist, dass ich für mein ganzes Leben kein Protokoll finden kann, in dem erwähnt wird, dass eine Namespace-Bereinigung beim Löschen einer CRD fehlschlägt oder sogar, was sie gerade tut. Ich musste eine Stunde damit verbringen, herauszufinden, auf welcher CRD es klebte. Wenn jemand eine Idee hat, wie er mehr Informationen erhalten kann, muss ich nicht viel Zeit damit verbringen, die feststeckende Ressource herauszufinden, die fantastisch wäre.

@jecafarelli guter Hinweis für Produktionscluster. Aber unglücklich für mich, ich konnte es einfach nicht anders töten. Ich wusste auch, dass ich später den gesamten Cluster neu erstellen werde.

Ich habe versucht, das Problem zu analysieren, aber nichts in diesem Thread hat mir geholfen, es auf andere Weise zu lösen.

Diese offizielle Lösung hat mir geholfen: https://success.docker.com/article/kubernetes-namespace-stuck-in-terminating
Dies ist nicht dasselbe wie kubectl edit namespace rook-ceph . Ich konnte dieses Problem nicht lösen, bis ich PUT mit gelöschten _ "Finalizern" _ anforderte

ok also bin ich mit coreos wieder darauf gestoßen und habe ein bisschen tiefer gegraben. Dies liegt definitiv an einer clusterweiten Ressourcendefinition mit Namespace, und außerdem kann sie möglicherweise nicht gelöscht werden, da keine Informationen zu Coreos abgefragt werden können. Ich habe Fehler in den Apiserver-Protokollen gefunden, die Fehler beim Abrufen von Informationen zu einer API-Gruppe zeigten. Ich habe das oben genannte Problem verwendet, um ein schnelles Skript zu erstellen, in dem die Ressourcen aufgelistet sind, bei denen die ns für mich hängen geblieben sind.

Ich werde dies wahrscheinlich in Zukunft nur verwenden, wenn ich erneut darauf stoße und weitere Ressourcen mit Namespace hinzufüge, auf die ich stoße.

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

Vielen Dank @jecafarelli , du hast mir geholfen, mein Problem richtig zu lösen

Ich hatte Cert-Manager in einem OpenShift-Cluster im Cert-Manager-Namespace installiert und als ich versuchte, diesen Namespace zu löschen, blieb er im Beendigungsstatus hängen. Das Ausführen von oc delete apiservices v1beta1.admission.certmanager.k8s.io scheint das Problem gelöst zu haben, der Namespace ist weg.

Vielen Dank @jecafarelli , du hast mir geholfen, mein Problem richtig zu lösen

Ich hatte Cert-Manager in einem OpenShift-Cluster im Cert-Manager-Namespace installiert und als ich versuchte, diesen Namespace zu löschen, blieb er im Beendigungsstatus hängen. Das Ausführen von oc delete apiservices v1beta1.admission.certmanager.k8s.io scheint das Problem gelöst zu haben, der Namespace ist weg.

Das gleiche gilt für kubectl delete -f https://raw.githubusercontent.com/jetstack/cert-manager/release-0.8/deploy/manifests/00-crds.yaml

Ich mische mich nur ein, um zu sagen, dass ich diesen Fehler auch bei Version 1.13.6 mit GKE festgestellt habe. Dies geschah, nachdem ich das Istio-Addon von GKE deaktiviert hatte, um es manuell zu installieren und die volle Kontrolle zu behalten.
Dies ist der längste Themen-Thread, für dessen Durchlesen ich mir jemals die Zeit genommen habe, und ich bin überwältigt, dass es keine wirklichen Konsens- oder Reproduktionsschritte gibt, um die Wurzel dieses Problems zu finden. Es scheint, dass es auf so viele verschiedene Arten ausgelöst werden kann :(

Die oben mehrfach erwähnte und unter https://success.docker.com/article/kubernetes-namespace-stuck-in-terminating dokumentierte JSON- und Curl / Proxy-Methode hat mich gerettet.

Der Rat unter https://success.docker.com/article/kubernetes-namespace-stuck-in-terminating ist aktiv schädlich und kann dazu führen, dass verwaiste Ressourcen nicht bereinigt werden und wieder auftauchen, wenn ein Namespace mit identischem Namen später neu erstellt wird .

Es wird derzeit daran gearbeitet, die spezifische Ursache für das Löschen zu ermitteln. Das grundlegende Problem besteht jedoch darin, dass es API-Typen gibt, deren Bereinigung nicht überprüft werden kann. Daher wird das Löschen des Namespace blockiert, bis sie überprüft werden.

Wir haben dies auch mit Knative erreicht, das diesen namespace apiservice installiert.

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

Nach dem Löschen wurden sowohl das knative Serving ns als auch eine Reihe anderer festsitzender Namespaces aufgeräumt. Vielen Dank an @jecafarelli für das obige Bash-Skript.
Hier ist eine schreckliche Powershell-Version.

$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

Ich hatte heute das gleiche Problem und dieses Skript funktionierte für mich.

@ kubernetes / sig-api-machine-misc

Dieser Fehler besteht seit> einem Jahr und ist immer noch ein Problem ... Was ist Ihr Plan, um eingehende Probleme wie dieses zu beheben?

Dies könnte helfen, zumindest zu verstehen, was los ist: https://github.com/kubernetes/kubernetes/pull/80962

Ich treffe das gleiche Problem

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

Der Namespace-Controller sollte Bedingungen an den Namespace-Status melden, und Clients sollten dies melden. Benötigt einen KEP, sollte aber ziemlich einfach sein, wenn jemand ihn nehmen und validieren kann.

@timothysc Es gibt (oder gab) eine PR im Flug (irgendwo), die genau das tut, was @smarterclayton sagt.

Ich bin mir ziemlich sicher, dass es auch ein anderes Github-Problem gibt?

Ja, die PR ist hier: https://github.com/kubernetes/kubernetes/pull/73405

Das Problem, das ich für kanonisch halte, ist hier: https://github.com/kubernetes/kubernetes/issues/70916

Hier ist eine Ressource, die mir geholfen hat: https://www.ibm.com/support/knowledgecenter/de/SSBS6K_3.1.1/troubleshoot/ns_terminating.html

Es ähnelt der von @slassh vorgeschlagenen kubectl proxy , um einen lokalen Proxy zu erstellen und die Ziel-IP des Befehls curl vorhersehbar zu machen.

- -

Bearbeiten: Wie unter dieser Antwort mehrmals angegeben, ist diese Lösung ein schmutziger Hack und hinterlässt möglicherweise einige abhängige Ressourcen im Cluster. Die Verwendung erfolgt auf eigenes Risiko und möglicherweise nur als schneller Ausweg in einem Entwicklungscluster (nicht in einem Produktionscluster).

Das direkte Entfernen des Finalizers wie im obigen Dokument beschrieben kann Konsequenzen haben. Die Ressourcen, deren Löschung ausstand, werden auch nach der Freigabe des Namespace im Cluster definiert. Dies ist der Zweck des Finalizers. Um sicherzustellen, dass alle abhängigen Elemente entfernt werden, bevor das Löschen des ns ermöglicht wird.

Problemumgehung in ähnlichen Fragen gefunden:

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

Problemumgehung in ähnlichen Fragen gefunden:

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

Vielen Dank!
Es funktioniert gut.
Ich erstelle eine einfache App mit dieser Problemumgehung: https://github.com/jenoOvchi/k8sdelns
Ich benutze es zum schnellen Löschen und hoffe, dass es für jemanden hilfreich ist.

Kubernetes 1.12.2-Namespaces befinden sich im Status "Beenden". Manchmal können die Finalizer gelöscht werden, indem das yaml von ns geändert wird. Es kann nicht von API gelöscht werden. Kann es gelöscht werden? Was ist die Situation? Haben wir es speziell verfolgt (Voraussetzung: Es gibt keine Ressourcen in diesem ns), hoffe ich kann Hinweise bekommen, danke!

Bitte entfernen Sie den Finalizer nicht, er ist aus einem bestimmten Grund vorhanden. Versuchen Sie stattdessen herauszufinden, welche Ressourcen im NS noch gelöscht werden müssen, indem:

• Überprüfen, ob ein Apiservice nicht verfügbar ist und daher seine Ressourcen nicht bereitstellt: kubectl get apiservice|grep False
• Finden aller Ressourcen, die noch vorhanden sind, über kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get -n $your-ns-to-delete (ein großes Lob an Jordan für diese)

Die Lösung für dieses Problem besteht nicht darin, den Bereinigungsmechanismus kurzzuschließen, sondern herauszufinden, was den Erfolg der Bereinigung verhindert.

Bitte entfernen Sie den Finalizer nicht, er ist aus einem bestimmten Grund vorhanden. Versuchen Sie stattdessen herauszufinden, welche Ressourcen im NS noch gelöscht werden müssen, indem:

• Überprüfen, ob ein Apiservice nicht verfügbar ist und daher seine Ressourcen nicht bereitstellt: kubectl get apiservice|grep False
• Finden aller Ressourcen, die noch vorhanden sind, über kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get -n $your-ns-to-delete (ein großes Lob an Jordan für diese)

Die Lösung für dieses Problem besteht nicht darin, den Bereinigungsmechanismus kurzzuschließen, sondern herauszufinden, was den Erfolg der Bereinigung verhindert.

Wie richtig du bist.
In meinem Fall wurde der Pod von Operator Framework apiservice gelöscht und der Beendigungsprozess blockiert.
Nicht verwendeten Apiservice entfernen (kubectl delete apiservice) Problem gelöst.

Hallo zusammen, das Einfrieren des Codes erfolgt in nur wenigen Tagen (Donnerstag, Ende des Tages, PST). Daher müssen wir sicherstellen, dass dieses Problem für Version 1.16 behoben oder auf Version 1.17 verschoben wird. Können Sie den Status kommentieren?

Wird dies in eine aktuelle GKE-Version zurückportiert? Ich habe einen Cluster mit einer Handvoll Namespaces, die noch "terminieren".

@squarelover auch danach? https://github.com/kubernetes/kubernetes/issues/60807#issuecomment -524772920

@josiahbjorgaard Ich habe gerade die PR genehmigt, was alles ist, was wir für 1.16 tun werden.

https://github.com/kubernetes/kubernetes/pull/73405 ist die oben genannte PR

Es ist zusammengeführt. Ich denke, wir können vielleicht noch mehr tun, aber bitte nehmen Sie zukünftige Kommentare zu # 70916.

Bitte entfernen Sie den Finalizer nicht, er ist aus einem bestimmten Grund vorhanden. Versuchen Sie stattdessen herauszufinden, welche Ressourcen im NS noch gelöscht werden müssen, indem:

• Überprüfen, ob ein Apiservice nicht verfügbar ist und daher seine Ressourcen nicht bereitstellt: kubectl get apiservice|grep False
• Finden aller Ressourcen, die noch vorhanden sind, über kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get -n $your-ns-to-delete (ein großes Lob an Jordan für diese)

Die Lösung für dieses Problem besteht nicht darin, den Bereinigungsmechanismus kurzzuschließen, sondern herauszufinden, was den Erfolg der Bereinigung verhindert.

In vielen Fällen ist möglicherweise Metric-Server installiert. Wenn die Pods, die Sie in einem bestimmten Namespace bereitstellen, nach der Erfassung von Metriken suchen. Es hängt mit dem Metric-Server zusammen. Selbst nachdem Sie alle Ressourcen in diesem Namespace gelöscht haben, ist der Metricserver irgendwie mit diesem Namespace verknüpft. Dadurch wird verhindert, dass Sie den Namespace löschen.
In diesem Beitrag können Sie den Grund ermitteln, warum Sie den Namespace nicht löschen können. Also der Ritusweg.

Versuchen Sie dies, um die aktuelle Liste aller Dinge in Ihrem Namespace zu erhalten: kubernetes / kubectl # 151 (Kommentar)

Führen Sie dann für jedes Objekt kubectl delete oder kubectl edit , um die Finalizer zu entfernen.

Diese Lösung ist nützlich für mich, danke.

Hallo Leute,

Ich habe ein Skript erstellt, um das Löschen von Namespaces im Abschlussstatus zu vereinfachen: https://github.com/thyarles/knsk.

Vielen Dank.

Wir haben das gleiche Problem festgestellt: Beim Löschen eines Namespace bleibt dieser im Status "Beenden" hängen. Ich habe die obigen Schritte befolgt, um 'kubernetes' im Finalizer in der yaml-Datei zu entfernen. Es klappt.

Wir wissen jedoch nicht, warum wir zusätzliche Schritte ausführen müssen. Es sollte kubectl löschen ns foonamespace und es sollte löschen. Kann mir jemand einen Grund geben? Vielen Dank!

Hallo @ xzhang007 ,

Wenn Sie herausfinden, warum das Löschen des Namespace im Status "Beenden" stecken bleibt, lassen Sie es mich bitte wissen. Ich habe eine Weile versucht, eine gute Antwort zu finden, aber nichts. Dann habe ich ein Skript erstellt, um mir das Leben zu erleichtern, bis ich die Ursache entdeckt und behoben habe.

Vielen Dank.

@thyales es scheint, dass ich bis jetzt keine Antwort gefunden habe.

In unserem Fall haben wir festgestellt, dass wir einer der Webhhoks und Finalizer waren
Verwenden war, nach einer Kapsel zu greifen, die in den Namespaces lebte, die es gab
gelöscht.
Sobald der Pod gelöscht wurde, steckte die Beendigung fest.

>

@ xzhang007 hast du dir die Antwort @alvaroaleman angesehen ? Für uns war das genug, um herauszufinden, was die Ursache war.

Bitte entfernen Sie den Finalizer nicht, er ist aus einem bestimmten Grund vorhanden. Versuchen Sie stattdessen herauszufinden, welche Ressourcen im NS noch gelöscht werden müssen, indem:

• Überprüfen, ob ein Apiservice nicht verfügbar ist und daher seine Ressourcen nicht bereitstellt: kubectl get apiservice|grep False
• Finden aller Ressourcen, die noch vorhanden sind, über kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get -n $your-ns-to-delete (ein großes Lob an Jordan für diese)

Die Lösung für dieses Problem besteht nicht darin, den Bereinigungsmechanismus kurzzuschließen, sondern herauszufinden, was den Erfolg der Bereinigung verhindert.

Als dieses Problem geschlossen wurde, wurde auf ein neues Ticket verwiesen, um zu erläutern, wie klargestellt werden kann, warum der Namespace in Terminating stecken bleibt. Ich schlage vor, dass Sie das Gespräch dort anstelle dieses geschlossenen Themas führen.

Es ist zusammengeführt. Ich denke, wir können vielleicht noch mehr tun, aber bitte nehmen Sie zukünftige Kommentare zu # 70916.

@ Jeff-Knurek Das sollte der richtige Weg sein. Vielen Dank.

In unserem Fall war es ein verpfuschtes Upgrade von cert-manager das den Finalizer kaputt machte. 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

Hallo.
Mein Fall-Namespace bleibt beim Beenden hängen, wenn https://github.com/rancher/rancher/issues/21546#issuecomment -553635629

Vielleicht hilft es.

https://medium.com/@newtondev/how -to-fix-kubernetes-namespace-deleting-stecken-im-terminierungsstatus-5ed75792647e

Das hat für mich wie ein Champion funktioniert

Ich hatte auch das gleiche Problem, jetzt funktioniert es gut für mich. Bitte beziehen Sie sich auf das folgende Dokument und lösen Sie Ihr Problem

@zerkms gut, manchmal ist es ein legitimer Rat, nicht

Beachten Sie, dass der Artikel nur anwendbar ist, wenn das Problem durch die auf der Seite "Bekannte Probleme", die oben im Artikel verlinkt ist, aufgeführten Anwendungsschritte nicht behoben wurde. Dies ist im Grunde der Rat, den der von Ihnen verknüpfte Kommentar wiederholt.

@zerkms gut, manchmal ist es ein legitimer Rat, nicht

Ich habe noch nie gesehen, dass dies für einen spec.finalizer in einem Namespace zutrifft. Jede Instanz, die ich gesehen habe, war mit dem Namespace-Bereinigungscontroller verbunden und wurde entweder durch ein beständiges Objekt im Namespace verursacht (in dem dieser Hinweis enthalten wäre) oder durch eine nicht reagierende aggregierte API (die das Entfernen des Namespace spec.finalizer überspringen würde warten, auch alle persistierten Ressourcen von dieser API stranden)

Der Artikel warnt nicht davor, dass das Umgehen der Namespace-Finalisierung dazu führen kann, dass namespace-Ressourcen im Speicher verbleiben, und wird nicht empfohlen.

Ich habe noch nie gesehen, dass dies für einen spec.finalizer in einem Namespace zutrifft

Ja, das ist richtig, da dieser Finalizer von den Kubernetes selbst implementiert wird, aber es könnte andere Finalizer für Objekte in diesem Namespace geben, die von Objekten in diesem Namespace implementiert werden könnten. Ein Beispiel, auf das ich kürzlich gestoßen bin, war https://appscode.com/products/stash/ .

Es setzt Finalisierer auf einige seiner CRDs, die von der Stash-Operator-Bereitstellung gewartet werden sollen. Da der Stash-Operator bereits gelöscht wurde, kann nichts die Finalizer-Markierung von diesen CRDs entfernen, und das Löschen des Namespace bleibt hängen. In diesem Fall ist es nur sinnvoll, diese Finalizer auszubessern (nicht im Namespace selbst, sondern in diesen Objekten).

Hoffe es macht Sinn.

In diesem Fall ist es nur sinnvoll, diese Finalizer auszubessern (nicht im Namespace selbst, sondern in diesen Objekten).

Richtig. Ich würde dem in einem Bereinigungsszenario "Alle Ressourcen löschen" nicht widersprechen, aber das ist nicht das, was der verlinkte Artikel durchläuft ... es beschreibt, wie ein spec.finalizer aus dem Namespace entfernt wird.

Nehmen Sie zuerst einen kleinen Kaffee und entspannen Sie sich. Gehen Sie jetzt zu Ihren k8s-Masterknoten

kubectl cluster-info
Der Kubernetes-Master wird unter https: // localhost : 6443 ausgeführt
KubeDNS wird unter https: // localhost : 6443 / api / v1 / namespaces / kube-system / services / kube- dns: dns / proxy ausgeführt
Verwenden Sie 'kubectl cluster-info dump', um Clusterprobleme weiter zu debuggen und zu diagnostizieren.

Führen Sie nun den Kube-Proxy aus
kubectl Proxy &
Beginn des Dienstes am 127.0.0.1:8001
Speichern Sie die ID, um sie später zu löschen :)

1. Finden Sie Ihren Namensraum, der entschieden hat, nicht gelöscht zu werden :) Für uns wird es ein Viehsystem sein
   kubectl get ns
   Viehsystem Abschluss 1d

lege es in die Datei

1. kubectl get Namespace Viehsystem -o json> tmp.json

Bearbeiten Sie die Datei und entfernen Sie die Finalizer
},
"spec": {
"Finalizer": [
"kubernetes"
]]
},
Nach der Bearbeitung sollte es so aussehen 👍
},
"spec": {
"Finalizer": [
]]
},
wir fast da 👍
curl -k -H "Inhaltstyp: application / json" -X PUT --data-binary @ tmp.json http://127.0.0.1 : 8001 / api / v1 / namespaces / $ {NAMESPACE} / finalize

und es ist weg 👍

Bitte entfernen Sie den Finalizer nicht, er ist aus einem bestimmten Grund vorhanden. Versuchen Sie stattdessen herauszufinden, welche Ressourcen im NS noch gelöscht werden müssen, indem:

• Überprüfen, ob ein Apiservice nicht verfügbar ist und daher seine Ressourcen nicht bereitstellt: kubectl get apiservice|grep False
• Finden aller Ressourcen, die noch vorhanden sind, über kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get -n $your-ns-to-delete (ein großes Lob an Jordan für diese)

Die Lösung für dieses Problem besteht nicht darin, den Bereinigungsmechanismus kurzzuschließen, sondern herauszufinden, was den Erfolg der Bereinigung verhindert.

Hallo Leute! Ich folge den Tipps von @alvaroaleman und habe ein Skript erstellt, das das saubere Löschen überprüft und

Was macht das Skript https://github.com/thyarles/knsk :

1. Suchen Sie nach nicht verfügbaren Quellen und bitten Sie, diese zu löschen
2. Suchen Sie im Namespace nach ausstehenden Ressourcen und bitten Sie, diese zu löschen
3. Warten Sie ca. 5 Minuten, um festzustellen, ob Kubernetes einen sauberen Löschvorgang ausführt, wenn das Skript einen Löschvorgang ausführt
4. Löschen des feststeckenden Namespace erzwingen

Ich hoffe es hilft.

@ thyarles Vielen Dank. Ich habe Ihren Weg benutzt, um das Problem zu lösen.

$ kubectl veranlasst apiservices, zu überprüfen, welcher Dienst nicht verfügbar ist, die verfügbaren zu löschen, ist durch $ kubectl delete apiservice [Dienstname] falsch, und danach gibt es keine Probleme beim Löschen eines Namensraums.

Für unser Team gibt es 3 nicht verfügbare Apiservices: v1beta1.admission.certmanager.k8s.io, v1beta1.metrics.k8s.io und v1beta1.webhook.certmanager.k8s.io.

Beachten Sie, dass Ihr Cluster etwas kaputt ist, wenn der Metrik-Apiserver nicht ausgeführt wird. Nur das Entfernen des APIService behebt die eigentliche Ursache nicht.

@lavalamp Die Metriken sind ein nicht verfügbarer Apiservice.

Ja, was bedeutet, dass der Metrik-Apiserver nicht ausgeführt wird, was bedeutet, dass HPA in Ihrem Cluster nicht funktioniert, und wahrscheinlich auch in anderen Dingen.

Ja. HPA funktioniert jetzt nicht. Ich sollte keine Metriken löschen und einen Weg finden, dies zu beheben.

@ thyarles Vielen Dank. Ich habe Ihren Weg benutzt, um das Problem zu lösen.

$ kubectl veranlasst apiservices, zu überprüfen, welcher Dienst nicht verfügbar ist, die verfügbaren zu löschen, ist durch $ kubectl delete apiservice [Dienstname] falsch, und danach gibt es keine Probleme beim Löschen eines Namensraums.

Für unser Team gibt es 3 nicht verfügbare Apiservices: v1beta1.admission.certmanager.k8s.io, v1beta1.metrics.k8s.io und v1beta1.webhook.certmanager.k8s.io.

@ xzhang007 freut sich zu hören! Jetzt müssen Sie überprüfen, warum Ihre v1beta1.metrics.k8s.io defekt ist. Überprüfen Sie, wie es möchte:

`` `
$ kubectl -n kube-system alles bekommen | grep Metriken

pod /metrics-server-64f74f8d47-r5vcq 2/2 Running 9 119d
Service / Metrics-Server ClusterIP xx.xx.xx.xx443 / TCP 201d
Implementation.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 alles bekommen | grep Metriken

pod /metrics-server-5dcfd4dd9f-m2v9k 1/1 Läuft 0 2d20h

Service / Metrics-Server ClusterIP xx.xx.xx.xx443 / TCP 27d

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

Ja. HPA funktioniert jetzt nicht. Ich sollte keine Metriken löschen und einen Weg finden, dies zu beheben.

@ xzhang007 in der Tat funktioniert es nicht, bevor Sie das Problem bemerkt haben ... Sie haben es gerade bemerkt, weil es Ihre gelöschten Namespaces in den stecken gebliebenen Modus versetzt hat. Verwenden Sie einfach einen Helmpaket-Manager, um Ihren Metrik-Server erneut bereitzustellen, oder rufen Sie einfach den folgenden Befehl auf, um das Problem zu beheben ( überprüfen Sie die Bereitstellungsdatei, bevor Sie sie anwenden ):

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

@slassh Lösung funktionierte für mich auf Kubernetes 1.15

Löschen Sie den APIService v1beta1.metrics.k8s.io

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

Der Zertifikatsmanager war möglicherweise nicht verfügbar, da er falsch eingerichtet wurde. Verwenden Sie beispielsweise eine falsche Syntax im Ingress Controller. Für unser System war es das

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

und es wurde geändert zu

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

zur Verfügung stellen.

Wie bereits in dieser Ausgabe erwähnt, gibt es eine andere Möglichkeit, einen Namespace mithilfe einer API zu beenden, die nicht von kubectl verfügbar gemacht wurde, indem eine moderne Version von kubectl verwendet wird, für die kubectl replace --raw verfügbar ist (nicht sicher, von welcher Version). Auf diese Weise müssen Sie keinen kubectl proxy -Prozess erzeugen und eine Abhängigkeit von curl vermeiden (die in einer Umgebung wie Busybox nicht verfügbar ist). In der Hoffnung, dass dies jemand anderem hilft, habe ich dies hier gelassen:

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

Wurde festgestellt, ob dies ein behebbares Problem ist? Scheint hier eine Menge hackiger Lösungen zu sein, aber nichts, was das zugrunde liegende Problem angeht, dass keiner von uns seine Namespaces löschen kann ...
Ich habe dies auf EKS v1.14 Cluster

Wurde festgestellt, ob dies ein behebbares Problem ist? Scheint hier eine Menge hackiger Lösungen zu sein, aber nichts, was das zugrunde liegende Problem angeht, dass keiner von uns seine Namespaces löschen kann

Das grundlegende Problem besteht darin, dass eine aggregierte API-Gruppe in Ihrem Cluster nicht verfügbar ist. Es ist beabsichtigt, dass der Namespace-Bereinigungscontroller blockiert, bis alle APIs verfügbar sind, damit überprüft werden kann, ob alle Ressourcen aller API-Gruppen für diesen Namespace bereinigt wurden.

für ppl, die versuchen, die API zu locken:

# 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

Hier ist ein Skript, um dies automatisch zu tun. Benötigt 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

Jeder: Skripte zur Automatisierung der Entfernung des Finalizers schaden mehr als sie nützen . Sie können Zeitbomben in den aggregierten Apiservern hinterlassen, die nicht verfügbar sind. Wenn jemand den Namespace neu erstellt, werden plötzlich wieder einige alte Objekte angezeigt.

Die wirkliche Lösung ist:

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

Jeder: Skripte zur Automatisierung der Entfernung des Finalizers schaden mehr als sie nützen . Sie können Zeitbomben in den aggregierten Apiservern hinterlassen, die nicht verfügbar sind. Wenn jemand den Namespace neu erstellt, werden plötzlich wieder einige alte Objekte angezeigt.

Die wirkliche Lösung ist:

$ 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

Dieses Skript führt alle Überprüfungen durch und versucht, eine saubere Löschung durchzuführen, einschließlich der Suche nach verwaisten Ressourcen. Wenn der Benutzer ein Risiko eingehen möchte, bietet das Skript die Option --force, um eine nicht empfohlene Löschmethode auszuführen.

Tippfehler, sollte apiservices sein

Dieser Befehl zeigt nicht verfügbare APIs an:

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

Dieser Artikel wird Ihnen sicherlich nützlich sein:

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

Tatsächlich besteht ein Konflikt in den Apiservices, sie könnten den Gesundheitszustand der Apis in OpenShift validieren:

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

Die fehlgeschlagene API muss sie neu starten, den Pod oder die Bereitstellung, die zu dieser API gehört, neu starten und anschließend versuchen, den Namespace zu löschen.

$ oc namspace löschen

und fertig, Geschäft behoben !!

Ziemlich respektlos, wenn Sie Ihre eigene Sprache an einem Ort verwenden, an dem alle zustimmen, Englisch zu sprechen. 👎

Wo sind sich alle einig, Englisch zu sprechen?

Am Do, 30. April 2020 um 17:58 schrieb theAkito [email protected] :

Ziemlich respektlos, deine eigene Sprache an einem Ort zu verwenden, an dem jeder ist
stimmt zu, Englisch zu sprechen. 👎

- -
Sie erhalten dies, weil Sie kommentiert haben.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/kubernetes/kubernetes/issues/60807#issuecomment-622137770 ,
oder abbestellen
https://github.com/notifications/unsubscribe-auth/ALGMKB6K4OU4X3XOYMALOBLRPHYCDANCNFSM4ETUOEPA
.

>

Chris, Leitender Architekt @ brace.ai

- -

Vertraulichkeitshinweis: Diese E-Mail ist ausschließlich zur Verwendung durch die E-Mail bestimmt
beabsichtigte Empfänger und können vertrauliche, geschützte oder
privilegierte Informationen. Wenn Sie nicht der beabsichtigte Empfänger sind, sind Sie es
darüber informiert, dass jede Verwendung, Überprüfung, Verbreitung, Vervielfältigung oder ergriffene Maßnahme auf der Grundlage dieser Maßnahmen erfolgt
auf dieser Nachricht oder ihren Anhängen, falls vorhanden, ist verboten. Wenn Sie nicht sind
Den beabsichtigten Empfänger kontaktieren Sie bitte den Absender per Antwort-E-Mail und
Zerstören oder löschen Sie alle Kopien der Originalnachricht und aller Anhänge.

bereit, entschuldigen Sie, es war für meine Geschwindigkeit, es wurde behoben

Wir haben eine mehrsprachige Benutzerbasis, es ist schon schlimm genug, dass keines unserer Tools internationalisiert ist. Wir können hier auf Github zumindest nett sein, bitte.

@teoincontatto

Wie bereits in dieser Ausgabe erwähnt, gibt es eine andere Möglichkeit, einen Namespace mithilfe einer API zu beenden, die nicht von kubectl verfügbar gemacht wurde, indem eine moderne Version von kubectl verwendet wird, für die kubectl replace --raw verfügbar ist (nicht sicher, von welcher Version). Auf diese Weise müssen Sie keinen kubectl proxy -Prozess erzeugen und eine Abhängigkeit von curl vermeiden (die in einer Umgebung wie Busybox nicht verfügbar ist). In der Hoffnung, dass dies jemand anderem hilft, habe ich dies hier gelassen:

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

Das hat perfekt funktioniert!

Wir haben eine mehrsprachige Benutzerbasis, es ist schon schlimm genug, dass keines unserer Tools internationalisiert ist. Wir können hier auf Github zumindest nett sein, bitte.

Wir haben eine mehrsprachige Benutzerbasis, es ist schon schlimm genug, dass keines unserer Tools internationalisiert ist. Wir können hier auf Github zumindest nett sein, bitte.

Ich versuche immer noch zu verstehen. Vergib mir. Möglicherweise habe ich versehentlich die Daumen nach unten geklickt.
Ja, Werkzeuge wurden nicht perfekt ausgeführt.
Diejenigen, die ohne Erklärung einen Daumen nach unten drücken, ergeben keinen Sinn.

Fast die ganze Zeit, in der ich dieses Problem erlebe, liegt es an den CRDs. Löschen Sie CRDs, wenn sie nur in diesem Namespace verwendet werden. Anschließend können Sie Finalizer und Namespace löschen.

Wie bereits in dieser Ausgabe erwähnt, gibt es eine andere Möglichkeit, einen Namespace mithilfe einer API zu beenden, die nicht von kubectl verfügbar gemacht wurde, indem eine moderne Version von kubectl verwendet wird, für die kubectl replace --raw verfügbar ist (nicht sicher, von welcher Version). Auf diese Weise müssen Sie keinen kubectl proxy -Prozess erzeugen und eine Abhängigkeit von curl vermeiden (die in einer Umgebung wie Busybox nicht verfügbar ist). In der Hoffnung, dass dies jemand anderem hilft, habe ich dies hier gelassen:

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 Danke! Das hat endlich geklappt!

Manchmal funktioniert es nicht sehr gut, nur das Ressourcenmanifest online zu bearbeiten (ich meine, entfernen Sie das eingereichte finalizers und speichern Sie es).
Also habe ich einen neuen Weg von anderen bekommen.

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

Nachdem Sie diesen Befehl ausgeführt haben, sollte der Namespace jetzt nicht mehr in Ihrer Namespace-Liste enthalten sein. Und das funktioniert bei mir.

Nicht nur namespace sondern auch die anderen Ressourcen.

Ich habe das Problem behoben, indem ich die Finalizer-Zeilen mit: kubectl edit annoying-ns

Hmm ... ich habe dieses Problem gerade :)
Heute habe ich ein Update meines eks-Clusters von 1.15 auf 1.16 durchgeführt.
Bisher sieht alles gut aus.
Aber meine Entwicklung ns "configcluster" war eine Art "beschädigt".
Also entscheide ich mich, es aufzuräumen.

k lösche ns configcluster
....
jetzt hängt dies (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

Wie können wir diesem Dorn im Auge mehr ausgesetzt sein?

Am Fr, 19. Juni 2020 um 04:46 Uhr Andreas Höhmann [email protected]
schrieb:

Hmm ... ich habe dieses Problem gerade :)
Heute habe ich ein Update meines eks-Clusters von 1.15 auf 1.16 durchgeführt.
Bisher sieht alles gut aus.
Aber meine Entwicklung ns "configcluster" war eine Art "beschädigt".
Also entscheide ich mich, es aufzuräumen.

k lösche ns configcluster
....
jetzt hängt dies (3h +): /

$ kubectl get Namespace configcluster -o yaml
apiVersion: v1
Art: Namespace
Metadaten:
Anmerkungen:
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: Konfigurationscluster
resourceVersion: "22598109"
selfLink: / api / v1 / namespaces / configcluster
UID: e50f0b53-b21e-4e6e-8946-c0a0803f031b
spec:
Finalisierer:

• kubernetes
  Status:
  Bedingungen:
• lastTransitionTime: "2020-06-19T09: 19: 21Z"
  Meldung: 'Ermittlung für einige Gruppen fehlgeschlagen, 1 fehlgeschlagen: Die kann nicht abgerufen werden
  Vollständige Liste der Server-APIs :metrics.k8s.io/v1beta1: Der Server befindet sich derzeit
  kann die Anfrage nicht bearbeiten '
  Grund: DiscoveryFailed
  Status: "True"
  Typ: NamespaceDeletionDiscoveryFailure
• lastTransitionTime: "2020-06-19T09: 19: 22Z"
  Nachricht: Alle älteren Kube-Typen wurden erfolgreich analysiert
  Grund: ParsedGroupVersions
  Status: "Falsch"
  Typ: NamespaceDeletionGroupVersionParsingFailure
• lastTransitionTime: "2020-06-19T09: 19: 22Z"
  Nachricht: Alle Inhalte erfolgreich gelöscht
  Grund: ContentDeleted
  Status: "Falsch"
  Typ: NamespaceDeletionContentFailure
  Phase: Beenden

- -
Sie erhalten dies, weil Sie kommentiert haben.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/kubernetes/kubernetes/issues/60807#issuecomment-646543073 ,
oder abbestellen
https://github.com/notifications/unsubscribe-auth/AFLKRCLHIZ77X2Z3F5GAOCTRXMXVTANCNFSM4ETUOEPA
.

@bobhenkel Nun, dieses Problem ist geschlossen. Dies bedeutet also effektiv, dass es kein Problem gibt (was umsetzbare Elemente betrifft). Wenn Sie praktische Hilfe bei der Bewältigung einer ähnlichen Situation benötigen, lesen Sie bitte den obigen Thread. Dort gibt es einige gute (und auch einige schlechte) Ratschläge.

In meinem Fall musste ich meinen Ingress Load Balancer manuell von der GCP Network Service-Konsole löschen. Ich hatte das Load Balancer-Frontend manuell direkt in der Konsole erstellt. Nachdem ich den Load Balancer gelöscht hatte, wurde der Namespace automatisch gelöscht.

Ich vermute, dass Kubernetes nicht löschen wollte, da sich der Status des Load Balancers vom Status im Manifest unterschied.

Ich werde versuchen, die Erstellung des Ingress-Frontends mithilfe von Anmerkungen zu automatisieren, um festzustellen, ob ich dieses Problem beheben kann.

Manchmal funktioniert es nicht sehr gut, nur das Ressourcenmanifest online zu bearbeiten (ich meine, entfernen Sie das eingereichte finalizers und speichern Sie es).
Also habe ich einen neuen Weg von anderen bekommen.

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

Nachdem Sie diesen Befehl ausgeführt haben, sollte der Namespace jetzt nicht mehr in Ihrer Namespace-Liste enthalten sein. Und das funktioniert bei mir.

Nicht nur namespace sondern auch die anderen Ressourcen.

Du bist ein Star, es hat funktioniert

Manchmal funktioniert es nicht sehr gut, nur das Ressourcenmanifest online zu bearbeiten (ich meine, entfernen Sie das eingereichte finalizers und speichern Sie es).
Also habe ich einen neuen Weg von anderen bekommen.

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

Nachdem Sie diesen Befehl ausgeführt haben, sollte der Namespace jetzt nicht mehr in Ihrer Namespace-Liste enthalten sein. Und das funktioniert bei mir.

Nicht nur namespace sondern auch die anderen Ressourcen.

Ich habe viele Lösungen ausprobiert, aber dies ist die, die für mich funktioniert hat. Vielen Dank!

curl -k -H "Inhaltstyp: application / json" -X PUT --data-binary @ tmp.json https: // kubernetes-cluster-ip / api / v1 / namespaces / nerviger-namespace zum löschen / finalisieren

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

Dies sollte wirklich die "akzeptierte" Antwort sein - es hat die Wurzel dieses Problems vollständig gelöst!

Nehmen Sie aus dem obigen Link:

Dies ist insbesondere in einer Produktionsumgebung nicht der richtige Weg.

Heute bin ich auf das gleiche Problem gekommen. Wenn Sie den Finalizer entfernen, erhalten Sie Reste in verschiedenen Zuständen. Sie sollten tatsächlich herausfinden, was den Löschvorgang verhindert.

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

(Außerdem meldet 'kubetctl get all' leider nicht alle Dinge. Sie müssen ähnliche Befehle wie im Link verwenden.)

Mein Fall - Löschen des Namespace 'cert-manager'. In der Ausgabe von 'kubectl get apiservice -o yaml' habe ich APIService 'v1beta1.admission.certmanager.k8s.io' mit status = False gefunden. Dieser Apiservice war Teil des Cert-Managers, den ich gerade gelöscht habe. In 10 Sekunden, nachdem ich 'kisectl apiservice v1beta1.admission.certmanager.k8s.io' gelöscht habe, verschwand der Namespace.

Hoffentlich hilft das.

Nachdem dies gesagt wurde, habe ich einen kleinen Microservice geschrieben, der jede Stunde als CronJob ausgeführt wird und automatisch terminierende Namespaces löscht.

Sie finden es hier: https://github.com/oze4/service.remove-terminating-namespaces

Ich habe einen kleinen Microservice geschrieben, der jede Stunde als CronJob ausgeführt wird und automatisch terminierende Namespaces löscht.

Sie finden es hier: https://github.com/oze4/service.remove-terminating-namespaces

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

Das Löschen festsitzender Namespaces ist jedoch keine gute Lösung. Der richtige Weg ist herauszufinden, warum es feststeckt. Ein sehr häufiger Grund ist, dass es nicht verfügbare API-Dienste gibt, die verhindern, dass Cluster Namespaces finalisieren.
Zum Beispiel habe ich Knative hier nicht richtig gelöscht:

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

Das Löschen löste das Problem

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  

Ich habe einen kleinen Microservice geschrieben, der jede Stunde als CronJob ausgeführt wird und automatisch terminierende Namespaces löscht.

Sie finden es hier: https://github.com/oze4/service.remove-terminating-namespaces

Gut gemacht.

Ich hatte ein ähnliches Problem mit 1.18 in einem Labor-K8s-Cluster und fügte eine Notiz hinzu, um vielleicht anderen zu helfen. Ich habe mit der Metrik-API und insbesondere mit benutzerdefinierten Metriken gearbeitet. Nachdem diese k8s-Objekte gelöscht wurden, um sie neu zu erstellen, kam es beim Löschen des Namespace zu dem Fehler, dass der Metrik-API-Endpunkt nicht gefunden wurde. Wenn Sie das wieder in einen anderen Namespace einfügen, wird alles sofort geklärt.

Dies war im Namespace unter 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

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

Das Löschen festsitzender Namespaces ist jedoch keine gute Lösung. Der richtige Weg ist herauszufinden, warum es feststeckt. Ein sehr häufiger Grund ist, dass es nicht verfügbare API-Dienste gibt, die verhindern, dass Cluster Namespaces finalisieren.
Zum Beispiel habe ich Knative hier nicht richtig gelöscht:

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

Das Löschen löste das Problem

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  

Auf jeden Fall der sauberste Liner! Es ist wichtig zu beachten, dass keine dieser "Lösungen" das Grundproblem tatsächlich löst.

Hier finden Sie die richtige Lösung

Das ist die Botschaft, die sich verbreiten sollte: Lächeln: nicht "noch ein Einzeiler".

Endlich der sauberste Liner! Es ist wichtig zu beachten, dass keine dieser "Lösungen" das Grundproblem tatsächlich löst.

Diese Lösung löst eine der allen Möglichkeiten. Um nach allen möglichen Ursachen zu suchen und diese zu beheben, verwende ich dieses Skript: https://github.com/thyarles/knsk

@ Thyarles sehr schön!

Bitte verwenden Sie nicht modify finalize , um den Namespace zu löschen. Das wird einen Fehler verursachen

Bitte finden Sie die Ursache für die Beendigung des Namespace heraus. Derzeit bekannte Anweisungen zur Fehlerbehebung

• Pod wird beendet
• Cert-Manager Webhook Block Secrte

Ich stoße auf das gleiche Problem:

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

Sie können etcdctl , um nicht gelöschte Ressourcen zu finden

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>

Kopieren Sie es einfach und fügen Sie es in Ihr Terminal ein

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

Dies funktionierte für mich und ich lief, nachdem ich überprüft hatte, dass keine k8s-Objekte in der ns baumelten. Vielen Dank!

Ich habe dies verwendet, um einen Namespace zu entfernen, der bei Terminated hängen bleibt

Beispiel:

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

Für alle Googler, die bei Terminating on Rancher auf festsitzende Namespaces gestoßen sind (z. B. Viehsystem), hat der folgende modifizierte Befehl (Grebois 'Original) für mich funktioniert:

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

Leute, nur zu Ihrer Information , wenn das Video für diesen

Ich habe eine 10-minütige Erklärung aufgenommen und sie bei dieser SIG Deep Dive-Sitzung vorgestellt .

Hier ist ein korrekter Kommentar mit 65 positiven Stimmen

Dieser mehrfach erwähnte Beitrag ist ein Beispiel dafür, wie man Dinge richtig macht. Finden und beheben Sie den defekten API-Service.

Alle Einzeiler, die nur die Finalizer im Namespace entfernen, beheben die Grundursache und lassen Ihren Cluster auf subtile Weise kaputt, was Sie später beißen wird. Also mach das bitte nicht. Die Behebung der Grundursache ist normalerweise sowieso einfacher. Es scheint, dass die Leute gerne Variationen zu diesem Thema posten, obwohl es bereits zahlreiche richtige Antworten im Thread gibt. Deshalb werde ich das Problem jetzt sperren, um sicherzustellen, dass dieser Kommentar ganz unten bleibt.