Kubernetes: حذف مساحة الاسم عالق في حالة "الإنهاء"

/ sig api-machinery

@ shean-guangchang هل لديك طريقة لإعادة إنتاج هذا؟

وبدافع الفضول ، هل تستخدم أي أجهزة CRD؟ لقد واجهنا هذه المشكلة مع نظام الحماية المؤقت سابقًا.

/ نوع الخطأ

يبدو أنني أواجه هذه المشكلة مع نشر الغراب:

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

أعتقد أن الأمر يتعلق بشيء ما مع CRD الخاص بهم ، وأرى هذا في سجلات خادم API:

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

لقد نشرت rook على مساحة اسم مختلفة الآن ، لكنني غير قادر على إنشاء الكتلة 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 ، ومع ذلك ، يبدو أنه يتم تنظيفها.

@ shean-guangchang - كان لدي نفس المشكلة. لقد حذفت كل شيء تحت مساحات الأسماء يدويًا ، وحذفت وأزلت كل شيء من "helm" وأعدت تشغيل العقد الرئيسية واحدة تلو الأخرى وتم حل المشكلة.

أتخيل أن ما صادفته له علاقة بكل من "ark" و "Tiller" و Kuberenets الذين يعملون معًا (لقد تم التمهيد باستخدام خوذة ونسخ احتياطيًا باستخدام الفلك) لذلك قد لا تكون هذه مشكلة Kuberenets في حد ذاتها ، من ناحية أخرى من ناحية أخرى ، كان من المستحيل إلى حد كبير حل المشكلات نظرًا لعدم وجود سجلات ذات صلة.

إذا كان هذا هو الرخ ، ألق نظرة على هذا: https://github.com/rook/rook/issues/1488#issuecomment -365058080

أعتقد أن هذا أمر منطقي ، ولكن يبدو أنه من الممكن الحصول على مساحة اسم في حالة غير قابلة للإزالة.

لدي بيئة مشابهة (Ark & Helm) مع barakAtSoluto ولدي نفس المشكلة. تطهير وإعادة تشغيل الماجستير لم يصلح لي رغم ذلك. لا يزال عالقًا عند الإنهاء.

كان لدي ذلك أيضًا عند محاولة إعادة إنشاء المشكلة. اضطررت في النهاية إلى إنشاء مجموعة جديدة ...
استبعاد - افتراضي ، kube-system / public وجميع مساحات الأسماء المرتبطة بـ ark من النسخ الاحتياطي والاستعادة لمنع حدوث ذلك ...

أرى هذا أيضًا على مجموعة تمت ترقيتها من 1.8.4 إلى 1.9.6. لا أعرف حتى السجلات التي يجب أن أنظر إليها

نفس المشكلة في 1.10.1 :(

نفس المشكلة في 1.9.6

تحرير: لا يمكن حذف مساحة الاسم بسبب تعليق بعض البودات. لقد قمت بحذف باستخدام --grace-period = 0 - فرض عليهم جميعًا وبعد دقيقتين تم حذف مساحة الاسم أيضًا.

مهلا،

لقد حصلت على هذا مرارًا وتكرارًا ، وفي معظم الأحيان هناك بعض المشاكل مع المصورين.

إذا كانت مساحة الاسم عالقة ، فحاول kubectl get namespace XXX -o yaml وتحقق مما إذا كان هناك برنامج نهائي عليها. إذا كان الأمر كذلك ، فقم بتحرير مساحة الاسم وإزالة المصير النهائي (بتمرير مصفوفة فارغة) ثم يتم حذف مساحة الاسم

xetys هل هو آمن؟ في حالتي ، لا يوجد سوى أداة نهائية واحدة تسمى "kubernetes".

هذا غريب ، لم أر مثل هذا المصير. يمكنني فقط التحدث بناءً على تجربتي. لقد فعلت ذلك عدة مرات في مجموعة إنتاج وما زالت حية

نفس المشكلة في 1.10.5. لقد جربت كل النصائح في هذه المسألة دون نتيجة. لقد تمكنت من التخلص من الكبسولات ، لكن مساحة الاسم لا تزال معلقة.

في الواقع ، تم حذف ns أيضًا بعد فترة.

سيكون من الجيد أن نفهم أسباب هذا السلوك ، والصير النهائي الوحيد الذي لدي هو kubernetes. لدي أيضًا خطافات ويب ديناميكية ، فهل يمكن ربطها؟

xetys حسنًا ، لقد استخدمت

نفس المشكلة على مجموعة EKS 1.10.3:

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

وجود نفس المشكلة على كتلة معدنية عارية:

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

تبدو مساحة الاسم الخاصة بي هكذا:

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

إنها في الواقع مساحة الاسم الثانية التي أواجهها بهذه المشكلة.

جرب هذا للحصول على القائمة الفعلية لجميع الأشياء في مساحة الاسم الخاصة بك: https://github.com/kubernetes/kubectl/issues/151#issuecomment -402003022

ثم لكل كائن ، قم بعمل kubectl delete أو kubectl edit لإزالة الصيغ النهائية.

أدت إزالة أداة التهيئة إلى الحيلة بالنسبة لي ...

عندما أقوم بعمل kubectl edit namespace annoying-namespace-to-delete وأزل الصيغ النهائية ، تتم إعادة إضافتهم عندما أتحقق من kubectl get -o yaml .

أيضًا ، عند تجربة ما اقترحته adampl ، لم أحصل على أي ناتج (إزالة --ignore-not-found تؤكد عدم وجود موارد في مساحة الاسم من أي نوع).

ManifoldFR ، لقد واجهت نفس المشكلة التي تواجهها وتمكنت من جعلها تعمل عن طريق إجراء مكالمة API باستخدام ملف json.
kubectl get namespace annoying-namespace-to-delete -o json > tmp.json
ثم قم بتحرير tmp.json وإزالة "kubernetes"

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

ويجب حذف مساحة الاسم الخاصة بك ،

slassh عملت! كان ينبغي التفكير في إجراء مكالمة API: شكرًا جزيلاً! سنغني بحمدك إلى الأبد

المشكلة موجودة في v1.11.1. كان لدي مربي مزرعة / نشر دفة dokuwiki. اضطررت أولاً إلى فرض حذف البودات كما اقترحه slassh . كل خير الآن.

slassh كيف ترى kubernetes-الكتلة-IP؟ أستخدم أحد العقدة ip التي تم نشرها في kubernetes واستبدلها ، وأبلغت 404.

مرحبًا jiuchongxiao ، بواسطة kubernetes-الكتلة-IP ، قصدت أحد عناوين IP الرئيسية الخاصة بالعقد.
آسف إذا كان محيرا!

إذا بدأت "kubectl proxy" أولاً ، يمكنك توجيه curl إلى http://127.0.0.1 : 8001 / api / v1 / namespaces / annoying-namespace-to-delete / finalize. لم أتمكن من الحصول على المصادقة للعمل حتى فعلت ذلك بهذه الطريقة.

نصائح جيدة @ 2stacks. فقط تحتاج إلى استبدال https إلى http .

ما زلت أرى هذه المشكلة في 1.11.2.

لإعطاء المزيد من السياق لإعادة الإنتاج ، رأيت هذا فقط مع CRDs. بحذف كائن CRD ، حصلت على حالة غريبة حيث لم يتم حذف الكائنات التي يمتلكها. لم ألاحظ لذلك أصدرت حذفًا لمساحة الاسم. ثم قمت بحذف جميع الكائنات في مساحة الاسم بـ kubectl delete all --all -n my-namespace . في تلك المرحلة ، توقف حذف مساحة الاسم. آمل أن يساعد هذا في بعض الطريق.

من خلال النظر في السجلات ، اكتشفت للتو أن هذه المشكلة بالذات كانت تتعلق بمدير وحدة التحكم غير صحي. في حالتي لم يكن هناك خطأ على الأرجح. عندما صعد مدير وحدة التحكم مرة أخرى ، تم تنظيف كل شيء بشكل صحيح.

slassh الحل الأمثل! شكرا جزيلا!!!!

أرى أيضًا هذه المشكلة مع 1.10.x. أجد تعليق slassh بمثابة حل بديل يخفي المشكلة الحقيقية فقط. لماذا تم تعليق مساحات الأسماء عند Terminating ؟

اكتشفنا سبب حذف مساحات الأسماء لتكون عالقة في حالتنا (palmerabollo)

عندما تحتوي مساحة الاسم على أداة نهائية kubernetes ، فهذا يعني أنها مشكلة داخلية مع خادم API.

قم بتشغيل kubectl api-resources ، إذا أعاد مثل ما يلي ، فهذا يعني أن واجهة برمجة التطبيقات المخصصة لا يمكن الوصول إليها.

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

يجب أن يكون سبب الخطأ أعلاه هو تعطل الحلقة التي تؤثر على خادم المقاييس. سيكون مشابهًا لواجهات برمجة التطبيقات المخصصة الأخرى المسجلة في Kubernetes.

تحقق من صحة خدماتك في kube-system لاستعادة عمليات تشغيل المجموعة مثل حذف مساحات الأسماء.

أواجه هذه المشكلة في الإصدار 1.11.3. في برنامج Finalizers ، توجد kubernetes فقط لمساحة الاسم التي بها مشاكل.

spec:
  finalizers:
  - kubernetes

slassh شكرًا مليونًا ، الحل الخاص بك يعمل بشكل جيد!
لدي نفس المشكلة في مجموعتي مع الفلك والحرث والكوبيد. أظن أن المشكلات قد تكون واجهة برمجة تطبيقات kubed التي تقدم خطأً ، على الرغم من عدم التأكد من سبب تأثيرها على حذف مساحة اسم أخرى.

javierprovecho كنت فقط

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

هل تعرف كيف تتعافى من هذه الحالة؟

تحرير: اكتشفت ... اضطررت إلى حذف _ كل شيء _ حتى عن بعد فيما يتعلق بالمقاييس / HPA ثم إعادة تشغيل مستوى التحكم بالكامل (اضطررت إلى إزالة جميع النسخ المتماثلة الخاصة بي قبل إعادة تشغيلها احتياطيًا.) وشمل ذلك حذف apiservice v1beta1.metrics.k8s.io نفسها.

@ 2rs2ts

$ kubectl delete apiservice v1beta1.metrics.k8s.io

من خلال التخلص من خدمة metrics API التي لا تعمل ، سيتمكن مدير وحدة التحكم من حذف مساحة (مساحات) الأسماء القديمة.

إعادة تشغيل مستوى التحكم ليست ضرورية.

antoineco لا ، كان من الضروري ؛ لقد حذفت الخدمة وانتظرت بعض الوقت ولكن لن يتم حذف مساحة الاسم حتى أعد تشغيل مستوى التحكم.

أولاً ، تناول القليل من القهوة واسترخي ، انتقل الآن إلى العقد الرئيسية لـ k8s

1. kubectl الكتلة المعلومات
   Kubernetes master يعمل على https: // localhost : 6443
   KubeDNS يعمل على https: // localhost : 6443 / api / v1 / namespaces / kube-system / services / kube- dns: dns / proxy

لمزيد من تصحيح أخطاء المجموعة وتشخيصها ، استخدم "kubectl cluster-info dump".

1. الآن قم بتشغيل وكيل kube
   وكيل kubectl &
   يبدأ العرض على 127.0.0.1:8001

احفظ المعرف لحذفه لاحقًا :)

1. اعثر على مساحة الاسم التي قررت عدم حذفها :) بالنسبة لنا ، ستكون نظام ماشية
   kubectl الحصول على ns
   إنهاء نظام الماشية 1 د

ضعه في ملف

1. kubectl الحصول على مساحة الاسم cattle-system -o json> tmp.json

1. قم بتحرير الملف وإزالة الصيغ النهائية
   } ،
   "المواصفات": {
   "المصممون النهائيون": [
   "kubernetes"
   ]
   } ،
   بعد التحرير يجب أن تبدو هكذا 👍
   } ،
   "المواصفات": {
   "المصممون النهائيون": [
   ]
   } ،
   نحن تقريبا هناك

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

وذهبت 👍

مرحبًا ، المصير kubernetes موجود لسبب ما. بالنسبة لنا كان اسم خدمة مقاييس تم تكوينه بشكل خاطئ. ربما بالنسبة لك شيء آخر ، يمكنك اكتشافه من خلال الاطلاع على سجلات طائرة التحكم الخاصة بك. بدون تأكيد الخطأ ، قد تؤدي إزالة أداة الإنهاء إلى عواقب غير مرغوب فيها مثل ترك أشياء تم إنشاؤها لم يعد من الممكن الوصول إليها مرة أخرى لأغراض الحذف.

لأن هذه القضية لا تزال مفتوحة:
داخل مجموعة minikube التي تعمل مع "لا شيء" ، حدث هذا بعد أن استيقظ المضيف من السبات.

افتراضي:
في حالتي ، تسبب الإسبات في حدوث نفس المشكلات ، فستعمل المقايضة الممكّنة.

والذي ينتج عنه الافتراض:
قد يتم تمكين المبادلة في الكتل المتأثرة؟

لكن هذا مجرد تخمين. الشيء المهم بالنسبة لي ، وأي شخص يهبط في هذا الخطأ بإعداداتي المحلية:

أولاً ، تناول القليل من القهوة واسترخي ، انتقل الآن إلى العقد الرئيسية لـ k8s

1. kubectl الكتلة المعلومات
   Kubernetes master يعمل على https: // localhost : 6443
   KubeDNS يعمل على https: // localhost : 6443 / api / v1 / namespaces / kube-system / services / kube- dns: dns / proxy

لمزيد من تصحيح أخطاء المجموعة وتشخيصها ، استخدم "kubectl cluster-info dump".

1. الآن قم بتشغيل وكيل kube
   وكيل kubectl &
   يبدأ العرض على 127.0.0.1:8001

احفظ المعرف لحذفه لاحقًا :)

1. اعثر على مساحة الاسم التي قررت عدم حذفها :) بالنسبة لنا ، ستكون نظام ماشية
   kubectl الحصول على ns
   إنهاء نظام الماشية 1 د

ضعه في ملف

1. kubectl الحصول على مساحة الاسم cattle-system -o json> tmp.json

1. قم بتحرير الملف وإزالة الصيغ النهائية
   } ،
   "المواصفات": {
   "المصممون النهائيون": [
   "kubernetes"
   ]
   } ،
   بعد التحرير يجب أن تبدو هكذا 👍
   } ،
   "المواصفات": {
   "المصممون النهائيون": [
   ]
   } ،
   نحن تقريبا هناك

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

وذهبت 👍

عظيم!!
يعمل

أواجه هذه المشكلة بشكل دوري إذا قمنا بتغيير مثيلات gcloud (على سبيل المثال ترقية العقد). يستبدل هذا العقدة القديمة من gcloud instances list بأخرى جديدة ولكنه يترك البودات في مساحة الاسم k8s معلقة:

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

هذا يترك القرون في حالة غير معروفة:

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

نتيجة لهذا ، لن تنتهي مساحة الاسم من الإنهاء. لست متأكدًا مما إذا كان هذا يعني أنه يجب علينا تغيير أدواتنا النهائية أو إذا كان هناك خطأ فعلي متعلق بالإنهاء الذي يجب أن يتعامل مع البودات في حالة UNKNOWN (أو إذا كان يجب أن تكون هناك طريقة لفرض إنهاء مساحة اسم لحالات مثل هذه ).

أواجه هذه المشكلة بشكل دوري إذا قمنا بتغيير مثيلات gcloud (على سبيل المثال ترقية العقد). يستبدل هذا العقدة القديمة من gcloud instances list بأخرى جديدة ولكنه يترك البودات في مساحة الاسم k8s معلقة:

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

هذا يترك القرون في حالة غير معروفة:

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

نتيجة لهذا ، لن تنتهي مساحة الاسم من الإنهاء. لست متأكدًا مما إذا كان هذا يعني أنه يجب علينا تغيير أدواتنا النهائية أو إذا كان هناك خطأ فعلي متعلق بالإنهاء الذي يجب أن يتعامل مع البودات في حالة UNKNOWN (أو إذا كان يجب أن تكون هناك طريقة لفرض إنهاء مساحة اسم لحالات مثل هذه ).

رائع انها ليست نفس المشكلة
تحتاج إلى وضع العقد في وضع الصيانة وبعد ذلك بعد أن تكون في وضع الصيانة ، سيتم إخلاء جميع الكبسولات ومن ثم يمكنك الحذف / الترقية

انظر إليه ， https://kubernetes.io/docs/concepts/workloads/controllers/garbage-collection/ ،
تحرير الموارد وحذف metadata.finalizers ， وحذف crd غير مفيد يمكنك حذفها بالقوة

ولكن ما الذي يفعله المصمم النهائي kubernetes بالضبط؟ هل هناك أي خطر من عدم تنظيف الموارد بشكل صحيح باستخدام هذا الاختراق؟

بالنسبة إلى الغراب العالق ، ساعد إنهاء هذا https://github.com/rook/rook/blob/master/Documentation/ceph-teardown.md

curl -k -H "Content-Type: application / json" -X PUT --data-binary @ tmp.json https: // kubernetes-cluster-ip / api / v1 / namespaces / annoying-namespace-to-delete / وضع اللمسات الأخيرة

خطأ من الخادم (NotFound): لم يتم العثور على مساحات الأسماء "مساحة الاسم المزعجة للحذف"

أولاً ، تناول القليل من القهوة واسترخي ، انتقل الآن إلى العقد الرئيسية لـ k8s

1. kubectl الكتلة المعلومات
   Kubernetes master يعمل على https: // localhost : 6443
   KubeDNS يعمل على https: // localhost : 6443 / api / v1 / namespaces / kube-system / services / kube- dns: dns / proxy

لمزيد من تصحيح أخطاء المجموعة وتشخيصها ، استخدم "kubectl cluster-info dump".

1. الآن قم بتشغيل وكيل kube
   وكيل kubectl &
   يبدأ العرض على 127.0.0.1:8001

احفظ المعرف لحذفه لاحقًا :)

1. اعثر على مساحة الاسم التي قررت عدم حذفها :) بالنسبة لنا ، ستكون نظام ماشية
   kubectl الحصول على ns
   إنهاء نظام الماشية 1 د

ضعه في ملف

1. kubectl الحصول على مساحة الاسم cattle-system -o json> tmp.json

1. قم بتحرير الملف وإزالة الصيغ النهائية
   } ،
   "المواصفات": {
   "المصممون النهائيون": [
   "kubernetes"
   ]
   } ،
   بعد التحرير يجب أن تبدو هكذا 👍
   } ،
   "المواصفات": {
   "المصممون النهائيون": [
   ]
   } ،
   نحن تقريبا هناك

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

وذهبت 👍

قيمة غير صالحة: "فشل التحقق من صحة الملف المحرر": ValidationError (Namespace.spec): نوع غير صالح لـ io.k8s.api.core.v1.NamespaceSpec: حصلت على "سلسلة" ، توقع "خريطة"

إذا كان لديك العديد من مساحات الأسماء عالقة في الإنهاء ، فيمكنك أتمتة هذا:

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 لما ورد أعلاه للعمل.

في حالتنا ، خدمة metrics api معطلة ويمكنني رؤية سجل الأخطاء هذا من التسجيل المطول

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

بعد إصلاح خدمة المقاييس ، يتم الانتهاء من إنهاء الخدمة.
لست متأكدًا حقًا من سبب اعتماد الحذف على خدمة المقاييس ، ومهتم أيضًا بمعرفة كيفية عملها إذا لم يتم تثبيت خدمة المقاييس على الكتلة

لست متأكدًا حقًا من سبب اعتماد الحذف على خدمة المقاييس ،

manojbadam نظرًا لتسجيل القياسات في خادم api ، عند إجراء حذف مساحة الاسم ، يجب الاستعلام عن واجهة برمجة التطبيقات الخارجية لموارد (ذات مساحة الاسم) المراد حذفها (إن وجدت) المرتبطة بمساحة الاسم هذه. إذا لم يكن خادم الامتداد متاحًا ، فلا يمكن لـ Kubernetes ضمان إزالة جميع الكائنات ، وليس لديه آلية ثابتة (في الذاكرة أو القرص) للتوفيق فيما بعد لأنه قد تمت إزالة الكائن الجذر. يحدث ذلك مع أي خدمة تمديد API مسجلة.

نظرًا لأنني كنت أواجه هذا الأمر باستمرار ، فقد أتممت ذلك باستخدام برنامج نصي صغير:

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

يجلب المشروع ، ويصلح JSON ، ويبدأ ويوقف "وكيل kubectl" بشكل صحيح ، ...

بفضل كل شخص يوجهني إلى الاتجاه الصحيح!

نظرًا لأنني كنت أواجه هذا الأمر باستمرار ، فقد أتممت ذلك باستخدام برنامج نصي صغير:

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

يجلب المشروع ، ويصلح JSON ، ويبدأ ويوقف "وكيل kubectl" بشكل صحيح ، ...

بفضل كل شخص يوجهني إلى الاتجاه الصحيح!

بطلي! <3

واجهت هذه المشكلة أيضا. أنا في Google Kubernetes Engine وأستخدم Terraform لتدوير مجموعات Kubernetes وإنشاء مساحات أسماء وأجزاء داخل المجموعة. بدأت المشكلة بعد فترة من تشغيل terraform destroy .

في حالتي ، تبين أن هذا يمثل مشكلة في الترتيب الذي ينفذ به Terraform التدمير. يحذف Terraform مجموعة العقد أولاً ، ثم يحذف مساحات الأسماء والقرون. ولكن نظرًا لحذف تجمع العقدة (فقط) ، تعطلت مجموعة Kubernetes ، وهذا ما تسبب في توقف حذف مساحة الاسم عند "إنهاء" إلى الأبد.

FooBarWidget نفس المشكلة بالنسبة لي :(

نظرًا لأنني كنت أواجه هذا الأمر باستمرار ، فقد أتممت ذلك باستخدام برنامج نصي صغير:

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

يجلب المشروع ، ويصلح JSON ، ويبدأ ويوقف "وكيل kubectl" بشكل صحيح ، ...

بفضل كل شخص يوجهني إلى الاتجاه الصحيح!

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

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

حصلت على رمز إرجاع 403 ، ماذا أفعل :(

نظرًا لأنني كنت أواجه هذا الأمر باستمرار ، فقد أتممت ذلك باستخدام برنامج نصي صغير:
https://github.com/ctron/kill-kube-ns/blob/master/kill-kube-ns
يجلب المشروع ، ويصلح JSON ، ويبدأ ويوقف "وكيل kubectl" بشكل صحيح ، ...
بفضل كل شخص يوجهني إلى الاتجاه الصحيح!

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

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

حصلت على رمز إرجاع 403 ، ماذا أفعل :(

Thx god ، انتهى أخيرًا مساحة الاسم. الطريقة التالية خدعة بالنسبة لي.

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

لدي نفس المشكلة ولكني لا أرى أي خدمة مقاييس.

أنا ألعب مع k8s من digitalocean و gitlab auto devops. افتراضي هو تخزين blob الرقمي ، لكنني ضائع في كيفية تحليله أو إصلاحه.

تضمين التغريدة قام بتعديل مساحة الاسم التي لم تفي بالغرض. السيناريو الخاص بك فعل ذلك.

واو ، أخيرا تخلصت منه. شكرا للأوامر 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"
  ...
}

لكنني مبتدئ في القيادة وكان لدي قالب يحتوي على قالب فيه أنشأ مساحة اسم تسمى servicer . تسبب هذا في وصول terraform و k8 إلى هذه الحالة السيئة حيث يفشل terraform ، ثم تترك 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. ومع ذلك ، يجب أن تسهل kubernetes العثور على الجاني ، لأن أطوال هذا الخيط توضح أنه قد يكون هناك العديد من الأسباب وليس من السهل الوصول إلى الجزء السفلي منها في كل سيناريو معين.

أنا مستجد kubernetes لذا لا يمكنني تقديم الكثير من المعلومات هنا ولكن لدي أيضًا مساحتان أسماء عالقتان في حالة الإنهاء. إعداد kubernetes الخاص بي يستخدم

kubectl version
Client Version: version.Info{Major:"1", Minor:"12", GitVersion:"v1.12.4+icp", GitCommit:"3f5277fa129f05fea532de48284b8b01e3d1ab4e", GitTreeState:"clean", BuildDate:"2019-01-17T13:41:02Z", GoVersion:"go1.10.4", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"12", GitVersion:"v1.12.4+icp", GitCommit:"3f5277fa129f05fea532de48284b8b01e3d1ab4e", GitTreeState:"clean", BuildDate:"2019-01-17T13:41:02Z", GoVersion:"go1.10.4", Compiler:"gc", Platform:"linux/amd64"}

kubectl cluster-info
Kubernetes master is running at https://ip
catalog-ui is running at https://ip/api/v1/namespaces/kube-system/services/catalog-ui:catalog-ui/proxy
Heapster is running at https://ip/api/v1/namespaces/kube-system/services/heapster/proxy
image-manager is running at https://ip/api/v1/namespaces/kube-system/services/image-manager:image-manager/proxy
CoreDNS is running at https://ip/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
metrics-server is running at https://ip/api/v1/namespaces/kube-system/services/https:metrics-server:/proxy
platform-ui is running at https://ip/api/v1/namespaces/kube-system/services/platform-ui:platform-ui/proxy

kubectl get nodes
NAME          STATUS                     ROLES                          AGE   VERSION
ip1    Ready,SchedulingDisabled   etcd,management,master,proxy   23h   v1.12.4+icp
ip2   Ready                      worker                         23h   v1.12.4+icp
ip3   Ready                      worker                         23h   v1.12.4+icp

لدي مساحتا أسماء عالقتان في حالة الإنهاء

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

عندما أتحقق من الصيغ النهائية كما هو موضح في هذا التعليق أرى فقط kubernetes .

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

بغض النظر عن أنني حاولت إزالة kubernetes من المصنّعين ولم تنجح حاولت أيضًا استخدام نهج json / api الموضح في هذا التعليق . أيضا لا يعمل. حاولت إعادة تشغيل جميع العقد ولم ينجح ذلك أيضًا.

لقد حاولت أيضًا إجراء حذف بالقوة وهذا لا يعمل أيضًا

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

في حالتي ، مساحة الاسم هي rook-ceph ، kubectl -n rook-ceph patch cephclusters.ceph.rook.io rook-ceph -p '{"metadata":{"finalizers": []}}' --type=merge يعمل بالنسبة لي. بالنسبة للحالات الأخرى يجب أن تعمل أيضًا.

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

ManifoldFR ، لقد واجهت نفس المشكلة التي تواجهها وتمكنت من جعلها تعمل عن طريق إجراء مكالمة API باستخدام ملف json.
kubectl get namespace annoying-namespace-to-delete -o json > tmp.json
ثم قم بتحرير tmp.json وإزالة "kubernetes"

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

ويجب حذف مساحة الاسم الخاصة بك ،

لدي بعض المشاكل أثناء استخدام النهج الخاص بك ، فماذا أفعل للخطوة التالية لاستكشاف الأخطاء وإصلاحها؟

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

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

ManifoldFR ، لقد واجهت نفس المشكلة التي تواجهها وتمكنت من جعلها تعمل عن طريق إجراء مكالمة API باستخدام ملف json.
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 .

نعم https://github.com/ctron/kill-kube-ns/blob/master/kill-kube-ns يقوم بالمهمة

set -eo pipefail

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

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

# checking pre-reqs

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

PROJECT="$1"
shift

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

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

sleep 1 # give the proxy a second

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

يبدو أن مساحات الأسماء لم يتم حذفها بالفعل.
في حالتي ، لا يُظهر kubectl get ns مُعرف الهيكلة المحذوف ولكن kubectl get all -n <namespace> يُظهر جميع الموارد آمنة وسليمة.
لقد تحققت من العقد وكانت حاويات الرصيف لا تزال تعمل ...

glouis هذا لأنك تجاوزت

إنه لأمر محزن حقًا أن نرى الكثير من الناس يدافعون بشكل أعمى عن هذه الطريقة دون فهم عواقبها. إنه قبيح للغاية ويمكن أن يترك أطنانًا من بقايا الطعام في المجموعة. javierprovecho ذكرها بالفعل أعلاه ، و liggitt ذكرها أيضًا في مشكلة GitHub أخرى.

سيكون من الأفضل لك إصلاح خدمة API المعطلة v1beta1.metrics.k8s.io أو حذفها إذا لم تكن بحاجة إليها.

أنظر أيضا # 73405

أنا ثاني رسالة antoineco . لقد اختبرت ذلك في إحدى بيئات بيئة الحماية لأننا كنا دائمًا نتعثر في مساحات الأسماء. بعد حوالي شهر ، تجمدت جميع شياطين الرصيف بدون سبب. اتضح أننا أنشأنا تسريبات ذاكرة ضخمة من ترك الموارد وراءنا.

بعد الكثير من التجربة والخطأ ، وقراءة هذه التعليقات ، اتضح أنه تعريف مورد مخصص لمكدس coreos grafana لمساحات الأسماء. أظهرت قائمة CRDs موارد محددة لمساحة الاسم تلك. كنت محظوظًا جدًا لأن اسم CRD كان به مساحة الاسم التي كانت عالقة.

واتضح أيضًا أن وجود مساحة اسم عالقة يؤدي إلى إيقاف أي مساحات أسماء أخرى ليتم حذفها. لذا ، حتى إذا كان لديك مساحة الاسم A التي لا تحتوي على CRD مما يجعلها عالقة ، وهناك مساحة اسم B مع CRD عالق ، فإن جميع الموارد الموجودة في A ستظل موجودة حتى تختفي B. أعتقد أنني يجب أن أكون قد قمت بالإصلاح الموصوف أعلاه على مساحة الاسم أ وترك الكثير من الموارد في كل مرة.

الشيء الذي لا يزال يقتلني هو أنني لا أستطيع أن أجد طوال حياتي أي سجل يذكر تنظيف مساحة الاسم فشل في حذف CRD ، أو حتى ما يفعله حاليًا. كان علي أن أقضي ساعة فقط في معرفة ما هو CRD الذي تم تعليقه عليه. إذا كان لدى أي شخص فكرة عن كيفية الحصول على مزيد من المعلومات ، فلا داعي لقضاء قدر كبير من الوقت في اكتشاف المورد المتوقف الذي سيكون رائعًا.

jecafarelli تلميح جيد لمجموعات الإنتاج. لكن لسوء حظي ، لم أتمكن من قتله بطريقة أخرى. علمت أيضًا أنني سأعيد إنشاء المجموعة بأكملها لاحقًا.

حاولت تحليل المشكلة ولكن لم يساعدني شيء في هذا الموضوع في حلها بوسائل أخرى.

ساعدني هذا الحل الرسمي: https://success.docker.com/article/kubernetes-namespace-stuck-in-terminating
هذا ليس هو نفسه kubectl edit namespace rook-ceph . لم أتمكن من حل هذه المشكلة حتى قمت بطلب PUT مع _ "finalizers" _

حسنًا ، لقد واجهت هذا مرة أخرى مع coreos ، وحفرت أعمق قليلاً. هذا بالتأكيد بسبب تعريف مورد واسع للكتلة محدد بمساحة الاسم ، وربما أكثر من ذلك ربما لم يتمكن من حذفه لأنه لا يمكنه الاستعلام عن معلومات حول coreos. لقد وجدت أخطاء في سجلات apiserver التي أظهرت أخطاء في محاولة الحصول على معلومات حول مجموعة api. لقد استخدمت المشكلة المشار إليها أعلاه للتوصل إلى نص برمجي سريع يسرد الموارد التي تسببت في تعطل الأمور بالنسبة لي.

ربما استخدم هذا في المستقبل فقط إذا واجهت ذلك مرة أخرى وواصلت إضافة أي موارد أخرى ذات أسماء نطاقات أواجهها.

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

فقط تناغم ليقول إنني قابلت أيضًا هذا الخطأ في الإصدار 1.13.6 مع GKE. حدث ذلك بعد أن قمت بتعطيل الملحق Istio الخاص بـ GKE بهدف تثبيته يدويًا للتحكم الكامل.
هذه هي أطول سلسلة رسائل قضيتها على الإطلاق لقراءتها ، وقد شعرت بالذهول لعدم وجود إجماع حقيقي أو خطوات إعادة إنتاج لجذر هذه المشكلة. يبدو أنه يمكن أن يتعثر بعدة طرق مختلفة :(

طريقة JSON و curl / proxy المذكورة عدة مرات أعلاه وموثقة على https://success.docker.com/article/kubernetes-namespace-stuck-in-terminating هي ما أنقذني.

تعتبر النصيحة الموجودة على https://success.docker.com/article/kubernetes-namespace-stuck-in-terminating ضارة بشكل فعال ، ويمكن أن تؤدي إلى عدم تنظيف الموارد المعزولة وإعادة الظهور في حالة إعادة إنشاء مساحة اسم ذات اسم مماثل لاحقًا .

هناك عمل قيد التقدم لإظهار السبب المحدد للحذف المعلق ، ولكن المشكلة الأساسية هي أن هناك أنواعًا من واجهات برمجة التطبيقات لا يمكن التحقق من تنظيفها ، وبالتالي يتم حظر حذف مساحة الاسم حتى يتم التحقق منها.

لقد ضربنا هذا أيضًا مع Knative الذي يثبت هذه الخدمة ذات مساحة الاسم.

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

بعد حذفه ، تم تنظيف كل من ns التي تخدم knative ومجموعة من مساحات الأسماء العالقة الأخرى. بفضل jecafarelli على نص bash أعلاه.
ها هي نسخة باورشيل الرهيبة.

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

كان لدي نفس المشكلة اليوم وهذا السيناريو نجح معي.

@ kubernetes / sig-api-machinery-misc

هذا الخطأ موجود منذ> عام ولا يزال يمثل مشكلة ... ما هي خطتك لمعالجة المشكلات الواردة مثل هذا؟

قد يساعد هذا في فهم ما يحدث على الأقل: https://github.com/kubernetes/kubernetes/pull/80962

أنا أواجه نفس المشكلة

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

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

يجب على وحدة التحكم في Namespace الإبلاغ عن الشروط إلى حالة مساحة الاسم ويجب على العملاء الإبلاغ عن ذلك. يحتاج إلى KEP ، ولكن يجب أن يكون واضحًا جدًا إذا كان بإمكان شخص ما قبوله والتحقق منه.

timothysc هناك (أو كان) العلاقات العامة في الرحلة (في مكان ما) تفعل بالضبط ما يقوله smarterclayton .

أنا متأكد من أن هناك مشكلة جيثب أخرى حول هذا أيضًا؟

نعم ، العلاقات العامة هنا: https://github.com/kubernetes/kubernetes/pull/73405

المشكلة التي أعتبرها أساسية هنا: https://github.com/kubernetes/kubernetes/issues/70916

إليك مورد ساعدني: https://www.ibm.com/support/knowledgecenter/en/SSBS6K_3.1.1/troubleshoot/ns_terminating.html

إنه مشابه للحل الذي اقترحه slassh ، لكنه يستخدم kubectl proxy لإنشاء وكيل محلي وجعل عنوان IP المستهدف للأمر 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
أنا أستخدمه للحذف السريع وآمل أن يكون مفيدًا لشخص ما.

توجد مساحات أسماء Kubernetes 1.12.2 في حالة الإنهاء. في بعض الأحيان يمكن حذف المصغرات بتعديل yaml of ns. لا يمكن حذفه بواسطة api. هل يمكن حذفه؟ ما هو الوضع؟ هل قمنا بتتبعه على وجه التحديد (شرط أساسي: لا توجد موارد في هذا العدد) ، آمل أن أحصل على مؤشرات ، شكرًا لك!

مرة أخرى ، من فضلك لا تقم بإزالة المصير ، فهو موجود لسبب ما. حاول بدلاً من ذلك معرفة الموارد الموجودة في 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) حل المشكلة.

مرحبًا بالجميع ، سيظهر تجميد الكود في غضون أيام قليلة (الخميس ، نهاية اليوم ، توقيت المحيط الهادي) ، لذلك نحتاج إلى التأكد من أن هذه المشكلة سيتم حلها للإصدار 1.16 أو نقلها إلى الإصدار 1.17. هل يمكنك التعليق على حالتها؟

هل سيتم نقل هذا إلى إصدار GKE الحالي؟ لدي مجموعة بها عدد قليل من مساحات الأسماء التي لا تزال "منتهية".

squarelover حتى بعد القيام بذلك؟ https://github.com/kubernetes/kubernetes/issues/60807#issuecomment -524772920

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 (مجد للأردن لذلك)

لا يكمن حل هذه المشكلة في قصر دائرة آلية التنظيف ، بل في معرفة ما الذي يمنع عملية التنظيف من النجاح.

في كثير من الحالات ، قد يكون لديك Metric-Server مثبتًا. عندما تبحث البودات التي تنشرها في مساحات أسماء محددة عن تجميع المقاييس. انها معلقة مع خادم متري. لذلك حتى بعد حذف جميع الموارد في مساحة الاسم هذه ، فإن خادم القياس مرتبط بطريقة أو بأخرى بمساحة الاسم هذه. مما سيمنعك من حذف مساحة الاسم.
تساعدك هذه المشاركة في تحديد سبب عدم تمكنك من حذف Namespace. هكذا طريقة الطقوس.

جرب هذا للحصول على القائمة الفعلية لجميع الأشياء في مساحة الاسم الخاصة بك: kubernetes / kubectl # 151 (تعليق)

ثم لكل كائن ، قم بعمل kubectl delete أو kubectl edit لإزالة الصيغ النهائية.

هذا الحل مفيد لي ، شكرا.

اهلا ياجماعة،

لقد أنشأت برنامجًا نصيًا لتسهيل حذف مساحات الأسماء في حالة الإنهاء: https://github.com/thyarles/knsk.

شكر.

لقد واجهنا نفس المشكلة ، عند حذف مساحة الاسم ، ستظل عالقة في حالة "إنهاء". لقد اتبعت stpes أعلاه لإزالة "kubernetes" في finalizer في ملف yaml. إنها تعمل.

ومع ذلك ، لا نعرف سبب حاجتنا إلى اتخاذ خطوات إضافية. يجب أن تفعل kubectl حذف ns foonamespace ويجب أن تحذف. يمكن لأي شخص أن يعطيني سبب؟ شكرا لك!

مرحبًا @ xzhang007 ،

إذا اكتشفت سبب توقف حذف مساحة الاسم في حالة الإنهاء ، فيرجى إبلاغي بذلك. حاولت لفترة من الوقت إجابة جيدة ، لكن لا شيء. ثم صنعت سيناريو لجعل حياتي أسهل حتى أكتشف السبب وأصلحه.

شكرا لك.

thyales يبدو أنني لم أجد إجابة حتى الآن.

في حالتنا ، اكتشفنا أن أحد الوبوكس والنهائي كنا
باستخدام كان الوصول إلى حجرة كانت تعيش في مساحات الأسماء التي حصلت عليها
تم الحذف.
بمجرد حذف الكبسولة ، توقف الإنهاء.

>

@ 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://medium.com/@newtondev/how -to-fix-kubernetes-namespace-deleting-stuck-in-terminating-state-5ed75792647e

كان هذا بمثابة بطل بالنسبة لي

لقد واجهت أيضًا نفس المشكلة الآن وهي تعمل بشكل جيد بالنسبة لي. يرجى الرجوع إلى المستند التالي وحل مشكلتك

zerkms حسناً ، أحياناً ، هذه نصيحة مشروعة ، أليس كذلك؟ غالبًا ما يتم استخدام المصممين النهائيين الذين يتم انتظارهم ليتم تقديمها بواسطة الكائنات التي تم حذفها كجزء من حذف مساحة الاسم. في هذه الحالة ، نظرًا لأنه لا جدوى من الانتظار أكثر - لا يوجد شيء يمكن أن يفعله بعد الآن - ، فإن تصحيح الكائنات بالطريقة التي تصفها المقالة _ هو الخيار الوحيد _.

لاحظ أن المقالة قابلة للتطبيق فقط إذا لم يتم حل المشكلة من خلال خطوات التطبيق المدرجة في صفحة المشكلات المعروفة ، والمرتبطة بأعلى المقالة ، وهي في الأساس النصيحة التي يكررها التعليق الذي ربطته.

zerkms حسناً ، أحياناً ، هذه نصيحة مشروعة ، أليس كذلك؟ غالبًا ما يتم استخدام المصممين النهائيين الذين يتم انتظارهم ليتم تقديمها بواسطة الكائنات التي تم حذفها كجزء من حذف مساحة الاسم

لم أر قط أن هذا يكون صحيحًا بالنسبة لمؤشر نهائي على مساحة اسم. كل مثيل رأيته يشتمل على وحدة تحكم تنظيف مساحة الاسم ، وقد نتج إما عن كائن ثابت في مساحة الاسم (والتي ستحدد هذه النصيحة في etcd) ، أو واجهة برمجة تطبيقات مجمعة غير مستجيبة (والتي تزيل محدد مساحة الاسم. في انتظار ، تقطع السبل أيضًا بأي موارد مستمرة من واجهة برمجة التطبيقات تلك)

لا تحذر المقالة من أن تجاوز إنهاء مساحة الاسم يخاطر بترك الموارد ذات مساحة الاسم عالقة في التخزين ، ولا يوصى بذلك.

لم أر قط أن هذا يكون صحيحًا بالنسبة لمُحدد نهائي لمواصفات على مساحة اسم

نعم ، هذا صحيح ، لأن هذا المصمم النهائي يتم تنفيذه بواسطة kubernetes نفسه ، ولكن يمكن أن يكون هناك مواد نهائية أخرى على الكائنات داخل مساحة الاسم هذه ، والتي يمكن تنفيذها بواسطة الكائنات في مساحة الاسم المذكورة. أحد الأمثلة التي صادفتها مؤخرًا كان https://appscode.com/products/stash/ .

إنها تضع المصنّعين النهائيين على بعض CRDs الخاصة بها والتي سيتم صيانتها من خلال نشر مشغل stash. ولكن مع حذف عامل التخزين المؤقت بالفعل ، لا يوجد شيء يمكنه إزالة علامة Finalizer من CRDs ويتعطل حذف مساحة الاسم. في هذه الحالة ، فإن ترقيع هؤلاء المصممين (ليس في مساحة الاسم نفسها ، ولكن على تلك الكائنات) هو الشيء المعقول الوحيد الذي يجب القيام به.

اتمنى ان يكون منطقي

في هذه الحالة ، فإن ترقيع هؤلاء المصممين (ليس في مساحة الاسم نفسها ، ولكن على تلك الكائنات) هو الشيء المعقول الوحيد الذي يجب القيام به.

صيح. لن أعترض على ذلك في سيناريو تنظيف "حذف جميع الموارد" ، ولكن هذا ليس ما تتناوله المقالة المرتبطة ... فهو يصف كيفية إزالة spec.finalizer من مساحة الاسم.

أولاً ، تناول القليل من القهوة واسترخي ، انتقل الآن إلى العقد الرئيسية لـ k8s

kubectl الكتلة المعلومات
Kubernetes master يعمل على https: // localhost : 6443
KubeDNS يعمل على https: // localhost : 6443 / api / v1 / namespaces / kube-system / services / kube- dns: dns / proxy
لمزيد من تصحيح أخطاء المجموعة وتشخيصها ، استخدم "kubectl cluster-info dump".

الآن قم بتشغيل وكيل kube
وكيل kubectl &
يبدأ العرض على 127.0.0.1:8001
احفظ المعرف لحذفه لاحقًا :)

1. اعثر على مساحة الاسم التي قررت عدم حذفها :) بالنسبة لنا ، ستكون نظام ماشية
   kubectl الحصول على ns
   إنهاء نظام الماشية 1 د

ضعه في ملف

1. kubectl الحصول على مساحة الاسم cattle-system -o json> tmp.json

قم بتحرير الملف وإزالة الصيغ النهائية
} ،
"المواصفات": {
"المصممون النهائيون": [
"kubernetes"
]
} ،
بعد التحرير يجب أن تبدو هكذا 👍
} ،
"المواصفات": {
"المصممون النهائيون": [
]
} ،
نحن تقريبا هناك
curl -k -H "Content-Type: application / json" -X PUT --data-binary @ tmp.json http://127.0.0.1 : 8001 / api / v1 / namespaces / $ {NAMESPACE} / finalize

وذهبت 👍

مرة أخرى ، من فضلك لا تقم بإزالة المصير ، فهو موجود لسبب ما. حاول بدلاً من ذلك معرفة الموارد الموجودة في NS التي تنتظر الحذف من خلال:

• التحقق مما إذا كانت أي خدمة غير متوفرة وبالتالي لا تخدم مواردها: 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. تحقق من وجود مصادر غير متوفرة واطلب حذفها
2. تحقق من وجود موارد معلقة في مساحة الاسم واطلب حذفها
3. انتظر حوالي 5 دقائق لمعرفة ما إذا كان برنامج Kubernetes يقوم بحذف نظيف إذا كان البرنامج النصي يقوم بأي حذف
4. فرض حذف مساحة الاسم العالقة

آمل أن يساعد.

thyarles شكرا جزيلا لك. لقد استخدمت طريقك لحل المشكلة.

الحصول على خدمات $ kubectl للتحقق من الخدمة غير المتاحة ، وحذف تلك المتاحة خطأ من خلال $ kubectl حذف apiservice [اسم الخدمة] ، وبعد ذلك لن تكون هناك مشكلات حول حذف مساحة الاسم.

بالنسبة لفريقنا ، هناك 3 خدمات غير متوفرة ، v1beta1.admission.certmanager.k8s.io و v1beta1.metrics.k8s.io و v1beta1.webhook.certmanager.k8s.io.

لاحظ أن مجموعتك مكسورة إلى حد ما إذا كان خادم المقاييس لا يعمل ، فمجرد إزالة APIService لا يصلح بالفعل السبب الجذري.

lavalamp المقاييس هي خدمة غير متوفرة.

نعم ، مما يعني أن خادم المقاييس لا يعمل ، مما يعني أن HPA لا يعمل على مجموعتك ، وربما أشياء أخرى أيضًا.

نعم. HPA لا يعمل الآن. لا يجب أن أحذف المقاييس وأجد طريقة لإصلاحها.

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

pod / metrics-server-64f74f8d47-r5vcq 2/2 يعمل 9119d
خدمة / مقاييس خادم ClusterIP xx.xx.xx.xx443 / TCP 201d
publish.apps / metrics-server 1/1 1 1 201d
replicaset.apps / metrics-server-55c7f68d94 0 0 0 165d
replicaset.apps / metrics-server-5c696bb6d7 0 0 0 201d
replicaset.apps / metrics-server-5cdb8bb4fb 0 0 0 201d
replicaset.apps / metrics-server-64f74f8d47 1 1 1111d
replicaset.apps / metrics-server-686789bb4b 0 0 0145d ```

$ kubectl -n kube-system احصل على كل شيء | مقاييس grep

pod / metrics-server-5dcfd4dd9f-m2v9k 1/1 قيد التشغيل 0 2d20h

خدمة / مقاييس خادم ClusterIP xx.xx.xx.xx443 / TCP 27d

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

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

نعم. HPA لا يعمل الآن. لا يجب أن أحذف المقاييس وأجد طريقة لإصلاحها.

@ xzhang007 في الواقع لا يعمل قبل أن تلاحظ المشكلة .... لقد لاحظت للتو لأنه وضع مساحات الأسماء المحذوفة في وضع عالق. ما عليك سوى استخدام مدير حزمة الدفة لإعادة نشر خادم القياس الخاص بك أو فقط اتصل بالأمر أدناه لإصلاحه ( تحقق من ملف النشر قبل التقديم ):

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

لقد نجح حل

احذف 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 باستخدام إصدار حديث من kubectl حيث يتوفر kubectl replace --raw (لست متأكدًا من الإصدار). بهذه الطريقة لن تضطر إلى إنتاج عملية kubectl proxy وتجنب التبعية مع curl (ذلك في بعض البيئات مثل busybox غير متوفر). على أمل أن يساعد هذا شخصًا آخر تركته هنا:

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

هل تم إثبات ما إذا كانت هذه مشكلة قابلة للإصلاح؟ يبدو أن هناك الكثير من الحلول المخترقة هنا ولكن لا يوجد شيء يعالج المشكلة الأساسية وهي أنه لا يمكن لأي منا حذف مساحات الأسماء الخاصة بنا ...
لدي هذا على مجموعة EKS v1.14

هل تم إثبات ما إذا كانت هذه مشكلة قابلة للإصلاح؟ يبدو أن هناك الكثير من الحلول المخترقة هنا ولكن لا يوجد شيء يعالج المشكلة الأساسية وهي أنه لا يمكن لأي منا حذف مساحات الأسماء الخاصة بنا

المشكلة الأساسية هي أن مجموعة API المجمعة في نظام المجموعة الخاص بك غير متوفرة. من المتعمد حظر وحدة تحكم تنظيف مساحة الاسم حتى تتوفر جميع واجهات برمجة التطبيقات ، بحيث يمكنها التحقق من تنظيف جميع الموارد من جميع مجموعات API لمساحة الاسم هذه.

لمحاولة ppl تجعيد API:

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

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

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

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

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

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

إليك نص برمجي للقيام بذلك تلقائيًا. يحتاج 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

يقوم هذا البرنامج النصي بإجراء جميع عمليات الفحص ويحاول إجراء حذف نظيف ، بما في ذلك البحث عن الموارد المعزولة. إذا أراد المستخدم المخاطرة ، فإن البرنامج النصي يوفر خيار فرض - لتنفيذ طريقة غير موصى بها للحذف.

خطأ مطبعي ، يجب أن يكون apiservices

يظهر هذا الأمر واجهات برمجة تطبيقات غير متوفرة:

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

في الواقع ما هو موجود هو تضارب في الخدمات ، يمكنهم التحقق من صحة الحالة الصحية لـ apis في النقل المفتوح:

oc get apiservices -o = custom-عمود = " الاسم: .metadata.name ، الحالة: .status.conditions [0] .status"

ستحتاج واجهة برمجة التطبيقات التي فشلت إلى إعادة تشغيلها ، أو إعادة تشغيل البود أو النشر الذي ينتمي إلى واجهة برمجة التطبيقات هذه ، بعد ذلك حاول حذف مساحة الاسم.

$ oc حذف namspace

وجاهز ، عمل ثابت !!

استخدام لغتك الخاصة في مكان يوافق فيه الجميع على التحدث باللغة الإنجليزية. 👎

أين يوافق الجميع على التحدث باللغة الإنجليزية؟

في الخميس ، 30 أبريل 2020 الساعة 17:58 ، كتب theAkito [email protected] :

من غير المحترم استخدام لغتك الخاصة في مكان يكون فيه الجميع
يوافق على التحدث باللغة الإنجليزية. 👎

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/60807#issuecomment-622137770 ،
أو إلغاء الاشتراك
https://github.com/notifications/unsubscribe-auth/ALGMKB6K4OU4X3XOYMALOBLRPHYCDANCNFSM4ETUOEPA
.

>

كريس ، كبير المهندسين المعماريين @ brace.ai

-

إشعار السرية: هذا البريد الإلكتروني مخصص للاستخدام الحصري لـ
المستلم (المستلمون) المقصودون وقد تحتوي على معلومات سرية أو مملوكة أو
معلومات سرية. إذا لم تكن المستلم المقصود ، فأنت كذلك
أخطرت بأن أي استخدام أو مراجعة أو نشر أو نسخ أو إجراء تم اتخاذه على أساس
في هذه الرسالة أو مرفقاتها ، إن وجدت. إذا لم تكن
المستلم المقصود ، يرجى الاتصال بالمرسل عن طريق البريد الإلكتروني الرد و
إتلاف أو حذف جميع نسخ الرسالة الأصلية وأي مرفقات.

جاهز ، عفواً ، لقد كان ذلك بسبب سرعي ، لقد تم إصلاحه

لدينا قاعدة مستخدمين متعددة اللغات ، ومن السيئ بما فيه الكفاية ألا يتم تدويل أي من أدواتنا ، على الأقل يمكننا أن نكون لطيفين هنا على جيثب ، من فضلك.

تضمين التغريدة

كما ذكرنا سابقًا في هذه المشكلة ، هناك طريقة أخرى لإنهاء مساحة اسم باستخدام واجهة برمجة التطبيقات التي لم يتم الكشف عنها بواسطة kubectl باستخدام إصدار حديث من kubectl حيث يتوفر kubectl replace --raw (لست متأكدًا من الإصدار). بهذه الطريقة لن تضطر إلى إنتاج عملية kubectl proxy وتجنب التبعية مع curl (ذلك في بعض البيئات مثل busybox غير متوفر). على أمل أن يساعد هذا شخصًا آخر تركته هنا:

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

لقد نجح هذا على أكمل وجه!

لدينا قاعدة مستخدمين متعددة اللغات ، ومن السيئ بما فيه الكفاية ألا يتم تدويل أي من أدواتنا ، على الأقل يمكننا أن نكون لطيفين هنا على جيثب ، من فضلك.

لدينا قاعدة مستخدمين متعددة اللغات ، ومن السيئ بما فيه الكفاية ألا يتم تدويل أي من أدواتنا ، على الأقل يمكننا أن نكون لطيفين هنا على جيثب ، من فضلك.

ما زلت أحاول أن أفهم. سامحني. ربما أكون قد نقرت على الإبهام عن طريق الخطأ.
نعم ، في الواقع ، لم يتم عمل الأدوات بشكل مثالي.
هؤلاء ، الذين يعطون إبهامًا بدون تفسير ، لا معنى له.

في جميع الأوقات تقريبًا التي أواجه فيها هذه المشكلة ، يعود الأمر إلى CRD. احذف CRD's إذا تم استخدامها فقط في مساحة الاسم تلك ، وبعد ذلك يمكنك متابعة حذف finalizer ومساحة الاسم.

كما ذكرنا سابقًا في هذه المشكلة ، هناك طريقة أخرى لإنهاء مساحة اسم باستخدام واجهة برمجة التطبيقات التي لم يتم الكشف عنها بواسطة kubectl باستخدام إصدار حديث من kubectl حيث يتوفر kubectl replace --raw (لست متأكدًا من الإصدار). بهذه الطريقة لن تضطر إلى إنتاج عملية kubectl proxy وتجنب التبعية مع curl (ذلك في بعض البيئات مثل busybox غير متوفر). على أمل أن يساعد هذا شخصًا آخر تركته هنا:

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

teoincontatto شكرا لك! لقد نجح هذا أخيرًا!

في بعض الأحيان ، لن يعمل بشكل جيد جدًا تعديل بيان المورد عبر الإنترنت (أعني إزالة ملف finalizers وحفظه).
لذلك ، حصلت على طريقة جديدة من الآخرين.

kubectl get namespace linkerd -o json > linkerd.json

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

بعد تشغيل هذا الأمر ، يجب أن تكون مساحة الاسم الآن غائبة عن قائمة مساحات الأسماء الخاصة بك .. وهي تعمل بالنسبة لي.

ليس فقط namespace ولكن أيضًا دعم الموارد الأخرى.

لقد أصلحت المشكلة عن طريق إزالة خطوط finalizers باستخدام: kubectl edit annoying-ns

حسنًا ... لدي هذه المشكلة الآن :)
قمت اليوم بتحديث مجموعة eks الخاصة بي من 1.15 إلى 1.16.
كل شيء يبدو على ما يرام حتى الآن.
لكن "configcluster" تطويري كان نوعًا من "damanged".
لذلك قررت تنظيفه.

ك حذف ns configcluster
....
الآن توقف هذا (3 ساعات +): /

$ 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 صباحًا Andreas Höhmann [email protected]
كتب:

حسنًا ... لدي هذه المشكلة الآن :)
قمت اليوم بتحديث مجموعة eks الخاصة بي من 1.15 إلى 1.16.
كل شيء يبدو على ما يرام حتى الآن.
لكن "configcluster" تطويري كان نوعًا من "damanged".
لذلك قررت تنظيفه.

ك حذف ns configcluster
....
الآن توقف هذا (3 ساعات +): /

$ kubectl احصل على مجموعة تكوين مساحة الاسم -o yaml
الإصدار: v1.0
النوع: Namespace
البيانات الوصفية:
التعليقات التوضيحية:
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion": "v1"، "kind": "Namespace"، "metadata": {"توضيحية": {}، "name": "configcluster"}}
إنشاء الطابع الزمني: "2020-06-19T06: 40: 15Z"
الحذف الطابع الزمني: "2020-06-19T09: 19: 16Z"
الاسم: configcluster
الموارد الإصدار: "22598109"
selfLink: / api / v1 / namespaces / configcluster
uid: e50f0b53-b21e-4e6e-8946-c0a0803f031b
المواصفات:
النهائيين:

• kubernetes
  الحالة:
  الظروف:
• lastTransitionTime: "2020-06-19T09: 19: 21Z"
  الرسالة: 'فشل الاكتشاف لبعض المجموعات ، 1 فشل: غير قادر على استرداد ملف
  القائمة الكاملة لواجهات برمجة تطبيقات الخادم: metrics.k8s.io/v1beta1: الخادم حاليًا
  غير قادر على التعامل مع الطلب '
  السبب: فشل الاكتشاف
  الحالة: "صحيح"
  النوع: NamespaceDeletionDiscoveryFailure
• lastTransitionTime: "2020-06-19T09: 19: 22Z"
  الرسالة: تم تحليل جميع أنواع kube القديمة بنجاح
  السبب: ParsedGroupVersions
  الحالة: "خطأ"
  النوع: NamespaceDeletionGroupVersionParsingFailure
• lastTransitionTime: "2020-06-19T09: 19: 22Z"
  الرسالة: تم حذف كل المحتوى بنجاح
  السبب: حذف المحتوى
  الحالة: "خطأ"
  النوع: NamespaceDeletionContentFailure
  المرحلة: الإنهاء

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/60807#issuecomment-646543073 ،
أو إلغاء الاشتراك
https://github.com/notifications/unsubscribe-auth/AFLKRCLHIZ77X2Z3F5GAOCTRXMXVTANCNFSM4ETUOEPA
.

bobhenkel حسنًا ، تم إغلاق هذه المشكلة ، وهذا يعني بشكل فعال أنه لا توجد مشكلة (فيما يتعلق بأي عناصر قابلة للتنفيذ) إذا كنت بحاجة إلى مساعدة عملية للتعامل مع موقف مشابه ، فيرجى قراءة الموضوع أعلاه ، فهناك بعض النصائح الجيدة هناك (وكذلك بعض النصائح السيئة).

في حالتي ، اضطررت إلى حذف موازن تحميل الدخول يدويًا من وحدة تحكم خدمة شبكة GCP. لقد قمت يدويًا بإنشاء واجهة موازن التحميل مباشرة في وحدة التحكم. بمجرد أن قمت بحذف موازن التحميل ، تم حذف مساحة الاسم تلقائيًا.

أشك في أن Kubernetes لم يرغب في الحذف لأن حالة موازن التحميل كانت مختلفة عن الحالة الموجودة في البيان.

سأحاول أتمتة إنشاء الواجهة الأمامية لـ ingress باستخدام التعليقات التوضيحية التالية لمعرفة ما إذا كان بإمكاني حل هذه المشكلة.

في بعض الأحيان ، لن يعمل بشكل جيد جدًا تعديل بيان المورد عبر الإنترنت (أعني إزالة ملف finalizers وحفظه).
لذلك ، حصلت على طريقة جديدة من الآخرين.

kubectl get namespace linkerd -o json > linkerd.json

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

بعد تشغيل هذا الأمر ، يجب أن تكون مساحة الاسم الآن غائبة عن قائمة مساحات الأسماء الخاصة بك .. وهي تعمل بالنسبة لي.

ليس فقط namespace ولكن أيضًا دعم الموارد الأخرى.

كنت نجما عملت

في بعض الأحيان ، لن يعمل بشكل جيد جدًا تعديل بيان المورد عبر الإنترنت (أعني إزالة ملف finalizers وحفظه).
لذلك ، حصلت على طريقة جديدة من الآخرين.

kubectl get namespace linkerd -o json > linkerd.json

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

بعد تشغيل هذا الأمر ، يجب أن تكون مساحة الاسم الآن غائبة عن قائمة مساحات الأسماء الخاصة بك .. وهي تعمل بالنسبة لي.

ليس فقط namespace ولكن أيضًا دعم الموارد الأخرى.

جربت الكثير من الحلول ولكن هذا هو الحل الذي نجح معي. شكرا لك!

curl -k -H "Content-Type: application / json" -X PUT --data-binary @ tmp.json https: // kubernetes-cluster-ip / api / v1 / namespaces / annoying-namespace-to-delete / وضع اللمسات الأخيرة

أفضل https://stackoverflow.com/a/59667608/429476

يجب أن تكون هذه هي الإجابة "المقبولة" حقًا - لقد حلت تمامًا جذور هذه المشكلة!

خذ من الرابط أعلاه:

هذه ليست الطريقة الصحيحة ، خاصة في بيئة الإنتاج.

اليوم واجهت نفس المشكلة. عن طريق إزالة المصمم النهائي ، سينتهي بك الأمر مع بقايا طعام في حالات مختلفة. يجب أن تجد في الواقع ما يمنع الحذف من الاكتمال.

راجع https://github.com/kubernetes/kubernetes/issues/60807#issuecomment -524772920

(أيضًا ، للأسف ، لا يبلغ "kubetctl get all" عن كل الأشياء ، فأنت بحاجة إلى استخدام أوامر مماثلة كما هو الحال في الرابط)

حالتي - حذف مساحة الاسم "cert-manager". في إخراج 'kubectl get apiservice -o yaml' وجدت APIService 'v1beta1.admission.certmanager.k8s.io' بالحالة = خطأ. كانت هذه الخدمة جزءًا من إدارة الشهادات ، والتي قمت بحذفها للتو. لذلك ، في غضون 10 ثوانٍ بعد حذف kubectl 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

لكن حذف مساحات الأسماء العالقة ليس حلاً جيدًا. الطريقة الصحيحة هي معرفة سبب توقفها. السبب الشائع جدًا هو وجود خدمة (خدمات) API غير متوفرة والتي تمنع الكتلة من إنهاء مساحات الأسماء.
على سبيل المثال هنا لم أحذف Knative بشكل صحيح:

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

حذفها حل المشكلة

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

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

لقد كتبت خدمة مصغرة لتشغيلها كبرنامج CronJob كل ساعة والتي تحذف تلقائيًا مساحات أسماء النطاقات.

يمكنك العثور عليها هنا: https://github.com/oze4/service.remove-terminating-namespaces

عمل جيد.

واجهت مشكلة مماثلة في 1.18 في مجموعة معمل k8s وإضافة ملاحظة ربما لمساعدة الآخرين. كنت أعمل مع مقاييس API ومع المقاييس المخصصة على وجه الخصوص. بعد حذف كائنات k8s لإعادة إنشائها ، توقف عند حذف مساحة الاسم مع ظهور خطأ يتعذر العثور على نقطة نهاية واجهة برمجة التطبيقات الخاصة بالمقاييس. بوضع ذلك مرة أخرى في مساحة اسم أخرى ، تم مسح كل شيء على الفور.

كان هذا في مساحة الاسم تحت status.conditions.message:

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

مع ذلك oneliner آخر:

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

لكن حذف مساحات الأسماء العالقة ليس حلاً جيدًا. الطريقة الصحيحة هي معرفة سبب توقفها. السبب الشائع جدًا هو وجود خدمة (خدمات) API غير متوفرة والتي تمنع الكتلة من إنهاء مساحات الأسماء.
على سبيل المثال هنا لم أحذف Knative بشكل صحيح:

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

حذفها حل المشكلة

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

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

بالتأكيد أنظف بطانة واحدة! من المهم ملاحظة أن أياً من هذه "الحلول" لا يحل المشكلة الجذرية بالفعل.

انظر هنا للحل الصحيح

هذه هي الرسالة التي يجب أن تنتشر: ابتسم: ليس "خط واحد آخر".

بالتأكيد أنظف بطانة واحدة! من المهم ملاحظة أن أياً من هذه "الحلول" لا يحل المشكلة الجذرية بالفعل.

هذا الحل يحل واحدًا من جميع الاحتمالات. للبحث عن جميع الأسباب الجذرية المحتملة وإصلاحها ، أستخدم هذا البرنامج النصي: https://github.com/thyarles/knsk

thyarles لطيفة جدا!

الرجاء عدم استخدام modify finalize لحذف مساحة الاسم. سيؤدي ذلك إلى حدوث خطأ

يرجى معرفة سبب إنهاء مساحة الاسم. اتجاهات استكشاف الأخطاء وإصلاحها المعروفة حاليًا

• إنهاء جراب
• مدير الشهادات للخطاب على الويب

أواجه نفس المشكلة:

# 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

لقد نجح هذا بالنسبة لي ، وركضت بعد التحقق من عدم وجود كائنات k8s متدلية في ns. شكر!

لقد استخدمت هذا لإزالة مساحة اسم عالقة عند تم إنهاء

مثال:

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

بالنسبة لجميع موظفي Google الذين اصطدموا بمساحات أسماء عالقة عند إنهاء على مساحات أسماء محددة لـ Rancher (مثل نظام الماشية) ، نجح الأمر المعدل التالي (الأصلي grebois) بالنسبة لي:

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

أيها الناس ، لمعلوماتك فقط ، عندما يكون الفيديو الخاص بمحادثة kubecon هذا خارجًا ، أخطط للربط به وبعض التعليقات المفيدة أعلاه ، وقفل هذه المشكلة.

لقد سجلت شرحًا لمدة 10 دقائق لما يجري وقدمته في جلسة SIG Deep Dive هذه .

هذا تعليق صحيح مع 65 صوتًا مؤيِّدًا

تم ذكر هذا المنشور الوسيط عدة مرات أعلاه ، وهو مثال على فعل الأشياء بالطريقة الصحيحة. ابحث عن خدمة api المعطلة وأصلحها.

كل الخطوط الوحيدة التي تزيل فقط النهايات في مساحة الاسم تعالج السبب الجذري وتترك مجموعتك مكسورة بمهارة ، الأمر الذي سوف يعضك لاحقًا. لذا من فضلك لا تفعل ذلك. عادة ما يكون إصلاح السبب الجذري أسهل على أي حال. يبدو أن الأشخاص يرغبون في نشر أشكال مختلفة حول هذا الموضوع على الرغم من وجود العديد من الإجابات الصحيحة في سلسلة الرسائل بالفعل ، لذلك سأغلق المشكلة الآن ، للتأكد من بقاء هذا التعليق في الأسفل.