Kubernetes: "종료 중"상태에서 멈춘 네임 스페이스 삭제

/ sig api-machinery

@ shean-guangchang 이것을 재현 할 방법이 있습니까?

궁금해서 CRD를 사용하고 있습니까? 우리는 이전에 TPR에서이 문제에 직면했습니다.

/ 종류의 버그

루크 배포에서이 문제가 발생하는 것 같습니다.

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

나는 그것이 그들의 CRD와 관련이 있다고 생각합니다. API 서버 로그에서 이것을 볼 수 있습니다.

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

지금 다른 네임 스페이스에 루크를 배포했지만 클러스터 CRD를 만들 수 없습니다.

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

CRD가 정리되지 않은 것 같습니다.

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

비슷한 상태의 핵분열 네임 스페이스가 있습니다.

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

핵분열은 또한 CRD를 사용하지만 정화 된 것으로 보입니다.

@ shean-guangchang-저도 같은 문제가있었습니다. 네임 스페이스 아래의 모든 항목을 수동으로 삭제하고 "helm"에서 모든 항목을 삭제 및 제거하고 마스터 노드를 하나씩 다시 시작하여 문제를 해결했습니다.

내가 만난 것은 "방주", "경운기"및 Kuberenets가 모두 함께 작동하는 것과 관련이 있다고 생각합니다 (나는 투구를 사용하여 부트 스트랩하고 방주를 사용하여 백업). 따라서 이것은 다른 쪽에서는 Kuberenets 문제가 아닐 수 있습니다. 손, 관련 로그가 없기 때문에 문제 해결이 거의 불가능했습니다.

루크 인 경우 https://github.com/rook/rook/issues/1488#issuecomment -365058080을 살펴보세요.

나는 그것이 의미가 있다고 생각하지만 네임 스페이스를 삭제 불가능한 상태로 만드는 것이 가능하다는 것은 버그가있는 것 같습니다.

@barakAtSoluto 와 비슷한 환경 (Ark & Helm)이 있으며 동일한 문제가 있습니다. 마스터를 제거하고 다시 시작해도 문제가 해결되지 않았습니다. 여전히 종료 중입니다.

문제를 재현하려고 할 때도 마찬가지였습니다. 결국 새 클러스터를 만들어야했습니다 ....
제외-기본, kube-system / public 및 모든 ark 관련 네임 스페이스가 백업 및 복원에서 발생하지 않도록 방지합니다.

1.8.4에서 1.9.6으로 업그레이드 된 클러스터에서도이 문제를보고 있습니다. 어떤 로그를보아야할지조차 모릅니다.

1.10.1에 대한 동일한 문제 :(

1.9.6에서 동일한 문제

편집 : 일부 포드가 중단되어 네임 스페이스를 삭제할 수 없습니다. --grace-period = 0 --force로 모두 삭제했고 몇 분 후에 네임 스페이스도 삭제되었습니다.

야,

나는 이것을 반복해서 가지고 있으며 대부분의 경우 종료 자에 문제가 있습니다.

네임 스페이스가 멈춘 경우 kubectl get namespace XXX -o yaml 시도하고 종료자가 있는지 확인하십시오. 그렇다면 네임 스페이스를 편집하고 종료자를 제거 (빈 배열 전달)하면 네임 스페이스가 삭제됩니다.

@xetys 는 안전합니까? 제 경우에는 "kubernetes"라는 이름의 종료자가 하나뿐입니다.

이상합니다. 그런 종료자를 본 적이 없습니다. 나는 내 경험을 바탕으로 말할 수 있습니다. 프로덕션 클러스터에서 여러 번 수행했지만 여전히 살아 있습니다.

1.10.5에서 동일한 문제. 이 문제에 대한 모든 조언을 결과없이 시도했습니다. 포드를 제거 할 수 있었지만 네임 스페이스는 여전히 매달려 있습니다.

실제로 ns도 잠시 후 삭제되었습니다.

이 동작의 원인을 이해하는 것이 좋을 것입니다. 내가 가진 유일한 종료자는 kubernetes입니다. 또한 동적 웹훅이 있는데 관련 될 수 있습니까?

@xetys 글쎄, 마침내 나는 그 네임 스페이스 내부의 복제본에 대한 트릭을 사용했습니다. 그들은 아마도 더 이상 존재하지 않는 커스텀 파이널 라이저를 가지고 있었기 때문에 삭제할 수 없었습니다. 해당 종료 자에 대한 참조를 제거했을 때 그것들이 사라지고 네임 스페이스도 사라졌습니다. 감사! :)

EKS 1.10.3 클러스터에서 동일한 문제 :

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

베어 메탈 클러스터에 동일한 문제가 있습니다.

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

내 네임 스페이스는 다음과 같습니다.

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

실제로이 문제가 발생한 두 번째 네임 스페이스입니다.

네임 스페이스에있는 모든 항목의 실제 목록을 얻으려면 다음을 시도하십시오. https://github.com/kubernetes/kubectl/issues/151#issuecomment -402003022

그런 다음 각 개체에 대해 kubectl delete 또는 kubectl edit 를 수행하여 종료자를 제거합니다.

이니셜 라이저를 제거하면 트릭이 생겼습니다 ...

kubectl edit namespace annoying-namespace-to-delete 하고 종료자를 제거하면 kubectl get -o yaml 확인하면 다시 추가됩니다.

또한 @adampl 을 제안한 것을 시도 할 때 출력이 표시되지 않습니다 ( --ignore-not-found 제거하면 모든 유형의 네임 스페이스에 리소스가 없음을 확인 함).

@ManifoldFR , 나는 당신과 같은 문제가 있었고 json 파일로 API 호출을 만들어 작동하도록 관리했습니다.
kubectl get namespace annoying-namespace-to-delete -o json > tmp.json
그런 다음 tmp.json을 편집하고 "kubernetes" 제거하십시오.

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

네임 스페이스를 삭제해야합니다.

@slassh 작동했습니다! API 호출에 대해 생각 했어야했습니다. 감사합니다! 우리는 영원히 당신의 찬양을 노래 할 것입니다

v1.11.1에 문제가 있습니다. 도쿠 위키의 목장주 / 조타 배포가 막혔습니다. 먼저 @siXor가 제안한대로 포드를 강제로 삭제 한 다음 @slassh 조언을 따라야

@slassh kubernetes-cluster-ip를 보는 방법은 무엇입니까? kubernetes 클러스터 교체를 배포 한 노드 IP 중 하나를 사용하고 404를보고합니다.

안녕하세요 @jiuchongxiao , kubernetes-cluster-ip의 노드 마스터 IP 중 하나를 의미했습니다.
헷갈 리면 죄송합니다!

먼저 'kubectl 프록시'를 시작하면 curl을 http://127.0.0.1 : 8001 / api / v1 / namespaces / annoying-namespace-to-delete / finalize로 지정할 수 있습니다. 그렇게 할 때까지 인증을받을 수 없었습니다.

좋은 팁 @ 2stacks. https 를 http 됩니다.

1.11.2에서 여전히이 문제가 발생합니다.

재현에 대한 더 많은 컨텍스트를 제공하기 위해 CRD에서만 이것을 보았습니다. CRD 객체를 삭제하면 소유 한 객체가 삭제되지 않은 이상한 상태가되었습니다. 눈치 채지 못했기 때문에 네임 스페이스에 대한 삭제를 발행했습니다. 그런 다음 kubectl delete all --all -n my-namespace 를 사용하여 네임 스페이스의 모든 개체를 삭제했습니다. 그 시점에서 네임 스페이스 삭제가 중단되었습니다. 이것이 어떤 식 으로든 도움이되기를 바랍니다.

로그를 살펴보면이 특정 문제가 컨트롤러 관리자가 비정상적인 것과 관련이 있다는 것을 알았습니다. 제 경우에는 버그가 아니 었습니다. 컨트롤러 관리자가 다시 올라 갔을 때 모든 것이 올바르게 정리되었습니다.

@slassh 완벽한 솔루션! 대단히 감사합니다 ！！！！

1.10.x에서도이 문제가 발생합니다. @slassh 의 의견은 실제 문제를 숨기는 해결 방법입니다. 네임 스페이스가 Terminating 에서 멈춘 이유는 무엇입니까?

우리의 경우 네임 스페이스를 삭제하는 이유를 발견했습니다 (@palmerabollo).

네임 스페이스에 종료 자 kubernetes 경우 이는 API 서버의 내부 문제를 의미합니다.

kubectl api-resources 실행합니다. 다음과 같은 결과가 반환되면 사용자 지정 API에 연결할 수 없음을 의미합니다.

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

상태 조건을 확인하려면 kubectl get apiservices v1beta1.metrics.k8s.io -o yaml 실행하십시오.

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

위의 오류는 metrics-server에 영향을 미치는 crashloopbackoff로 인해 발생해야합니다. Kubernetes에 등록 된 다른 사용자 지정 API의 경우와 유사합니다.

네임 스페이스 삭제와 같은 클러스터 런타임 작업을 복원하려면 kube-system 에서 서비스 상태를 확인하세요.

v1.11.3에서이 문제에 직면했습니다. 종료 자에는 문제가있는 네임 스페이스에 대한 kubernetes 만 있습니다.

spec:
  finalizers:
  - kubernetes

@slassh 백만명 감사합니다, 귀하의 솔루션은 잘 작동합니다!
ark, tiller 및 kubed와 함께 클러스터에 동일한 문제가 있습니다. 문제가 다른 네임 스페이스의 삭제에 영향을 미치는 이유는 확실하지 않지만 오류를 제공하는 kubed의 API 일 수 있다고 생각합니다.

@javierprovecho 나는 단지 메트릭 서버를 가지고

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

이 상태에서 회복하는 방법을 알고 있습니까?

편집 : 알아 냈습니다 ... 측정 항목 / HPA와 원격으로 관련된 모든 항목을 삭제 한 다음 전체 제어 플레인을 다시 시작해야했습니다 (백업하기 전에 모든 복제본을 제거해야 함). 여기에는 apiservice 삭제가 포함됩니다. v1beta1.metrics.k8s.io 자체.

뿡 빵뀨

$ kubectl delete apiservice v1beta1.metrics.k8s.io

작동하지 않는 metrics API 서비스를 제거하면 컨트롤러 관리자가 오래된 네임 스페이스를 삭제할 수 있습니다.

제어 플레인을 다시 시작할 필요가 없습니다.

@antoineco 아니요, 필요했습니다. apiservice를 삭제하고 꽤 기다렸지 만 컨트롤 플레인을 다시 시작할 때까지 네임 스페이스가 삭제되지 않았습니다.

먼저 작은 커피를 마시고 긴장을 풀고 이제 k8s 마스터 노드로 이동하십시오.

1. kubectl 클러스터 정보
   Kubernetes 마스터는 https : // localhost : 6443에서 실행 중입니다.
   KubeDNS는 https : // localhost : 6443 / api / v1 / namespaces / kube-system / services / kube- dns : dns / proxy에서 실행됩니다.

클러스터 문제를 추가로 디버그하고 진단하려면 'kubectl cluster-info dump'를 사용하십시오.

1. 이제 kube-proxy를 실행하십시오.
   kubectl 프록시 및
   127.0.0.1:8001에 게재 시작

나중에 삭제하려면 ID를 저장하십시오. :)

1. 삭제하지 않기로 결정한 이름 공간을 찾으십시오. :) 우리에게는 가축 시스템이 될 것입니다.
   kubectl get ns
   가축 시스템 종료 1d

파일에 넣어

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

1. 파일 편집 및 종료 자 제거
   },
   "spec": {
   "종료 자": [
   "쿠 베르네 테스"
   ]
   },
   편집 후 다음과 같이 보일 것입니다 👍
   },
   "spec": {
   "종료 자": [
   ]
   },
   거의 다 왔어요 👍

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

그리고 사라졌습니다 👍

파이널 라이저 kubernetes 이 (가) 이유가 있습니다. 우리에게는 잘못 구성된 메트릭 API 서비스 이름이었습니다. 아마도 당신은 제어 플레인 로그를보고 발견 할 수있는 다른 것일 수도 있습니다. 버그 확인없이 종료자를 제거하면 더 이상 삭제 목적으로 다시 액세스 할 수없는 생성 된 항목을 남겨 두는 것과 같은 원하지 않는 결과 가 발생할 수 있습니다.

이 문제는 아직 진행 중이므로 :
"none"으로 실행되는 내 minikube 클러스터 내에서 호스트가 최대 절전 모드에서 깨어 난 후 발생했습니다.

내 가정 :
제 경우에는 최대 절전 모드가 동일한 문제를 발생 시켰으며 활성화 된 스왑이 가능합니다.

가정을 산출합니다.
영향을받는 클러스터에서 스왑이 활성화 될 수 있습니까?

그러나 이것은 단지 추측입니다. 나에게 중요한 것은 내 로컬 설정으로이 버그에 착수하는 모든 사람 : hibernate는 kubernetes에 좋지 않습니다 .

먼저 작은 커피를 마시고 긴장을 풀고 이제 k8s 마스터 노드로 이동하십시오.

1. kubectl 클러스터 정보
   Kubernetes 마스터는 https : // localhost : 6443에서 실행 중입니다.
   KubeDNS는 https : // localhost : 6443 / api / v1 / namespaces / kube-system / services / kube- dns : dns / proxy에서 실행됩니다.

클러스터 문제를 추가로 디버그하고 진단하려면 'kubectl cluster-info dump'를 사용하십시오.

1. 이제 kube-proxy를 실행하십시오.
   kubectl 프록시 및
   127.0.0.1:8001에 게재 시작

나중에 삭제하려면 ID를 저장하십시오. :)

1. 삭제하지 않기로 결정한 이름 공간을 찾으십시오. :) 우리에게는 가축 시스템이 될 것입니다.
   kubectl get ns
   가축 시스템 종료 1d

파일에 넣어

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

1. 파일 편집 및 종료 자 제거
   },
   "spec": {
   "종료 자": [
   "쿠 베르네 테스"
   ]
   },
   편집 후 다음과 같이 보일 것입니다 👍
   },
   "spec": {
   "종료 자": [
   ]
   },
   거의 다 왔어요 👍

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

그리고 사라졌습니다 👍

큰!!
공장

gcloud 인스턴스를 변경하면 (예 : 노드 업그레이드)이 문제가 주기적으로 발생합니다. 이렇게하면 gcloud instances list 의 이전 노드가 새 노드로 교체되지만 k8s 네임 스페이스의 포드는 중단됩니다.

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

그러면 포드가 알 수없는 상태가됩니다.

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

이로 인해 네임 스페이스가 종료되지 않습니다. 이것이 종료자를 변경해야하는지 또는 UNKNOWN 상태에서 포드를 처리해야하는 종료와 관련된 실제 버그가 있는지 여부 (또는 이와 같은 경우 네임 스페이스를 강제 종료하는 방법이 있어야하는 경우) ).

gcloud 인스턴스를 변경하면 (예 : 노드 업그레이드)이 문제가 주기적으로 발생합니다. 이렇게하면 gcloud instances list 의 이전 노드가 새 노드로 교체되지만 k8s 네임 스페이스의 포드는 중단됩니다.

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

그러면 포드가 알 수없는 상태가됩니다.

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

이로 인해 네임 스페이스가 종료되지 않습니다. 이것이 종료자를 변경해야하는지 또는 UNKNOWN 상태에서 포드를 처리해야하는 종료와 관련된 실제 버그가 있는지 여부 (또는 이와 같은 경우 네임 스페이스를 강제 종료하는 방법이 있어야하는 경우) ).

멋지다, 같은 문제가 아니야
노드를 유지 관리 모드로 전환 한 다음 유지 관리 모드가되면 모든 포드가 비워지고 삭제 / 업그레이드 할 수 있습니다.

보세요 ， https://kubernetes.io/docs/concepts/workloads/controllers/garbage-collection/ ,
리소스를 편집하고 metadata.finalizers를 삭제하고 사용하지 않는 crd를 삭제합니다. 강제로 삭제할 수 있습니다.

그러나 kubernetes 자는 정확히 무엇을합니까? 이 해킹으로 리소스가 올바르게 정리되지 않을 위험이 있습니까?

루크가 종료하는 데 도움이되었습니다 https://github.com/rook/rook/blob/master/Documentation/ceph-teardown.md

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

서버 오류 (NotFound) : "삭제할 성가신 네임 스페이스"네임 스페이스를 찾을 수 없습니다.

먼저 작은 커피를 마시고 긴장을 풀고 이제 k8s 마스터 노드로 이동하십시오.

1. kubectl 클러스터 정보
   Kubernetes 마스터는 https : // localhost : 6443에서 실행 중입니다.
   KubeDNS는 https : // localhost : 6443 / api / v1 / namespaces / kube-system / services / kube- dns : dns / proxy에서 실행됩니다.

클러스터 문제를 추가로 디버그하고 진단하려면 'kubectl cluster-info dump'를 사용하십시오.

1. 이제 kube-proxy를 실행하십시오.
   kubectl 프록시 및
   127.0.0.1:8001에 게재 시작

나중에 삭제하려면 ID를 저장하십시오. :)

1. 삭제하지 않기로 결정한 이름 공간을 찾으십시오. :) 우리에게는 가축 시스템이 될 것입니다.
   kubectl get ns
   가축 시스템 종료 1d

파일에 넣어

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

1. 파일 편집 및 종료 자 제거
   },
   "spec": {
   "종료 자": [
   "쿠 베르네 테스"
   ]
   },
   편집 후 다음과 같이 보일 것입니다 👍
   },
   "spec": {
   "종료 자": [
   ]
   },
   거의 다 왔어요 👍

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

그리고 사라졌습니다 👍

잘못된 값 : "편집 된 파일 유효성 검사에 실패했습니다.": ValidationError (Namespace.spec) : io.k8s.api.core.v1.NamespaceSpec에 대한 잘못된 유형 : "문자열"가져 오기, "맵"필요

Terminating 중에 많은 네임 스페이스가 멈춘 경우이를 자동화 할 수 있습니다.

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

종료자를 제거하려는 모든 네임 스페이스가 실제로 Terminating .

위의 작업을 수행하려면 kubectl proxy 실행 및 jq 필요합니다.

우리의 경우 메트릭 API 서비스가 다운되었으며 자세한 로깅에서이 오류 로그를 볼 수 있습니다.

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

메트릭 apiservice를 수정 한 후 종료가 완료됩니다.
삭제가 메트릭 apiservice에 의존하는 이유가 확실하지 않으며, 메트릭 apiservice가 클러스터에 설치되지 않은 경우 어떻게 작동하는지 알 수 있습니다.

삭제가 메트릭 apiservice에 의존하는 이유를 잘 모르겠습니다.

@manojbadam 메트릭이 API 서버에 등록되어 있기 때문에 네임 스페이스 삭제를 수행 할 때 해당 네임 스페이스와 연결된 (존재하는 경우) 삭제할 (네임 스페이스) 리소스에 대해 외부 API를 쿼리해야합니다. 확장 서버를 사용할 수없는 경우 Kubernetes는 모든 개체가 제거되었음을 보장 할 수 없으며 루트 개체가 제거 되었기 때문에 나중에 조정할 영구 메커니즘 (메모리 또는 디스크)이 없습니다. 이는 등록 된 모든 API 확장 서비스에서 발생합니다.

이 문제를 지속적으로 실행하면서 작은 쉘 스크립트로이를 자동화했습니다.

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

프로젝트를 가져오고, JSON을 수정하고, "kubectl proxy"를 시작하고 올바르게 중지합니다.…

저를 올바른 방향으로 안내해 주신 모든 분들께 감사드립니다!

이 문제를 지속적으로 실행하면서 작은 쉘 스크립트로이를 자동화했습니다.

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

프로젝트를 가져오고, JSON을 수정하고, "kubectl proxy"를 시작하고 올바르게 중지합니다.…

저를 올바른 방향으로 안내해 주신 모든 분들께 감사드립니다!

내 영웅! <3

나도이 문제에 부딪혔다. 저는 Google Kubernetes Engine에서 Terraform을 사용하여 Kubernetes 클러스터를 가동하고 클러스터 내부에 네임 스페이스와 포드를 만듭니다. 문제는 terraform destroy 실행 후 잠시 시작되었습니다.

제 경우에는 Terraform이 파괴를 실행하는 순서에 문제가있는 것으로 밝혀졌습니다. Terraform은 먼저 노드 풀을 삭제 한 다음 네임 스페이스와 포드를 삭제합니다. 그러나 (유일한) 노드 풀 삭제로 인해 Kubernetes 클러스터가 중단되었으며, 이것이 네임 스페이스 삭제가 영원히 "종료"되는 원인이되었습니다.

@FooBarWidget 나를 위해 같은 문제 :(

이 문제를 지속적으로 실행하면서 작은 쉘 스크립트로이를 자동화했습니다.

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

프로젝트를 가져오고, JSON을 수정하고, "kubectl proxy"를 시작하고 올바르게 중지합니다.…

저를 올바른 방향으로 안내해 주신 모든 분들께 감사드립니다!

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

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

반환 코드 403을 받았습니다. 어떻게해야합니까? (

이 문제를 지속적으로 실행하면서 작은 쉘 스크립트로이를 자동화했습니다.
https://github.com/ctron/kill-kube-ns/blob/master/kill-kube-ns
프로젝트를 가져오고, JSON을 수정하고, "kubectl proxy"를 시작하고 올바르게 중지합니다.…
저를 올바른 방향으로 안내해 주신 모든 분들께 감사드립니다!

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

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

반환 코드 403을 받았습니다. 어떻게해야합니까? (

Thx god, 종료 네임 스페이스가 마침내 사라졌습니다. 다음 방법은 나를 위해 트릭을 수행합니다.

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

동일한 문제가 있지만 메트릭 서비스가 표시되지 않습니다.

나는 digitalocean 및 gitlab auto devops의 k8s로 놀고 있습니다. 내 가정은 일부 digitalocean blob 저장소이지만 분석하거나 수정하는 방법을 잃었습니다.

@mingxingshi 텍사스. 트릭을 수행하지 않은 편집 네임 스페이스를 수행했습니다. 스크립트가 해냈습니다.

와우, 드디어 제거했습니다. @mingxingshi 명령에 감사드립니다!

저에게 해결책은 다음과 같습니다.

kubectl delete apiservice v1beta1.metrics.k8s.io

이 경험을 여기에 남겨 두어야한다고 생각했습니다.

다음 리소스로 terraform apply 을 (를) 수행했습니다.

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

하지만 저는 helm newb이고 servicer 라는 네임 스페이스를 만든 템플릿이있는 템플릿을 가지고 있습니다. 이로 인해 terraform 및 k8s가 terraform이 실패하는이 잘못된 상태가되고 k8s는 Terminating 상태에서 servicer 네임 스페이스를 영구적으로 남겨 둡니다. @mingxingshi 가 위에서

이 문제는 네임 스페이스를 만든 템플릿을 제거하고이를 생성하도록 맡겼을 때 저에게 발생하지 않았습니다.

문제는 저에게 완전히 반복됩니다. 먼저 prometheus-operator를 복제합니다. 그때:

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

중단됩니다. 그러나 kubectl delete -f manifests/ 을 사용하면 정리가 성공합니다.

네, 프로 메테우스 운영자와 똑같은 시간을 보냈습니다. 고정을 해제하려면 kubectl delete -f manifests/ 이 필요합니다.
프로 메테우스 CRD에 오작동하는 일부 종료자가 있다고 생각합니다.이 특정 시나리오에서는 거의 kubernetes 잘못이 아닙니다. 그러나 kubernetes를 사용하면 범인을 더 쉽게 찾을 수 있습니다.이 스레드의 길이는 여러 원인이있을 수 있으며 각 특정 시나리오에서 그 원인을 파악하는 것이 쉽지 않기 때문입니다.

저는 kubernetes noob이므로 여기에 많은 정보를 제공 할 수 없지만 종료 상태에 2 개의 네임 스페이스가 붙어 있습니다. 내 kubernetes 설정은 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

종료 상태에있는 두 개의 네임 스페이스가 있습니다.

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

이 주석에 설명 된대로 종료자를 확인하면 kubernetes 됩니다.

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

어쨌든 종료 자에서 kubernetes 제거를 시도했지만 작동하지 않았습니다. 또한 이 주석에 설명 된 json / api 접근 방식을 사용해 보았습니다. 또한 작동하지 않았습니다. 모든 노드를 다시 시작하려고 시도했지만 작동하지 않았습니다.

나는 또한 강제 삭제를 시도했지만 작동하지 않습니다.

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

제 경우 네임 스페이스는 rook-ceph이고, kubectl -n rook-ceph patch cephclusters.ceph.rook.io rook-ceph -p '{"metadata":{"finalizers": []}}' --type=merge 는 저에게 적합합니다. 다른 경우에도 작동합니다.

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

@ManifoldFR , 나는 당신과 같은 문제가 있었고 json 파일로 API 호출을 만들어 작동하도록 관리했습니다.
kubectl get namespace annoying-namespace-to-delete -o json > tmp.json
그런 다음 tmp.json을 편집하고 "kubernetes" 제거하십시오.

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

네임 스페이스를 삭제해야합니다.

접근 방식을 사용하는 동안 문제가 있습니다. 다음 단계 문제 해결을 위해 어떻게해야합니까?

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

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

@ManifoldFR , 나는 당신과 같은 문제가 있었고 json 파일로 API 호출을 만들어 작동하도록 관리했습니다.
kubectl get namespace annoying-namespace-to-delete -o json > tmp.json
그런 다음 tmp.json을 편집하고 "kubernetes" 제거하십시오.
curl -k -H "Content-Type: application/json" -X PUT --data-binary @tmp.json https://kubernetes-cluster-ip/api/v1/namespaces/annoying-namespace-to-delete/finalize
네임 스페이스를 삭제해야합니다.

접근 방식을 사용하는 동안 문제가 있습니다. 다음 단계 문제 해결을 위해 어떻게해야합니까?

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

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

내 문제는이 스크립트로 해결할 수 있습니다 : https://github.com/ctron/kill-kube-ns/blob/master/kill-kube-ns .

yup https://github.com/ctron/kill-kube-ns/blob/master/kill-kube-ns 가 트릭을 수행합니다.

set -eo pipefail

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

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

# checking pre-reqs

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

PROJECT="$1"
shift

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

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

sleep 1 # give the proxy a second

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

실제로 네임 스페이스가 삭제되지 않은 것 같습니다.
제 경우 kubectl get ns 는 삭제 된 네임 스페이스를 표시하지 않지만 kubectl get all -n <namespace> 는 모든 리소스를 안전하고 건전하게 표시합니다.
노드와 도커 컨테이너가 여전히 실행 중인지 확인했습니다.

@glouis 는 위의 방법을 사용하여

많은 사람들이 그 결과를 이해하지 못하고이 방법을 맹목적으로 옹호하는 것을 보는 것은 정말 슬픈 일입니다. 매우 추하고 잠재적으로 클러스터에 많은 잔여 물을 남길 수 있습니다. @javierprovecho는 이미 위에서 언급 했으며 @liggitt 는 다른 GitHub 문제에서도 언급했습니다 .

손상된 v1beta1.metrics.k8s.io API 서비스 를 수정하거나 필요하지 않은 경우 삭제하는 것이 좋습니다.

참조 # 73405

두 번째 @antoineco 메시지입니다. 우리는 계속해서 네임 스페이스가 고착되어 있었기 때문에 샌드 박스 환경 중 하나에서 이것을 테스트했습니다. 약 한 달 후에 모든 도커 데몬이 아무런 이유없이 동결되었습니다. 리소스를 남겨 두면서 엄청난 메모리 누수가 발생했습니다.

많은 시행 착오를 거쳐 이러한 주석을 읽은 후 네임 스페이스에 대한 coreos grafana 스택에 대한 사용자 지정 리소스 정의로 판명되었습니다. CRD를 나열하면 해당 네임 스페이스에 대한 특정 리소스가 표시되었습니다. 나는 CRD의 이름에 네임 스페이스가 붙어있어서 매우 운이 좋았습니다.

또한 하나의 고정 된 네임 스페이스가 있으면 더 이상 삭제할 네임 스페이스가 중지되는 것으로 밝혀졌습니다. 따라서 CRD가없는 네임 스페이스 A가 있고 고정 된 CRD가있는 네임 스페이스 B가 있어도 B가 사라질 때까지 A의 모든 리소스가 유지됩니다. 나는 매번 많은 리소스를 남겨두고 네임 스페이스 A에서 위에서 설명한 수정을 수행해야한다고 생각합니다.

여전히 나를 죽이고있는 것은 내가 평생 동안 CRD 삭제에 실패한 네임 스페이스 정리를 언급하는 로그를 찾을 수 없거나 현재 수행중인 작업을 찾을 수 없다는 것입니다. 나는 그것이 어떤 CRD에 붙어 있는지 알아내는 데 한 시간을 소비해야했습니다. 누군가가 더 많은 정보를 얻는 방법에 대한 아이디어를 가지고 있다면 굉장 할 것 같은 고착 된 리소스를 알아내는 데 엄청난 시간을 할애 할 필요가 없습니다.

@jecafarelli 프로덕션 클러스터에 대한 좋은 힌트입니다. 하지만 불행하게도, 다른 방법으로는 죽일 수 없었습니다. 또한 나중에 전체 클러스터를 다시 만들 것임을 알았습니다.

문제를 분석해 보았지만이 스레드에서 다른 방법으로 문제를 해결하는 데 도움이되지 않았습니다.

이 공식 솔루션이 도움이되었습니다 : https://success.docker.com/article/kubernetes-namespace-stuck-in-terminating
kubectl edit namespace rook-ceph 와 동일 하지 않습니다 . 삭제 된 _ "finalizers"_에 PUT 요청을 할 때까지이 문제를 해결할 수 없었습니다.

그래서 나는 coreos와 함께 이것을 다시 만났고 조금 더 깊이 파고 들었습니다. 이것은 네임 스페이스가있는 클러스터 전체 리소스 정의 때문이며 더 나아가 coreos에서 정보를 쿼리 할 수 ​​없기 때문에 삭제할 수 없습니다. api 그룹에 대한 정보를 얻으려고 할 때 오류를 표시하는 apiserver 로그에서 오류를 발견했습니다. 위의 참조 된 문제를 사용하여 ns가 저에게 붙어있는 리소스를 나열하는 빠른 스크립트를 작성했습니다.

내가 다시 실행하고 내가 실행하는 다른 네임 스페이스 리소스를 계속 추가하면 나중에 이것을 사용할 것입니다.

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

@jecafarelli 감사합니다. 제 문제를 올바른 방법으로 해결하는 데 도움을 주셨습니다 ;-)

cert-manager 네임 스페이스 내부의 OpenShift 클러스터에 cert-manager를 설치했으며이 네임 스페이스를 삭제하려고 할 때 종료 상태에서 멈췄습니다. oc delete apiservices v1beta1.admission.certmanager.k8s.io 실행하면 문제가 해결 된 것 같지만 네임 스페이스가 사라졌습니다.

@jecafarelli 감사합니다. 제 문제를 올바른 방법으로 해결하는 데 도움을 주셨습니다 ;-)

cert-manager 네임 스페이스 내부의 OpenShift 클러스터에 cert-manager를 설치했으며이 네임 스페이스를 삭제하려고 할 때 종료 상태에서 멈췄습니다. oc delete apiservices v1beta1.admission.certmanager.k8s.io 실행하면 문제가 해결 된 것 같지만 네임 스페이스가 사라졌습니다.

여기서도 kubectl delete -f https://raw.githubusercontent.com/jetstack/cert-manager/release-0.8/deploy/manifests/00-crds.yaml 도움이되었습니다.

GKE를 사용하는 1.13.6 버전에서도이 오류가 발생했습니다. GKE의 Istio 애드온을 사용 중지하여 모든 권한을 수동으로 설치 한 후에 발생했습니다.
이것은 내가 읽어 본 가장 긴 문제 스레드이며,이 문제의 근원에 대한 실제 합의 나 재현 단계가 없다는 사실에 놀랐습니다. 너무 많은 다른 방식으로 넘어 질 수 있습니다.

JSON 및 curl / proxy 방법은 위에서 여러 번 언급되고 https://success.docker.com/article/kubernetes-namespace-stuck-in-terminating에 문서화되어 저를 구했습니다.

https://success.docker.com/article/kubernetes-namespace-stuck-in-terminating 의 조언은 적극적으로 유해하며 나중에 동일한 이름을 가진 네임 스페이스가 다시 생성되는 경우 고아 리소스가 정리되지 않고 다시 표시 될 수 있습니다. .

정지 된 삭제의 구체적인 원인을 밝히기위한 작업이 진행 중이지만 근본적인 문제는 정리 된 것으로 확인할 수없는 API 유형이 있으므로 네임 스페이스 삭제가 확인 될 때까지 차단된다는 것입니다.

또한이 네임 스페이스가 지정된 apiservice를 설치하는 Knative를 사용하여이 문제를 해결했습니다.

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

knative-serving ns와 다른 많은 네임 스페이스를 삭제 한 후 정리했습니다. 위의 bash 스크립트에 대해 @jecafarelli 에게 감사드립니다.
여기 끔찍한 powershell 버전이 있습니다.

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

나는 오늘 같은 문제가 있었고이 스크립트 는 나를 위해 일했습니다.

@ kubernetes / sig-api-machinery-misc

이 버그는> 년 동안 존재했으며 여전히 문제입니다 ... 이와 같은 인바운드 문제를 해결할 계획은 무엇입니까?

이것은 적어도 무슨 일이 일어나고 있는지 이해하는 데 도움이 될 수 있습니다 : https://github.com/kubernetes/kubernetes/pull/80962

나는 같은 문제를 겪고있다

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

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

네임 스페이스 컨트롤러는 네임 스페이스 상태에 조건을보고해야하며 클라이언트는이를보고해야합니다. KEP가 필요하지만 누군가가 그것을 받아 검증 할 수 있다면 매우 간단해야합니다.

@timothysc @smarterclayton 말한다 정확히 무엇을하고 비행 (어딘가에)에 PR이있다 (또는이었다).

이것에 대해 또 다른 github 문제가 있다고 확신합니까?

네 PR은 여기 있습니다 : https://github.com/kubernetes/kubernetes/pull/73405

내가 표준이라고 생각하는 문제는 다음과 같습니다. https://github.com/kubernetes/kubernetes/issues/70916

저에게 도움이 된 리소스는 다음과 같습니다. https://www.ibm.com/support/knowledgecenter/en/SSBS6K_3.1.1/troubleshoot/ns_terminating.html

@slassh 에서 제안한 솔루션과 비슷하지만 kubectl proxy 를 사용하여 로컬 프록시를 만들고 curl 명령의 대상 IP를 예측 가능하게 만듭니다.

-

편집 :이 답변 아래에 여러 번 언급 했듯이이 솔루션은 더러운 해킹이며 클러스터에 일부 종속 리소스를 남길 수 있습니다. 자신의 책임하에 사용하고 개발 클러스터에서 빠른 방법으로 만 사용하십시오 (프로덕션 클러스터에서는 사용하지 마십시오).

위의 문서에 설명 된대로 종료자를 직접 제거하면 결과가 발생할 수 있습니다. 삭제 보류 중이던 리소스는 네임 스페이스가 해제 된 후에도 클러스터에 계속 정의됩니다. 이것이 종료 자의 목적입니다. ns 삭제를 허용하기 전에 모든 종속 항목이 제거되었는지 확인합니다.

유사한 질문에서 해결 방법을 찾았습니다.

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

유사한 질문에서 해결 방법을 찾았습니다.

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

감사합니다!
잘 작동합니다.
이 해결 방법을 사용하여 간단한 앱을 만듭니다. https://github.com/jenoOvchi/k8sdelns
빠른 삭제를 위해 사용하고 누군가에게 도움이되기를 바랍니다.

Kubernetes 1.12.2 네임 스페이스는 Terminating 상태입니다. 때때로 ns의 yaml을 수정하여 종료자를 삭제할 수 있습니다. api로 삭제할 수 없습니다. 삭제할 수 있습니까? 상황은 어떻습니까? 구체적으로 추적 했습니까 (전제 조건 :이 ns에는 리소스가 없음), 포인터를 얻을 수 있기를 바랍니다. 감사합니다!

다시 말하지만, 종료자를 제거하지 마십시오. 이유가 있습니다. 대신 다음을 수행하여 NS에서 삭제 보류중인 리소스를 찾으십시오.

• apiservice를 사용할 수 없어 리소스를 제공하지 않는지 확인 : kubectl get apiservice|grep False
• kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get -n $your-ns-to-delete 를 통해 여전히 존재하는 모든 리소스 찾기 (Kudos에서 Jordan까지)

이 문제에 대한 해결책은 정리 메커니즘을 단락시키는 것이 아니라 정리가 성공하지 못하게하는 원인을 찾는 것입니다.

다시 말하지만, 종료자를 제거하지 마십시오. 이유가 있습니다. 대신 다음을 수행하여 NS에서 삭제 보류중인 리소스를 찾으십시오.

• apiservice를 사용할 수 없어 리소스를 제공하지 않는지 확인 : kubectl get apiservice|grep False
• kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get -n $your-ns-to-delete 를 통해 여전히 존재하는 모든 리소스 찾기 (Kudos에서 Jordan까지)

이 문제에 대한 해결책은 정리 메커니즘을 단락시키는 것이 아니라 정리가 성공하지 못하게하는 원인을 찾는 것입니다.

당신이 얼마나 옳은가.
제 경우에는 Operator Framework apiservice의 포드가 삭제되고 프로세스 종료가 차단되었습니다.
사용하지 않는 apiservice 제거 (kubectl delete apiservice) 문제를 해결했습니다.

안녕하세요, 코드 동결이 며칠 (목요일, 하루의 끝, 태평양 표준시) 내에 발생하므로이 문제가 v1.16에서 해결되거나 v1.17로 이동되었는지 확인해야합니다. 그것의 상태에 대해 언급 할 수 있습니까?

현재 GKE 릴리스로 백 포트 되나요? 아직 "종료 중"인 소수의 네임 스페이스가있는 클러스터가 있습니다.

이 일을 한 후에도 @squarelover ? https://github.com/kubernetes/kubernetes/issues/60807#issuecomment -524772920

@josiahbjorgaard 방금 PR을 승인했습니다. 1.16에 대해이 작업을 수행 할 전부입니다.

https://github.com/kubernetes/kubernetes/pull/73405 는 앞서 언급 한 PR입니다.

병합되었습니다. 우리가 할 수있는 일이 더있을 것 같지만, # 70916에 대한 향후 의견을 부탁드립니다.

다시 말하지만, 종료자를 제거하지 마십시오. 이유가 있습니다. 대신 다음을 수행하여 NS에서 삭제 보류중인 리소스를 찾으십시오.

• apiservice를 사용할 수 없어 리소스를 제공하지 않는지 확인 : kubectl get apiservice|grep False
• kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get -n $your-ns-to-delete 를 통해 여전히 존재하는 모든 리소스 찾기 (Kudos에서 Jordan까지)

이 문제에 대한 해결책은 정리 메커니즘을 단락시키는 것이 아니라 정리가 성공하지 못하게하는 원인을 찾는 것입니다.

대부분의 경우 Metric-Server가 설치되어있을 수 있습니다. 특정 네임 스페이스에 배포하는 포드가 메트릭 수집을 찾을 때. Metric-server와 연결되어 있습니다. 따라서 해당 네임 스페이스의 모든 리소스를 삭제 한 후에도 metric-server는 어떻게 든 해당 네임 스페이스에 연결됩니다. 그러면 네임 스페이스를 삭제할 수 없습니다.
이 게시물은 네임 스페이스를 삭제할 수없는 이유를 식별하는 데 도움이됩니다. 그래서 의식 방법.

네임 스페이스에있는 모든 항목의 실제 목록을 얻으려면 다음을 시도하십시오. kubernetes / kubectl # 151 (주석)

그런 다음 각 개체에 대해 kubectl delete 또는 kubectl edit 를 수행하여 종료자를 제거합니다.

이 솔루션은 나에게 유용합니다. 감사합니다.

안녕하세요 여러분,

Terminating status : https://github.com/thyarles/knsk 에서 네임 스페이스를 쉽게 삭제할 수있는 스크립트를 만들었습니다

감사.

네임 스페이스를 삭제하면 '종료 중'상태로 멈춘다는 동일한 문제가 발생했습니다. 위의 stpes를 따라 yaml 파일의 종료 자에서 'kubernetes'를 제거했습니다. 효과가있다.

그러나 우리는 추가 단계를 수행해야하는 이유를 모릅니다. kubectl delete ns foonamespace를 수행해야하며 삭제해야합니다. 아무도 나에게 이유를 줄 수 있습니까? 감사합니다!

안녕하세요 @ xzhang007 ,

네임 스페이스 삭제가 Terminating 상태에서 멈춘 이유를 발견하면 알려주세요. 나는 좋은 대답을 잠시 시도했지만 아무것도 없었다. 그런 다음 원인을 발견하고 수정할 때까지 내 삶을 더 쉽게 만드는 스크립트를 만들었습니다.

감사합니다.

@thyales 지금까지 답을 찾지 못한 것 같습니다.

우리의 경우 우리는 webhhoks와 finalizer 중 하나가
사용은 네임 스페이스에 살고있는 포드에 도달했습니다.
삭제되었습니다.
포드가 삭제되면 종료가 중단되었습니다.

>

@ xzhang007 @alvaroaleman 이 제공 한 답변을 보셨습니까 ? 우리에게는 원인이 무엇인지 알아내는 데 충분했습니다.

다시 말하지만, 종료자를 제거하지 마십시오. 이유가 있습니다. 대신 다음을 수행하여 NS에서 삭제 보류중인 리소스를 찾으십시오.

• apiservice를 사용할 수 없어 리소스를 제공하지 않는지 확인 : kubectl get apiservice|grep False
• kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get -n $your-ns-to-delete 를 통해 여전히 존재하는 모든 리소스 찾기 (Kudos에서 Jordan까지)

이 문제에 대한 해결책은 정리 메커니즘을 단락시키는 것이 아니라 정리가 성공하지 못하게하는 원인을 찾는 것입니다.

또한이 문제가 종결되었을 때 네임 스페이스가 Terminating에서 멈춘 이유를 명확히하는 방법을 논의하기 위해 참조 된 새 티켓이있었습니다. 이 닫힌 문제 대신 거기에서 대화를 나누는 것이 좋습니다.

병합되었습니다. 우리가 할 수있는 일이 더있을 것 같지만, # 70916에 대한 향후 의견을 부탁드립니다.

@ jeff-knurek 올바른 방법이어야합니다. 감사합니다.

우리의 경우에는 cert-manager 의 잘못된 업그레이드로 종료자가 중단되었습니다. https://github.com/jetstack/cert-manager/issues/1582

$ kube get apiservice

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

안녕하세요.
내 케이스 네임 스페이스는 https://github.com/rancher/rancher/issues/21546#issuecomment -553635629

아마도 도움이 될 것입니다.

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

이것은 나를위한 챔피언처럼 작동했습니다.

나는 또한 동일한 문제에 직면했으며 이제는 잘 작동합니다. 다음 문서를 참조하여 문제를 해결하십시오.

@zerkms 글쎄, 때로는 합법적 인 조언이지 않습니까? 종종 대기중인 종료자는 네임 스페이스 삭제의 일부로 삭제 된 개체가 제공하는 데 사용되었습니다. 이 경우, 더 이상 기다릴 필요가 없기 때문에-더 이상 마무리를 할 수있는 것이 없습니다-기사에서 설명하는 방식대로 객체를 패치하는 것이 유일한 옵션입니다 _.

이 기사는 기사 상단에 링크 된 알려진 문제 페이지에 나열된 단계를 적용하여 문제가 _ 해결되지 않은 경우에만 적용되며, 이는 기본적으로 링크 한 댓글이 반복되는 조언입니다.

@zerkms 글쎄, 때로는 합법적 인 조언이지 않습니까? 종종 대기중인 종료자는 네임 스페이스 삭제의 일부로 삭제 된 개체가 제공하는 데 사용되었습니다.

네임 스페이스의 spec.finalizer에 대해 이것이 사실 인 것을 본 적이 없습니다. 내가 본 모든 인스턴스는 네임 스페이스 정리 컨트롤러와 관련되어 있으며 네임 스페이스의 영구 개체 (어드바이스가 etcd에서 좌초 될 것임) 또는 응답하지 않는 집계 API (네임 스페이스 spec.finalizer를 제거하면 건너 뛸 수 있음)로 인해 발생했습니다. 대기 중이며 해당 API에서 지속되는 리소스도 좌초)

이 기사는 네임 스페이스 마무리를 우회하면 네임 스페이스 리소스가 스토리지에 좌초 될 위험이 있다는 경고를하지 않으며 권장하지 않습니다.

네임 스페이스의 spec.finalizer에 대한 사실을 본 적이 없습니다.

네, 맞습니다. 이것은이 종료자가 kubernetes 자체에 의해 구현되기 때문입니다. 그러나 해당 네임 스페이스 내의 객체에 다른 종료자가있을 수 있으며, 해당 네임 스페이스의 객체에 의해 구현 될 수 있습니다. 최근에 만난 한 가지 예는 https://appscode.com/products/stash/ 입니다.

stash-operator 배치에서 서비스 할 일부 CRD에 종료자를 배치합니다. 그러나 stash-operator가 이미 삭제되었으므로 해당 CRD에서 종료 자 표시를 제거 할 수있는 것은 없으며 네임 스페이스 삭제가 중단됩니다. 이 경우 해당 종료자를 패치 (네임 스페이스 자체가 아니라 해당 개체)하는 것이 유일하게 현명한 작업입니다.

이해가 되길 바랍니다.

이 경우 해당 종료자를 패치 (네임 스페이스 자체가 아니라 해당 개체)하는 것이 유일하게 현명한 작업입니다.

옳은. "모든 리소스 삭제"정리 시나리오에서는 이에 반대하지 않지만 링크 된 문서가 안내하는 내용이 아닙니다. 네임 스페이스에서 spec.finalizer를 제거하는 방법을 설명합니다.

먼저 작은 커피를 마시고 긴장을 풀고 이제 k8s 마스터 노드로 이동하십시오.

kubectl 클러스터 정보
Kubernetes 마스터는 https : // localhost : 6443에서 실행 중입니다.
KubeDNS는 https : // localhost : 6443 / api / v1 / namespaces / kube-system / services / kube- dns : dns / proxy에서 실행됩니다.
클러스터 문제를 추가로 디버그하고 진단하려면 'kubectl cluster-info dump'를 사용하십시오.

이제 kube-proxy를 실행하십시오.
kubectl 프록시 및
127.0.0.1:8001에 게재 시작
나중에 삭제하려면 ID를 저장하십시오. :)

1. 삭제하지 않기로 결정한 이름 공간을 찾으십시오. :) 우리에게는 가축 시스템이 될 것입니다.
   kubectl get ns
   가축 시스템 종료 1d

파일에 넣어

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

파일 편집 및 종료 자 제거
},
"spec": {
"종료 자": [
"쿠 베르네 테스"
]
},
편집 후 다음과 같이 보일 것입니다 👍
},
"spec": {
"종료 자": [
]
},
거의 다 왔어요 👍
curl -k -H "Content-Type : application / json"-X PUT --data-binary @ tmp.json http://127.0.0.1 : 8001 / api / v1 / namespaces / $ {NAMESPACE} / finalize

그리고 사라졌습니다 👍

다시 말하지만, 종료자를 제거하지 마십시오. 이유가 있습니다. 대신 다음을 수행하여 NS에서 삭제 보류중인 리소스를 찾으십시오.

• apiservice를 사용할 수 없어 리소스를 제공하지 않는지 확인 : kubectl get apiservice|grep False
• kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get -n $your-ns-to-delete 를 통해 여전히 존재하는 모든 리소스 찾기 (Kudos에서 Jordan까지)

이 문제에 대한 해결책은 정리 메커니즘을 단락시키는 것이 아니라 정리가 성공하지 못하게하는 원인을 찾는 것입니다.

얘들 아! @alvaroaleman이 제공하는 팁을 있는 네임 스페이스를 하드 삭제하기 전에 깨끗한 삭제 를 검사하고

https://github.com/thyarles/knsk 스크립트의 기능 :

1. 사용할 수없는 apiresources를 확인하고 삭제 요청
2. 네임 스페이스에서 보류중인 리소스를 확인하고 삭제 요청
3. 스크립트가 삭제를 수행하는 경우 Kubernetes가 완전 삭제를 수행하는지 확인하려면 약 5 분 정도 기다리십시오.
4. 고정 된 네임 스페이스 강제 삭제

도움이 되었기를 바랍니다.

@thyarles 정말 감사합니다. 나는 당신의 방식으로 문제를 해결했습니다.

$ kubectl get apiservices는 사용할 수없는 서비스를 확인하고, 사용 가능한 서비스를 삭제하면 $ kubectl delete apiservice [service-name]에 의해 false가됩니다. 그 후에는 네임 스페이스 삭제에 문제가 없습니다.

우리 팀에는 사용할 수없는 3 개의 apiservices, v1beta1.admission.certmanager.k8s.io, v1beta1.metrics.k8s.io 및 v1beta1.webhook.certmanager.k8s.io가 있습니다.

메트릭 apiserver가 실행되고 있지 않으면 클러스터가 다소 손상되었으며 APIService를 제거하는 것만으로 근본 원인이 실제로 해결되지는 않습니다.

@lavalamp 메트릭은 사용할 수없는 apiservice입니다.

예, 이는 메트릭 apiserver가 실행되고 있지 않음을 의미합니다. 즉, HPA가 클러스터에서 작동하지 않고 다른 것들도 작동하지 않음을 의미합니다.

예. HPA는 지금 작동하지 않습니다. 측정 항목을 삭제하고 수정하는 방법을 찾아서는 안됩니다.

@thyarles 정말 감사합니다. 나는 당신의 방식으로 문제를 해결했습니다.

$ kubectl get apiservices는 사용할 수없는 서비스를 확인하고, 사용 가능한 서비스를 삭제하면 $ kubectl delete apiservice [service-name]에 의해 false가됩니다. 그 후에는 네임 스페이스 삭제에 문제가 없습니다.

우리 팀에는 사용할 수없는 3 개의 apiservices, v1beta1.admission.certmanager.k8s.io, v1beta1.metrics.k8s.io 및 v1beta1.webhook.certmanager.k8s.io가 있습니다.

@ xzhang007 기뻐요! 이제 v1beta1.metrics.k8s.io가 손상된 이유를 확인해야합니다. 어떻게되는지 확인하세요 :

```
$ kubectl -n kube-system 모두 가져 오기 | grep 메트릭

pod / metrics-server-64f74f8d47-r5vcq 2/2 실행 9119d
service / 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 00 201d
replicaset.apps / metrics-server-64f74f8d471111119d
replicaset.apps / metrics-server-686789bb4b 000145d''`

$ kubectl -n kube-system 모두 가져 오기 | grep 메트릭

pod / metrics-server-5dcfd4dd9f-m2v9k 1/1 실행 중 0 2d20h

service / metrics-server ClusterIP xx.xx.xx.xx443 / TCP 27 일

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

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

예. HPA는 지금 작동하지 않습니다. 측정 항목을 삭제하고 수정하는 방법을 찾아서는 안됩니다.

@ xzhang007 사실 문제를 발견하기 전에는 작동하지 않습니다 .... 삭제 된 네임 스페이스를 멈춤 모드로 설정했기 때문에 방금 알아 차 렸습니다. helm 패키지 관리자를 사용하여 메트릭 서버를 다시 배포하거나 다음 명령을 호출하여 수정하십시오 ( 적용하기 전에 배포 파일 확인 ).

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

@slassh 솔루션은 Kubernetes 1.15에서 저에게

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

인증서 관리자가 잘못 설정 되었기 때문에 사용할 수 없었습니다. 예를 들어 수신 컨트롤러에서 잘못된 구문을 사용합니다. 우리 시스템의 경우

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

그리고 그것은

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

사용할 수 있도록합니다.

이 문제에서 앞서 kubectl replace --raw 를 사용할 수있는 최신 버전의 kubectl을 사용하여 kubectl에 의해 노출되지 않은 API를 사용하여 네임 스페이스를 종료하는 또 다른 방법이 있습니다 (어떤 버전인지 확실하지 않음). 이렇게하면 kubectl proxy 프로세스를 생성 할 필요가없고 curl 와의 종속성을 피할 수 있습니다 (busybox와 같은 일부 환경에서는 사용할 수 없음). 이것이 다른 사람을 도울 수 있기를 바라며 나는 이것을 여기에 남겼습니다.

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

이것이 해결 가능한 문제인지 여부가 확인 되었습니까? 여기에는 많은 해키 솔루션이 있지만 우리 중 누구도 네임 스페이스를 삭제할 수 없다는 근본적인 문제를 해결하는 것은 없습니다 ....
EKS v1.14 클러스터에 있습니다.

이것이 해결 가능한 문제인지 여부가 확인 되었습니까? 여기에는 많은 해키 솔루션이 있지만 우리 중 누구도 네임 스페이스를 삭제할 수 없다는 근본적인 문제를 해결하는 것은 없습니다.

근본적인 문제는 클러스터의 집계 된 API 그룹을 사용할 수 없다는 것입니다. 모든 API를 사용할 수있을 때까지 네임 스페이스 정리 컨트롤러가 차단되어 모든 API 그룹의 모든 리소스가 해당 네임 스페이스에 대해 정리되었는지 확인할 수 있습니다.

API를 컬링하려는 ppl의 경우 :

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

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

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

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

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

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

다음은이 작업을 자동으로 수행하는 스크립트입니다. jq :

#!/bin/bash

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

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

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

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

kill -15 $PID

모두 : 종료 자 제거를 자동화하는 스크립트는 이익보다 해를 끼칩니다 . 그들은 사용할 수없는 집계 된 apiserver (s)에 시간 폭탄을 남길 수 있습니다. 누군가 네임 스페이스를 다시 만들면 갑자기 오래된 개체가 다시 나타날 수 있습니다.

실제 솔루션은 다음과 같습니다.

$ kubectl get api-services

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

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

모두 : 종료 자 제거를 자동화하는 스크립트는 이익보다 해를 끼칩니다 . 그들은 사용할 수없는 집계 된 apiserver (s)에 시간 폭탄을 남길 수 있습니다. 누군가 네임 스페이스를 다시 만들면 갑자기 오래된 개체가 다시 나타날 수 있습니다.

실제 솔루션은 다음과 같습니다.

$ kubectl get api-services

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

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

https://github.com/thyarles/knsk

이 스크립트는 모든 검사를 수행하고 고아 리소스 찾기를 포함하여 완전한 삭제를 시도합니다. 사용자가 위험을 감수하려는 경우 스크립트는 권장되지 않는 삭제 방법을 수행하는 --force 옵션을 제공합니다.

오타, apiservices 여야 함

이 명령은 사용할 수없는 API를 표시합니다.

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

이 기사는 확실히 당신에게 유용 할 것입니다.

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

실제로 존재하는 것은 apiservices의 충돌이며 openshift에서 API의 상태를 확인할 수 있습니다.

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

실패한 api는 네임 스페이스 삭제를 시도한 후 해당 API에 속한 포드 또는 배포를 다시 시작하여 다시 시작해야합니다.

$ oc namspace 삭제

그리고 준비, 사업 고정 !!

모든 사람이 영어를 사용하는 데 동의하는 곳에서 자신의 언어를 사용하는 것은 무례합니다. 👎

모두가 영어로 말하는 데 동의하는 곳은 어디입니까?

2020 년 4 월 30 일 목요일 17:58 theAkito [email protected] 은 다음과 같이 썼습니다.

모두가 자신의 언어를 사용하는 것은 무례합니다.
영어로 말하는 것에 동의합니다. 👎

—
댓글을 달았 기 때문에 수신 한 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/60807#issuecomment-622137770 ,
또는 구독 취소
https://github.com/notifications/unsubscribe-auth/ALGMKB6K4OU4X3XOYMALOBLRPHYCDANCNFSM4ETUOEPA
.

>

Chris, 수석 아키텍트 @ brace.ai

-

기밀 유지 고지 :이 이메일은
의도 된 수신자를 포함 할 수 있으며 기밀, 독점 또는
특권 정보. 귀하가 의도 된 수신자가 아닌 경우
사용, 검토, 유포, 복사 또는 취해진 조치를
이 메시지 또는 첨부 파일 (있는 경우)에서 금지됩니다. 그렇지 않다면
원하는 수신자에게 회신 이메일로 보낸 사람에게 연락하십시오.
원본 메시지의 모든 사본과 첨부 파일을 파기하거나 삭제합니다.

준비, 실례합니다. 속도 때문이었습니다. 해결되었습니다.

우리는 다국어 사용자 기반을 가지고 있습니다. 우리의 도구 중 어느 것도 국제화되지 않은 것은 충분히 나쁩니다. 적어도 여기 github에서 친절 할 수 있습니다.

안녕하세요.

이 문제에서 앞서 kubectl replace --raw 를 사용할 수있는 최신 버전의 kubectl을 사용하여 kubectl에 의해 노출되지 않은 API를 사용하여 네임 스페이스를 종료하는 또 다른 방법이 있습니다 (어떤 버전인지 확실하지 않음). 이렇게하면 kubectl proxy 프로세스를 생성 할 필요가없고 curl 와의 종속성을 피할 수 있습니다 (busybox와 같은 일부 환경에서는 사용할 수 없음). 이것이 다른 사람을 도울 수 있기를 바라며 나는 이것을 여기에 남겼습니다.

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

이것은 완벽하게 작동했습니다!

우리는 다국어 사용자 기반을 가지고 있습니다. 우리의 도구 중 어느 것도 국제화되지 않은 것은 충분히 나쁩니다. 적어도 여기 github에서 친절 할 수 있습니다.

우리는 다국어 사용자 기반을 가지고 있습니다. 우리의 도구 중 어느 것도 국제화되지 않은 것은 충분히 나쁩니다. 적어도 여기 github에서 친절 할 수 있습니다.

아직도 이해하려고합니다. 용서 해줘. 실수로 싫어요를 클릭했을 수 있습니다.
예, 실제로 도구가 완벽하게 수행되지 않았습니다.
설명없이 엄지 손가락을 내리는 것은 말이되지 않습니다.

거의 항상이 문제를 경험할 때 CRD에 달려 있습니다. 해당 네임 스페이스에서만 사용되는 경우 CRD를 삭제 한 다음 종료 자 및 네임 스페이스 삭제를 진행할 수 있습니다.

이 문제에서 앞서 kubectl replace --raw 를 사용할 수있는 최신 버전의 kubectl을 사용하여 kubectl에 의해 노출되지 않은 API를 사용하여 네임 스페이스를 종료하는 또 다른 방법이 있습니다 (어떤 버전인지 확실하지 않음). 이렇게하면 kubectl proxy 프로세스를 생성 할 필요가없고 curl 와의 종속성을 피할 수 있습니다 (busybox와 같은 일부 환경에서는 사용할 수 없음). 이것이 다른 사람을 도울 수 있기를 바라며 나는 이것을 여기에 남겼습니다.

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

@teoincontatto 감사합니다! 이것은 마침내 작동했습니다!

때로는 리소스 매니페스트를 온라인으로 편집하는 것이 잘 작동하지 않을 수 있습니다 (즉, finalizers 파일을 제거하고 저장하십시오).
그래서 나는 다른 사람들로부터 새로운 방법을 얻었습니다.

kubectl get namespace linkerd -o json > linkerd.json

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

이 명령을 실행 한 후 네임 스페이스 목록에 네임 스페이스가 없어야합니다.

namespace 뿐만 아니라 다른 리소스도 지원합니다.

kubectl edit annoying-ns 사용하여 종료 자 줄을 제거하여 문제를 해결했습니다.

흠 ... 나는 지금이 문제가 있습니다 :)
오늘 저는 1.15에서 1.16으로 eks 클러스터를 업데이트했습니다.
지금까지 모든 것이 괜찮아 보입니다.
그러나 내 개발 ns "configcluster"는 일종의 "손상"이었습니다.
그래서 나는 그것을 정리하기로 결정했습니다.

k ns configcluster 삭제
....
이제 이것은 중단됩니다 (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

발 문제에서이 가시에 더 많이 노출되는 방법은 무엇입니까?

2020 년 6 월 19 일 금요일 오전 4:46 Andreas Höhmann [email protected]
썼다 :

흠 ... 나는 지금이 문제가 있습니다 :)
오늘 저는 1.15에서 1.16으로 eks 클러스터를 업데이트했습니다.
지금까지 모든 것이 괜찮아 보입니다.
그러나 내 개발 ns "configcluster"는 일종의 "손상"이었습니다.
그래서 나는 그것을 정리하기로 결정했습니다.

k ns configcluster 삭제
....
이제 이것은 중단됩니다 (3h +) : /

$ kubectl get namespace configcluster -o yaml
apiVersion : v1
종류 : 네임 스페이스
메타 데이터 :
주석 :
kubectl.kubernetes.io/last-applied-configuration : |
{ "apiVersion": "v1", "kind": "Namespace", "metadata": { "annotations": {}, "name": "configcluster"}}
creationTimestamp : "2020-06-19T06 : 40 : 15Z"
deleteTimestamp : "2020-06-19T09 : 19 : 16Z"
이름 : configcluster
resourceVersion : "22598109"
selfLink : / api / v1 / namespaces / configcluster
uid : e50f0b53-b21e-4e6e-8946-c0a0803f031b
투기:
종료 자 :

• Kubernetes
  상태:
  정황:
• lastTransitionTime : "2020-06-19T09 : 19 : 21Z"
  메시지 : '일부 그룹에 대한 검색 실패, 1 개 실패 : 검색 할 수 없음
  서버 API의 전체 목록 : metrics.k8s.io/v1beta1 : 서버는 현재
  요청을 처리 할 수 ​​없습니다. '
  이유 : DiscoveryFailed
  상태 : "참"
  유형 : NamespaceDeletionDiscoveryFailure
• lastTransitionTime : "2020-06-19T09 : 19 : 22Z"
  메시지 : 모든 레거시 kube 유형이 성공적으로 파싱되었습니다.
  이유 : ParsedGroupVersions
  상태 : "False"
  유형 : NamespaceDeletionGroupVersionParsingFailure
• lastTransitionTime : "2020-06-19T09 : 19 : 22Z"
  메시지 : 모든 콘텐츠가 성공적으로 삭제되었습니다.
  이유 : ContentDeleted
  상태 : "False"
  유형 : NamespaceDeletionContentFailure
  단계 : 종료

—
댓글을 달았 기 때문에 수신 한 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/60807#issuecomment-646543073 ,
또는 구독 취소
https://github.com/notifications/unsubscribe-auth/AFLKRCLHIZ77X2Z3F5GAOCTRXMXVTANCNFSM4ETUOEPA
.

@bobhenkel 잘이 문제는 종결되었으므로 실제로 이것은 문제가 없음을 의미합니다 (실행 가능한 항목에 관한 한). 유사한 상황을 처리하는 데 실질적인 도움이 필요한 경우 위의 스레드를 읽으십시오. 거기에 좋은 조언 (및 일부 나쁜 조언)이 있습니다.

제 경우에는 GCP 네트워크 서비스 콘솔에서 인 그레스 부하 분산기를 수동으로 삭제해야했습니다. 콘솔에서 직접로드 밸런서 프런트 엔드를 수동으로 생성했습니다. 로드 밸런서를 삭제하면 네임 스페이스가 자동으로 삭제되었습니다.

로드 밸런서의 상태가 매니페스트의 상태와 다르기 때문에 Kubernetes가 삭제를 원하지 않는 것 같습니다.

이 문제를 해결할 수 있는지 확인하기 위해 다음 주석을 사용하여 수신 프런트 엔드 생성을 자동화하려고합니다.

때로는 리소스 매니페스트를 온라인으로 편집하는 것이 잘 작동하지 않을 수 있습니다 (즉, finalizers 파일을 제거하고 저장하십시오).
그래서 나는 다른 사람들로부터 새로운 방법을 얻었습니다.

kubectl get namespace linkerd -o json > linkerd.json

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

이 명령을 실행 한 후 네임 스페이스 목록에 네임 스페이스가 없어야합니다.

namespace 뿐만 아니라 다른 리소스도 지원합니다.

당신은 그것이 일한 스타입니다

때로는 리소스 매니페스트를 온라인으로 편집하는 것이 잘 작동하지 않을 수 있습니다 (즉, finalizers 파일을 제거하고 저장하십시오).
그래서 나는 다른 사람들로부터 새로운 방법을 얻었습니다.

kubectl get namespace linkerd -o json > linkerd.json

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

이 명령을 실행 한 후 네임 스페이스 목록에 네임 스페이스가 없어야합니다.

namespace 뿐만 아니라 다른 리소스도 지원합니다.

많은 솔루션을 시도했지만 이것은 나를 위해 일한 것입니다. 감사합니다!

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

더 나은 https://stackoverflow.com/a/59667608/429476

이것은 정말로 "허용되는"대답이어야합니다 .이 문제의 근원 이 완전히 해결되었습니다!

위의 링크에서 가져옵니다.

이것은 특히 프로덕션 환경에서 올바른 방법이 아닙니다.

오늘 나는 같은 문제에 들어갔다. 종료자를 제거하면 다양한 상태에서 남은 음식이 남게됩니다. 실제로 삭제를 완전하게 유지하는 것이 무엇인지 찾아야합니다.

https://github.com/kubernetes/kubernetes/issues/60807#issuecomment -524772920을 참조

(또한 불행히도 'kubetctl get all'은 모든 것을보고하지 않습니다. 링크에서와 같은 유사한 명령을 사용해야합니다.)

내 사례- 'cert-manager'네임 스페이스 삭제. 'kubectl get apiservice -o yaml'의 출력에서 ​​status = False 인 APIService 'v1beta1.admission.certmanager.k8s.io'를 찾았습니다. 이 apiservice는 방금 삭제 한 cert-manager의 일부였습니다. 따라서 'kubectl delete apiservice v1beta1.admission.certmanager.k8s.io'후 10 초 만에 네임 스페이스가 사라졌습니다.

도움이되기를 바랍니다.

즉, Terminating 네임 스페이스를 자동으로 삭제하는 매시간 CronJob으로 실행되는 작은 마이크로 서비스를 작성했습니다.

여기에서 찾을 수 있습니다 : https://github.com/oze4/service.remove-terminating-namespaces

저는 Terminating 네임 스페이스를 자동으로 삭제하는 매시간 CronJob으로 실행되는 작은 마이크로 서비스를 작성했습니다.

여기에서 찾을 수 있습니다 : https://github.com/oze4/service.remove-terminating-namespaces

또 다른 oneliner :

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

그러나 고정 된 네임 스페이스를 삭제하는 것은 좋은 해결책이 아닙니다. 올바른 방법은 왜 붙어 있는지 알아내는 것입니다. 매우 일반적인 이유는 사용할 수없는 API 서비스가있어 클러스터가 네임 스페이스를 완료하지 못하도록하기 때문입니다.
예를 들어 여기에서는 Knative를 제대로 삭제하지 않았습니다.

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

그것을 삭제하면 문제가 해결되었습니다.

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

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

저는 Terminating 네임 스페이스를 자동으로 삭제하는 매시간 CronJob으로 실행되는 작은 마이크로 서비스를 작성했습니다.

여기에서 찾을 수 있습니다 : https://github.com/oze4/service.remove-terminating-namespaces

잘 했어.

나는 랩 k8s 클러스터의 1.18에서 비슷한 문제가 있었고 다른 사람들을 돕기 위해 메모를 추가했습니다. 저는 메트릭 API와 특히 사용자 지정 메트릭으로 작업했습니다. 다시 생성하기 위해 해당 k8s 객체를 삭제 한 후 메트릭 API 엔드 포인트를 찾을 수 없다는 오류와 함께 네임 스페이스 삭제가 중단되었습니다. 다시 다른 이름 공간에 넣으면 모든 것이 즉시 정리되었습니다.

이것은 status.conditions.message 아래의 네임 스페이스에있었습니다.

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

또 다른 oneliner :

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

그러나 고정 된 네임 스페이스를 삭제하는 것은 좋은 해결책이 아닙니다. 올바른 방법은 왜 붙어 있는지 알아내는 것입니다. 매우 일반적인 이유는 사용할 수없는 API 서비스가있어 클러스터가 네임 스페이스를 완료하지 못하도록하기 때문입니다.
예를 들어 여기에서는 Knative를 제대로 삭제하지 않았습니다.

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

그것을 삭제하면 문제가 해결되었습니다.

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

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

확실히 가장 깨끗한 라이너! 이러한 "솔루션"중 어느 것도 실제로 근본 문제를 해결하지 못한다는 점에 유의하는 것이 중요합니다.

올바른 솔루션은 여기를 참조하십시오.

그것은 메시지가 퍼져 야 할 것입니다. : smile : "아직 다른 하나의 라이너"가 아닙니다.

확실히 가장 깨끗한 한 라이너! 이러한 "솔루션"중 어느 것도 실제로 근본 문제를 해결하지 못한다는 점에 유의하는 것이 중요합니다.

이 솔루션은 모든 가능성 중 하나를 해결합니다. 가능한 모든 근본 원인을 찾아 수정하려면 다음 스크립트를 사용합니다. https://github.com/thyarles/knsk

@thyarles 아주 좋은!

modify finalize 를 사용하여 네임 스페이스를 삭제하지 마십시오. 오류가 발생합니다.

네임 스페이스가 종료되는 원인을 찾으십시오. 현재 알려진 문제 해결 방법

• 포드 종료
• cert-manager webhook 블록 secrte

동일한 문제가 발생합니다.

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

#  sudo kubectl version

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

etcdctl 를 사용하여 삭제되지 않은 리소스를 찾을 수 있습니다.

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

터미널에 복사하여 붙여 넣기 만하면됩니다.

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

/tmp/$NS.json

이것은 나를 위해 일했으며 ns에 매달려있는 k8s 객체가 없는지 확인한 후 실행했습니다. 감사!

Terminated에서 멈춘 네임 스페이스를 제거하기 위해 이것을 사용했습니다.

예 :

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

Terminating on Rancher 특정 네임 스페이스 (예 : 가축 시스템)에서 갇힌 네임 스페이스에 부딪힌 모든 Google 직원에게 다음 수정 된 명령 (grebois의 원본)이 저에게 효과적이었습니다.

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

여러분, 참고로,이 kubecon 토크 의 비디오가 나왔을 때 나는 그것과 위의 유용한 댓글 중 일부를 링크하고이 문제를 잠글 계획입니다.

나는 무슨 일이 일어나고 있는지에 대한 10 분간의 설명을 녹음 했고이 SIG Deep Dive 세션 에서 발표했습니다.

여기 에 65 개의 찬성 으로

위에서 여러 번 언급 된이 중간 게시물 은 올바른 방식으로 작업을 수행하는 예입니다. 깨진 API 서비스를 찾아 수정합니다.

네임 스페이스에서 종료자를 제거하는 모든 라이너 는 근본 원인을 해결하고 클러스터를 미묘하게 깨뜨려 나중에 물릴 수 있습니다. 그러니 제발 그러지 마세요. 근본 원인 수정은 일반적으로 더 쉽습니다. 이미 스레드에 많은 정답이 있지만 사람들이이 테마에 대한 변형을 게시하는 것을 좋아하는 것 같습니다. 따라서이 댓글이 맨 아래에 머물도록하기 위해 지금 문제를 잠글 것입니다.