Kubernetes: "समाप्ति" स्थिति में अटके हुए नामस्थान को हटाना

/ सिग एपी-मशीनरी

@ shean-guangchang क्या आपके पास इसे पुन: पेश करने का कोई तरीका है?

और जिज्ञासा से बाहर, क्या आप किसी भी सीआरडी का उपयोग कर रहे हैं? हमने पहले टीपीआर के साथ इस समस्या का सामना किया।

/ तरह बग

मुझे लगता है कि इस मुद्दे पर एक बदमाश की तैनाती हो सकती है:

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

मुझे लगता है कि इसका उनके सीआरडी के साथ कुछ करना है, मैं इसे एपीआई सर्वर लॉग में देखता हूं:

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

विखंडन भी CRDs का उपयोग करता है, हालांकि, वे साफ किए जाते हैं।

@ शॉन-गुंगचांग - मेरे पास एक ही मुद्दा था। मैंने मैन्युअल रूप से नेमस्पेस के तहत सब कुछ डिलीट कर दिया है, "हेल्म" से सब कुछ डिलीट कर दिया है और एक-एक करके मास्टर नोड्स को फिर से शुरू किया है और इसने समस्या को ठीक कर दिया है।

मुझे लगता है कि मैंने जो कुछ भी किया है उसका "सन्दूक", "टिलर" और कुबेरनेट्स के साथ काम करना है (मैं हेल्म का उपयोग करके बूट कर रहा हूं और सन्दूक का उपयोग करके बैक-अप किया गया है) इसलिए यह उनके कहने पर कुबेरनेट्स मुद्दा नहीं हो सकता है, दूसरे पर हाथ, यह समस्या निवारण के लिए बहुत असंभव था क्योंकि कोई प्रासंगिक लॉग नहीं हैं।

यदि यह बदमाश है, तो इस पर एक नज़र डालें: https://github.com/rook/rook/issues/1488#issuecomment -365058080

मुझे लगता है कि समझ में आता है, लेकिन यह छोटी बात लगती है कि एक नामचीन राज्य में एक नाम स्थान प्राप्त करना संभव है।

मेरे पास @barakAtSoluto के साथ एक समान वातावरण (सन्दूक और हेल्म) है और एक ही मुद्दा है। मास्टर्स को शुद्ध करना और फिर से शुरू करना मेरे लिए हालांकि यह तय नहीं था। फिर भी समाप्त करने पर अटक गया।

मैं भी था कि जब समस्या को फिर से बनाने की कोशिश कर रहा। मुझे आखिरकार एक नया क्लस्टर बनाना पड़ा ...।
बहिष्कृत करें - डिफ़ॉल्ट, क्यूब-सिस्टम / पब्लिक और बैकअप से सभी सन्दूक संबंधी नामस्थान और इसे होने से रोकने के लिए पुनर्स्थापित करें ...

मैं इसे भी देख रहा हूँ, एक क्लस्टर पर 1.8.4 से 1.9.6 में अपग्रेड किया गया। मुझे यह भी पता नहीं है कि लॉग देखने के लिए क्या होता है

1.10.1 :( पर वही अंक

1.9.6 पर समान अंक

संपादित करें: कुछ पॉड्स के लटकने के कारण नामस्थान को हटाया नहीं जा सका। मैंने उन सभी पर --grace-period = 0 --force के साथ एक डिलीट किया और कुछ मिनटों के बाद नामपट्ट भी हटा दिया गया।

अरे,

मुझे यह बार-बार मिला है और यह सबसे अधिक समय है जब फाइनल के साथ कुछ परेशानी होती है।

यदि कोई नाम स्थान अटक गया है, तो kubectl get namespace XXX -o yaml का प्रयास करें और जांचें कि क्या उस पर कोई अंतिम रूप है। यदि ऐसा है, तो नाम स्थान को संपादित करें और फाइनलिज़र (एक खाली सरणी पास करके) को हटा दें और फिर नाम स्थान हटा दिया जाता है

@xetys क्या यह सुरक्षित है? मेरे मामले में "कुबेरनेट्स" नाम का केवल एक फाइनल है।

यह अजीब है, मैंने ऐसा फाइनल कभी नहीं देखा है। मैं सिर्फ अपने अनुभव के आधार पर बोल सकता हूं। मैंने ऐसा कई बार प्रोडक्शन क्लस्टर में किया और यह अभी भी जीवित है

1.10.5 पर समान अंक। मैंने बिना परिणाम के इस मुद्दे में सभी सलाह की कोशिश की। मैं फली से छुटकारा पाने में सक्षम था, लेकिन नाम स्थान अभी भी लटका हुआ है।

दरअसल, ns भी कुछ समय बाद डिलीट हो गया।

यह समझना अच्छा होगा कि इस व्यवहार का क्या कारण है, मेरे पास एकमात्र फाइनल है कुबेरनेट्स। मेरे पास डायनामिक वेबहूक भी हैं, क्या ये संबंधित हो सकते हैं?

@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 पुष्टि करता है कि कोई भी संसाधन किसी भी प्रकार के नामस्थान में नहीं पाए जाते हैं)।

@ मेनफोल्डएफआर , मेरे पास आपके जैसा ही मुद्दा था और मैं इसे
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

और यह आपके नामस्थान को हटाना चाहिए,

@ सालशः यह काम किया! एपीआई कॉल करने के बारे में सोचना चाहिए: बहुत बहुत धन्यवाद! हम हमेशा के लिए आपकी प्रशंसा करेंगे

समस्या v1.11.1 में मौजूद है। मेरे पास डॉक्यूविक की एक अटकी हुई रैंचर / हेल्म तैनाती थी। मुझे पहली बार @siXor द्वारा सुझाए गए फली को हटाने के लिए मजबूर करना पड़ा और उसके बाद @slassh की सलाह का पालन करना

@slassh कुबेरनेट्स-क्लस्टर-आईपी कैसे देखें? मैं एक नोड का उपयोग कुबेरनेट क्लस्टर की जगह तैनात आईपी, और यह 404 की रिपोर्ट करें।

hi @jiuchongxiao , kubernetes-क्लस्टर-आईपी से मेरा मतलब आपके नोड मास्टर्स आईपी में से एक से है।
खेद है अगर यह भ्रामक है!

यदि आप 'kubectl प्रॉक्सी' शुरू करते हैं, तो आप कर्ल को http://127.0.0.1 : 8001 / api / v1 / namepaces / कष्टप्रद-नेमस्पेस-से-डिलीट / फाइनल कर सकते हैं। जब तक मैंने इस तरह से काम नहीं किया, मुझे काम करने का प्रमाणीकरण नहीं मिला।

अच्छा सुझाव @ 2stacks। बस https http ।

मैं अभी भी 1.11.2 में इस मुद्दे को देखता हूं।

प्रजनन के लिए अधिक संदर्भ देने के लिए, मैंने इसे केवल सीआरडी के साथ देखा। सीआरडी ऑब्जेक्ट को हटाकर, मुझे एक अजीब स्थिति में मिला, इसके स्वामित्व वाले ऑब्जेक्ट हटाए नहीं गए थे। मैंने नोटिस नहीं किया इसलिए मैंने नाम स्थान के लिए एक विलोपन जारी किया। तब मैंने नामस्थान में kubectl delete all --all -n my-namespace सभी वस्तुओं को हटा दिया। उस बिंदु पर नाम स्थान विलोपन अटक गया। मुझे उम्मीद है कि यह किसी तरह से मदद करता है।

लॉग को देखकर मुझे सिर्फ यह पता चला कि यह विशेष समस्या नियंत्रक प्रबंधक के अस्वस्थ होने से संबंधित थी। मेरे मामले में यह एक बग सबसे अधिक संभावना नहीं थी। जब नियंत्रक प्रबंधक फिर से ऊपर गया तो सब कुछ सही ढंग से साफ हो गया।

@ सालशः परफेक्ट उपाय! आपका बहुत बहुत धन्यवाद!!!!

मैं भी 1.10.x के साथ इस मुद्दे को देखता हूं। मुझे लगता है कि @slassh एक टिप्पणी है जो केवल वास्तविक मुद्दे को छुपाता है। नाम स्थान Terminating पर क्यों अटके हुए हैं?

हमने अपने मामले में फंसे नामस्थानों को हटाने का कारण खोजा (@palmerabollo)

जब किसी नेमस्पेस में अंतिम रूप से kubernetes , तो इसका मतलब एपीआई सर्वर के साथ एक आंतरिक समस्या है।

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

उपरोक्त त्रुटि मेट्रिक्स-सर्वर को प्रभावित करने वाले क्रैशलूपबैकऑफ के कारण होनी चाहिए। यह कुबेरनेट्स में पंजीकृत अन्य कस्टम एपीआई के समान होगा।

नामस्थानों को हटाने जैसे क्लस्टर रनटाइम संचालन को पुनर्स्थापित करने के लिए kube-system में अपनी सेवाओं के स्वास्थ्य की जाँच करें।

मैं v1.11.3 पर इस मुद्दे का सामना कर रहा हूं। अंतिम नाम पर केवल समस्याग्रस्त नाम स्थान के लिए मौजूद कुबेरनेट्स।

spec:
  finalizers:
  - kubernetes

@slassh एक लाख धन्यवाद, आपका समाधान अच्छी तरह से काम करता है!
मुझे अपने क्लस्टर में सन्दूक, टिलर और कुबेड के साथ एक ही समस्या है। मुझे संदेह है कि समस्याएँ कुबेद की एपी हो सकती हैं जो एक त्रुटि दे रही हैं, हालांकि यह निश्चित नहीं है कि यह दूसरे नामस्थान के विलोपन को प्रभावित क्यों करती है।

@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

क्या आप जानते हैं कि इस अवस्था से कैसे उबरें?

संपादित करें: मुझे पता चला ... मुझे मेट्रिक्स / एचपीए से संबंधित दूर से भी _everything_ को हटाना पड़ा और फिर पूरे नियंत्रण विमान को फिर से शुरू करना पड़ा (इसके सभी प्रतिकृति को नीचे उतारना पड़ा, उन्हें वापस बूट करने से पहले।) इसमें apiservice को हटाना शामिल था। v1beta1.metrics.k8s.io स्वयं।

@ 2rs2ts

$ kubectl delete apiservice v1beta1.metrics.k8s.io

गैर-कामकाज metrics API सेवा से छुटकारा पाने से नियंत्रक-प्रबंधक बासी नाम स्थान (ओं) को हटाने में सक्षम होंगे।

नियंत्रण विमान को फिर से शुरू करना आवश्यक नहीं है।

@antoineco नहीं, यह आवश्यक था; मैंने एपिस सर्विस को डिलीट कर दिया और काफी देर इंतजार किया लेकिन जब तक मैंने कंट्रोल प्लेन को दोबारा शुरू नहीं किया तब तक नेमस्पेस को डिलीट नहीं किया जाएगा।

पहले, छोटी कॉफ़ी लें और आराम करें, अब अपने k8s मास्टर नोड्स पर जाएँ

1. kubectl क्लस्टर-जानकारी
   कुबेरनेट्स मास्टर https: // localhost : 6443 पर चल रहा है
   KubeDNS https: // localhost : 6443 / api / v1 / namespaces / kube-system / services / kube- dns: dns / xy पर चल रहा है

क्लस्टर समस्याओं के लिए आगे डीबग और निदान करने के लिए, 'kubectl क्लस्टर-जानकारी डंप' का उपयोग करें।

1. अब क्यूब-प्रॉक्सी चलाएं
   kubectl प्रॉक्सी और
   127.0.0.1:8001 पर सेवा शुरू करना

बाद में इसे हटाने के लिए आईडी सहेजें :)

1. अपना नाम-स्थान खोजें जिसने तय किया है कि हटाए नहीं जाने की :) हमारे लिए यह पशु-प्रणाली होगी
   kubectl ns मिलता है
   मवेशी-व्यवस्था समाप्त 1 डी

इसे फाइल में डालें

1. kubectl को namepace मवेशी-सिस्टम -o json> tmp.json मिलता है

1. फ़ाइल को संपादित करें और फाइनल को हटा दें
   },
   "कल्पना": {
   "फाइनल": [
   "Kubernetes"
   ]
   },
   संपादन के बाद यह इस तरह दिखना चाहिए like
   },
   "कल्पना": {
   "फाइनल": [
   ]
   },
   हम लगभग वहाँ 👍

curl -k -H "सामग्री-प्रकार: अनुप्रयोग / json" -X PUT --data- बाइनरी @ tmp.json http://127.0.0.1 : 8001 / एपीआई / v1 / नामस्थान / $ {NAMESPAD} / अंतिम रूप

और यह 👍 चला गया है

अरे, फाइनली kubernetes एक कारण से है। हमारे लिए यह एक गलत तरीके से कॉन्फ़िगर किया गया मीट्रिक एपीआई सेवा नाम था। हो सकता है कि आपके लिए कुछ और हो, जिसे आप अपने कंट्रोल प्लेन को देखकर खोज सकते हैं। बग की पुष्टि किए बिना, अंतिम रूप से हटाने से अवांछित परिणाम उत्पन्न हो सकते हैं जैसे कि बनाए गए सामान को छोड़ देना जो अब हटाने योग्य उद्देश्यों के लिए फिर से उपयोग योग्य नहीं हो सकता है।

जैसा कि यह मुद्दा अभी भी खुला है:
मेरे मिनीब्यूब क्लस्टर के भीतर "कोई नहीं" के साथ चल रहा है, यह मेजबान द्वारा हाइबरनेट से जागने के बाद हुआ।

मेरी धारणा:
मेरे मामले में हाइबरनेट समान समस्याओं को ट्रिगर करता है, एक सक्षम स्वैप करेगा।

जो धारणा पैदा करता है:
प्रभावित समूहों में स्वैप सक्षम हो सकता है?

लेकिन यह सिर्फ अनुमान है। मेरे लिए महत्वपूर्ण बात, और मेरे स्थानीय सेटअप के साथ इस बग में उतरने वाला: हाइबरनेट कुबेरनेट्स के लिए बुरा है ।

पहले, छोटी कॉफ़ी लें और आराम करें, अब अपने k8s मास्टर नोड्स पर जाएँ

1. kubectl क्लस्टर-जानकारी
   कुबेरनेट्स मास्टर https: // localhost : 6443 पर चल रहा है
   KubeDNS https: // localhost : 6443 / api / v1 / namespaces / kube-system / services / kube- dns: dns / xy पर चल रहा है

क्लस्टर समस्याओं के लिए आगे डीबग और निदान करने के लिए, 'kubectl क्लस्टर-जानकारी डंप' का उपयोग करें।

1. अब क्यूब-प्रॉक्सी चलाएं
   kubectl प्रॉक्सी और
   127.0.0.1:8001 पर सेवा शुरू करना

बाद में इसे हटाने के लिए आईडी सहेजें :)

1. अपना नाम-स्थान खोजें जिसने तय किया है कि हटाए नहीं जाने की :) हमारे लिए यह पशु-प्रणाली होगी
   kubectl ns मिलता है
   मवेशी-व्यवस्था समाप्त 1 डी

इसे फाइल में डालें

1. kubectl को namepace मवेशी-सिस्टम -o json> tmp.json मिलता है

1. फ़ाइल को संपादित करें और फाइनल को हटा दें
   },
   "कल्पना": {
   "फाइनल": [
   "Kubernetes"
   ]
   },
   संपादन के बाद यह इस तरह दिखना चाहिए like
   },
   "कल्पना": {
   "फाइनल": [
   ]
   },
   हम लगभग वहाँ 👍

curl -k -H "सामग्री-प्रकार: अनुप्रयोग / json" -X PUT --data- बाइनरी @ tmp.json http://127.0.0.1 : 8001 / एपीआई / v1 / नामस्थान / $ {NAMESPAD} / अंतिम रूप

और यह 👍 चला गया है

महान!!
काम करता है

यदि हम अपने 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 स्थिति में पॉड्स को संभालना चाहिए (या यदि इस तरह के मामलों के लिए एक नेमस्पेस को समाप्त करने का एक तरीका होना चाहिए )।

शांत यह एक ही मुद्दा नहीं है
आपको रखरखाव मोड में नोड्स लगाने की आवश्यकता है और फिर रखरखाव मोड में होने के बाद सभी पॉड्स को खाली कर दिया जाएगा और फिर यू को हटा / अपग्रेड कर सकते हैं

इसे देखें d https://kubernetes.io/docs/concepts/workloads/controllers/garbage-collection/ ,
संसाधन संपादित करें और मेटाडेटा.फिनालाइज़र को हटा दें और अप्रयुक्त crd को हटा दें ad आप इसे बल हटा सकते हैं

लेकिन kubernetes फाइनल क्या करता है? क्या कोई खतरा है कि संसाधनों को इस हैक से ठीक से साफ नहीं किया जा रहा है?

बदमाशों के लिए यह समाप्त करने में मदद मिली https://github.com/rook/rook/blob/master/Documentation/ceph-teardown.md

curl -k -H "कंटेंट-टाइप: एप्लीकेशन / जसन" -X PUT --data- बाइनरी @ tmp.json https: // kubernetes-क्लस्टर-आईपी / एपी / v1 / नेमस्पेस / कष्टप्रद-नेमस्पेस-टू-डिलीट / को अंतिम रूप देने

सर्वर से त्रुटि (NotFound): नेमस्पेस "कष्टप्रद-नेमस्पेस-टू-डिलीट" नहीं मिला

पहले, छोटी कॉफ़ी लें और आराम करें, अब अपने k8s मास्टर नोड्स पर जाएँ

1. kubectl क्लस्टर-जानकारी
   कुबेरनेट्स मास्टर https: // localhost : 6443 पर चल रहा है
   KubeDNS https: // localhost : 6443 / api / v1 / namespaces / kube-system / services / kube- dns: dns / xy पर चल रहा है

क्लस्टर समस्याओं के लिए आगे डीबग और निदान करने के लिए, 'kubectl क्लस्टर-जानकारी डंप' का उपयोग करें।

1. अब क्यूब-प्रॉक्सी चलाएं
   kubectl प्रॉक्सी और
   127.0.0.1:8001 पर सेवा शुरू करना

बाद में इसे हटाने के लिए आईडी सहेजें :)

1. अपना नाम-स्थान खोजें जिसने तय किया है कि हटाए नहीं जाने की :) हमारे लिए यह पशु-प्रणाली होगी
   kubectl ns मिलता है
   मवेशी-व्यवस्था समाप्त 1 डी

इसे फाइल में डालें

1. kubectl को namepace मवेशी-सिस्टम -o json> tmp.json मिलता है

1. फ़ाइल को संपादित करें और फाइनल को हटा दें
   },
   "कल्पना": {
   "फाइनल": [
   "Kubernetes"
   ]
   },
   संपादन के बाद यह इस तरह दिखना चाहिए like
   },
   "कल्पना": {
   "फाइनल": [
   ]
   },
   हम लगभग वहाँ 👍

curl -k -H "सामग्री-प्रकार: अनुप्रयोग / json" -X PUT --data- बाइनरी @ tmp.json http://127.0.0.1 : 8001 / एपीआई / v1 / नामस्थान / $ {NAMESPAD} / अंतिम रूप

और यह 👍 चला गया है

अमान्य मान: "संपादित की गई फ़ाइल विफल हुई मान्यता": मान्यकरण (नाम स्थान)

यदि आपके पास समाप्ति में कई नाम स्थान हैं, तो आप इसे स्वचालित कर सकते हैं:

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 ।

हमारे मामले में, मेट्रिक्स एपी सेवा नीचे है और मैं इस त्रुटि लॉग को वर्बोज़ लॉगिंग से देख सकता हूं

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

मेट्रिक्स एपिस सर्विस को ठीक करने के बाद, समाप्त करने वालों को पूरा किया जाता है।
वास्तव में यह सुनिश्चित नहीं है कि विलोपन मैट्रिक्स एप्रिस सर्विस पर क्यों निर्भर करता है, यह जानने का भी इरादा है कि यह कैसे काम करता है यदि मैट्रिक्स एपिसेवर्क क्लस्टर पर स्थापित नहीं है

वास्तव में यह निश्चित नहीं है कि विलोपन मेट्रिक्स एपिस सर्विस पर क्यों निर्भर करता है,

@manojbadam क्योंकि

जैसा कि मैं लगातार इसमें भाग रहा था, मैंने इसे एक छोटे शेल स्क्रिप्ट के साथ स्वचालित किया:

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

यह परियोजना को ठीक करता है, JSON को ठीक करता है, शुरू करता है और "कुबेकेल प्रॉक्सी" को ठीक से रोकता है, ...

मुझे सही दिशा में इंगित करने के लिए सभी को धन्यवाद!

जैसा कि मैं लगातार इसमें भाग रहा था, मैंने इसे एक छोटे शेल स्क्रिप्ट के साथ स्वचालित किया:

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

यह परियोजना को ठीक करता है, JSON को ठीक करता है, शुरू करता है और "कुबेकेल प्रॉक्सी" को ठीक से रोकता है, ...

मुझे सही दिशा में इंगित करने के लिए सभी को धन्यवाद!

मेरे हीरो! <3

मैं इस समस्या में भी भाग गया। मैं Google Kubernetes इंजन पर हूं और Kubernetes समूहों को स्पिन करने और क्लस्टर के अंदर नेमस्पेस और पॉड्स बनाने के लिए Terraform का उपयोग कर रहा हूं। terraform destroy चलने के कुछ समय बाद समस्या शुरू हुई।

मेरे मामले में, यह एक मुद्दा है जिसमें टेराफॉर्म विनाश को अंजाम देता है। टेराफॉर्म पहले नोड पूल को हटाता है, और फिर नेमस्पेस और पॉड को हटाता है। लेकिन (केवल) नोड पूल को हटाने के कारण, कुबेरनेट्स क्लस्टर टूट गया, और यही कारण है कि नेमस्पेस विलोपन "हमेशा के लिए" समाप्त हो गया।

@FooBarWidget मेरे लिए एक ही समस्या :(

जैसा कि मैं लगातार इसमें भाग रहा था, मैंने इसे एक छोटे शेल स्क्रिप्ट के साथ स्वचालित किया:

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

यह परियोजना को ठीक करता है, JSON को ठीक करता है, शुरू करता है और "कुबेकेल प्रॉक्सी" को ठीक से रोकता है, ...

मुझे सही दिशा में इंगित करने के लिए सभी को धन्यवाद!

[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 को ठीक करता है, शुरू करता है और "कुबेकेल प्रॉक्सी" को ठीक से रोकता है, ...
मुझे सही दिशा में इंगित करने के लिए सभी को धन्यवाद!

[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 भगवान, समाप्ति नाम स्थान अंत में चला गया है। निम्नलिखित विधि मेरे लिए चाल है।

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

मेरे पास एक ही मुद्दा है लेकिन मुझे कोई मेट्रिक्स-सेवा नहीं दिख रही है।

मैं k8s के साथ digitalocean और gitlab ऑटो डेपॉप्स के साथ खेल रहा हूं। मेरी धारणा कुछ डिजिटल ब्लॉब स्टोरेज है लेकिन मैं इसका विश्लेषण या ठीक करने के तरीके पर हार गया हूं।

@mingxingshi tx एक नाम स्थान संपादित किया जो चाल नहीं किया। आपकी स्क्रिप्ट ने किया।

वाह, आखिरकार इससे छुटकारा मिल गया। कमांड के लिए धन्यवाद @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"
  ...
}

लेकिन मैं एक पतवार newb हूँ और है कि बनाया गया एक नाम स्थान कहा जाता है उस में एक टेम्पलेट था एक टेम्पलेट था servicer । इससे टेराफॉर्म और k8s इस बुरी स्थिति में आ गए जहां टेराफॉर्म विफल हो जाएगा, फिर k8s servicer नेमस्पेस को Terminating राज्य में स्थायी रूप से छोड़ देंगे। @Mingxingshi ने जो सुझाव दिया है उसे करते हुए नेमस्पेस को समाप्त कर दिया, क्योंकि इसमें कोई संसाधन नहीं जुड़े थे।

यह समस्या मेरे लिए तब हो रही है जब मैंने उस टेम्पलेट को हटा दिया, जिसने नाम स्थान बना दिया और इसे बनाने के लिए इसे छोड़ दिया।

मेरे लिए यह समस्या पूरी तरह से दोहराई जा सकती है। सबसे पहले, प्रोमेथियस-ऑपरेटर को क्लोन करें। फिर:

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/ को अनस्टक करने की आवश्यकता है।
मुझे लगता है कि प्रोमेथियस सीआरडी में कुछ फाइनल हैं जो दुर्व्यवहार कर रहे हैं, इस विशेष परिदृश्य में यह शायद ही कभी कुबेरनेट की गलती है। हालाँकि, कुबेरनेट्स को अपराधी को ढूंढना आसान बनाना चाहिए, क्योंकि इस धागे के लैंग्ट यह प्रदर्शित करते हैं कि इसके कई कारण हो सकते हैं और प्रत्येक विशेष परिदृश्य में इसके नीचे तक पहुँचना आसान नहीं है।

मैं एक kubernetes noob हूं, इसलिए मैं यहां बहुत अधिक जानकारी नहीं दे सकता, लेकिन मेरे पास 2 नामस्थान भी हैं जो स्थिति को समाप्त करने में फंस गए हैं। मेरा कुबेरनेट सेटअप IBM क्लाउड प्राइवेट 3.1.2 कम्युनिटी एडिशन का उपयोग कर रहा है

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.

मेरे मामले में नाम स्थान बदनाम है, मेरे लिए 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

@ मेनफोल्डएफआर , मेरे पास आपके जैसा ही मुद्दा था और मैं इसे
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

@ मेनफोल्डएफआर , मेरे पास आपके जैसा ही मुद्दा था और मैं इसे
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 ने पहले ही इसका उल्लेख ऊपर कर दिया था, और @ लिगिट ने एक अन्य गिटहब मुद्दे में भी इसका उल्लेख किया ।

टूटी हुई v1beta1.metrics.k8s.io API सेवा को ठीक करना , या इसे हटा देना बेहतर होगा यदि आपको इसकी आवश्यकता नहीं है।

# 73405 भी देखें

मैं दूसरा @antoineco संदेश। मैंने इसे हमारे सैंडबॉक्स वातावरण में से एक पर परीक्षण किया क्योंकि हम लगातार नाम स्थान प्राप्त कर रहे थे। लगभग एक महीने के बाद सभी डॉकटर डेमॉन बिना किसी कारण के फ्रीज हो गए। पता चलता है कि हमने संसाधनों को पीछे छोड़ने से बहुत बड़ी स्मृति लीक बनाई।

बहुत सारे परीक्षण और त्रुटि के बाद, और इन टिप्पणियों के माध्यम से पढ़कर, यह नामस्थानों के लिए कोरोस ग्राफाना स्टैक के लिए कस्टम संसाधन परिभाषा निकला। सीआरडी को सूचीबद्ध करने से उस नाम स्थान के लिए विशिष्ट संसाधन दिखाई दिए। मैं बहुत भाग्यशाली था कि सीआरडी के नाम में यह नाम स्थान था जो अटक गया था।

यह भी पता चला है कि एक अटक नामस्थान को हटाने के लिए किसी भी अधिक नामस्थान बंद हो जाता है। यहां तक ​​कि अगर आपके पास नाम स्थान A है जिसमें कोई CRD नहीं है, तो यह अटक गया है, और एक नाम स्थान B है, जो कि अटक CRD के साथ है, A के सभी संसाधन B के चले जाने तक इधर-उधर चिपके रहेंगे। मुझे लगता है कि मैंने हर बार चारों ओर संसाधनों का एक टन छोड़ने वाले नामस्थान ए पर ऊपर वर्णित वर्णन किया होगा।

जो चीज अभी भी मुझे मार रही है, वह यह है कि मैं अपने जीवन के लिए किसी भी लॉग का नाम नहीं दे सकता हूं, जिसमें सीआरपी को हटाने पर किसी नेमस्पेस को साफ करने में विफल होने का उल्लेख है, या यहां तक ​​कि वर्तमान में यह क्या कर रहा है। मुझे एक घंटा बिताना था और यह पता लगाना था कि CRD क्या है। अगर किसी को अधिक जानकारी प्राप्त करने के बारे में कोई विचार है, तो मुझे समय की एक बड़ी राशि खर्च करने की ज़रूरत नहीं है जो अटके हुए संसाधन का पता लगाएगा जो कि भयानक होगा।

प्रोडक्शन क्लस्टर्स के लिए @jecafarelli अच्छा संकेत। लेकिन मेरे लिए दुर्भाग्यपूर्ण है, मैं इसे अन्यथा मारने में सक्षम नहीं था। मुझे यह भी पता था कि मैं बाद में पूरे क्लस्टर को फिर से बनाऊंगा।

मैंने इस मुद्दे का विश्लेषण करने की कोशिश की, लेकिन इस सूत्र में नोटिन ने मुझे अन्य माध्यमों से इसे हल करने में मदद की।

इस आधिकारिक समाधान ने मेरी मदद की: https://success.docker.com/article/kubernetes-namespace-stuck-in-terminating
यह kubectl edit namespace rook-ceph के समान नहीं है। हटाए गए _ "फाइनल" "_" के साथ मैं PUT अनुरोध करने तक इस समस्या को हल करने में असमर्थ था

ठीक है तो मैं कोरोस के साथ फिर से इस में भाग गया, और मैंने थोड़ा गहरा खोदा। यह निश्चित रूप से क्लस्टर वाइड रिसोर्स डेफिनिशन की वजह से है जो नाम स्थान पर है, और आगे शायद यह इसे हटा नहीं सकता क्योंकि यह कोरोस के बारे में क्वेरी जानकारी नहीं दे सकता है। मुझे एपीसर्वर लॉग में त्रुटियां मिलीं जो एक एपीआई समूह के बारे में जानकारी प्राप्त करने की कोशिश में त्रुटियों को दिखाती हैं। मैंने ऊपर दिए गए संदर्भित मुद्दे का उपयोग त्वरित स्क्रिप्ट के साथ आने के लिए किया है जो उन संसाधनों को सूचीबद्ध करता है जो मेरे लिए 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 , आपने मुझे मेरे मुद्दे को सही तरीके से हल करने में मदद की ;-)

मैंने प्रमाणित-प्रबंधक नामस्थान के अंदर एक OpenShift क्लस्टर पर प्रमाणपत्र-प्रबंधक स्थापित किया था और जब मैंने इस नाम स्थान को हटाने की कोशिश की, तो यह समाप्त होने की स्थिति में फंस गया। oc delete apiservices v1beta1.admission.certmanager.k8s.io की समस्या को हल करने के लिए लगता है, नाम स्थान चला गया है।

बहुत बहुत धन्यवाद @jecafarelli , आपने मुझे मेरे मुद्दे को सही तरीके से हल करने में मदद की ;-)

मैंने प्रमाणित-प्रबंधक नामस्थान के अंदर एक OpenShift क्लस्टर पर प्रमाणपत्र-प्रबंधक स्थापित किया था और जब मैंने इस नाम स्थान को हटाने की कोशिश की, तो यह समाप्त होने की स्थिति में फंस गया। 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 संस्करण में यह त्रुटि मिली है। यह पूर्ण नियंत्रण के लिए मैन्युअल रूप से स्थापित करने के लक्ष्य के साथ जीके के इस्तियो एडोन को अक्षम करने के बाद हुआ।
यह सबसे लंबा मुद्दा धागा है जिसे मैंने कभी भी पढ़ने के लिए समय लिया है, और मुझे उड़ा दिया गया है कि इस मुद्दे की जड़ में कोई वास्तविक सहमति या प्रजनन कदम नहीं है। ऐसा लगता है कि यह बहुत अलग तरीके से फंस सकता है :(

JSON और कर्ल / प्रॉक्सी विधि ने ऊपर कई बार उल्लेख किया और https://success.docker.com/article/kubernetes-namespace-stuck-in-terminating पर प्रलेखित किया जो मुझे बचा रहा है।

Https://success.docker.com/article/kubernetes-namespace-stuck-in-terminating पर सलाह सक्रिय रूप से हानिकारक है, और इसके परिणामस्वरूप अनाथ संसाधनों को साफ नहीं किया जा सकता है और एक समान नाम वाले नामस्थान को बाद में फिर से बनाया गया है। ।

त्रिशंकु हटाने के विशिष्ट कारण को धरातल पर लाने का काम चल रहा है, लेकिन मूलभूत मुद्दा यह है कि एपीआई प्रकार हैं जिन्हें साफ नहीं किया जा सकता है, इसलिए नामस्थान विलोपन ब्लॉक का सत्यापन होने तक।

हमने इसे चाकू से भी मारा जो इस नामांकित एपिस सर्विस को स्थापित करता है।

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

इसे हटाने के बाद दोनों चाकू से काम करने वाले एनएस और अन्य अटक नामस्थानों का एक गुच्छा साफ हो गया। उपरोक्त बैश स्क्रिप्ट के लिए @jecafarelli का धन्यवाद।
यहां एक भयानक पॉवरशेल संस्करण है।

$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-मशीनरी-विविध

यह बग> वर्ष के लिए अस्तित्व में है और अभी भी एक समस्या है ... इस तरह के इनबाउंड मुद्दों को संबोधित करने के लिए आपकी क्या योजना है?

इससे कम से कम समझने में मदद मिल सकती है कि क्या चल रहा है: 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

नाम स्थान नियंत्रक को नामस्थान स्थिति को रिपोर्ट करना चाहिए और क्लाइंट को रिपोर्ट करना चाहिए। एक केईपी की जरूरत है, लेकिन बहुत सीधा होना चाहिए अगर कोई इसे ले सकता है और इसे मान्य कर सकता है।

@timothysc वहाँ उड़ान (कहीं) में एक पीआर कर @smarterclayton वास्तव में क्या कहते हैं (या था)।

मुझे पूरा यकीन है कि इस बारे में एक और github मुद्दा भी है?

हाँ पीआर यहाँ है: https://github.com/kubernetes/kubernetes/pull/73405

जिस मुद्दे पर मैं विहित मानता हूं, वह यहां है: https://github.com/kubernetes/kubernetes/issues/70x16

यहाँ एक संसाधन है जिसने मेरी मदद की: https://www.ibm.com/support/knowledgecenter/en/SSBS6K_3.1.1/troubleshoot/ns_terminating.html

यह @slassh द्वारा प्रस्तावित समाधान के समान है, लेकिन यह स्थानीय प्रॉक्सी बनाने के लिए kubectl proxy का उपयोग करता है और curl कमांड के लक्ष्य आईपी को पूर्वानुमान योग्य बनाता है।

-

संपादित करें: जैसा कि इस उत्तर के नीचे कई बार कहा गया है, यह समाधान एक गंदा हैक है और संभवतः क्लस्टर में कुछ निर्भर संसाधनों को छोड़ देगा। अपने जोखिम पर उपयोग करें, और संभवतः इसे केवल विकास क्लस्टर में एक त्वरित तरीके के रूप में उपयोग करें (उत्पादन क्लस्टर में इसका उपयोग न करें)।

सीधे अंतिम रूप से हटाने के रूप में ऊपर डॉक्टर में वर्णित परिणाम हो सकते हैं। विलोपन जारी होने के बाद भी जो संसाधन लंबित थे, उन्हें क्लस्टर में परिभाषित किया जाएगा। यह फाइनल का उद्देश्य है। यह सुनिश्चित करने के लिए कि 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
मैं इसे तेजी से हटाने के लिए उपयोग करता हूं और आशा करता हूं कि यह किसी के लिए उपयोगी होगा।

कुबेरनेट्स 1.12.2 नामस्थान समाप्ति की स्थिति में हैं। कभी-कभी फाइनल को ns के yaml को संशोधित करके हटाया जा सकता है। इसे एपीआई द्वारा हटाया नहीं जा सकता। क्या इसे हटाया जा सकता है? परिस्थिति क्या है? क्या हमने विशेष रूप से इसे ट्रैक किया है (पूर्वापेक्षा: इस एनएस में कोई संसाधन नहीं हैं), मुझे आशा है कि मुझे संकेत मिल सकते हैं, धन्यवाद!

फिर से, कृपया अंतिम रूप न निकालें, यह एक कारण के लिए है। इसके बजाय यह जानने की कोशिश करें कि NS में कौन से संसाधन विलोपित हैं:

• यह देखना कि क्या कोई एपिस्सर्व अनुपलब्ध है और इसलिए अपने संसाधनों की सेवा नहीं करता है: kubectl get apiservice|grep False
• सभी संसाधनों को खोजना जो अभी भी kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get -n $your-ns-to-delete (उस एक के लिए जॉर्डन के लिए यश) के माध्यम से मौजूद हैं

इस समस्या का समाधान सफाई तंत्र को शॉर्ट-सर्किट करने के लिए नहीं है, यह पता लगाने के लिए कि क्या सफाई को सफल होने से रोकता है।

फिर से, कृपया अंतिम रूप न निकालें, यह एक कारण के लिए है। इसके बजाय यह जानने की कोशिश करें कि NS में कौन से संसाधन विलोपित हैं:

• यह देखना कि क्या कोई एपिस्सर्व अनुपलब्ध है और इसलिए अपने संसाधनों की सेवा नहीं करता है: kubectl get apiservice|grep False
• सभी संसाधनों को खोजना जो अभी भी kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get -n $your-ns-to-delete (उस एक के लिए जॉर्डन के लिए यश) के माध्यम से मौजूद हैं

इस समस्या का समाधान सफाई तंत्र को शॉर्ट-सर्किट करने के लिए नहीं है, यह पता लगाने के लिए कि क्या सफाई को सफल होने से रोकता है।

आप कितने सही हैं
मेरे मामले में ऑपरेटर फ्रेमवर्क की फली को हटा दिया गया और प्रक्रिया को समाप्त कर दिया गया।
अप्रयुक्त सेवा को हटाना (kubectl apiservice को हटाना) समस्या का हल किया।

हाय सब, कोड फ्रीज बस कुछ ही दिनों (गुरुवार, दिन, पीएसटी) में आ रहा है, इसलिए हमें यह सुनिश्चित करने की आवश्यकता है कि यह समस्या v1.16 के लिए हल हो जाएगी या v1.17 में स्थानांतरित हो जाएगी। क्या आप इस पर टिप्पणी कर सकते हैं?

क्या इसे वर्तमान GKE रिलीज़ में वापस लाया जाएगा? मेरे पास एक क्लस्टर है जिसमें कुछ मुट्ठी भर नामस्थान हैं जो अभी भी "समाप्त" हैं।

@squarelover ऐसा करने के बाद भी? https://github.com/kubernetes/kubernetes/issues/60807#issuecomment -550772920

@josiahbjorgaard मैंने अभी पीआर को मंजूरी दी है, जो कि हम 1.16 पर कर रहे हैं।

https://github.com/kubernetes/kubernetes/pull/73405 पूर्वोक्त पीआर है

यह विलय हो गया है। मुझे लगता है कि हम और भी कुछ कर सकते हैं, लेकिन कृपया भविष्य की टिप्पणी # 70916 पर लें।

फिर से, कृपया अंतिम रूप न निकालें, यह एक कारण के लिए है। इसके बजाय यह जानने की कोशिश करें कि NS में कौन से संसाधन विलोपित हैं:

• यह देखना कि क्या कोई एपिस्सर्व अनुपलब्ध है और इसलिए अपने संसाधनों की सेवा नहीं करता है: kubectl get apiservice|grep False
• सभी संसाधनों को खोजना जो अभी भी kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get -n $your-ns-to-delete (उस एक के लिए जॉर्डन के लिए यश) के माध्यम से मौजूद हैं

इस समस्या का समाधान सफाई तंत्र को शॉर्ट-सर्किट करने के लिए नहीं है, यह पता लगाने के लिए कि क्या सफाई को सफल होने से रोकता है।

कई मामलों में आपके पास मीट्रिक-सर्वर स्थापित हो सकता है। जब आप एक विशिष्ट नामस्थान में तैनात पॉड्स मैट्रिक सभा के लिए देखते हैं। यह मीट्रिक-सर्वर से लटका रहता है। तो आपके द्वारा उस नाम स्थान के सभी संसाधनों को हटाने के बाद भी, मीट्रिक-सर्वर किसी न किसी तरह उस नामस्थान से जुड़ा होता है। जो आपको नामस्थान को हटाने से रोकेगा।
यह पोस्ट आपको इस कारण की पहचान करने में मदद करती है कि आप नेमस्पेस को क्यों नहीं हटा सकते। तो संस्कार तरीका है।

अपने नाम स्थान की सभी चीज़ों की वास्तविक सूची प्राप्त करने के लिए इसे आज़माएँ: kubernetes / kubectl # 151 (टिप्पणी)

फिर प्रत्येक ऑब्जेक्ट के लिए फाइनली निकालने के लिए kubectl delete या kubectl edit करते हैं।

यह समाधान मेरे लिए उपयोगी है, धन्यवाद।

हाय दोस्तों,

मैंने समाप्ति की स्थिति में आसान हटाए गए नामस्थान बनाने के लिए एक स्क्रिप्ट बनाई: https://github.com/thyarles/knsk।

धन्यवाद।

हम एक ही मुद्दे के साथ मिले थे, जब एक नाम स्थान को हटाते हुए, यह 'समाप्त' स्थिति में फंस जाएगा। मैंने yaml फ़ाइल में अंतिम रूप में 'कुबेरनेट्स' को हटाने के लिए ऊपर दिए गए स्टैप्स का पालन किया। यह काम करता हैं।

हालाँकि, हमें नहीं पता कि हमें अतिरिक्त कदम उठाने की आवश्यकता क्यों है। यह kubectl ns foonamespace को डिलीट करना चाहिए और इसे डिलीट करना चाहिए। क्या कोई मुझे कारण दे सकता है? धन्यवाद!

हैलो @ xzhang007 ,

यदि आपको पता है कि नाम स्थान विलोपन समाप्त होने की स्थिति में क्यों अटक गया है, तो कृपया मुझे बताएं। मैंने कुछ समय के लिए एक अच्छा जवाब देने की कोशिश की, लेकिन कुछ भी नहीं। तब मैंने अपने जीवन को आसान बनाने के लिए एक स्क्रिप्ट बनाई जब तक खोज और कारण को ठीक नहीं किया।

धन्यवाद।

@ यह लगता है कि मुझे अब तक कोई जवाब नहीं मिला।

हमारे मामले में हमें पता चला कि वेबहॉक और फाइनल में से एक हम थे
उपयोग एक फली तक पहुंच रहा था जो कि प्राप्त नामस्थानों में रह रही थी
नष्ट कर दिया।
एक बार फली हटने के बाद, समाप्ति अटक गई।

>

@ xzhang007 आपने @alvaroaleman द्वारा गौर किया है? हमारे लिए यह जानने के लिए पर्याप्त था कि इसका कारण क्या था।

फिर से, कृपया अंतिम रूप न निकालें, यह एक कारण के लिए है। इसके बजाय यह जानने की कोशिश करें कि NS में कौन से संसाधन विलोपित हैं:

• यह देखना कि क्या कोई एपिस्सर्व अनुपलब्ध है और इसलिए अपने संसाधनों की सेवा नहीं करता है: kubectl get apiservice|grep False
• सभी संसाधनों को खोजना जो अभी भी kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get -n $your-ns-to-delete (उस एक के लिए जॉर्डन के लिए यश) के माध्यम से मौजूद हैं

इस समस्या का समाधान सफाई तंत्र को शॉर्ट-सर्किट करने के लिए नहीं है, यह पता लगाने के लिए कि क्या सफाई को सफल होने से रोकता है।

यह भी, जब यह मुद्दा बंद हो गया था, तो इस बात पर चर्चा करने के लिए एक नया टिकट था कि यह कैसे स्पष्ट किया जाए कि नाम समाप्ति में क्यों अटक गया है। मेरा सुझाव है कि आप इस बंद मुद्दे के बजाय वहां बातचीत करें।

यह विलय हो गया है। मुझे लगता है कि हम और भी कुछ कर सकते हैं, लेकिन कृपया भविष्य की टिप्पणी # 70916 पर लें।

@ jeff-knurek यह सही तरीका होना चाहिए। धन्यवाद।

हमारे मामले में यह cert-manager का एक उन्नत उन्नयन था जिसने अंतिम रूप दिया। https://github.com/jetstack/cert-manager/issues/1582

$ kube get apiservice

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

नमस्ते।
जब मैं https://github.com/rancher/rancher/issues/21546#issuecomment -553635629

शायद यह मदद करेगा।

https ://मीडिया

यह मेरे लिए एक विजेता की तरह काम करता था

मैंने भी उसी मुद्दे का सामना किया जो अब मेरे लिए ठीक काम कर रहा है। कृपया निम्नलिखित दस्तावेज़ देखें और अपनी समस्या को हल करें

@zerkms अच्छी तरह से, कभी-कभी, यह एक वैध सलाह है, है ना? अक्सर अंतिम रूप से प्रतीक्षा की जा रही वस्तुओं को नामस्थान विलोपन के हिस्से के रूप में हटा दिया जाता था। इस मामले में, चूंकि अब और इंतजार करने का कोई मतलब नहीं है - ऐसा कुछ भी नहीं है जो किसी भी तरह से अंतिम रूप दे सकता है - वस्तुओं को पैच करना जिस तरह से लेख का वर्णन _is एकमात्र विकल्प_ है।

ध्यान दें कि लेख केवल तभी लागू होता है, जब समस्या _was हल नहीं होती है_ ज्ञात मुद्दे पृष्ठ में सूचीबद्ध चरणों को लागू करने से, लेख के शीर्ष पर जुड़ा हुआ है, जो मूल रूप से सलाह है कि टिप्पणी जो आपने दोहराई है।

@zerkms अच्छी तरह से, कभी-कभी, यह एक वैध सलाह है, है ना? अक्सर अंतिम रूप से प्रतीक्षा की जा रही वस्तुओं को नामस्थान विलोपन के भाग के रूप में हटा दिया जाता था

मैंने कभी नहीं देखा है कि किसी नेमस्पेस पर एक spec.finalizer के लिए सच हो। मेरे द्वारा देखे गए हर उदाहरण में नेमस्पेस क्लीनअप कंट्रोलर शामिल है, और या तो नेमस्पेस में एक स्थायी वस्तु के कारण होता है (जो कि सलाह आदि में फंसेगा), या एक गैर-समेकित एपीआई (जो नेमस्पेस स्पेस को हटा रहा है। फाइनेलाइज़र को छोड़ देगा प्रतीक्षा कर रहा है, उस एपीआई से किसी भी निरंतर संसाधनों को फंसे हुए)

लेख यह चेतावनी नहीं देता है कि नामस्थान के अंतिमकरण के जोखिम को दरकिनार करते हुए, भंडारण में फंसे नामस्थान संसाधनों को छोड़ दिया जाता है, और इसकी अनुशंसा नहीं की जाती है।

मैंने कभी नहीं देखा है कि किसी नेमस्पेस पर एक spec.finalizer के लिए सच हो

हां, यह सही है, यह निर्णायक है यह कुबेरनेट्स द्वारा ही कार्यान्वित किया जाता है, लेकिन उस नामस्थान के अंदर की वस्तुओं पर अन्य अंतिम रूप हो सकते हैं, जिसे उस नामस्थान में ऑब्जेक्ट द्वारा कार्यान्वित किया जा सकता है। एक उदाहरण जो मुझे हाल ही में मिला था, वह https://appscode.com/products/stash/ ।

यह अपने कुछ CRD पर फाइनल डालता है जो कि स्टैश-ऑपरेटर की तैनाती द्वारा सेवित किए जाते हैं। लेकिन पहले से हटाए गए स्टैश-ऑपरेटर के साथ, ऐसा कुछ भी नहीं है जो उन CRDs से अंतिम निशान को हटा सकता है और नाम स्थान विलोपन अटक जाता है। इस मामले में उन फाइनलर्स (खुद नामस्थान पर नहीं, बल्कि उन वस्तुओं पर) को पैच करना ही एकमात्र समझदारी वाली बात है।

आशा है कि यह समझ में आता है।

इस मामले में उन फाइनलर्स (खुद नामस्थान पर नहीं, बल्कि उन वस्तुओं पर) को पैच करना ही एकमात्र समझदारी वाली बात है।

सही बात। मुझे इस बात पर आपत्ति नहीं होगी कि "सभी संसाधनों को हटाएं" क्लीनअप परिदृश्य, लेकिन यह नहीं है कि लिंक किए गए लेख के माध्यम से क्या चलता है ... यह बताता है कि नामस्थान से एक spec.finalizer कैसे निकालना है।

पहले, छोटी कॉफ़ी लें और आराम करें, अब अपने k8s मास्टर नोड्स पर जाएँ

kubectl क्लस्टर-जानकारी
कुबेरनेट्स मास्टर https: // localhost : 6443 पर चल रहा है
KubeDNS https: // localhost : 6443 / api / v1 / namespaces / kube-system / services / kube- dns: dns / xy पर चल रहा है
क्लस्टर समस्याओं के लिए आगे डीबग और निदान करने के लिए, 'kubectl क्लस्टर-जानकारी डंप' का उपयोग करें।

अब क्यूब-प्रॉक्सी चलाएं
kubectl प्रॉक्सी और
127.0.0.1:8001 पर सेवा शुरू करना
बाद में इसे हटाने के लिए आईडी सहेजें :)

1. अपना नाम-स्थान खोजें जिसने तय किया है कि हटाए नहीं जाने की :) हमारे लिए यह पशु-प्रणाली होगी
   kubectl ns मिलता है
   मवेशी-व्यवस्था समाप्त 1 डी

इसे फाइल में डालें

1. kubectl को namepace मवेशी-सिस्टम -o json> tmp.json मिलता है

फ़ाइल को संपादित करें और फाइनल को हटा दें
},
"कल्पना": {
"फाइनल": [
"Kubernetes"
]
},
संपादन के बाद यह इस तरह दिखना चाहिए like
},
"कल्पना": {
"फाइनल": [
]
},
हम लगभग वहाँ 👍
curl -k -H "सामग्री-प्रकार: अनुप्रयोग / json" -X PUT --data- बाइनरी @ tmp.json http://127.0.0.1 : 8001 / एपीआई / v1 / नामस्थान / $ {NAMESPAD} / अंतिम रूप

और यह 👍 चला गया है

फिर से, कृपया अंतिम रूप न निकालें, यह एक कारण के लिए है। इसके बजाय यह जानने की कोशिश करें कि NS में कौन से संसाधन विलोपित हैं:

• यह देखना कि क्या कोई एपिस्सर्व अनुपलब्ध है और इसलिए अपने संसाधनों की सेवा नहीं करता है: kubectl get apiservice|grep False
• सभी संसाधनों को खोजना जो अभी भी kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get -n $your-ns-to-delete (उस एक के लिए जॉर्डन के लिए यश) के माध्यम से मौजूद हैं

इस समस्या का समाधान सफाई तंत्र को शॉर्ट-सर्किट करने के लिए नहीं है, यह पता लगाने के लिए कि क्या सफाई को सफल होने से रोकता है।

हे लोगों! मैं @alvaroaleman द्वारा प्रदान की गई युक्तियों का पालन करता अटक नाम स्थान का एक कठिन विलोपन करने से पहले निरीक्षण और

स्क्रिप्ट https://github.com/thyarles/knsk क्या करें:

1. अनुपलब्ध apiresources की जाँच करें और इसे हटाने के लिए कहें
2. नाम स्थान में लंबित संसाधनों की जाँच करें और इसे हटाने के लिए कहें
3. स्क्रिप्ट के किसी भी विलोपन को देखने के लिए कुबेरनेट्स एक स्पष्ट विलोपन करते हैं या नहीं यह देखने के लिए लगभग 5 मिनट प्रतीक्षा करें
4. अटक नाम स्थान का बल विलोपन

आशा है कि इससे सहायता मिलेगी।

@thyarles आपका बहुत-बहुत धन्यवाद। मैंने समस्या को हल करने के लिए आपके तरीके का इस्तेमाल किया।

$ kubectl को यह जांचने के लिए एपिसिस मिलता है कि कौन सी सेवा अनुपलब्ध है, जो उपलब्ध हैं उन्हें हटा दें $ kubectl द्वारा apiservice [सेवा-नाम] को हटा दें, और उसके बाद नाम स्थान को हटाने के बारे में कोई समस्या नहीं होगी।

हमारी टीम के लिए, 3 उपलब्ध अनुपलब्धताएँ हैं, v1beta1.admission.certmanager.k8s.io, v1beta1.metrics.k8s.io, और v1beta1.webhook.certmanager.k8s.io।

ध्यान दें कि यदि आपका एपर्चर चल नहीं रहा है, तो आपका क्लस्टर कुछ हद तक टूट गया है, बस APIService को हटाने से वास्तव में मूल कारण ठीक नहीं होता है।

@ मेटालैम्प मेट्रिक्स एक अनुपलब्ध एपिसिसवर्क है।

हां, जिसका अर्थ है कि मैट्रिक्स एप्रिसवर नहीं चल रहा है, जिसका अर्थ है कि एचपीए आपके क्लस्टर पर काम नहीं करता है, और शायद अन्य चीजें भी।

हाँ। एचपीए अब काम नहीं करता है। मुझे मैट्रिक्स को नहीं हटाना चाहिए और इसे ठीक करने का तरीका खोजना चाहिए।

@thyarles आपका बहुत-बहुत धन्यवाद। मैंने समस्या को हल करने के लिए आपके तरीके का इस्तेमाल किया।

$ kubectl को यह जांचने के लिए एपिसिस मिलता है कि कौन सी सेवा अनुपलब्ध है, जो उपलब्ध हैं उन्हें हटा दें $ kubectl द्वारा apiservice [सेवा-नाम] को हटा दें, और उसके बाद नाम स्थान को हटाने के बारे में कोई समस्या नहीं होगी।

हमारी टीम के लिए, 3 उपलब्ध अनुपलब्धताएँ हैं, v1beta1.admission.certmanager.k8s.io, v1beta1.metrics.k8s.io, और v1beta1.webhook.certmanager.k8s.io।

@ xzhang007 सुनकर खुशी हुई! अब आपको जांचना चाहिए कि आपका v1beta1.metrics.k8s.io क्यों टूट गया। जांचें कि यह कैसा होगा:

`` `
$ kubectl -n kube-system सब मिलता है | grep मेट्रिक्स

पॉड / मेट्रिक्स-सर्वर -64 एफ74 एफ 8 डी 47-आर 5 पीवीसीक्यू 2/2 रनिंग 9 119 डी
सेवा / मैट्रिक्स-सर्वर ClusterIP xx.xx.xx.xx443 / टीसीपी 201 डी
परिनियोजन .app / मेट्रिक्स-सर्वर 1/1 1 1 201 डी
replicaset.apps / मेट्रिक्स-सर्वर -55 c7f68d94 0 0 0 165d
replicaset.apps / मेट्रिक्स-सर्वर -5c696bb6d7 0 0 0 201 डी
replicaset.apps / मेट्रिक्स-सर्वर-5cdb8bb4fb 0 0 0 201 डी
replicaset.apps / मेट्रिक्स-सर्वर -64f74f8d47 1 1 1 119 डी
replicaset.apps / मेट्रिक्स-सर्वर -686789bb4b 0 0 0 145d```

$ kubectl -n kube-system सब मिलता है | grep मेट्रिक्स

फली / मेट्रिक्स-सर्वर -5dcfd4dd9f-m2v9k 1/1 रनिंग 0 2d20h

सेवा / मैट्रिक्स-सर्वर ClusterIP xx.xx.xx.xx443 / टीसीपी 27 डी

परिनियोजन .apps / मेट्रिक्स-सर्वर 1/1 1 1 27 डी

replicaset.apps / मेट्रिक्स-सर्वर -5dcfd4dd9f 1 1 1 27 डी
replicaset.apps / मेट्रिक्स-सर्वर -7fcf9cc98b 0 0 0 27 डी

हाँ। एचपीए अब काम नहीं करता है। मुझे मैट्रिक्स को नहीं हटाना चाहिए और इसे ठीक करने का तरीका खोजना चाहिए।

@ xzhang007 वास्तव में आपके द्वारा समस्या पर ध्यान दिए जाने से पहले यह काम नहीं करता है .... आपने सिर्फ इसलिए गौर किया क्योंकि इसने आपके हटाए गए नामस्थानों को अटक मोड में डाल दिया। अपने मीट्रिक-सर्वर को पुन: परिनियोजित करने के लिए एक हेल्म पैकेज प्रबंधक का उपयोग करें या इसे ठीक करने के लिए केवल कमांड बलो को कॉल करें ( लागू होने से पहले तैनाती फ़ाइल की जांच करें ):

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

@ तालश समाधान ने कुबेरनेट्स 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 proxy प्रक्रिया नहीं अपनानी पड़ेगी और curl साथ निर्भरता से बचना होगा (कि कुछ वातावरण में जैसे कि बिजीबॉक्स उपलब्ध नहीं है)। इस उम्मीद में कि यह किसी और को मेरी मदद करेगा जो मैंने यहां छोड़ दिया:

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 समूह अनुपलब्ध है। यह जानबूझकर है कि सभी एपीआई उपलब्ध होने तक नेमस्पेस क्लीनअप कंट्रोलर ब्लॉक, ताकि यह सत्यापित कर सके कि सभी एपीआई समूहों से सभी संसाधन उस नाम स्थान के लिए साफ किए गए हैं।

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

यहां स्वचालित रूप से ऐसा करने के लिए एक स्क्रिप्ट है। 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

हर कोई: अंतिम हटाने को स्वचालित करने के लिए स्क्रिप्ट अच्छे से अधिक नुकसान करती है । वे उपलब्ध एफ़िसर (ओं) में समय-बम छोड़ सकते हैं जो उपलब्ध नहीं हैं; यदि कोई नामस्थान को पुन: बनाता है, तो अचानक पुरानी वस्तुओं का एक गुच्छा फिर से प्रकट हो सकता है।

वास्तविक समाधान है:

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

हर कोई: अंतिम हटाने को स्वचालित करने के लिए स्क्रिप्ट अच्छे से अधिक नुकसान करती है । वे उपलब्ध एफ़िसर (ओं) में समय-बम छोड़ सकते हैं जो उपलब्ध नहीं हैं; यदि कोई नामस्थान को पुन: बनाता है, तो अचानक पुरानी वस्तुओं का एक गुच्छा फिर से प्रकट हो सकता है।

वास्तविक समाधान है:

$ 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 विकल्प प्रदान करता है।

टाइपो, एपिसिस होना चाहिए

यह आदेश उपलब्ध नहीं दिखाता है:

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

वास्तव में जो मौजूद है वह एपिसिस में एक संघर्ष है, वे ओपनशीट में एपिस के स्वास्थ्य की स्थिति को मान्य कर सकते हैं:

oc को apiservices -o = कस्टम-कॉलम = " नाम: .metadata.name , स्थिति: .status.conditions [0] .status"

एपीआई जो विफल रहता है, उसे फिर से शुरू करने की आवश्यकता होगी, पॉड को फिर से शुरू करना या उस एपीआई से संबंधित प्रतिगमन, इसके बाद नाम स्थान को हटाने का प्रयास करें।

$ महासागर नेमस्पेस को हटा दें

और तैयार, व्यापार तय !!

अपनी भाषा का उपयोग करने के लिए बहुत अपमानजनक जगह है जहाँ हर कोई अंग्रेजी बोलने के लिए सहमत है। 👎

हर कोई अंग्रेजी बोलने के लिए कहाँ सहमत है?

Thu पर, अप्रैल 30, 2020 को 17:58 बजे TheAkito सूचनाएं @github.com ने लिखा:

अपनी भाषा का उपयोग करने के लिए बहुत अपमानजनक जगह है जहाँ हर कोई
अंग्रेजी बोलने के लिए सहमत है। 👎

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की है।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/60807#issuecomment-622137770 ,
या सदस्यता समाप्त करें
https://github.com/notifications/unsubscribe-auth/ALGMKB6K4OU4X3XOYMALOBLRPHYCDANCNFSM4ETUOEPA
।

>

क्रिस, लीड आर्किटेक्ट @ brace.ai

-

गोपनीयता सूचना: यह ईमेल एकमात्र उपयोग के लिए है
इच्छित प्राप्तकर्ता (ओं) और गोपनीय, मालिकाना या हो सकता है
विशेषाधिकार प्राप्त जानकारी। यदि आप इच्छित प्राप्तकर्ता नहीं हैं, तो आप हैं
अधिसूचित किया गया है कि किसी भी उपयोग, समीक्षा, प्रसार, नकल या आधारित कार्रवाई
इस संदेश या इसके अनुलग्नकों पर, यदि कोई हो, निषिद्ध है। यदि आप नहीं हैं
इच्छित प्राप्तकर्ता, कृपया उत्तर ईमेल द्वारा प्रेषक से संपर्क करें और
मूल संदेश और किसी भी अनुलग्नक की सभी प्रतियां नष्ट या हटा दें।

तैयार, मुझे माफ करना यह मेरी गति के लिए था, यह तय हो गया था

हमारे पास एक बहुभाषी उपयोगकर्ता आधार है, यह काफी खराब है कि हमारे किसी भी उपकरण का अंतर्राष्ट्रीयकरण नहीं किया गया है, हम कम से कम यहाँ जीथब पर अच्छा कर सकते हैं, कृपया।

@teoincontatto

जैसा कि इस अंक में पहले उल्लेख किया गया है कि कुबेकेल के आधुनिक संस्करण का उपयोग करके कुबेकेल द्वारा उजागर नहीं किए गए एपीआई का उपयोग करते हुए नाम स्थान को समाप्त करने का एक और तरीका है जहां kubectl replace --raw उपलब्ध है (जो कि संस्करण से निश्चित नहीं है)। इस तरह से आपको kubectl proxy प्रक्रिया नहीं अपनानी पड़ेगी और curl साथ निर्भरता से बचना होगा (कि कुछ वातावरण में जैसे कि बिजीबॉक्स उपलब्ध नहीं है)। इस उम्मीद में कि यह किसी और को मेरी मदद करेगा जो मैंने यहां छोड़ दिया:

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

यह पूरी तरह से काम किया!

हमारे पास एक बहुभाषी उपयोगकर्ता आधार है, यह काफी खराब है कि हमारे किसी भी उपकरण का अंतर्राष्ट्रीयकरण नहीं किया गया है, हम कम से कम यहाँ जीथब पर अच्छा कर सकते हैं, कृपया।

हमारे पास एक बहुभाषी उपयोगकर्ता आधार है, यह काफी खराब है कि हमारे किसी भी उपकरण का अंतर्राष्ट्रीयकरण नहीं किया गया है, हम कम से कम यहाँ जीथब पर अच्छा कर सकते हैं, कृपया।

फिर भी समझने की कोशिश कर रहा हूं। मुझे माफ़ करदो। मैंने गलती से अंगूठे क्लिक कर दिए होंगे।
हां, वास्तव में, उपकरण पूर्णता के लिए नहीं किए गए हैं।
वे, जो एक स्पष्टीकरण के बिना एक अंगूठे को दे रहे हैं, कोई मतलब नहीं है।

लगभग हर समय मैं इस मुद्दे का अनुभव करता हूं, यह सीआरडी पर निर्भर है। CRD को हटा दें यदि उनका उपयोग केवल उस नामस्थान में किया जाता है और फिर आप अंतिम नाम और नाम स्थान को हटाकर आगे बढ़ सकते हैं।

जैसा कि इस अंक में पहले उल्लेख किया गया है कि कुबेकेल के आधुनिक संस्करण का उपयोग करके कुबेकेल द्वारा उजागर नहीं किए गए एपीआई का उपयोग करते हुए नाम स्थान को समाप्त करने का एक और तरीका है जहां kubectl replace --raw उपलब्ध है (जो कि संस्करण से निश्चित नहीं है)। इस तरह से आपको kubectl proxy प्रक्रिया नहीं अपनानी पड़ेगी और curl साथ निर्भरता से बचना होगा (कि कुछ वातावरण में जैसे कि बिजीबॉक्स उपलब्ध नहीं है)। इस उम्मीद में कि यह किसी और को मेरी मदद करेगा जो मैंने यहां छोड़ दिया:

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

पैर के मुद्दे में इस कांटे के संपर्क में आने से हमें और अधिक कैसे मिलेगा?

शुक्र पर, 19 जून, 2020 को सुबह 4:46 बजे एंड्रियास हुमैन नोटिफिकेशन @github.com
लिखा था:

हम्म ... मुझे अभी यह समस्या है :)
आज मैंने 1.15 से 1.16 तक अपने eks क्लस्टर का अपडेट किया।
सब कुछ अब तक ठीक लग रहा है।
लेकिन मेरा विकास ns "configcluster" एक प्रकार का "डैमेज्ड" था।
इसलिए मैं इसे साफ करने का फैसला करता हूं।

k हटाना ns configcluster
....
अब यह लटका हुआ है (3h +): /

$ kubectl को नाम स्थान विन्यास -o yaml मिलता है
एपीवर्सन: v1
तरह: नामस्थान
मेटाडाटा:
एनोटेशन:
kubectl.kubernetes.io/last-applied-configuration: |
{ "ApiVersion": "v1" "प्रकार": "नाम स्थान", "मेटाडाटा": { "एनोटेशन": {}, "नाम": "configcluster"}}
सृष्टिप्रमाण: "2020-06-19T06: 40: 15Z"
डिलीटमेंटस्टैम्प: "2020-06-19T09: 19: 16Z"
नाम: configcluster
संसाधन विचलन: "22598109"
selfLink: / api / v1 / namespaces / configcluster
uid: e50f0b53-b21e-4e6e-8946-c0a0803f00b
कल्पना:
finalizers:

• Kubernetes
  स्थिति:
  शर्तेँ:
• lastTransitionTime: "2020-06-19T09: 19: 21Z"
  संदेश: 'कुछ समूहों के लिए डिस्कवरी विफल रही, 1 असफल: को पुनर्प्राप्त करने में असमर्थ
  सर्वर API की पूरी सूची: metrics.k8s.io/v1beta1: सर्वर वर्तमान में है
  अनुरोध को संभालने में असमर्थ '
  कारण: डिस्कवरी
  स्थिति: "सत्य"
  प्रकार: NamespaceDeletionDiscoveryFailure
• lastTransitionTime: "2020-06-19T09: 19: 22Z"
  संदेश: सभी लीगेसी क्यूब प्रकार सफलतापूर्वक पार्स किए गए
  कारण: ParsedGroupVersions
  स्थिति: "गलत"
  प्रकार: NamespaceDeletionGroupVersionParsingFailure
• lastTransitionTime: "2020-06-19T09: 19: 22Z"
  संदेश: सभी सामग्री सफलतापूर्वक हटा दी गई
  कारण: ContentDeleted
  स्थिति: "गलत"
  प्रकार: NamespaceDeletionContentFailure
  चरण: समाप्ति

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की है।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/60807#issuecomment-646543073 ,
या सदस्यता समाप्त करें
https://github.com/notifications/unsubscribe-auth/AFLKRCLHIZ77X2Z3F5GAOCTRXMXVTANCNFSM4ETUOEPA
।

@bobhenkel अच्छी तरह से यह मुद्दा बंद है, इसलिए प्रभावी रूप से इसका मतलब है कि कोई मुद्दा नहीं है (जहां तक ​​किसी भी कार्रवाई योग्य वस्तुओं का संबंध है)। यदि आपको एक समान स्थिति से निपटने के लिए व्यावहारिक सहायता की आवश्यकता है, तो कृपया ऊपर दिए गए थ्रेड को पढ़ें, वहां सलाह के कुछ अच्छे टुकड़े हैं (और कुछ खराब भी)।

मेरे मामले में, मुझे GCP नेटवर्क सेवा कंसोल से अपने इनग्रेस लोड बैलेंसर को मैन्युअल रूप से हटाना पड़ा। मैंने मैन्युअल रूप से कंसोल में लोड बैलेंसर फ्रंटेंड को मैन्युअल रूप से बनाया था। एक बार जब मैंने लोड बैलेंसर को हटा दिया तो नाम स्थान स्वचालित रूप से हटा दिया गया था।

मुझे संदेह है कि कुबेरनेट्स को हटाना नहीं चाहिए था क्योंकि लोड बैलेंसर की स्थिति प्रकट में राज्य की तुलना में अलग थी।

मैं यह देखने के लिए कि क्या मैं इस मुद्दे को हल कर सकता हूं, यह देखने के लिए कि एनोटेशन का उपयोग करके इनग्रेन्ड फ्रंटेंड क्रिएशन को स्वचालित करने की कोशिश करेंगे।

कभी-कभी केवल संसाधन प्रकट को संपादित करें ऑनलाइन बहुत अच्छी तरह से काम नहीं करेगा (मेरा मतलब है कि 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 "कंटेंट-टाइप: एप्लीकेशन / जसन" -X PUT --data- बाइनरी @ tmp.json https: // kubernetes-क्लस्टर-आईपी / एपी / v1 / नेमस्पेस / कष्टप्रद-नेमस्पेस-टू-डिलीट / को अंतिम रूप देने

बेहतर https://stackoverflow.com/a/59667608/429476

यह वास्तव में "स्वीकृत" उत्तर होना चाहिए - इसने इस मुद्दे की जड़ को पूरी तरह से हल कर दिया है!

उपरोक्त लिंक से लें:

यह सही तरीका नहीं है, खासकर उत्पादन के माहौल में।

आज मैं उसी समस्या में पड़ गया। फाइनल को हटाकर आप विभिन्न राज्यों में बचे हुए को समाप्त करेंगे। आपको वास्तव में यह पता लगाना चाहिए कि विलोपन को पूर्ण से क्या रखा जा रहा है।

Https://github.com/kubernetes/kubernetes/issues/60807#issuecomment -524772920 देखें

(यह भी, दुर्भाग्य से, 'कुबेटक्टेल गेट ऑल' सभी चीजों की रिपोर्ट नहीं करता है, आपको लिंक में समान कमांड का उपयोग करने की आवश्यकता है)

मेरा मामला - 'प्रमाणित-प्रबंधक' नामस्थान को हटाना। 'Kubectl get apiservice -o yaml' के आउटपुट में मैंने APIService 'v1beta1.admission.certmanager.k8s.io' को स्टेटस = गलत के साथ पाया। यह एपिसेवा सर्टिफिकेट-मैनेजर का हिस्सा था, जिसे मैंने अभी डिलीट किया था। इसलिए, 10 सेकंड के बाद मैंने 'kubectl delete apiservice v1beta1.admission.certmanager.k8s.io' नाम दिया, नाम गायब हो गया।

उम्मीद है की वो मदद करदे।

इसके साथ ही कहा जा रहा है, मैंने हर घंटे CronJob के रूप में चलाने के लिए एक छोटा सा माइक्रोसेवा लिखा था जो स्वचालित रूप से समाप्ति नामस्थान हटाता है।

आप इसे यहाँ पा सकते हैं: https://github.com/oze4/service.remove-terminating-namespaces

मैंने हर घंटे 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

लेकिन अटके हुए नेमस्पेस को हटाना एक अच्छा उपाय नहीं है। सही तरीका यह पता लगाना है कि यह क्यों अटका हुआ है। बहुत ही सामान्य कारण एक अनुपलब्ध एपीआई सेवा है जो क्लस्टर को नामस्थान को अंतिम रूप देने से रोकती है।
यहाँ उदाहरण के लिए मैंने चाकू को ठीक से नहीं हटाया है:

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

इसे हटाने से समस्या हल हो गई

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

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

मैंने हर घंटे CronJob के रूप में चलाने के लिए एक छोटा सा माइक्रोसेवा लिखा था जो स्वचालित रूप से समाप्ति नामस्थान हटाता है।

आप इसे यहाँ पा सकते हैं: https://github.com/oze4/service.remove-terminating-namespaces

बहुत बढ़िया।

मैं एक प्रयोगशाला k8s क्लस्टर में 1.18 पर एक समान मुद्दा था और शायद दूसरों की मदद करने के लिए एक नोट जोड़ रहा था। मैं मेट्रिक्स एपीआई और विशेष रूप से कस्टम मेट्रिक्स के साथ काम कर रहा था। इसे पुनः बनाने के लिए उन k8 ऑब्जेक्ट्स को हटाने के बाद, यह एक त्रुटि के साथ नामस्थान को हटाने पर रोक दिया गया कि मेट्रिक्स एपी एंडपॉइंट नहीं मिल सका। एक और नेमस्पेस पर वापस डाल दिया, सब कुछ तुरंत मंजूरी दे दी।

यह स्थिति के अंतर्गत नामस्थान में था।

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

लेकिन अटके हुए नेमस्पेस को हटाना एक अच्छा उपाय नहीं है। सही तरीका यह पता लगाना है कि यह क्यों अटका हुआ है। बहुत ही सामान्य कारण एक अनुपलब्ध एपीआई सेवा है जो क्लस्टर को नामस्थान को अंतिम रूप देने से रोकती है।
यहाँ उदाहरण के लिए मैंने चाकू को ठीक से नहीं हटाया है:

$ 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  

निश्चित रूप से सबसे साफ एक लाइनर! यह ध्यान रखना महत्वपूर्ण है कि इनमें से कोई भी "समाधान" वास्तव में मूल मुद्दे को हल नहीं करता है।

सही समाधान के लिए यहां देखें

यह संदेश फैलाना चाहिए: मुस्कान: "अभी तक एक और एक लाइनर" नहीं।

ईमानदारी से एक लाइनर सबसे साफ! यह ध्यान रखना महत्वपूर्ण है कि इनमें से कोई भी "समाधान" वास्तव में मूल मुद्दे को हल नहीं करता है।

यह समाधान सभी संभावनाओं में से एक को हल करता है। सभी संभावित मूल कारणों की तलाश करने और उन्हें ठीक करने के लिए, मैं इस स्क्रिप्ट का उपयोग करता हूं: https://github.com/thyarles/knsk

@ बहुत अच्छा!

कृपया नामस्थान को हटाने के लिए modify finalize का उपयोग न करें। जिसके कारण त्रुटि होगी

कृपया नाम स्थान समाप्ति का कारण पता करें। वर्तमान में ज्ञात समस्या निवारण दिशा-निर्देश

• फली समाप्त करना
• प्रमाणित-प्रबंधक 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

यह मेरे लिए काम करता है, और मैं सत्यापित करने के बाद भाग गया कि एनएस में कोई झूलने वाले k8 ऑब्जेक्ट नहीं थे। धन्यवाद!

मैंने टर्मिनेटेड नाम से अटके एक नामस्थान को हटाने के लिए इसका इस्तेमाल किया

उदाहरण :

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

सभी गोगलर्स के लिए जो रैंचर विशिष्ट नामस्थान (जैसे मवेशी-प्रणाली) पर समाप्त होने पर अटक नामस्थानों में टकराए थे, मेरे लिए निम्न संशोधित कमांड (ग्रीबोइस मूल) ने काम किया:

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

फोल्क्स , सिर्फ FYI, जब इस जुड़ी कुछ उपयोगी टिप्पणियों से लिंक करने की योजना

मैंने 10 मिनट की व्याख्या की कि क्या चल रहा है और इसे इस एसआईजी दीप गोता सत्र में प्रस्तुत किया।

यहाँ 65 upvotes के साथ एक

ऊपर कई बार उल्लेख किया गया, यह माध्यम पोस्ट चीजों को सही तरीके से करने का एक उदाहरण है। टूटी हुई एपीआई सेवा को ढूंढें और ठीक करें।

सभी एक लाइनर जो सिर्फ नेमस्पेस पर फाइनल निकालते हैं, मूल कारण को संबोधित करते हैं और अपने क्लस्टर को सूक्ष्म रूप से टूट जाते हैं, जो आपको बाद में काट देगा। तो कृपया ऐसा मत करो। मूल कारण फिक्स आमतौर पर वैसे भी आसान होता है। ऐसा लगता है कि लोग इस विषय पर भिन्नताएं पोस्ट करना पसंद करते हैं, भले ही थ्रेड में पहले से ही कई सही उत्तर हों, इसलिए मैं इस मुद्दे को अब बंद करने जा रहा हूं, ताकि यह सुनिश्चित हो सके कि यह टिप्पणी सबसे नीचे रहती है।