Kubernetes: eliminar el espacio de nombres atascado en el estado "Terminando"

/ sig api-maquinaria

@ shean-guangchang ¿Tienes alguna forma de reproducir esto?

Y por curiosidad, ¿está utilizando algún CRD? Enfrentamos este problema con los TPR anteriormente.

/ tipo error

Parece que estoy experimentando este problema con una implementación de torre:

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

Creo que tiene algo que ver con su CRD, veo esto en los registros del servidor API:

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

Implementé rook en un espacio de nombres diferente ahora, pero no puedo crear el CRD del clúster:

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

Parece que el CRD nunca se limpió:

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

Tengo un espacio de nombres de fisión en un estado similar:

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

La fisión también usa CRD, sin embargo, parece que se limpian.

@ shean-guangchang - Tuve el mismo problema. Eliminé todo en los espacios de nombres manualmente, eliminé y purgué todo de "helm" y reinicié los nodos maestros uno por uno y solucionó el problema.

Me imagino que lo que he encontrado tiene algo que ver con "ark", "tiller" y Kuberenets todos trabajando juntos (arranqué usando helm y hice una copia de seguridad usando ark) por lo que esto puede no ser un problema de Kuberenets por decir, por otro lado. Por otro lado, fue prácticamente imposible solucionar el problema porque no hay registros relevantes.

si es la torre, eche un vistazo a esto: https://github.com/rook/rook/issues/1488#issuecomment -365058080

Supongo que tiene sentido, pero parece erróneo que sea posible poner un espacio de nombres en un estado indeleble.

Tengo un entorno similar (Ark & Helm) con @barakAtSoluto y tengo el mismo problema. Sin embargo, purgar y reiniciar los maestros no lo solucionó. Todavía estancado en terminar.

También tuve eso cuando intenté recrear el problema. Finalmente tuve que crear un nuevo clúster ...
Excluir: predeterminado, kube-system / public y todos los espacios de nombres relacionados con ark de la copia de seguridad y restauración para evitar que esto suceda ...

También veo esto también, en un clúster actualizado de 1.8.4 a 1.9.6. Ni siquiera sé qué registros mirar

El mismo problema en 1.10.1 :(

Mismo problema en 1.9.6

Editar: el espacio de nombres no se pudo eliminar debido a que algunos pods se cuelgan. Hice una eliminación con --grace-period = 0 --force en todos ellos y, después de un par de minutos, el espacio de nombres también se eliminó.

Oye,

Lo tengo una y otra vez y la mayoría de las veces es un problema con los finalizadores.

Si un espacio de nombres está atascado, intente kubectl get namespace XXX -o yaml y verifique si hay un finalizador en él. Si es así, edite el espacio de nombres y elimine el finalizador (pasando una matriz vacía) y luego el espacio de nombres se elimina

@xetys ¿ es seguro? en mi caso, solo hay un finalizador llamado "kubernetes".

Es extraño, nunca había visto un finalizador así. Solo puedo hablar basado en mi experiencia. Hice eso varias veces en un clúster de producción y todavía está vivo

Mismo problema en 1.10.5. Probé todos los consejos en este tema sin resultado. Pude deshacerme de los pods, pero el espacio de nombres todavía está colgado.

En realidad, los ns también se eliminaron después de un tiempo.

Sería bueno entender qué causa este comportamiento, el único finalizador que tenía es kubernetes. También tengo webhooks dinámicos, ¿pueden estar relacionados?

@xetys Bueno, finalmente usé tu truco en las réplicas dentro de ese espacio de nombres. Tenían algún finalizador personalizado que probablemente ya no existía, por lo que no pude eliminarlos. Cuando eliminé las referencias a ese finalizador, desaparecieron y también lo hizo el espacio de nombres. ¡Gracias! :)

El mismo problema en un clúster EKS 1.10.3:

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

Tener el mismo problema en un clúster bare metal:

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

Mi espacio de nombres se ve así:

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

En realidad, es el segundo espacio de nombres que he tenido con este problema.

Intente esto para obtener la lista real de todas las cosas en su espacio de nombres: https://github.com/kubernetes/kubectl/issues/151#issuecomment -402003022

Luego, para cada objeto, haga kubectl delete o kubectl edit para eliminar los finalizadores.

quitar el inicializador hizo el truco para mí ...

Cuando hago kubectl edit namespace annoying-namespace-to-delete y elimino los finalizadores, se vuelven a agregar cuando verifico con kubectl get -o yaml .

Además, al intentar lo que sugirió @adampl, no obtengo resultados (eliminar --ignore-not-found confirma que no se encuentran recursos en el espacio de nombres, de ningún tipo).

@ManifoldFR , tuve el mismo problema que el tuyo y logré hacerlo funcionar haciendo una llamada a la API con el archivo json.
kubectl get namespace annoying-namespace-to-delete -o json > tmp.json
luego edite tmp.json y elimine "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

y debería eliminar su espacio de nombres,

@slassh ¡ Funcionó! Debería haber pensado en hacer una llamada a la API: ¡muchas gracias! Cantaremos tus alabanzas por siempre

Existe un problema en v1.11.1. Tuve un despliegue de ranchero / timón atascado de dokuwiki. Primero tuve que forzar la eliminación de los pods como lo sugirió @siXor y luego seguí el consejo de @slassh . Todo bien ahora.

@slassh ¿cómo ver el kubernetes-cluster-ip? Utilizo una de las ip de nodos que implementó el reemplazo del clúster de kubernetes, e informa 404.

hola @jiuchongxiao , por kubernetes-cluster-ip me refiero a uno de tus nodos maestros ip.
lo siento si es confuso!

Si inicia 'kubectl proxy' primero, puede dirigir el curl a http://127.0.0.1 : 8001 / api / v1 / namespaces / annoying-namespace-to-delete / finalize. No pude hacer que la autenticación funcionara hasta que lo hice de esa manera.

buenos consejos @ 2stacks. Solo necesita reemplazar https por http .

Todavía veo este problema en 1.11.2.

Para dar más contexto para la reproducción, vi esto solo con CRD. Al eliminar el objeto CRD, me puse en un estado extraño en el que los objetos que le pertenecen no se eliminaron. No me di cuenta, así que publiqué una eliminación para el espacio de nombres. Luego eliminé todos los objetos en el espacio de nombres con kubectl delete all --all -n my-namespace . En ese momento, la eliminación del espacio de nombres se atascó. Espero que esto ayude de alguna manera.

Al mirar los registros, descubrí que este problema en particular estaba relacionado con que el administrador del controlador no estaba en buen estado. En mi caso, lo más probable es que no haya sido un error. Cuando el administrador del controlador volvió a subir, todo se limpió correctamente.

@slassh ¡Solución perfecta! ¡¡¡¡muchas gracias!!!!

También veo este problema con 1.10.x. Encuentro que el comentario de @slassh es una solución que solo oculta el problema real. ¿Por qué los espacios de nombres están bloqueados en Terminating ?

Descubrimos que la razón de la eliminación de espacios de nombres se atasca en nuestro caso (@palmerabollo)

Cuando un espacio de nombres tiene un finalizador kubernetes , significa que es un problema interno con el servidor API.

Ejecute kubectl api-resources , si devuelve un resultado similar al siguiente, significa que la API personalizada no es accesible.

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

Ejecute kubectl get apiservices v1beta1.metrics.k8s.io -o yaml , para verificar sus condiciones de estado.

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

El error anterior debería ser causado por un crashloopbackoff que afecta al servidor de métricas. Sería similar para otras API personalizadas registradas en Kubernetes.

Verifique el estado de sus servicios en kube-system para restaurar las operaciones en tiempo de ejecución del clúster, como eliminar espacios de nombres.

Estoy enfrentando este problema en v1.11.3. En los finalizadores, solo los kubernetes están presentes para espacios de nombres problemáticos.

spec:
  finalizers:
  - kubernetes

@slassh ¡Un millón de gracias, su solución funciona bien!
Tengo el mismo problema en mi clúster con ark, tiller y kubed. Sospecho que los problemas podrían ser la api de kubed que está dando un error, aunque no estoy seguro de por qué afecta la eliminación de otro espacio de nombres.

@javierprovecho Simplemente estaba jugando con el servidor de métricas y, como no funcionaba, intenté eliminar el servicio y todo eso, pero mi espacio de nombres aún no se elimina, el error es

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

¿Sabes cómo recuperarte de este estado?

editar: descubrí ... tuve que eliminar _todo_ incluso remotamente relacionado con las métricas / HPA y luego reiniciar todo el plano de control (tuve que eliminar todas mis réplicas, antes de reiniciarlas) esto incluyó eliminar el apiservice v1beta1.metrics.k8s.io sí mismo.

@ 2rs2ts

$ kubectl delete apiservice v1beta1.metrics.k8s.io

Al deshacerse del servicio API metrics funciona, el controlador-administrador podrá eliminar los espacios de nombres obsoletos.

No es necesario reiniciar el plano de control.

@antoineco no, era necesario; Eliminé el servicio y esperé bastante tiempo, pero el espacio de nombres no se eliminaría hasta que reiniciara el plano de control.

primero, tome un café pequeño y relájese, ahora vaya a los nodos maestros de su k8s

1. kubectl cluster-info
   El maestro de Kubernetes se está ejecutando en https: // localhost : 6443
   KubeDNS se ejecuta en https: // localhost : 6443 / api / v1 / namespaces / kube-system / services / kube- dns: dns / proxy

Para depurar y diagnosticar más los problemas del clúster, utilice 'kubectl cluster-info dump'.

1. ahora ejecuta el kube-proxy
   proxy de kubectl y
   Comenzando a publicarse en 127.0.0.1:8001

guarda el ID para borrarlo más tarde :)

1. encuentre su espacio de nombre que decidió no ser eliminado :) para nosotros será el sistema de ganado
   kubectl obtener ns
   sistema de ganado que termina 1d

ponerlo en archivo

1. kubectl obtiene el espacio de nombres cattle-system -o json> tmp.json

1. editar el archivo y eliminar los finalizadores
   },
   "Especificaciones": {
   "finalizadores": [
   "kubernetes"
   ]
   },
   después de editarlo debería verse así 👍
   },
   "Especificaciones": {
   "finalizadores": [
   ]
   },
   ya casi llegamos 👍

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

y se ha ido 👍

Oye, el finalizador kubernetes está ahí por una razón. Para nosotros, era un nombre de servicio de API de métricas configurado incorrectamente. Quizás para usted haya algo más, que puede descubrir mirando los registros de su plano de control. Sin la confirmación de un error, eliminar el finalizador puede producir consecuencias no deseadas, como dejar cosas creadas que ya no pueden volver a ser accesibles para fines de eliminación.

ya que este problema aún está abierto:
dentro de mi clúster de minikube que se ejecuta con "none", esto sucedió después de que el host se despertó de la hibernación.

mi suposición:
en mi caso, la hibernación desencadenó los mismos problemas, un intercambio habilitado sería suficiente.

lo que produce la suposición:
el intercambio podría estar habilitado en los clústeres afectados?

pero esto es solo una conjetura. lo importante para mí, y para cualquiera que tenga este error con mi configuración local: hibernar es malo para kubernetes .

primero, tome un café pequeño y relájese, ahora vaya a los nodos maestros de su k8s

1. kubectl cluster-info
   El maestro de Kubernetes se está ejecutando en https: // localhost : 6443
   KubeDNS se ejecuta en https: // localhost : 6443 / api / v1 / namespaces / kube-system / services / kube- dns: dns / proxy

Para depurar y diagnosticar más los problemas del clúster, utilice 'kubectl cluster-info dump'.

1. ahora ejecuta el kube-proxy
   proxy de kubectl y
   Comenzando a publicarse en 127.0.0.1:8001

guarda el ID para borrarlo más tarde :)

1. encuentre su espacio de nombre que decidió no ser eliminado :) para nosotros será el sistema de ganado
   kubectl obtener ns
   sistema de ganado que termina 1d

ponerlo en archivo

1. kubectl obtiene el espacio de nombres cattle-system -o json> tmp.json

1. editar el archivo y eliminar los finalizadores
   },
   "Especificaciones": {
   "finalizadores": [
   "kubernetes"
   ]
   },
   después de editarlo debería verse así 👍
   },
   "Especificaciones": {
   "finalizadores": [
   ]
   },
   ya casi llegamos 👍

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

y se ha ido 👍

¡¡Excelente!!
Trabajos

Me encuentro con este problema periódicamente si cambiamos nuestras instancias de gcloud (por ejemplo, actualizando nodos). Esto reemplaza el nodo antiguo de gcloud instances list con uno nuevo, pero deja los pods en el espacio de nombres k8s colgando:

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

Esto luego deja las vainas en un estado desconocido:

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

Debido a esto, el espacio de nombres nunca terminará de terminar. No estoy seguro si esto significa que debemos cambiar nuestros finalizadores o si hay un error real relacionado con la terminación que debería estar manejando pods en un estado UNKNOWN (o si debería haber una forma de forzar la terminación de un espacio de nombres para casos como este ).

Me encuentro con este problema periódicamente si cambiamos nuestras instancias de gcloud (por ejemplo, actualizando nodos). Esto reemplaza el nodo antiguo de gcloud instances list con uno nuevo, pero deja los pods en el espacio de nombres k8s colgando:

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

Esto luego deja las vainas en un estado desconocido:

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

Debido a esto, el espacio de nombres nunca terminará de terminar. No estoy seguro si esto significa que debemos cambiar nuestros finalizadores o si hay un error real relacionado con la terminación que debería estar manejando pods en un estado UNKNOWN (o si debería haber una forma de forzar la terminación de un espacio de nombres para casos como este ).

genial no es el mismo problema
debe poner los nodos en modo de mantenimiento y luego, después de que estén en modo de mantenimiento, todos los pods serán evacuados y luego podrá eliminar / actualizar

míralo, https://kubernetes.io/docs/concepts/workloads/controllers/garbage-collection/ ,
editar el recurso y eliminar metadata.finalizers, y eliminar el crd inútil, puede eliminarlo forzar

Pero, ¿qué hace exactamente el finalizador kubernetes ? ¿Existe algún riesgo de que los recursos no se limpien correctamente con este truco?

Para la torre atascada, terminar esto ayudó a https://github.com/rook/rook/blob/master/Documentation/ceph-teardown.md

curl -k -H "Tipo de contenido: aplicación / json" -X PUT --data-binary @ tmp.json https: // kubernetes-cluster-ip / api / v1 / namespaces / annoying-namespace-to-delete / finalizar

Error del servidor (NotFound): los espacios de nombres "espacio de nombres molesto para eliminar" no se encuentran

primero, tome un café pequeño y relájese, ahora vaya a los nodos maestros de su k8s

1. kubectl cluster-info
   El maestro de Kubernetes se está ejecutando en https: // localhost : 6443
   KubeDNS se ejecuta en https: // localhost : 6443 / api / v1 / namespaces / kube-system / services / kube- dns: dns / proxy

Para depurar y diagnosticar más los problemas del clúster, utilice 'kubectl cluster-info dump'.

1. ahora ejecuta el kube-proxy
   proxy de kubectl y
   Comenzando a publicarse en 127.0.0.1:8001

guarda el ID para borrarlo más tarde :)

1. encuentre su espacio de nombre que decidió no ser eliminado :) para nosotros será el sistema de ganado
   kubectl obtener ns
   sistema de ganado que termina 1d

ponerlo en archivo

1. kubectl obtiene el espacio de nombres cattle-system -o json> tmp.json

1. editar el archivo y eliminar los finalizadores
   },
   "Especificaciones": {
   "finalizadores": [
   "kubernetes"
   ]
   },
   después de editarlo debería verse así 👍
   },
   "Especificaciones": {
   "finalizadores": [
   ]
   },
   ya casi llegamos 👍

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

y se ha ido 👍

Valor no válido: "El archivo editado falló la validación": ValidationError (Namespace.spec): tipo no válido para io.k8s.api.core.v1.NamespaceSpec: obtuvo "cadena", se esperaba "mapa"

Si tiene muchos espacios de nombres bloqueados en Terminating, puede automatizar esto:

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

asegúrese de que todos los espacios de nombres que desea que se elimine el finalizador sean efectivamente Terminating .

Necesita kubectl proxy ejecución y jq para que funcione lo anterior.

En nuestro caso, el servicio de API de métricas está inactivo y puedo ver este registro de errores desde el registro detallado

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

Después de arreglar las métricas apiservice, se completan las terminaciones.
No estoy muy seguro de por qué la eliminación depende de las métricas de un servicio, también estoy interesado en saber cómo funciona si las métricas de un servicio no están instaladas en el clúster.

No estoy seguro de por qué la eliminación depende de las métricas de un servicio,

@manojbadam debido a que las métricas están registradas en el servidor de la API, cuando se realiza una eliminación de un espacio de nombres, debe consultar esa API externa para que los recursos (espacios de nombres) se eliminen (si existen) asociados con ese espacio de nombres. Si el servidor de extensión no está disponible, Kubernetes no puede garantizar que se hayan eliminado todos los objetos y no tiene un mecanismo persistente (en la memoria o en el disco) para conciliar más tarde porque el objeto raíz se habría eliminado. Eso sucede con cualquier servicio de extensión de API registrado.

Como constantemente me encontraba con esto, lo automaticé con un pequeño script de shell:

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

Obtiene el proyecto, corrige el JSON, inicia y detiene correctamente "kubectl proxy", ...

¡Gracias a todos por señalarme en la dirección correcta!

Como constantemente me encontraba con esto, lo automaticé con un pequeño script de shell:

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

Obtiene el proyecto, corrige el JSON, inicia y detiene correctamente "kubectl proxy", ...

¡Gracias a todos por señalarme en la dirección correcta!

¡mi héroe! <3

También me encontré con este problema. Estoy en Google Kubernetes Engine y uso Terraform para activar los clústeres de Kubernetes y crear espacios de nombres y pods dentro del clúster. El problema comenzó un tiempo después de ejecutar un terraform destroy .

En mi caso, esto resulta ser un problema con el orden en el que Terraform ejecuta la destrucción. Terraform elimina primero el grupo de nodos y luego elimina los espacios de nombres y los pods. Pero debido a la eliminación del (único) grupo de nodos, el clúster de Kubernetes se rompió, y eso fue lo que provocó que la eliminación del espacio de nombres se atascara en la "terminación" para siempre.

@FooBarWidget mismo problema para mí :(

Como constantemente me encontraba con esto, lo automaticé con un pequeño script de shell:

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

Obtiene el proyecto, corrige el JSON, inicia y detiene correctamente "kubectl proxy", ...

¡Gracias a todos por señalarme en la dirección correcta!

[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

Obtuve un código de retorno 403, ¿qué debo hacer ?:(

Como constantemente me encontraba con esto, lo automaticé con un pequeño script de shell:
https://github.com/ctron/kill-kube-ns/blob/master/kill-kube-ns
Obtiene el proyecto, corrige el JSON, inicia y detiene correctamente "kubectl proxy", ...
¡Gracias a todos por señalarme en la dirección correcta!

[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

Obtuve un código de retorno 403, ¿qué debo hacer ?:(

Gracias Dios, el espacio de nombres de terminación finalmente se ha ido. El siguiente método me engaña.

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

Tengo el mismo problema, pero no veo ningún servicio de métricas.

Estoy jugando con k8s de digitalocean y gitlab auto devops. Mi suposición es algo de almacenamiento de blobs digitalocean, pero no sé cómo analizarlo o solucionarlo.

@mingxingshi tx. Hice una edición del espacio de nombres que no funcionó. Tu guión lo hizo.

Vaya, finalmente me deshice de él. ¡Gracias por los comandos @mingxingshi !

La solución para mí fue:

kubectl delete apiservice v1beta1.metrics.k8s.io

pensé que debería dejar mi experiencia de esto aquí:

estaba haciendo terraform apply con el siguiente recurso:

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

pero soy un novato en el timón y tenía una plantilla que tenía una plantilla que creaba un espacio de nombres llamado servicer . Esto causó que terraform y k8s entraran en este mal estado donde terraform fallaría, entonces k8s dejaría el espacio servicer nombres Terminating . Hacer lo que @mingxingshi sugiere arriba hizo que el espacio de nombres terminara, ya que no tenía recursos adjuntos.

este problema dejó de sucederme cuando eliminé esa plantilla que creaba el espacio de nombres y dejé que se encargara de crearlo.

El problema es completamente repetible para mí. Primero, clona el operador prometheus . Luego:

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

Cuelga. Sin embargo, si utilizo kubectl delete -f manifests/ , la limpieza se realiza correctamente.

Sí, tenía el mismo truco con Prometheus-operator. Necesita kubectl delete -f manifests/ para despegar.
Creo que hay algunos finalizadores en los CRD de prometheus que se están portando mal, en este escenario particular, no es culpa de Kubernetes. Sin embargo, kubernetes debería facilitar la búsqueda del culpable, porque la longitud de este hilo demuestra que podría haber muchas causas y no es fácil llegar al fondo en cada escenario en particular.

Soy un novato de Kubernetes, así que no puedo ofrecer mucha información aquí, pero también tengo 2 espacios de nombres bloqueados en estado de terminación. Mi configuración de kubernetes utiliza 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

Tengo dos espacios de nombres atascados en el estado de terminación

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

Cuando verifico los finalizadores como se describe en este comentario , solo veo 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

Independientemente, intenté eliminar kubernetes de los finalizadores y no funcionó. También intenté usar el enfoque json / api descrito en este comentario . Tampoco funcionó. Intenté reiniciar todos los nodos y tampoco funcionó.

También intenté hacer la eliminación forzada y eso tampoco funciona

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.

En mi caso, el espacio de nombres es rook-ceph, kubectl -n rook-ceph patch cephclusters.ceph.rook.io rook-ceph -p '{"metadata":{"finalizers": []}}' --type=merge funciona para mí. Para otros casos, también debería funcionar.

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

@ManifoldFR , tuve el mismo problema que el tuyo y logré hacerlo funcionar haciendo una llamada a la API con el archivo json.
kubectl get namespace annoying-namespace-to-delete -o json > tmp.json
luego edite tmp.json y elimine "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

y debería eliminar su espacio de nombres,

Tengo algún problema al utilizar su enfoque, ¿qué debo hacer para solucionar el problema del siguiente paso?

~ 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 , tuve el mismo problema que el tuyo y logré hacerlo funcionar haciendo una llamada a la API con el archivo json.
kubectl get namespace annoying-namespace-to-delete -o json > tmp.json
luego edite tmp.json y elimine "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
y debería eliminar su espacio de nombres,

Tengo algún problema al utilizar su enfoque, ¿qué debo hacer para solucionar el problema del siguiente paso?

~ 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

Mi problema puede resolverse con este script: https://github.com/ctron/kill-kube-ns/blob/master/kill-kube-ns .

sí https://github.com/ctron/kill-kube-ns/blob/master/kill-kube-ns hace el truco

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"

Parece que los espacios de nombres en realidad no se eliminan.
En mi caso, kubectl get ns no muestra el espacio de nombres eliminado, pero un kubectl get all -n <namespace> muestra todos los recursos sanos y salvos.
Revisé los nodos y los contenedores de la ventana acoplable todavía se estaban ejecutando ...

@glouis, eso se omitió los finalizadores con el método anterior, por lo que Kubernetes no tuvo tiempo para ejecutar todas esas tareas esenciales de eliminación.

Es realmente triste ver a tanta gente abogando ciegamente por este método sin entender sus consecuencias. Es extremadamente feo y potencialmente puede dejar toneladas de sobras en el grupo. @javierprovecho ya lo mencionó anteriormente, y @liggitt también lo mencionó en otro número de GitHub.

Será mejor que arregle el servicio de API v1beta1.metrics.k8s.io roto o lo elimine si no lo necesita.

Véase también # 73405

Segundo mensaje de @antoineco . Probé esto en uno de nuestros entornos sandbox porque constantemente nos quedamos atascados en espacios de nombres. después de aproximadamente un mes, todos los demonios de Docker se congelaron sin ningún motivo. Resulta que creamos enormes pérdidas de memoria al dejar recursos atrás.

Después de muchas pruebas y errores, y de leer estos comentarios, resultó ser una definición de recurso personalizada para la pila de coreos grafana para los espacios de nombres. Enumerar los CRD mostró recursos específicos para ese espacio de nombres. Tuve mucha suerte de que el nombre del CRD tuviera el espacio de nombres que estaba atascado.

También resultó que tener un espacio de nombres atascado evita que se eliminen más espacios de nombres. Entonces, incluso si tiene un espacio de nombres A que no tiene CRD y hay un espacio de nombres B con un CRD atascado, todos los recursos en A se mantendrán hasta que B desaparezca. Creo que debo haber hecho la corrección descrita anteriormente en el espacio de nombres A dejando un montón de recursos cada vez.

Lo que todavía me está matando es que no puedo por mi vida encontrar ningún registro que mencione una limpieza de espacio de nombres que falla al eliminar un CRD, o incluso lo que está haciendo actualmente. Tuve que pasar una hora averiguando en qué CRD estaba atascado. Si alguien tiene una idea sobre cómo obtener más información para que no tenga que gastar una gran cantidad de tiempo averiguando el recurso atascado, sería increíble.

@jecafarelli buena pista para los clústeres de producción. Pero desafortunadamente para mí, simplemente no pude matarlo de otra manera. También sabía que volvería a crear todo el clúster más adelante.

Intenté analizar el problema, pero nada en este hilo me ayudó a resolverlo por otros medios.

Esta solución oficial me ayudó: https://success.docker.com/article/kubernetes-namespace-stuck-in-terminating
Esto no es kubectl edit namespace rook-ceph . No pude resolver este problema hasta que PUT solicitud con _ "finalizadores" eliminados _

ok, me encontré con esto de nuevo con Coreos, y profundicé un poco más. esto definitivamente se debe a una definición de recurso de todo el clúster que tiene un espacio de nombres, y además, tal vez no pueda eliminarlo porque no puede consultar información sobre coreos. Encontré errores en los registros de apiserver que mostraban errores al intentar obtener información sobre un grupo de api. Utilicé el problema mencionado anteriormente para crear un script rápido que enumere los recursos que me atascaron los ns.

Probablemente solo use esto en el futuro si me encuentro con él nuevamente y sigo agregando cualquier otro recurso de espacio de nombres con el que me encuentre.

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

Muchas gracias @jecafarelli , me ayudaste a resolver mi problema de la manera correcta ;-)

Había instalado cert-manager en un clúster de OpenShift dentro del espacio de nombres de cert-manager y cuando intenté eliminar este espacio de nombres, se atascó en el estado de terminación. La ejecución de oc delete apiservices v1beta1.admission.certmanager.k8s.io parece haber resuelto el problema, el espacio de nombres se ha ido.

Muchas gracias @jecafarelli , me ayudaste a resolver mi problema de la manera correcta ;-)

Había instalado cert-manager en un clúster de OpenShift dentro del espacio de nombres de cert-manager y cuando intenté eliminar este espacio de nombres, se atascó en el estado de terminación. La ejecución de oc delete apiservices v1beta1.admission.certmanager.k8s.io parece haber resuelto el problema, el espacio de nombres se ha ido.

Lo mismo aquí, ejecutar kubectl delete -f https://raw.githubusercontent.com/jetstack/cert-manager/release-0.8/deploy/manifests/00-crds.yaml ayudó

Solo repito para decir que también encontré este error en la versión 1.13.6 con GKE. Ocurrió después de que inhabilité el complemento Istio de GKE con el objetivo de instalarlo manualmente para tener un control total.
Este es el hilo de problemas más largo que me he tomado el tiempo de leer, y estoy asombrado de que no haya un consenso real o pasos de reproducción para la raíz de este problema. Parece que se puede disparar de muchas maneras diferentes :(

El método JSON y curl / proxy mencionado varias veces anteriormente y documentado en https://success.docker.com/article/kubernetes-namespace-stuck-in-terminating es lo que me salvó.

El consejo en https://success.docker.com/article/kubernetes-namespace-stuck-in-terminating es activamente dañino y puede provocar que los recursos huérfanos no se limpien y resurjan si un espacio de nombres con un nombre idéntico se vuelve a crear más tarde. .

Hay trabajo en progreso para descubrir la causa específica de la eliminación bloqueada, pero el problema fundamental es que hay tipos de API que no se pueden verificar que se hayan limpiado, por lo que la eliminación del espacio de nombres se bloquea hasta que se verifican.

También logramos esto con Knative, que instala este servicio de espacio de nombres.

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

Después de eliminarlo, se limpiaron tanto los ns que sirven knative como un montón de otros espacios de nombres atascados. Gracias a @jecafarelli por el script bash anterior.
Aquí hay una terrible versión de PowerShell.

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

Hoy tuve el mismo problema y este script me funcionó.

@ kubernetes / sig-api-machinery-misc

Este error ha existido durante un año y sigue siendo un problema ... ¿Cuál es su plan para abordar problemas de entrada como este?

Esto podría ayudar al menos a comprender qué está pasando: https://github.com/kubernetes/kubernetes/pull/80962

Estoy teniendo el mismo problema

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

El controlador del espacio de nombres debe informar las condiciones al estado del espacio de nombres y los clientes deben informar eso. Necesita un KEP, pero debería ser bastante sencillo si alguien puede tomarlo y validarlo.

@timothysc hay (o había) un PR en vuelo (en algún lugar) haciendo exactamente lo que dice @smarterclayton .

Estoy bastante seguro de que también hay otro problema de github sobre esto.

Sí, el PR está aquí: https://github.com/kubernetes/kubernetes/pull/73405

El problema que considero canónico está aquí: https://github.com/kubernetes/kubernetes/issues/70916

Aquí hay un recurso que me ayudó: https://www.ibm.com/support/knowledgecenter/en/SSBS6K_3.1.1/troubleshoot/ns_terminating.html

Es similar a la solución propuesta por @slassh , pero usa kubectl proxy para crear un proxy local y hacer que la IP de destino del comando curl predecible.

-

Editar: como se indica varias veces debajo de esta respuesta, esta solución es un truco sucio y posiblemente dejará algunos recursos dependientes en el clúster. Úselo bajo su propio riesgo y posiblemente solo úselo como una salida rápida en un clúster de desarrollo (no lo use en un clúster de producción).

eliminar el finalizador directamente como se describe en el documento anterior puede tener consecuencias. Los recursos que estaban pendientes de eliminación seguirán estando definidos en el clúster incluso después de que se haya liberado el espacio de nombres. Este es el propósito del finalizador. Para garantizar que se eliminen todos los dependientes antes de permitir la eliminación de ns.

Solución alternativa encontrada en preguntas similares:

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

Solución alternativa encontrada en preguntas similares:

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

¡Gracias!
Funciona bien.
Creo una aplicación simple con esta solución alternativa: https://github.com/jenoOvchi/k8sdelns
Lo uso para una eliminación rápida y espero que sea útil para alguien.

Los espacios de nombres de Kubernetes 1.12.2 están en estado de terminación. A veces, los finalizadores se pueden eliminar modificando el yaml de ns. No puede ser eliminado por api. ¿Se puede eliminar? ¿Cual es la situación? ¿Lo hemos rastreado específicamente (requisito previo: no hay recursos en este ns), espero poder obtener sugerencias, gracias!

Nuevamente, no elimine el finalizador, está ahí por una razón. En su lugar, intente averiguar qué recursos en el NS están pendientes de eliminación mediante:

• Verificando si algún servicio no está disponible y por lo tanto no sirve a sus recursos: kubectl get apiservice|grep False
• Encontrar todos los recursos que todavía existen a través de kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get -n $your-ns-to-delete (Felicitaciones a Jordan por ese)

La solución a este problema no es cortocircuitar el mecanismo de limpieza, sino descubrir qué impide que la limpieza se realice correctamente.

Nuevamente, no elimine el finalizador, está ahí por una razón. En su lugar, intente averiguar qué recursos en el NS están pendientes de eliminación mediante:

• Verificando si algún servicio no está disponible y por lo tanto no sirve a sus recursos: kubectl get apiservice|grep False
• Encontrar todos los recursos que todavía existen a través de kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get -n $your-ns-to-delete (Felicitaciones a Jordan por ese)

La solución a este problema no es cortocircuitar el mecanismo de limpieza, sino descubrir qué impide que la limpieza se realice correctamente.

¡Qué razón tienes!
En mi caso, el pod de Operator Framework apiservice se eliminó y bloqueó el proceso de terminación.
Eliminando un apiservice no utilizado (kubectl delete apiservice) resuelve el problema.

Hola a todos, la congelación de código llegará en unos pocos días (jueves, final del día, hora del Pacífico), por lo que debemos asegurarnos de que este problema se resuelva para la v1.16 o se traslade a la v1.17. ¿Puedes comentar sobre su estado?

¿Se incluirá en una versión actual de GKE? Tengo un clúster que tiene un puñado de espacios de nombres que todavía están "terminando".

@squarelover incluso después de hacer esto? https://github.com/kubernetes/kubernetes/issues/60807#issuecomment -524772920

@josiahbjorgaard Acabo de aprobar el RP, que es todo lo que haremos en esto para la 1.16.

https://github.com/kubernetes/kubernetes/pull/73405 es el PR antes mencionado

Está fusionado. Creo que podemos hacer más, pero envíen sus comentarios futuros al número 70916.

Nuevamente, no elimine el finalizador, está ahí por una razón. En su lugar, intente averiguar qué recursos en el NS están pendientes de eliminación mediante:

• Verificando si algún servicio no está disponible y por lo tanto no sirve a sus recursos: kubectl get apiservice|grep False
• Encontrar todos los recursos que todavía existen a través de kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get -n $your-ns-to-delete (Felicitaciones a Jordan por ese)

La solución a este problema no es cortocircuitar el mecanismo de limpieza, sino descubrir qué impide que la limpieza se realice correctamente.

En muchos de los casos, es posible que tenga instalado Metric-Server. Cuando los pods que implementa en espacios de nombres específicos buscan recopilación de métricas. Se cuelga del Metric-server. Entonces, incluso después de eliminar todos los recursos en ese espacio de nombres, metric-server está vinculado de alguna manera a ese espacio de nombres. Lo que evitará que elimines el espacio de nombres.
Esta publicación le ayuda a identificar la razón por la que no puede eliminar el espacio de nombres. Así que la forma del rito.

Intente esto para obtener la lista real de todas las cosas en su espacio de nombres: kubernetes / kubectl # 151 (comentario)

Luego, para cada objeto, haga kubectl delete o kubectl edit para eliminar los finalizadores.

Esta solución es útil para mí, gracias.

Hola chicos,

Hice un script para facilitar la eliminación de espacios de nombres en el estado de terminación: https://github.com/thyarles/knsk.

Gracias.

Nos encontramos con el mismo problema, al eliminar un espacio de nombres, se atasca en el estado 'Terminando'. Seguí los pasos anteriores para eliminar 'kubernetes' en el finalizador en el archivo yaml. Funciona.

Sin embargo, no sabemos por qué debemos realizar pasos adicionales. Debería hacer kubectl delete ns foonamespace y debería eliminar. ¿Alguien puede darme una razón? ¡Gracias!

Hola @ xzhang007 ,

Si descubre por qué la eliminación del espacio de nombres se atasca en el estado Terminating, hágamelo saber. Intenté por un tiempo una buena respuesta, pero nada. Luego hice un guión para hacerme la vida más fácil hasta descubrir y arreglar la causa.

Gracias.

@thyales parece que no encontré una respuesta hasta ahora.

En nuestro caso, descubrimos que uno de los webhhoks y finalizadores que éramos
usar fue llegar a una vaina que vivía en los espacios de nombres que se
eliminado.
Una vez que se eliminó el pod, la terminación se bloqueó.

>

@ xzhang007, ¿ ha mirado la respuesta que proporcionó @alvaroaleman ? Para nosotros eso fue suficiente para averiguar cuál era la causa.

Nuevamente, no elimine el finalizador, está ahí por una razón. En su lugar, intente averiguar qué recursos en el NS están pendientes de eliminación mediante:

• Verificando si algún servicio no está disponible y por lo tanto no sirve a sus recursos: kubectl get apiservice|grep False
• Encontrar todos los recursos que todavía existen a través de kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get -n $your-ns-to-delete (Felicitaciones a Jordan por ese)

La solución a este problema no es cortocircuitar el mecanismo de limpieza, sino descubrir qué impide que la limpieza se realice correctamente.

Además, cuando se cerró este problema, se hizo referencia a un nuevo ticket para discutir cómo dejar en claro por qué el espacio de nombres está bloqueado en Terminating. Le sugiero que lleve la conversación allí en lugar de este tema cerrado.

Está fusionado. Creo que podemos hacer más, pero envíen sus comentarios futuros al número 70916.

@ jeff-knurek Ese debería ser el camino correcto. Gracias.

En nuestro caso, fue una actualización fallida de cert-manager que rompió el finalizador. 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

Hola.
Mi espacio de nombres de caso se atasca en Terminar cuando https://github.com/rancher/rancher/issues/21546#issuecomment -553635629

Quizás te ayude.

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

Esto funcionó como un campeón para mí

También enfrenté el mismo problema ahora, funciona bien para mí. Consulte el siguiente documento y resuelva su problema.

@zerkms bueno, a veces, es un consejo legítimo, ¿no? A menudo, los finalizadores que se estaban esperando solían ser servidos por objetos que se eliminaron como parte de la eliminación del espacio de nombres. En este caso, dado que no tiene sentido esperar más - ya no hay nada que pueda hacer la finalización -, parchear los objetos como se describe en el artículo _es la única opción_.

Tenga en cuenta que el artículo es aplicable solo si el problema _no se resolvió_ mediante los pasos de aplicación enumerados en la página Problemas conocidos, vinculada en la parte superior del artículo, que básicamente es el consejo que se repite en el comentario que vinculó.

@zerkms bueno, a veces, es un consejo legítimo, ¿no? A menudo, los finalizadores que se estaban esperando solían ser atendidos por objetos que se eliminaron como parte de la eliminación del espacio de nombres

Nunca he visto que eso sea cierto para un spec.finalizer en un espacio de nombres. Cada instancia que he visto ha involucrado el controlador de limpieza del espacio de nombres, y ha sido causada por un objeto persistente en el espacio de nombres (que ese consejo se desviaría en etcd), o una API agregada que no responde (que al eliminar la especificación del espacio de nombres, el finalizador saltaría esperando, también varando los recursos persistentes de esa API)

El artículo no advierte que omitir la finalización del espacio de nombres corre el riesgo de dejar los recursos con espacios de nombres varados en el almacenamiento y no se recomienda.

Nunca he visto que eso sea cierto para un finalizador de especificaciones en un espacio de nombres

Sí, es cierto, esto se debe a que este finalizador lo implementa el propio kubernetes, pero podría haber otros finalizadores en objetos dentro de ese espacio de nombres, que podrían ser implementados por objetos en dicho espacio de nombres. Un ejemplo que encontré recientemente fue https://appscode.com/products/stash/ .

Pone finalizadores en algunos de sus CRD que serán atendidos por el despliegue del operador de alijo. Pero con el operador de alijo ya eliminado, no hay nada que pueda eliminar la marca de finalizador de esos CRD y la eliminación del espacio de nombres se atasca. En este caso, parchear esos finalizadores (no en el espacio de nombres en sí, sino en esos objetos) es lo único sensato que se puede hacer.

Espero que tenga sentido.

En este caso, parchear esos finalizadores (no en el espacio de nombres en sí, sino en esos objetos) es lo único sensato que se puede hacer.

Correcto. No me opondría a eso en un escenario de limpieza de "eliminar todos los recursos", pero eso no es lo que explica el artículo vinculado ... describe cómo eliminar un spec.finalizer del espacio de nombres.

primero, tome un café pequeño y relájese, ahora vaya a los nodos maestros de su k8s

kubectl cluster-info
El maestro de Kubernetes se está ejecutando en https: // localhost : 6443
KubeDNS se ejecuta en https: // localhost : 6443 / api / v1 / namespaces / kube-system / services / kube- dns: dns / proxy
Para depurar y diagnosticar más los problemas del clúster, utilice 'kubectl cluster-info dump'.

ahora ejecuta el kube-proxy
proxy de kubectl y
Comenzando a publicarse en 127.0.0.1:8001
guarda el ID para borrarlo más tarde :)

1. encuentre su espacio de nombre que decidió no ser eliminado :) para nosotros será el sistema de ganado
   kubectl obtener ns
   sistema de ganado que termina 1d

ponerlo en archivo

1. kubectl obtiene el espacio de nombres cattle-system -o json> tmp.json

editar el archivo y eliminar los finalizadores
},
"Especificaciones": {
"finalizadores": [
"kubernetes"
]
},
después de editarlo debería verse así 👍
},
"Especificaciones": {
"finalizadores": [
]
},
ya casi llegamos 👍
curl -k -H "Content-Type: application / json" -X PUT --data-binary @ tmp.json http://127.0.0.1 : 8001 / api / v1 / namespaces / $ {NAMESPACE} / finalize

y se ha ido 👍

Nuevamente, no elimine el finalizador, está ahí por una razón. En su lugar, intente averiguar qué recursos en el NS están pendientes de eliminación mediante:

• Verificando si algún servicio no está disponible y por lo tanto no sirve a sus recursos: kubectl get apiservice|grep False
• Encontrar todos los recursos que todavía existen a través de kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get -n $your-ns-to-delete (Felicitaciones a Jordan por ese)

La solución a este problema no es cortocircuitar el mecanismo de limpieza, sino descubrir qué impide que la limpieza se realice correctamente.

¡Hola chicos! Sigo los consejos proporcionados por @alvaroaleman e hice un script que inspecciona y prueba la eliminación limpia antes de realizar una eliminación completa del espacio de nombres atascado .

Lo que hace el script https://github.com/thyarles/knsk :

1. Compruebe si hay fuentes de acceso no disponibles y solicite eliminarlas
2. Verifique los recursos pendientes en el espacio de nombres y solicite eliminarlos
3. Espere unos 5 minutos para ver si Kubernetes realiza una eliminación limpia si la secuencia de comandos realiza alguna eliminación
4. Forzar la eliminación del espacio de nombres atascado

Espero eso ayude.

@thyarles Muchas gracias. Usé tu forma de resolver el problema.

$ kubectl get apiservices para verificar qué servicio no está disponible, eliminar los disponibles es falso por $ kubectl delete apiservice [service-name], y después de eso no habría problemas para eliminar un espacio de nombre.

Para nuestro equipo, hay 3 apiservices no disponibles, v1beta1.admission.certmanager.k8s.io, v1beta1.metrics.k8s.io y v1beta1.webhook.certmanager.k8s.io.

Tenga en cuenta que su clúster está algo roto si la métrica apiserver no se está ejecutando, simplemente eliminar el APIService no soluciona la causa raíz.

@lavalamp la métrica es un servicio no disponible.

Sí, lo que significa que la métrica apiserver no se está ejecutando, lo que significa que HPA no funciona en su clúster y probablemente también en otras cosas.

Si. HPA no funciona ahora. No debería eliminar métricas y encontrar una forma de solucionarlo.

@thyarles Muchas gracias. Usé tu forma de resolver el problema.

$ kubectl get apiservices para verificar qué servicio no está disponible, eliminar los disponibles es falso por $ kubectl delete apiservice [service-name], y después de eso no habría problemas para eliminar un espacio de nombre.

Para nuestro equipo, hay 3 apiservices no disponibles, v1beta1.admission.certmanager.k8s.io, v1beta1.metrics.k8s.io y v1beta1.webhook.certmanager.k8s.io.

@ xzhang007 me alegro de escuchar! Ahora debe verificar por qué su v1beta1.metrics.k8s.io se rompió. Compruebe cómo le gustaría:

''
$ kubectl -n kube-system obtener todo | métricas grep

pod / metrics-server-64f74f8d47-r5vcq 2/2 Ejecutando 9 119d
servicio / metrics-server ClusterIP xx.xx.xx.xx443 / TCP 201d
deployment.apps / metrics-server 1/1 1 1 201d
replicaset.apps / metrics-server-55c7f68d94 0 0 0 165d
replicaset.apps / metrics-server-5c696bb6d7 0 0 0 201d
replicaset.apps / metrics-server-5cdb8bb4fb 0 0 0 201d
replicaset.apps / metrics-server-64f74f8d47 1 1 1 119d
replicaset.apps / metrics-server-686789bb4b 0 0 0 145d```

$ kubectl -n kube-system obtener todo | métricas grep

pod / metrics-server-5dcfd4dd9f-m2v9k 1/1 En ejecución 0 2d20h

servicio / metrics-server ClusterIP xx.xx.xx.xx443 / TCP 27d

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

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

Si. HPA no funciona ahora. No debería eliminar métricas y encontrar una forma de solucionarlo.

@ xzhang007, de hecho, no funciona antes de que notara el problema ... lo acaba de notar porque puso sus espacios de nombres eliminados en modo atascado. Simplemente use un administrador de paquetes de helm para volver a implementar su servidor de métricas o simplemente llame al comando a continuación para solucionarlo ( verifique el archivo de implementación antes de aplicar ):

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

La solución

Eliminar v1beta1.metrics.k8s.io APIService

kubectl get ns ns-to-delete -o yaml

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

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

 kubectl delete v1beta1.metrics.k8s.io APIService

El administrador de certificados no estaba disponible tal vez porque se configuró incorrectamente. Por ejemplo, use una sintaxis incorrecta en el controlador de entrada. Para nuestro sistema, fue

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

y fue cambiado a

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

que esté disponible.

Como se mencionó anteriormente en este número, hay otra forma de terminar un espacio de nombres usando una API no expuesta por kubectl usando una versión moderna de kubectl donde kubectl replace --raw está disponible (no estoy seguro de qué versión). De esta manera, no tendrá que generar un proceso kubectl proxy y evitar la dependencia con curl (que en algunos entornos como busybox no está disponible). Con la esperanza de que esto ayude a alguien más, dejé esto aquí:

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

¿Se ha establecido si se trata de un problema solucionable? Parece que hay muchas soluciones pirateadas aquí, pero nada que aborde el problema subyacente, que es que ninguno de nosotros puede eliminar nuestros espacios de nombres ...
Tengo esto en el clúster EKS v1.14

¿Se ha establecido si se trata de un problema solucionable? Parece que hay muchas soluciones piratas aquí, pero nada que aborde el problema subyacente, que es que ninguno de nosotros puede eliminar nuestros espacios de nombres.

El problema fundamental es que un grupo de API agregado en su clúster no está disponible. Es intencional que el controlador de limpieza del espacio de nombres se bloquee hasta que todas las API estén disponibles, de modo que pueda verificar que todos los recursos de todos los grupos de API se hayan limpiado para ese espacio de nombres.

para personas que intentan curvar la API:

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

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

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

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

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

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

Aquí hay una secuencia de comandos para hacer esto automáticamente. Necesita 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

Todos: los scripts para automatizar la eliminación del finalizador hacen más daño que bien . Pueden dejar bombas de tiempo en los apiserver agregados que no están disponibles; si alguien recrea el espacio de nombres, de repente puede volver a aparecer un montón de objetos antiguos.

La verdadera solución es:

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

Todos: los scripts para automatizar la eliminación del finalizador hacen más daño que bien . Pueden dejar bombas de tiempo en los apiserver agregados que no están disponibles; si alguien recrea el espacio de nombres, de repente puede volver a aparecer un montón de objetos antiguos.

La verdadera solución es:

$ 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

Este script realiza todas las comprobaciones e intenta realizar una eliminación limpia, incluida la búsqueda de recursos huérfanos. Si el usuario quiere correr un riesgo, el script ofrece una opción --force para realizar una forma de eliminación no recomendada.

error tipográfico, deberían ser apiservices

Este comando muestra apis no disponibles:

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

Este artículo seguramente te será útil:

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

En realidad lo que existe es un conflicto en los apiservices, podrían validar el estado de salud de las apis en openshift:

oc get apiservices -o = columnas-personalizadas = " nombre: .metadata.name , estado: .status.conditions [0] .status"

la api que falla deberá reiniciarla, reiniciando el pod o la implementación que pertenece a esa API, luego intente eliminar el espacio de nombres.

$ oc eliminar namspace

y listo, negocio arreglado !!

Bastante irrespetuoso usar tu propio idioma en un lugar donde todos aceptan hablar inglés. 👎

¿Dónde aceptan todos hablar inglés?

El jueves 30 de abril de 2020 a las 17:58, theAkito [email protected] escribió:

Bastante irrespetuoso usar tu propio idioma en un lugar donde todos
acepta hablar inglés. 👎

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/kubernetes/kubernetes/issues/60807#issuecomment-622137770 ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/ALGMKB6K4OU4X3XOYMALOBLRPHYCDANCNFSM4ETUOEPA
.

>

Chris, arquitecto principal @ brace.ai

-

Aviso de confidencialidad: este correo electrónico está destinado al uso exclusivo del
destinatario (s) previsto (s) y puede contener información confidencial, propietaria o
información privilegiada. Si no es el destinatario previsto, es
notificó que cualquier uso, revisión, difusión, copia o acción tomada en base
en este mensaje o sus archivos adjuntos, si los hubiera, está prohibido. Si no eres
el destinatario previsto, comuníquese con el remitente por correo electrónico de respuesta y
destruir o eliminar todas las copias del mensaje original y cualquier archivo adjunto.

listo, disculpe fue por mi velocidad, fue arreglado

Tenemos una base de usuarios multilingüe, ya es bastante malo que ninguna de nuestras herramientas esté internacionalizada, al menos podemos ser amables aquí en github, por favor.

@teoincontatto

Como se mencionó anteriormente en este número, hay otra forma de terminar un espacio de nombres usando una API no expuesta por kubectl usando una versión moderna de kubectl donde kubectl replace --raw está disponible (no estoy seguro de qué versión). De esta manera, no tendrá que generar un proceso kubectl proxy y evitar la dependencia con curl (que en algunos entornos como busybox no está disponible). Con la esperanza de que esto ayude a alguien más, dejé esto aquí:

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

¡Esto funcionó perfectamente!

Tenemos una base de usuarios multilingüe, ya es bastante malo que ninguna de nuestras herramientas esté internacionalizada, al menos podemos ser amables aquí en github, por favor.

Tenemos una base de usuarios multilingüe, ya es bastante malo que ninguna de nuestras herramientas esté internacionalizada, al menos podemos ser amables aquí en github, por favor.

Todavía estoy tratando de entender. Perdóname. Es posible que haya hecho clic con el pulgar hacia abajo por error.
Sí, de hecho, las herramientas no se han hecho a la perfección.
Esos, dar un pulgar hacia abajo sin una explicación, no tiene sentido.

Casi todo el tiempo que experimento este problema, depende de los CRD. Elimine los CRD si se usan solo en ese espacio de nombres y luego puede proceder a eliminar el finalizador y el espacio de nombres.

Como se mencionó anteriormente en este número, hay otra forma de terminar un espacio de nombres usando una API no expuesta por kubectl usando una versión moderna de kubectl donde kubectl replace --raw está disponible (no estoy seguro de qué versión). De esta manera, no tendrá que generar un proceso kubectl proxy y evitar la dependencia con curl (que en algunos entornos como busybox no está disponible). Con la esperanza de que esto ayude a alguien más, dejé esto aquí:

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 ¡ Gracias! ¡Esto finalmente funcionó!

A veces, solo editar el manifiesto de recursos en línea no funcionaría muy bien (me refiero a eliminar el finalizers archivado y guardar).
Entonces, obtuve una nueva forma de otros.

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

Después de ejecutar ese comando, el espacio de nombres ahora debería estar ausente de su lista de espacios de nombres ... Y funciona para mí.

No solo namespace sino que también es compatible con los otros recursos.

solucioné el problema eliminando las líneas de los finalizadores usando: kubectl edit annoying-ns

Hmm ... tengo este problema ahora mismo :)
Hoy hice una actualización de mi clúster eks de 1.15 a 1.16.
Todo parece estar bien hasta ahora.
Pero mi desarrollo ns "configcluster" fue una especie de "dañado".
Así que decido limpiarlo.

k eliminar ns configcluster
....
ahora esto cuelga (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

¿Cómo podemos exponernos más a este problema de la espina en el pie?

El viernes 19 de junio de 2020 a las 4:46 a.m. Andreas Höhmann [email protected]
escribió:

Hmm ... tengo este problema ahora mismo :)
Hoy hice una actualización de mi clúster eks de 1.15 a 1.16.
Todo parece estar bien hasta ahora.
Pero mi desarrollo ns "configcluster" fue una especie de "dañado".
Así que decido limpiarlo.

k eliminar ns configcluster
....
ahora esto cuelga (3h +): /

$ kubectl obtener configcluster de espacio de nombres -o yaml
apiVersion: v1
kind: espacio de nombres
metadatos:
anotaciones:
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion": "v1", "kind": "Espacio de nombres", "metadatos": {"annotations": {}, "name": "configcluster"}}
creationTimestamp: "2020-06-19T06: 40: 15Z"
deletionTimestamp: "2020-06-19T09: 19: 16Z"
nombre: configcluster
resourceVersion: "22598109"
selfLink: / api / v1 / namespaces / configcluster
uid: e50f0b53-b21e-4e6e-8946-c0a0803f031b
Especificaciones:
finalizadores:

• kubernetes
  estado:
  condiciones:
• lastTransitionTime: "2020-06-19T09: 19: 21Z"
  mensaje: 'El descubrimiento falló para algunos grupos, 1 falló: no se pudo recuperar el
  lista completa de API de servidor: metrics.k8s.io/v1beta1: el servidor está actualmente
  incapaz de manejar la solicitud '
  motivo: DiscoveryFailed
  estado: "Verdadero"
  tipo: NamespaceDeletionDiscoveryFailure
• lastTransitionTime: "2020-06-19T09: 19: 22Z"
  mensaje: todos los tipos de kube heredados se analizaron correctamente
  motivo: ParsedGroupVersions
  estado: "Falso"
  tipo: NamespaceDeletionGroupVersionParsingFailure
• lastTransitionTime: "2020-06-19T09: 19: 22Z"
  mensaje: Todo el contenido eliminado correctamente
  motivo: ContentDeleted
  estado: "Falso"
  tipo: NamespaceDeletionContentFailure
  fase: terminando

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/kubernetes/kubernetes/issues/60807#issuecomment-646543073 ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/AFLKRCLHIZ77X2Z3F5GAOCTRXMXVTANCNFSM4ETUOEPA
.

@bobhenkel bueno, este problema está cerrado, por lo que efectivamente esto significa que no hay ningún problema (en lo que respecta a los elementos procesables). Si necesita ayuda práctica para lidiar con una situación similar, lea el hilo de arriba, hay algunos buenos consejos allí (y también algunos malos).

En mi caso, tuve que borrar manualmente mi balanceador de carga de entrada de la consola de GCP Network Service. Había creado manualmente la interfaz del equilibrador de carga directamente en la consola. Una vez que eliminé el equilibrador de carga, el espacio de nombres se eliminó automáticamente.

Sospecho que Kubernetes no quiso eliminar porque el estado del balanceador de carga era diferente al estado en el manifiesto.

Intentaré automatizar la creación de la interfaz de entrada utilizando las anotaciones a continuación para ver si puedo resolver este problema.

A veces, solo editar el manifiesto de recursos en línea no funcionaría muy bien (me refiero a eliminar el finalizers archivado y guardar).
Entonces, obtuve una nueva forma de otros.

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

Después de ejecutar ese comando, el espacio de nombres ahora debería estar ausente de su lista de espacios de nombres ... Y funciona para mí.

No solo namespace sino que también es compatible con los otros recursos.

eres una estrella funcionó

A veces, solo editar el manifiesto de recursos en línea no funcionaría muy bien (me refiero a eliminar el finalizers archivado y guardar).
Entonces, obtuve una nueva forma de otros.

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

Después de ejecutar ese comando, el espacio de nombres ahora debería estar ausente de su lista de espacios de nombres ... Y funciona para mí.

No solo namespace sino que también es compatible con los otros recursos.

Probé muchas soluciones, pero esta es la que funcionó para mí. ¡Gracias!

curl -k -H "Tipo de contenido: aplicación / json" -X PUT --data-binary @ tmp.json https: // kubernetes-cluster-ip / api / v1 / namespaces / annoying-namespace-to-delete / finalizar

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

Esta debería ser la respuesta "aceptada" : ¡resolvió completamente la raíz de este problema!

Tome del enlace de arriba:

Esta no es la forma correcta, especialmente en un entorno de producción.

Hoy me metí en el mismo problema. Al eliminar el finalizador, terminará con sobras en varios estados. En realidad, debería encontrar lo que impide que se complete la eliminación.

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

(también, desafortunadamente, 'kubetctl get all' no informa todas las cosas, debe usar comandos similares como en el enlace)

Mi caso: eliminar el espacio de nombres 'cert-manager'. En la salida de 'kubectl get apiservice -o yaml' encontré APIService 'v1beta1.admission.certmanager.k8s.io' con status = False. Este servicio era parte de cert-manager, que acabo de eliminar. Entonces, en 10 segundos después de que 'kubectl elimine apiservice v1beta1.admission.certmanager.k8s.io', el espacio de nombres desapareció.

Espero que ayude.

Habiendo dicho eso, escribí un pequeño microservicio para que se ejecute como CronJob cada hora que elimina automáticamente los espacios de nombres Terminating.

Puede encontrarlo aquí: https://github.com/oze4/service.remove-terminating-namespaces

Escribí un pequeño microservicio para que se ejecute como CronJob cada hora que elimina automáticamente los espacios de nombres de terminación.

Puede encontrarlo aquí: https://github.com/oze4/service.remove-terminating-namespaces

Otro delineador más:

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

Pero eliminar los espacios de nombres bloqueados no es una buena solución. La forma correcta es averiguar por qué está atascado. Una razón muy común es que hay un servicio (s) API no disponible que evita que el clúster finalice los espacios de nombres.
Por ejemplo, aquí no he eliminado Knative correctamente:

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

Eliminarlo resolvió el problema

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  

Escribí un pequeño microservicio para que se ejecute como CronJob cada hora que elimina automáticamente los espacios de nombres de terminación.

Puede encontrarlo aquí: https://github.com/oze4/service.remove-terminating-namespaces

buen trabajo.

Tuve un problema similar en 1.18 en un clúster de laboratorio k8s y agregué una nota para quizás ayudar a otros. Había estado trabajando con la API de métricas y con métricas personalizadas en particular. Después de eliminar esos objetos k8s para recrearlo, se detuvo al eliminar el espacio de nombres con un error de que no se pudo encontrar el punto final de la API de métricas. Volviendo a poner eso en otro espacio de nombres, todo se aclaró de inmediato.

Esto estaba en el espacio de nombres bajo 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

Otro delineador más:

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

Pero eliminar los espacios de nombres bloqueados no es una buena solución. La forma correcta es averiguar por qué está atascado. Una razón muy común es que hay un servicio (s) API no disponible que evita que el clúster finalice los espacios de nombres.
Por ejemplo, aquí no he eliminado Knative correctamente:

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

Eliminarlo resolvió el problema

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  

¡Definitivamente el delineador más limpio! Es importante señalar que ninguna de estas "soluciones" resuelve realmente el problema de raíz.

Vea aquí la solución correcta

Ese es el mensaje que debería estar difundiendo: sonrisa: no "otra línea más".

¡Definitivamente el delineador más limpio! Es importante señalar que ninguna de estas "soluciones" resuelve realmente el problema de raíz.

Esta solución resuelve una de todas las posibilidades. Para buscar todas las posibles causas raíz y solucionarlas, utilizo este script: https://github.com/thyarles/knsk

@thyarles muy bonito!

No use modify finalize para eliminar el espacio de nombres. Eso provocará un error

Averigüe la causa de la terminación del espacio de nombres. Instrucciones de resolución de problemas conocidas actualmente

• vaina terminando
• sección de bloque de webhook del administrador de cert

Encuentro el mismo problema:

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

Puede usar etcdctl para buscar recursos no eliminados

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>

Solo copia y pega en tu terminal

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

/tmp/$NS.json

esto funcionó para mí, y corrí después de verificar que no había objetos k8s colgando en el ns. ¡Gracias!

Usé esto para eliminar un espacio de nombres atascado en Terminado

ejemplo:

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

Para todos los googlers que se encontraron con espacios de nombres atascados en Terminar en espacios de nombres específicos de Rancher (por ejemplo, sistema de ganado), el siguiente comando modificado (original de grebois) funcionó para mí:

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

Amigos, para su información, cuando salga el video de esta

Grabé una explicación de 10 minutos de lo que está pasando y la presenté en esta sesión de SIG Deep Dive .

Aquí hay un comentario correcto con 65 votos a favor.

Mencionado varias veces anteriormente, esta publicación mediana es un ejemplo de cómo hacer las cosas de la manera correcta. Encuentra y repara el servicio de api roto.

Todas las líneas de una sola línea que simplemente eliminan los finalizadores en el espacio de nombres abordan la causa raíz y dejan su clúster sutilmente roto, lo que lo morderá más tarde. Así que por favor no hagas eso. De todos modos, la solución de la causa raíz suele ser más fácil. Parece que a la gente le gusta publicar variaciones sobre este tema a pesar de que ya hay numerosas respuestas correctas en el hilo, así que voy a bloquear el problema ahora, para asegurarme de que este comentario permanezca en la parte inferior.