Kubernetes: menghapus namespace yang terhenti di status "Terminating"

/ sig api-mesin

@ shean-guangchang Apakah Anda punya cara untuk mereproduksi ini?

Dan karena penasaran, apakah Anda menggunakan CRD? Kami menghadapi masalah ini sebelumnya dengan TPR.

/ jenis bug

Saya tampaknya mengalami masalah ini dengan penerapan benteng:

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

Saya pikir itu ada hubungannya dengan CRD mereka, saya melihat ini di log server 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

Saya telah menerapkan benteng ke namespace yang berbeda sekarang, tetapi saya tidak dapat membuat CRD cluster:

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

Sepertinya CRD tidak pernah dibersihkan:

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

Saya memiliki ruang nama fisi dalam keadaan yang sama:

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

Fisi juga menggunakan CRD, namun tampaknya dibersihkan.

@ Shean-guangchang - Saya memiliki masalah yang sama. Saya telah menghapus semua yang ada di bawah namespace secara manual, menghapus dan membersihkan semuanya dari "helm" dan memulai ulang node master satu per satu dan itu memperbaiki masalah.

Saya membayangkan apa yang saya temui ada hubungannya dengan "ark", "tiller" dan Kuberenets semua bekerja bersama (saya bootstrap menggunakan helm dan didukung menggunakan bahtera) jadi ini mungkin bukan masalah Kuberenets per kata, di sisi lain tangan, sangat tidak mungkin untuk memecahkan masalah karena tidak ada log yang relevan.

jika itu adalah yang terbaik, lihat ini: https://github.com/rook/rook/issues/1488#issuecomment -365058080

Saya rasa itu masuk akal, tetapi tampaknya bermasalah karena mungkin saja membuat namespace menjadi keadaan yang tidak dapat dihapus.

Saya memiliki lingkungan yang mirip (Ark & Helm) dengan @barakAtSoluto dan memiliki masalah yang sama. Membersihkan dan memulai ulang master tidak memperbaikinya untuk saya. Masih terjebak saat mengakhiri.

Saya juga mengalami hal itu saat mencoba menciptakan kembali masalahnya. Saya akhirnya harus membuat cluster baru ....
Kecualikan - default, kube-system / public dan semua namespace terkait bahtera dari backup dan restore untuk mencegah hal ini terjadi ...

Saya juga melihat ini juga, pada cluster yang ditingkatkan dari 1.8.4 menjadi 1.9.6. Saya bahkan tidak tahu log apa yang harus dilihat

Masalah yang sama di 1.10.1 :(

Masalah yang sama di 1.9.6

Edit: Namespace tidak dapat dihapus karena beberapa pod macet. Saya melakukan penghapusan dengan --grace-period = 0 - force pada mereka semua dan setelah beberapa menit namespace juga dihapus.

Hei,

Saya mengalami hal ini berulang kali dan seringkali ada masalah dengan finalisator.

Jika namespace macet, coba kubectl get namespace XXX -o yaml dan periksa apakah ada finalizer di atasnya. Jika demikian, edit namespace dan hapus finalizer (dengan meneruskan array kosong) dan namespace dihapus

@xetys apakah aman? dalam kasus saya hanya ada satu finalizer bernama "kubernetes".

Aneh, saya belum pernah melihat finalis seperti itu. Saya hanya bisa berbicara berdasarkan pengalaman saya. Saya melakukannya beberapa kali di cluster produksi dan cluster tersebut masih hidup

Masalah yang sama di 1.10.5. Saya mencoba semua saran dalam masalah ini tanpa hasil. Saya bisa menyingkirkan pod, tetapi namespace masih menggantung.

Sebenarnya, ns juga terhapus setelah beberapa saat.

Akan lebih baik untuk memahami apa yang menyebabkan perilaku ini, satu-satunya finalizer yang saya miliki adalah kubernetes. Saya juga memiliki webhook dinamis, apakah ini terkait?

@xetys Nah, akhirnya saya menggunakan trik Anda pada replika di dalam namespace itu. Mereka memiliki beberapa finalizer khusus yang mungkin sudah tidak ada lagi, jadi saya tidak dapat menghapusnya. Ketika saya menghapus referensi ke finalizer itu, mereka menghilang dan begitu pula namespace. Terima kasih! :)

Masalah yang sama pada cluster 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"}

Memiliki masalah yang sama pada cluster bare metal:

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

Namespace saya terlihat seperti ini:

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

Ini sebenarnya namespace kedua saya mengalami masalah ini.

Coba ini untuk mendapatkan daftar sebenarnya dari semua hal di namespace Anda: https://github.com/kubernetes/kubectl/issues/151#issuecomment -402003022

Kemudian untuk setiap objek lakukan kubectl delete atau kubectl edit untuk menghapus finalizer.

menghapus penginisialisasi melakukan trik untuk saya ...

Ketika saya melakukan kubectl edit namespace annoying-namespace-to-delete dan menghapus finalizer, mereka ditambahkan kembali ketika saya memeriksa dengan kubectl get -o yaml .

Juga, ketika mencoba apa yang Anda sarankan @adampl saya tidak mendapatkan output (menghapus --ignore-not-found mengonfirmasi tidak ada sumber daya yang ditemukan di namespace, jenis apa pun).

@ManifoldFR , saya memiliki masalah yang sama seperti masalah Anda dan saya berhasil membuatnya bekerja dengan membuat panggilan API dengan file json.
kubectl get namespace annoying-namespace-to-delete -o json > tmp.json
lalu edit tmp.json dan hapus "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

dan itu harus menghapus namespace Anda,

@slassh Berhasil ! Seharusnya terpikir untuk melakukan panggilan API: terima kasih banyak! Kami akan menyanyikan pujian Anda selamanya

Masalah ada di v1.11.1. Saya sempat terjebak dalam penempatan peternak / helm dokuwiki. Pertama-tama saya harus menghapus paksa pod seperti yang disarankan oleh @siXor dan kemudian mengikuti saran @slassh . Semuanya baik-baik saja sekarang.

@slassh bagaimana cara melihat kubernetes-cluster-ip? saya menggunakan salah satu node ip yang digunakan menggantikan kubernetes cluster, dan melaporkan 404.

hai @jiuchongxiao , dengan kubernetes-cluster-ip yang saya maksud adalah salah satu ip master node Anda.
maaf jika membingungkan!

Jika Anda menjalankan 'kubectl proxy' terlebih dahulu, Anda dapat mengarahkan curl ke http://127.0.0.1 : 8001 / api / v1 / namespaces / mengganggu-namespace-to-delete / finalize. Saya tidak bisa mendapatkan otentikasi untuk bekerja sampai saya melakukannya dengan cara itu.

tips bagus @ 2stacks. Hanya perlu mengganti https menjadi http .

Saya masih melihat masalah ini di 1.11.2.

Untuk memberikan lebih banyak konteks untuk mereproduksi, saya melihat ini hanya dengan CRD. Dengan menghapus objek CRD, saya mendapat keadaan aneh jika objek yang dimilikinya tidak dihapus. Saya tidak memperhatikan jadi saya mengeluarkan delete untuk namespace. Kemudian saya menghapus semua objek di namespace dengan kubectl delete all --all -n my-namespace . Pada saat itu, penghapusan namespace macet. Saya harap ini membantu dalam beberapa hal.

Dengan melihat log, saya baru mengetahui bahwa masalah khusus ini terkait dengan manajer pengontrol yang tidak sehat. Dalam kasus saya, kemungkinan besar itu bukan bug. Ketika manajer pengontrol naik lagi semuanya sudah dibersihkan dengan benar.

@slassh Solusi sempurna! Terima kasih banyak!!!!

Saya juga melihat masalah ini dengan 1.10.x. Saya menemukan komentar @slassh sebagai solusi yang hanya menyembunyikan masalah sebenarnya. Mengapa namespace terjebak di Terminating ?

Kami menemukan alasan penghapusan namespace yang macet dalam kasus kami (@palmerabollo)

Ketika namespace memiliki finalizer kubernetes , itu berarti masalah internal dengan API Server.

Jalankan kubectl api-resources , jika mengembalikan seperti berikut, itu berarti API khusus tidak dapat dijangkau.

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

Jalankan kubectl get apiservices v1beta1.metrics.k8s.io -o yaml , untuk memeriksa kondisi statusnya.

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

Kesalahan di atas seharusnya disebabkan oleh crashloopbackoff yang memengaruhi server metrik. Ini akan serupa untuk API khusus lainnya yang terdaftar di Kubernetes.

Periksa kesehatan layanan Anda di kube-system untuk memulihkan operasi runtime cluster seperti menghapus namespace.

Saya menghadapi masalah ini di v1.11.3. Di finalisator hanya kubernetes yang ada untuk namespace bermasalah.

spec:
  finalizers:
  - kubernetes

@slassh Terima kasih banyak, solusi Anda berfungsi dengan baik!
Saya memiliki masalah yang sama di cluster saya dengan bahtera, anakan, dan kubed. Saya menduga masalahnya mungkin api dari kubed yang memberikan kesalahan, meskipun tidak yakin mengapa hal itu berdampak pada penghapusan namespace lain.

@javierprovecho Saya hanya bermain-main dengan server metrik dan karena tidak berfungsi saya mencoba untuk menghapus layanan dan yang lainnya tetapi namespace saya masih tidak dapat dihapus, kesalahannya

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

Apakah Anda tahu cara memulihkan dari keadaan ini?

sunting: Saya menemukan ... Saya harus menghapus _everything_ bahkan dari jarak jauh yang terkait dengan metrik / HPA dan kemudian memulai ulang seluruh bidang kontrol (harus menghapus semua replika saya, sebelum mem-boot mereka kembali.) ini termasuk menghapus apiservice v1beta1.metrics.k8s.io itu sendiri.

@ 2rs2

$ kubectl delete apiservice v1beta1.metrics.k8s.io

Dengan menyingkirkan layanan API metrics yang tidak berfungsi, manajer-pengontrol akan dapat menghapus namespace yang sudah usang.

Tidak perlu memulai ulang bidang kontrol.

@antoineco tidak, itu perlu; Saya menghapus apiservice dan menunggu cukup lama tetapi namespace tidak akan dihapus sampai saya memulai ulang bidang kontrol.

pertama, ambil kopi kecil dan rileks, sekarang pergi ke node master k8s Anda

1. kubectl cluster-info
   Master Kubernetes berjalan di https: // localhost : 6443
   KubeDNS berjalan di https: // localhost : 6443 / api / v1 / namespaces / kube-system / services / kube- dns: dns / proxy

Untuk men-debug dan mendiagnosis masalah cluster lebih lanjut, gunakan 'kubectl cluster-info dump'.

1. sekarang jalankan kube-proxy
   kubectl proxy &
   Mulai melayani di 127.0.0.1:8001

simpan ID untuk menghapusnya nanti :)

1. temukan ruang-nama Anda yang memutuskan tidak untuk dihapus :) bagi kami itu akan menjadi sistem ternak
   kubectl mendapatkan ns
   Penghentian sistem ternak 1d

taruh di file

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

1. edit file dan hapus finalizer
   },
   "spec": {
   "finalisator": [
   "kubernetes"
   ]
   },
   setelah diedit akan terlihat seperti ini 👍
   },
   "spec": {
   "finalisator": [
   ]
   },
   kita hampir sampai 👍

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

dan itu hilang 👍

Hei, finalis kubernetes ada di sana karena suatu alasan. Bagi kami, itu adalah nama layanan API metrik yang salah dikonfigurasi. Mungkin bagi Anda ada hal lain, yang dapat Anda temukan dengan melihat log bidang kontrol Anda. Tanpa konfirmasi bug, menghapus finalizer dapat menghasilkan konsekuensi yang tidak diinginkan seperti meninggalkan barang yang dibuat yang tidak lagi dapat diakses lagi untuk tujuan penghapusan.

karena masalah ini masih terbuka:
dalam cluster minikube saya berjalan dengan "tidak ada", ini terjadi setelah host bangun dari hibernasi.

asumsi saya:
dalam kasus saya, hibernasi memicu masalah yang sama, swap yang diaktifkan akan dilakukan.

yang menghasilkan asumsi:
swap mungkin diaktifkan di cluster yang terpengaruh?

tapi ini hanya dugaan. yang penting bagi saya, dan siapa pun yang mendapatkan bug ini dengan pengaturan lokal saya: hibernate buruk untuk kubernetes .

pertama, ambil kopi kecil dan rileks, sekarang pergi ke node master k8s Anda

1. kubectl cluster-info
   Master Kubernetes berjalan di https: // localhost : 6443
   KubeDNS berjalan di https: // localhost : 6443 / api / v1 / namespaces / kube-system / services / kube- dns: dns / proxy

Untuk men-debug dan mendiagnosis masalah cluster lebih lanjut, gunakan 'kubectl cluster-info dump'.

1. sekarang jalankan kube-proxy
   kubectl proxy &
   Mulai melayani di 127.0.0.1:8001

simpan ID untuk menghapusnya nanti :)

1. temukan ruang-nama Anda yang memutuskan tidak untuk dihapus :) bagi kami itu akan menjadi sistem ternak
   kubectl mendapatkan ns
   Penghentian sistem ternak 1d

taruh di file

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

1. edit file dan hapus finalizer
   },
   "spec": {
   "finalisator": [
   "kubernetes"
   ]
   },
   setelah diedit akan terlihat seperti ini 👍
   },
   "spec": {
   "finalisator": [
   ]
   },
   kita hampir sampai 👍

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

dan itu hilang 👍

Bagus!!
Bekerja

Saya mengalami masalah ini secara berkala jika kami mengubah instance gcloud kami (misalnya mengupgrade node). Ini menggantikan node lama dari gcloud instances list dengan yang baru tetapi membiarkan pod di namespace k8s menggantung:

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

Ini kemudian meninggalkan polong dalam keadaan tidak diketahui:

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

Karena itu, namespace tidak akan pernah selesai dihentikan. Tidak yakin apakah ini berarti kami harus mengubah finalizer kami atau jika ada bug aktual terkait penghentian yang seharusnya menangani pod dalam status UNKNOWN (atau jika harus ada cara untuk memaksa penghentian namespace untuk kasus seperti ini ).

Saya mengalami masalah ini secara berkala jika kami mengubah instance gcloud kami (misalnya mengupgrade node). Ini menggantikan node lama dari gcloud instances list dengan yang baru tetapi membiarkan pod di namespace k8s menggantung:

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

Ini kemudian meninggalkan polong dalam keadaan tidak diketahui:

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

Karena itu, namespace tidak akan pernah selesai dihentikan. Tidak yakin apakah ini berarti kami harus mengubah finalizer kami atau jika ada bug aktual terkait penghentian yang seharusnya menangani pod dalam status UNKNOWN (atau jika harus ada cara untuk memaksa penghentian namespace untuk kasus seperti ini ).

keren itu bukan masalah yang sama
Anda perlu menempatkan node dalam mode pemeliharaan dan setelah itu dalam mode pemeliharaan semua pod akan dievakuasi dan kemudian Anda dapat menghapus / meningkatkan

lihat, https://kubernetes.io/docs/concepts/workloads/controllers/garbage-collection/ ,
edit sumber daya dan hapus metadata.finalizers, dan hapus crd yang tidak berguna, Anda dapat menghapusnya secara paksa

Tapi apa sebenarnya yang dilakukan finalis kubernetes ? Apakah ada risiko bahwa sumber daya tidak dibersihkan dengan benar dengan peretasan ini?

Untuk benteng terjebak menghentikan ini membantu https://github.com/rook/rook/blob/master/Documentation/ceph-teardown.md

curl -k -H "Jenis-Konten: application / json" -X PUT --data-binary @ tmp.json https: // kubernetes-cluster-ip / api / v1 / namespaces / mengganggu-namespace-to-delete / menyelesaikan

Kesalahan dari server (NotFound): ruang nama "mengganggu-namespace-untuk-menghapus" tidak ditemukan

pertama, ambil kopi kecil dan rileks, sekarang pergi ke node master k8s Anda

1. kubectl cluster-info
   Master Kubernetes berjalan di https: // localhost : 6443
   KubeDNS berjalan di https: // localhost : 6443 / api / v1 / namespaces / kube-system / services / kube- dns: dns / proxy

Untuk men-debug dan mendiagnosis masalah cluster lebih lanjut, gunakan 'kubectl cluster-info dump'.

1. sekarang jalankan kube-proxy
   kubectl proxy &
   Mulai melayani di 127.0.0.1:8001

simpan ID untuk menghapusnya nanti :)

1. temukan ruang-nama Anda yang memutuskan tidak untuk dihapus :) bagi kami itu akan menjadi sistem ternak
   kubectl mendapatkan ns
   Penghentian sistem ternak 1d

taruh di file

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

1. edit file dan hapus finalizer
   },
   "spec": {
   "finalisator": [
   "kubernetes"
   ]
   },
   setelah diedit akan terlihat seperti ini 👍
   },
   "spec": {
   "finalisator": [
   ]
   },
   kita hampir sampai 👍

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

dan itu hilang 👍

Nilai tidak valid: "Validasi gagal file yang diedit": ValidationError (Namespace.spec): jenis tidak valid untuk io.k8s.api.core.v1.NamespaceSpec: mendapat "string", diharapkan "peta"

Jika Anda memiliki banyak ruang nama yang macet di Penghentian, Anda dapat mengotomatiskan ini:

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

pastikan bahwa semua ruang nama yang ingin Anda hapus finalizer benar-benar Terminating .

Anda membutuhkan berjalan kubectl proxy dan jq untuk bekerja di atas.

Dalam kasus kami, layanan api metrik sedang tidak aktif dan saya dapat melihat log kesalahan ini dari pencatatan verbose

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

Setelah memperbaiki layanan metrik, pengakhiran selesai.
Tidak begitu yakin mengapa penghapusan bergantung pada layanan metrik, juga tertarik untuk mengetahui cara kerjanya jika layanan metrik tidak diinstal pada kluster

Tidak begitu yakin mengapa penghapusan bergantung pada layanan metrik,

@manojbadam karena metrik terdaftar di server api, saat melakukan penghapusan namespace, ia harus menanyakan bahwa api eksternal untuk (namespaced) sumber daya yang akan dihapus (jika ada) terkait dengan namespace itu. Jika server ekstensi tidak tersedia, Kubernetes tidak dapat menjamin bahwa semua objek telah dihapus, dan tidak memiliki mekanisme persisten (dalam memori atau disk) untuk direkonsiliasi nanti karena objek root akan dihapus. Itu terjadi dengan layanan ekstensi api terdaftar.

Karena saya terus-menerus mengalami ini, saya mengotomatiskan ini dengan skrip shell kecil:

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

Ia mengambil proyek, memperbaiki JSON, memulai dan menghentikan "kubectl proxy" dengan benar,…

Terima kasih kepada semua orang yang mengarahkan saya ke arah yang benar!

Karena saya terus-menerus mengalami ini, saya mengotomatiskan ini dengan skrip shell kecil:

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

Ia mengambil proyek, memperbaiki JSON, memulai dan menghentikan "kubectl proxy" dengan benar,…

Terima kasih kepada semua orang yang mengarahkan saya ke arah yang benar!

Pahlawanku! <3

Saya mengalami masalah ini juga. Saya menggunakan Google Kubernetes Engine dan menggunakan Terraform untuk menjalankan cluster Kubernetes dan untuk membuat namespace dan pod di dalam cluster. Masalahnya dimulai beberapa saat setelah menjalankan terraform destroy .

Dalam kasus saya, ini ternyata menjadi masalah dengan urutan di mana Terraform mengeksekusi penghancuran. Terraform menghapus kumpulan node terlebih dahulu, lalu menghapus namespace dan pod. Namun karena menghapus kumpulan node (satu-satunya), cluster Kubernetes rusak, dan itulah yang menyebabkan penghapusan namespace macet saat "dihentikan" selamanya.

@FooBarWidget masalah yang sama untuk saya :(

Karena saya terus-menerus mengalami ini, saya mengotomatiskan ini dengan skrip shell kecil:

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

Ia mengambil proyek, memperbaiki JSON, memulai dan menghentikan "kubectl proxy" dengan benar,…

Terima kasih kepada semua orang yang mengarahkan saya ke arah yang benar!

[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

Saya mendapat kode pengembalian 403, apa yang harus saya lakukan :(

Karena saya terus-menerus mengalami ini, saya mengotomatiskan ini dengan skrip shell kecil:
https://github.com/ctron/kill-kube-ns/blob/master/kill-kube-ns
Ia mengambil proyek, memperbaiki JSON, memulai dan menghentikan "kubectl proxy" dengan benar,…
Terima kasih kepada semua orang yang mengarahkan saya ke arah yang benar!

[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

Saya mendapat kode pengembalian 403, apa yang harus saya lakukan :(

Terima kasih Tuhan, namespace penghentian akhirnya hilang. Metode berikut melakukan trik untuk saya.

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

Saya memiliki masalah yang sama tetapi saya tidak melihat layanan metrik apa pun.

Saya bermain-main dengan k8s dari digitalocean dan gitlab auto devops. Asumsi saya adalah beberapa penyimpanan gumpalan digitalocean tetapi saya bingung bagaimana menganalisis atau memperbaikinya.

@ mingxingshi tx. Melakukan edit namespace yang tidak berhasil. Skrip Anda berhasil.

Wow, akhirnya bisa dihilangkan. Terima kasih atas perintah @mingxingshi !

Solusi bagi saya adalah:

kubectl delete apiservice v1beta1.metrics.k8s.io

hanya berpikir saya harus meninggalkan pengalaman saya tentang ini di sini:

saya melakukan terraform apply dengan sumber daya berikut:

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

tetapi saya seorang helm newb dan memiliki template yang memiliki template di dalamnya yang membuat namespace bernama servicer . Hal ini menyebabkan terraform dan k8s masuk ke status buruk ini di mana terraform akan gagal, kemudian k8s akan meninggalkan namespace servicer secara permanen di negara bagian Terminating . Melakukan apa yang disarankan @mingxingshi di atas membuat namespace berhenti, karena tidak ada sumber daya yang menyertainya.

masalah ini berhenti terjadi pada saya ketika saya menghapus template yang membuat namespace dan membiarkannya mengarahkan untuk membuatnya.

Masalahnya benar-benar berulang bagi saya. Pertama, kloning operator prometheus . Kemudian:

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

Hang. Namun, jika saya menggunakan kubectl delete -f manifests/ , maka pembersihan berhasil.

Ya, memiliki hubungan yang sama dengan prometheus-operator. Perlu kubectl delete -f manifests/ untuk melepaskan.
Saya pikir ada beberapa finalisator dalam prometheus CRD yang tidak berfungsi, dalam skenario khusus ini hampir tidak ada kesalahan Kubernetes. Namun kubernetes seharusnya mempermudah menemukan pelakunya, karena panjang utas ini menunjukkan bahwa mungkin ada banyak penyebab dan tidak mudah untuk memahaminya di setiap skenario tertentu.

Saya seorang kubernetes noob jadi saya tidak bisa menawarkan banyak info di sini tetapi saya juga memiliki 2 namespace yang terjebak dalam status penghentian. Pengaturan kubernetes saya menggunakan IBM Cloud Private 3.1.2 Community Edition

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

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

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

Saya memiliki dua namespace yang terjebak dalam status penghentian

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

Ketika saya memeriksa finalisator seperti yang dijelaskan dalam komentar ini, saya hanya melihat 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

Terlepas dari saya mencoba menghapus kubernetes dari finalizer dan tidak berhasil. Saya juga mencoba menggunakan pendekatan json / api yang dijelaskan dalam komentar ini . Juga tidak berhasil. Saya mencoba memulai ulang semua node dan itu juga tidak berhasil.

Saya juga mencoba melakukan penghapusan paksa dan itu juga tidak berhasil

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.

Dalam kasus saya namespace adalah rook-ceph, kubectl -n rook-ceph patch cephclusters.ceph.rook.io rook-ceph -p '{"metadata":{"finalizers": []}}' --type=merge berfungsi untuk saya. Untuk kasus lain, ini harus berfungsi juga.

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

@ManifoldFR , saya memiliki masalah yang sama seperti masalah Anda dan saya berhasil membuatnya bekerja dengan membuat panggilan API dengan file json.
kubectl get namespace annoying-namespace-to-delete -o json > tmp.json
lalu edit tmp.json dan hapus "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

dan itu harus menghapus namespace Anda,

Saya memiliki beberapa masalah saat menggunakan pendekatan Anda, apa yang harus saya lakukan untuk langkah pemecahan masalah selanjutnya?

~ 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 , saya memiliki masalah yang sama seperti masalah Anda dan saya berhasil membuatnya bekerja dengan membuat panggilan API dengan file json.
kubectl get namespace annoying-namespace-to-delete -o json > tmp.json
lalu edit tmp.json dan hapus "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
dan itu harus menghapus namespace Anda,

Saya memiliki beberapa masalah saat menggunakan pendekatan Anda, apa yang harus saya lakukan untuk langkah pemecahan masalah selanjutnya?

~ 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

Masalah saya dapat diselesaikan dengan skrip ini: 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 melakukan triknya

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"

Tampaknya ruang nama sebenarnya tidak dihapus.
Dalam kasus saya, kubectl get ns tidak menunjukkan ruang nama yang dihapus tetapi kubectl get all -n <namespace> menunjukkan semua sumber daya dengan aman dan sehat.
Saya memeriksa node dan kontainer buruh pelabuhan masih berjalan ...

@glouis itu karena Anda melewati finalizer menggunakan metode di atas, jadi Kubernetes tidak punya waktu untuk menjalankan semua tugas penghapusan penting itu.

Sungguh menyedihkan melihat begitu banyak orang secara membabi buta menganjurkan metode ini tanpa memahami konsekuensinya. Ini sangat jelek dan berpotensi meninggalkan banyak sisa makanan di cluster. @javierprovecho sudah menyebutkannya di atas, dan @liggitt juga menyebutkannya di masalah GitHub lainnya.

Anda akan lebih baik memperbaiki layanan API v1beta1.metrics.k8s.io rusak , atau menghapusnya jika Anda tidak membutuhkannya.

Lihat juga # 73405

Saya kedua pesan @antoineco . Saya menguji ini di salah satu lingkungan kotak pasir kami karena kami terus-menerus terjebak dalam namespace. setelah sekitar sebulan semua daemon buruh pelabuhan membeku tanpa alasan. Ternyata kami menciptakan kebocoran memori yang sangat besar karena meninggalkan sumber daya.

Setelah banyak trial and error, dan membaca komentar-komentar ini, ternyata itu adalah definisi resource kustom untuk coreos grafana stack untuk namespace. Mendaftar CRD menunjukkan sumber daya khusus untuk namespace itu. Saya sangat beruntung bahwa nama CRD memiliki namespace di dalamnya yang macet.

Ternyata memiliki satu namespace yang macet akan menghentikan lebih banyak namespace untuk dihapus. Jadi, meskipun Anda memiliki namespace A yang tidak memiliki CRD yang membuatnya macet, dan ada namespace B dengan CRD yang macet, semua resource di A akan tetap ada sampai B hilang. Saya pikir saya harus melakukan perbaikan yang dijelaskan di atas pada namespace A meninggalkan banyak sumber daya setiap saat.

Hal yang masih membunuh saya adalah saya tidak bisa seumur hidup saya menemukan log yang menyebutkan pembersihan namespace gagal menghapus CRD, atau bahkan apa yang sedang dilakukannya. Saya harus menghabiskan satu jam hanya untuk mencari tahu CRD apa yang menempel di situ. Jika ada yang punya ide tentang cara mendapatkan info lebih lanjut, jadi saya tidak perlu menghabiskan banyak waktu untuk mencari tahu sumber macet yang akan luar biasa.

@jecafarelli petunjuk bagus untuk Cluster Produksi. Tapi malang bagi saya, saya tidak bisa membunuhnya jika tidak. Saya juga tahu saya akan membuat ulang seluruh cluster nanti.

Saya mencoba menganalisis masalah tetapi tidak ada di utas ini yang membantu saya menyelesaikannya dengan cara lain.

Solusi resmi ini membantu saya: https://success.docker.com/article/kubernetes-namespace-stuck-in-terminating
Ini tidak sama dengan kubectl edit namespace rook-ceph . Saya tidak dapat mengatasi masalah ini sampai saya PUT meminta dengan _ "finalizers" _ dihapus

ok jadi saya mengalami ini lagi dengan coreos, dan saya menggali lebih dalam. ini pasti karena definisi sumber daya cluster yang luas yang namespaced, dan lebih jauh lagi mungkin tidak dapat menghapusnya karena tidak dapat meminta info di coreos. Saya menemukan kesalahan di log apiserver yang menunjukkan kesalahan saat mencoba mendapatkan informasi tentang grup api. Saya menggunakan masalah yang dirujuk di atas untuk menghasilkan skrip cepat yang mencantumkan sumber daya yang membuat ns macet untuk saya.

sakit mungkin hanya menggunakan ini di masa depan jika saya bertemu lagi dan terus menambahkan sumber daya namespace lain yang saya hadapi.

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

Terima kasih banyak @jecafarelli , Anda membantu saya menyelesaikan masalah saya dengan cara yang benar ;-)

Saya telah menginstal cert-manager pada OpenShift cluster di dalam namespace cert-manager dan ketika saya mencoba untuk menghapus namespace ini, macet dalam keadaan penghentian. Mengeksekusi oc delete apiservices v1beta1.admission.certmanager.k8s.io sepertinya telah menyelesaikan masalah, namespace hilang.

Terima kasih banyak @jecafarelli , Anda membantu saya menyelesaikan masalah saya dengan cara yang benar ;-)

Saya telah menginstal cert-manager pada OpenShift cluster di dalam namespace cert-manager dan ketika saya mencoba untuk menghapus namespace ini, macet dalam keadaan penghentian. Mengeksekusi oc delete apiservices v1beta1.admission.certmanager.k8s.io sepertinya telah menyelesaikan masalah, namespace hilang.

Sama di sini, menjalankan kubectl delete -f https://raw.githubusercontent.com/jetstack/cert-manager/release-0.8/deploy/manifests/00-crds.yaml membantu

Menimpali untuk mengatakan saya juga menemui kesalahan ini pada versi 1.13.6 dengan GKE. Itu terjadi setelah saya menonaktifkan addon Istio GKE dengan tujuan menginstalnya secara manual untuk kontrol penuh.
Ini adalah utas masalah terpanjang yang pernah saya luangkan untuk membacanya, dan saya terpesona bahwa tidak ada konsensus atau langkah reproduksi nyata ke akar masalah ini. Sepertinya itu bisa tersandung dengan berbagai cara :(

Metode JSON dan curl / proxy yang disebutkan berkali-kali di atas dan didokumentasikan di https://success.docker.com/article/kubernetes-namespace-stuck-in-terminating adalah yang menyelamatkan saya.

Saran di https://success.docker.com/article/kubernetes-namespace-stuck-in-terminating secara aktif berbahaya, dan dapat mengakibatkan sumber daya yatim piatu tidak dibersihkan dan muncul kembali jika namespace dengan nama yang identik kemudian dibuat ulang .

Ada pekerjaan yang sedang berlangsung untuk memunculkan penyebab spesifik dari hang delete, tetapi masalah mendasar adalah bahwa ada jenis API yang tidak dapat diverifikasi untuk dibersihkan, jadi blok penghapusan namespace hingga diverifikasi.

Kami juga menekan ini dengan Knative yang menginstal layanan spasi nama ini.

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

Setelah menghapusnya, ns penyajian knative dan sekelompok namespace macet lainnya dibersihkan. Terima kasih kepada @jecafarelli untuk skrip bash di atas.
Ini versi PowerShell yang mengerikan.

$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

Saya memiliki masalah yang sama hari ini dan

@ kubernetes / sig-api-mesin-misc

Bug ini telah ada selama> setahun dan masih menjadi masalah ... Apa rencana Anda untuk mengatasi masalah masuk seperti ini?

Ini bisa membantu setidaknya memahami apa yang terjadi: https://github.com/kubernetes/kubernetes/pull/80962

Saya mengalami masalah yang sama

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

Pengontrol namespace harus melaporkan kondisi ke status namespace dan klien harus melaporkannya. Membutuhkan KEP, tetapi harus cukup jelas jika seseorang dapat mengambil dan memvalidasinya.

@timothysc ada (atau pernah) seorang PR dalam penerbangan (di suatu tempat) melakukan persis seperti yang dikatakan @smarterclayton .

Saya cukup yakin ada masalah github lain tentang ini juga?

Ya, PR ada di sini: https://github.com/kubernetes/kubernetes/pull/73405

Masalah yang saya anggap kanonik ada di sini: https://github.com/kubernetes/kubernetes/issues/70916

Inilah sumber daya yang membantu saya: https://www.ibm.com/support/knowledgecenter/en/SSBS6K_3.1.1/troubleshoot/ns_terminating.html

Ini mirip dengan solusi yang diusulkan oleh @slassh , tetapi menggunakan kubectl proxy untuk membuat proxy lokal dan membuat IP target dari perintah curl dapat diprediksi.

-

Sunting: seperti yang dinyatakan beberapa kali di bawah jawaban ini, solusi ini adalah peretasan kotor dan mungkin akan meninggalkan beberapa sumber daya yang bergantung di cluster. Gunakan dengan risiko Anda sendiri, dan mungkin hanya menggunakannya sebagai jalan keluar cepat dalam cluster pengembangan (jangan gunakan di cluster produksi).

menghapus finalizer secara langsung seperti yang dijelaskan dalam dokumen di atas dapat menimbulkan konsekuensi. Sumber daya yang menunggu penghapusan akan tetap ditentukan di cluster bahkan setelah namespace dirilis. Ini adalah tujuan finalisator. Untuk memastikan bahwa semua tanggungan dihapus sebelum mengizinkan penghapusan ns.

Menemukan solusi untuk pertanyaan serupa:

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

Menemukan solusi untuk pertanyaan serupa:

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

Terima kasih!
Ini bekerja dengan baik.
Saya membuat aplikasi sederhana menggunakan solusi ini: https://github.com/jenoOvchi/k8sdelns
Saya menggunakannya untuk penghapusan cepat dan berharap ini akan membantu seseorang.

Namespace Kubernetes 1.12.2 berada dalam status Terminating. Kadang-kadang finalisator dapat dihapus dengan memodifikasi yaml dari ns. Itu tidak bisa dihapus oleh api. Bisakah itu dihapus? Bagaimana situasinya? Sudahkah kami secara khusus melacaknya (prasyarat: tidak ada sumber daya di ns ini), saya harap saya bisa mendapatkan petunjuk, terima kasih!

Sekali lagi, jangan hapus finalizer, itu ada karena suatu alasan. Alih-alih, coba cari tahu sumber daya di NS yang menunggu penghapusan dengan:

• Memeriksa apakah ada layanan yang tidak tersedia dan karenanya tidak melayani sumber dayanya: kubectl get apiservice|grep False
• Menemukan semua sumber daya yang masih ada melalui kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get -n $your-ns-to-delete (Kudos to Jordan untuk yang satu itu)

Solusi untuk masalah ini bukanlah dengan menghubungkan pendek mekanisme pembersihan, ini untuk mengetahui apa yang mencegah pembersihan agar tidak berhasil.

Sekali lagi, jangan hapus finalizer, itu ada karena suatu alasan. Alih-alih, coba cari tahu sumber daya di NS yang menunggu penghapusan dengan:

• Memeriksa apakah ada layanan yang tidak tersedia dan karenanya tidak melayani sumber dayanya: kubectl get apiservice|grep False
• Menemukan semua sumber daya yang masih ada melalui kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get -n $your-ns-to-delete (Kudos to Jordan untuk yang satu itu)

Solusi untuk masalah ini bukanlah dengan menghubungkan pendek mekanisme pembersihan, ini untuk mengetahui apa yang mencegah pembersihan agar tidak berhasil.

Betapa benarnya dirimu.
Dalam kasus saya pod apiservice Operator Framework telah dihapus dan memblokir proses penghentian.
Menghapus sebuah perangkat lunak yang tidak digunakan (kubectl delete apiservice) memecahkan masalah.

Halo semuanya, pembekuan kode akan datang hanya dalam beberapa hari (Kamis, akhir hari, PST), jadi kami perlu memastikan bahwa masalah ini akan diselesaikan untuk v1.16 atau dipindahkan ke v1.17. Bisakah Anda mengomentari statusnya?

Apakah ini akan di-backport ke rilis GKE saat ini? Saya memiliki cluster yang memiliki beberapa namespace yang masih "Menghentikan".

@squarelover bahkan setelah melakukan ini? https://github.com/kubernetes/kubernetes/issues/60807#issuecomment -524772920

@josiahbjorgaard Saya baru saja menyetujui PR, hanya itu yang akan kami lakukan untuk 1,16.

https://github.com/kubernetes/kubernetes/pull/73405 adalah PR yang disebutkan di atas

Ini digabungkan. Saya pikir mungkin masih banyak yang bisa kami lakukan, tetapi harap berikan komentar berikutnya ke # 70916.

Sekali lagi, jangan hapus finalizer, itu ada karena suatu alasan. Alih-alih, coba cari tahu sumber daya di NS yang menunggu penghapusan dengan:

• Memeriksa apakah ada layanan yang tidak tersedia dan karenanya tidak melayani sumber dayanya: kubectl get apiservice|grep False
• Menemukan semua sumber daya yang masih ada melalui kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get -n $your-ns-to-delete (Kudos to Jordan untuk yang satu itu)

Solusi untuk masalah ini bukanlah dengan menghubungkan pendek mekanisme pembersihan, ini untuk mengetahui apa yang mencegah pembersihan agar tidak berhasil.

Dalam banyak kasus, Anda mungkin menginstal Metric-Server. Saat pod yang Anda terapkan di namespace tertentu mencari pengumpulan metrik. Itu tergantung dengan Metric-server. Jadi, bahkan setelah Anda menghapus semua sumber daya di namespace itu, metrik-server entah bagaimana ditautkan ke namespace itu. Yang akan mencegah Anda menghapus namespace.
Posting ini membantu Anda mengidentifikasi alasan mengapa Anda tidak dapat menghapus Namespace. Jadi cara ritusnya.

Coba ini untuk mendapatkan daftar sebenarnya dari semua hal di namespace Anda: kubernetes / kubectl # 151 (komentar)

Kemudian untuk setiap objek lakukan kubectl delete atau kubectl edit untuk menghapus finalizer.

Solusi ini bermanfaat bagi saya, terima kasih.

Hai kawan,

Saya membuat skrip untuk mempermudah menghapus ruang nama di status Pengakhiran: https://github.com/thyarles/knsk.

Terima kasih.

Kami bertemu dengan masalah yang sama, saat menghapus namespace, itu akan macet dalam status 'Terminating'. Saya mengikuti stpes di atas untuk menghapus 'kubernetes' di finalizer di file yaml. Berhasil.

Namun, kami tidak tahu mengapa kami perlu melakukan langkah-langkah ekstra. Itu harus melakukan kubectl delete ns foonamespace dan itu harus dihapus. Adakah yang bisa memberi saya alasan? Terima kasih!

Halo @ xzhang007 ,

Jika Anda mengetahui mengapa penghapusan namespace terhenti di status Penghentian, beri tahu saya. Saya mencoba untuk sementara jawaban yang bagus, tetapi tidak ada. Kemudian saya membuat script untuk mempermudah hidup saya sampai menemukan dan memperbaiki penyebabnya.

Terima kasih.

@thyales sepertinya saya belum menemukan jawaban sampai sekarang.

Dalam kasus kami, kami menemukan bahwa salah satu webhok dan finalizer kami
menggunakan menjangkau pod yang tinggal di ruang nama yang didapat
dihapus.
Setelah pod dihapus, penghentian macet.

>

@ xzhang007 sudahkah Anda melihat jawaban yang disediakan @alvaroaleman ? Bagi kami itu sudah cukup untuk mencari tahu apa penyebabnya.

Sekali lagi, jangan hapus finalizer, itu ada karena suatu alasan. Alih-alih, coba cari tahu sumber daya di NS yang menunggu penghapusan dengan:

• Memeriksa apakah ada layanan yang tidak tersedia dan karenanya tidak melayani sumber dayanya: kubectl get apiservice|grep False
• Menemukan semua sumber daya yang masih ada melalui kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get -n $your-ns-to-delete (Kudos to Jordan untuk yang satu itu)

Solusi untuk masalah ini bukanlah dengan menghubungkan pendek mekanisme pembersihan, ini untuk mengetahui apa yang mencegah pembersihan agar tidak berhasil.

juga, ketika masalah ini ditutup, ada tiket baru yang dirujuk untuk membahas bagaimana memperjelas mengapa namespace macet di Pengakhiran. Saya sarankan Anda melakukan percakapan di sana alih-alih masalah tertutup ini.

Ini digabungkan. Saya pikir mungkin masih banyak yang bisa kami lakukan, tetapi harap berikan komentar berikutnya ke # 70916.

@ jeff-knurek Itu seharusnya cara yang benar. Terima kasih.

Dalam kasus kami, itu adalah peningkatan yang gagal dari cert-manager yang mematahkan finalizer. 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

Hai.
Saya kasus namespace macet di Mengakhiri ketika https://github.com/rancher/rancher/issues/21546#issuecomment -553635629

Mungkin itu akan membantu.

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

Ini bekerja seperti juara bagi saya

Saya juga menghadapi masalah yang sama sekarang ini berfungsi dengan baik untuk saya. Silakan lihat dokumen berikut dan selesaikan masalah Anda

@zerkms yah, terkadang, itu saran yang sah, bukan? Seringkali finalizer yang sedang menunggu digunakan untuk melayani objek yang telah dihapus sebagai bagian dari penghapusan namespace. Dalam kasus ini, karena tidak ada gunanya menunggu lebih lama - tidak ada lagi yang bisa menyelesaikan finalisasi -, menambal objek seperti yang dijelaskan artikel _adalah satu-satunya opsi_.

Perhatikan bahwa artikel ini hanya berlaku jika masalah _tidak terselesaikan_ dengan menerapkan langkah-langkah yang tercantum di halaman Masalah yang Diketahui, ditautkan di bagian atas artikel, yang pada dasarnya merupakan saran bahwa komentar yang Anda tautkan berulang.

@zerkms yah, terkadang, itu saran yang sah, bukan? Seringkali finalizer yang sedang menunggu digunakan untuk melayani objek yang telah dihapus sebagai bagian dari penghapusan namespace

Saya belum pernah melihat hal itu benar untuk spec.finalizer pada namespace. Setiap contoh yang saya lihat telah melibatkan pengontrol pembersihan namespace, dan juga disebabkan oleh objek persisten di namespace (yang saran itu akan terdampar di etcd), atau API agregat yang tidak responsif (yang menghapus namespace spec.finalizer akan melewati menunggu, juga melepaskan sumber daya yang ada dari API itu)

Artikel ini tidak memperingatkan bahwa melewati penyelesaian namespace berisiko meninggalkan sumber daya dengan namespace terdampar di penyimpanan, dan tidak disarankan.

Saya belum pernah melihat hal itu benar untuk spec.finalizer pada namespace

Ya, benar, ini karena finalizer ini diimplementasikan oleh kubernetes itu sendiri, tetapi mungkin ada finalizer lain pada objek di dalam namespace itu, yang dapat diimplementasikan oleh objek di namespace tersebut. Salah satu contoh yang saya temui baru-baru ini adalah https://appscode.com/products/stash/ .

Ini menempatkan finalizer pada beberapa CRD-nya yang akan dilayani oleh penerapan operator simpanan. Tetapi dengan stash-operator sudah dihapus, tidak ada yang dapat menghapus tanda finalizer dari CRD tersebut dan penghapusan namespace macet. Dalam hal ini menambal finalizer tersebut (bukan pada namespace itu sendiri, tetapi pada objek tersebut) adalah satu-satunya hal yang masuk akal untuk dilakukan.

Semoga masuk akal.

Dalam hal ini menambal finalizer tersebut (bukan pada namespace itu sendiri, tetapi pada objek tersebut) adalah satu-satunya hal yang masuk akal untuk dilakukan.

Benar. Saya tidak akan keberatan dengan itu dalam skenario pembersihan "hapus semua sumber daya", tapi bukan itu yang berjalan melalui artikel terkait ... ini menjelaskan cara menghapus spec.finalizer dari namespace.

pertama, ambil kopi kecil dan rileks, sekarang pergi ke node master k8s Anda

kubectl cluster-info
Master Kubernetes berjalan di https: // localhost : 6443
KubeDNS berjalan di https: // localhost : 6443 / api / v1 / namespaces / kube-system / services / kube- dns: dns / proxy
Untuk men-debug dan mendiagnosis masalah cluster lebih lanjut, gunakan 'kubectl cluster-info dump'.

sekarang jalankan kube-proxy
kubectl proxy &
Mulai melayani di 127.0.0.1:8001
simpan ID untuk menghapusnya nanti :)

1. temukan ruang-nama Anda yang memutuskan tidak untuk dihapus :) bagi kami itu akan menjadi sistem ternak
   kubectl mendapatkan ns
   Penghentian sistem ternak 1d

taruh di file

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

edit file dan hapus finalizer
},
"spec": {
"finalisator": [
"kubernetes"
]
},
setelah diedit akan terlihat seperti ini 👍
},
"spec": {
"finalisator": [
]
},
kita hampir sampai 👍
curl -k -H "Content-Type: application / json" -X PUT --data-binary @ tmp.json http://127.0.0.1 : 8001 / api / v1 / namespaces / $ {NAMESPACE} / finalize

dan itu hilang 👍

Sekali lagi, jangan hapus finalizer, itu ada karena suatu alasan. Alih-alih, coba cari tahu sumber daya di NS yang menunggu penghapusan dengan:

• Memeriksa apakah ada layanan yang tidak tersedia dan karenanya tidak melayani sumber dayanya: kubectl get apiservice|grep False
• Menemukan semua sumber daya yang masih ada melalui kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get -n $your-ns-to-delete (Kudos to Jordan untuk yang satu itu)

Solusi untuk masalah ini bukanlah dengan menghubungkan pendek mekanisme pembersihan, ini untuk mengetahui apa yang mencegah pembersihan agar tidak berhasil.

Hai teman-teman! Saya mengikuti tip yang diberikan oleh @alvaroaleman dan saya membuat skrip yang memeriksa dan mencoba penghapusan bersih sebelum melakukan penghapusan yang sulit pada namespace yang terhenti .

Apa yang dilakukan skrip https://github.com/thyarles/knsk :

1. Periksa sumber aplikasi yang tidak tersedia dan minta untuk menghapusnya
2. Periksa sumber daya yang tertunda di namespace dan minta untuk menghapusnya
3. Tunggu sekitar 5 menit untuk melihat apakah Kubernetes melakukan penghapusan bersih jika skrip melakukan penghapusan apa pun
4. Penghapusan paksa namespace yang terhenti

Semoga membantu.

@thyarles Terima kasih banyak. Saya menggunakan cara Anda untuk memecahkan masalah.

$ kubectl dapatkan apiservices untuk memeriksa layanan mana yang tidak tersedia, hapus yang tersedia salah dengan $ kubectl delete apiservice [nama-layanan], dan setelah itu tidak akan ada masalah tentang menghapus ruang nama.

Untuk tim kami, ada 3 apiservices yang tidak tersedia, v1beta1.admission.certmanager.k8s.io, v1beta1.metrics.k8s.io, dan v1beta1.webhook.certmanager.k8s.io.

Perhatikan bahwa cluster Anda agak rusak jika apiserver metrik tidak berjalan, menghapus APIService tidak benar-benar memperbaiki akar penyebabnya.

@lavalamp metrik adalah layanan yang tidak tersedia.

Ya, yang berarti apiserver metrik tidak berjalan, yang berarti HPA tidak berfungsi di kluster Anda, dan mungkin juga hal-hal lain.

Iya. HPA tidak berfungsi sekarang. Saya tidak boleh menghapus metrik dan mencari cara untuk memperbaikinya.

@thyarles Terima kasih banyak. Saya menggunakan cara Anda untuk memecahkan masalah.

$ kubectl dapatkan apiservices untuk memeriksa layanan mana yang tidak tersedia, hapus yang tersedia salah dengan $ kubectl delete apiservice [nama-layanan], dan setelah itu tidak akan ada masalah tentang menghapus ruang nama.

Untuk tim kami, ada 3 apiservices yang tidak tersedia, v1beta1.admission.certmanager.k8s.io, v1beta1.metrics.k8s.io, dan v1beta1.webhook.certmanager.k8s.io.

@ xzhang007 senang mendengarnya! Sekarang Anda harus memeriksa mengapa v1beta1.metrics.k8s.io Anda rusak. Periksa seperti apa:

``
$ kubectl -n kube-system dapatkan semua | metrik grep

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

$ kubectl -n kube-system dapatkan semua | metrik grep

pod / metrics-server-5dcfd4dd9f-m2v9k 1/1 Berjalan 0 2d20h

layanan / metrik-server ClusterIP xx.xx.xx.xx443 / TCP 27d

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

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

Iya. HPA tidak berfungsi sekarang. Saya tidak boleh menghapus metrik dan mencari cara untuk memperbaikinya.

@ xzhang007 sebenarnya tidak berfungsi sebelum Anda melihat masalah .... Anda baru saja menyadarinya karena ini menempatkan ruang nama yang dihapus dalam mode macet. Cukup gunakan manajer paket helm untuk menerapkan kembali server metrik Anda atau cukup panggil perintah di bawah ini untuk memperbaikinya ( periksa file penerapan sebelum menerapkan ):

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

Solusi @slassh berfungsi untuk saya di Kubernetes 1.15

Hapus APIService v1beta1.metrics.k8s.io

kubectl get ns ns-to-delete -o yaml

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

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

 kubectl delete v1beta1.metrics.k8s.io APIService

Manajer sertifikat tidak tersedia mungkin karena tidak disiapkan dengan benar. Misalnya, gunakan sintaks yang salah dalam pengontrol masuk. Untuk sistem kami, itu benar

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

dan itu diubah menjadi

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

membuatnya tersedia.

Seperti yang disebutkan sebelumnya dalam edisi ini, ada cara lain untuk menghentikan namespace menggunakan API yang tidak diekspos oleh kubectl dengan menggunakan versi modern kubectl di mana kubectl replace --raw tersedia (tidak yakin dari versi mana). Dengan cara ini Anda tidak perlu menelurkan proses kubectl proxy dan menghindari ketergantungan dengan curl (yang di beberapa lingkungan seperti busybox tidak tersedia). Dengan harapan ini akan membantu orang lain, saya meninggalkan ini di sini:

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

Apakah sudah ditetapkan apakah ini masalah yang bisa diperbaiki? Tampaknya banyak solusi hacky di sini tetapi tidak ada yang mengatasi masalah mendasar yang tidak ada dari kita yang dapat menghapus ruang nama kita ....
Saya memiliki ini di cluster EKS v1.14

Apakah sudah ditetapkan apakah ini masalah yang bisa diperbaiki? Tampaknya banyak solusi yang meretas di sini tetapi tidak ada yang mengatasi masalah mendasar yang tidak ada dari kita yang dapat menghapus ruang nama kita

Masalah mendasar adalah bahwa grup API gabungan di cluster Anda tidak tersedia. Disengaja bahwa pengontrol pembersihan namespace memblokir hingga semua API tersedia, sehingga dapat memverifikasi semua resource dari semua grup API dibersihkan untuk namespace tersebut.

untuk ppl mencoba menggulung 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

Berikut skrip untuk melakukan ini secara otomatis. Membutuhkan 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

Semua orang: skrip untuk mengotomatiskan penghapusan finalizer lebih berbahaya daripada baik . Mereka mungkin meninggalkan bom waktu di apiserver gabungan yang tidak tersedia; jika seseorang membuat ulang namespace, tiba-tiba sekelompok objek lama mungkin muncul kembali.

Solusi sebenarnya adalah:

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

Semua orang: skrip untuk mengotomatiskan penghapusan finalizer lebih berbahaya daripada baik . Mereka mungkin meninggalkan bom waktu di apiserver gabungan yang tidak tersedia; jika seseorang membuat ulang namespace, tiba-tiba sekelompok objek lama mungkin muncul kembali.

Solusi sebenarnya adalah:

$ 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

Skrip ini melakukan semua pemeriksaan dan mencoba melakukan penghapusan bersih, termasuk mencari sumber daya yatim piatu. Jika pengguna ingin mengambil risiko, skrip menawarkan opsi --force untuk melakukan cara penghapusan yang tidak disarankan.

salah ketik, harus apiservices

Perintah ini menunjukkan aplikasi tidak tersedia:

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

Artikel ini pasti akan bermanfaat bagi Anda:

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

Sebenarnya yang ada adalah konflik di apiservices, mereka bisa memvalidasi status kesehatan apis di openshift:

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

api yang gagal perlu memulai ulang, memulai ulang pod atau penerapan yang dimiliki API tersebut, setelah itu coba hapus namespace.

$ oc hapus namspace

dan siap, bisnis sudah diperbaiki !!

Sangat tidak sopan menggunakan bahasa Anda sendiri di tempat di mana semua orang setuju untuk berbicara bahasa Inggris. 👎

Dimana semua orang setuju untuk berbicara bahasa Inggris?

Pada Kamis, 30 Apr 2020 pukul 17:58 theAkito [email protected] menulis:

Sangat tidak sopan menggunakan bahasa Anda sendiri di tempat di mana semua orang
setuju untuk berbicara bahasa Inggris. 👎

-
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/kubernetes/kubernetes/issues/60807#issuecomment-622137770 ,
atau berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/ALGMKB6K4OU4X3XOYMALOBLRPHYCDANCNFSM4ETUOEPA
.

>

Chris, Arsitek Utama @ brace.ai

-

Pemberitahuan Kerahasiaan: Email ini ditujukan untuk penggunaan tunggal
penerima yang dituju dan mungkin berisi rahasia, hak milik, atau
informasi istimewa. Jika Anda bukan penerima yang dimaksud, Anda adalah penerima
diberitahu bahwa setiap penggunaan, tinjauan, penyebaran, penyalinan atau tindakan yang diambil berdasarkan
pada pesan ini atau lampirannya, jika ada, dilarang. Jika tidak
penerima yang dituju, silakan hubungi pengirim melalui email balasan dan
menghancurkan atau menghapus semua salinan pesan asli dan lampirannya.

siap, permisi itu untuk kecepatan saya, sudah diperbaiki

Kami memiliki basis pengguna multi bahasa, cukup buruk bahwa tidak ada alat kami yang diinternasionalkan, setidaknya kami bisa bersikap baik di sini di github.

@tokopedia

Seperti yang disebutkan sebelumnya dalam edisi ini, ada cara lain untuk menghentikan namespace menggunakan API yang tidak diekspos oleh kubectl dengan menggunakan versi modern kubectl di mana kubectl replace --raw tersedia (tidak yakin dari versi mana). Dengan cara ini Anda tidak perlu menelurkan proses kubectl proxy dan menghindari ketergantungan dengan curl (yang di beberapa lingkungan seperti busybox tidak tersedia). Dengan harapan ini akan membantu orang lain, saya meninggalkan ini di sini:

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

Ini bekerja dengan sempurna!

Kami memiliki basis pengguna multi bahasa, cukup buruk bahwa tidak ada alat kami yang diinternasionalkan, setidaknya kami bisa bersikap baik di sini di github.

Kami memiliki basis pengguna multi bahasa, cukup buruk bahwa tidak ada alat kami yang diinternasionalkan, setidaknya kami bisa bersikap baik di sini di github.

Masih mencoba untuk mengerti. Maafkan aku. Saya mungkin telah mengklik jempol ke bawah secara tidak sengaja.
Ya, memang, perkakas belum dibuat dengan sempurna.
Itu, memberi jempol ke bawah tanpa penjelasan, tidak masuk akal.

Hampir sepanjang waktu saya mengalami masalah ini, terserah CRD. Hapus CRD jika mereka hanya digunakan di namespace itu dan kemudian Anda dapat melanjutkan dengan menghapus finalizer dan namespace.

Seperti yang disebutkan sebelumnya dalam edisi ini, ada cara lain untuk menghentikan namespace menggunakan API yang tidak diekspos oleh kubectl dengan menggunakan versi modern kubectl di mana kubectl replace --raw tersedia (tidak yakin dari versi mana). Dengan cara ini Anda tidak perlu menelurkan proses kubectl proxy dan menghindari ketergantungan dengan curl (yang di beberapa lingkungan seperti busybox tidak tersedia). Dengan harapan ini akan membantu orang lain, saya meninggalkan ini di sini:

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 Terima kasih! Ini akhirnya berhasil!

Terkadang hanya mengedit manifes sumber daya secara online tidak akan berfungsi dengan baik (maksud saya hapus finalizers diajukan dan simpan).
Jadi, saya mendapat cara baru dari orang lain.

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

Setelah menjalankan perintah itu, namespace sekarang seharusnya tidak ada dari daftar namespace Anda .. Dan itu berfungsi untuk saya.

Tidak hanya namespace tetapi juga mendukung sumber daya lainnya.

saya memperbaiki masalah dengan menghapus baris finalizers menggunakan: kubectl edit annoying-ns

Hmm ... Saya punya masalah ini sekarang :)
Hari ini saya melakukan update eks cluster saya dari 1.15 ke 1.16.
Semuanya terlihat baik-baik saja sejauh ini.
Tapi pengembangan saya dan "configcluster" adalah semacam "rusak".
Jadi saya memutuskan untuk membersihkannya.

k hapus ns configcluster
....
sekarang ini hang (3 jam +): /

$ 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

Bagaimana kita bisa lebih terpapar masalah duri di kaki ini?

Pada hari Jumat, 19 Jun 2020 jam 4:46 pagi Andreas Höhmann [email protected]
menulis:

Hmm ... Saya punya masalah ini sekarang :)
Hari ini saya melakukan update eks cluster saya dari 1.15 ke 1.16.
Semuanya terlihat baik-baik saja sejauh ini.
Tapi pengembangan saya dan "configcluster" adalah semacam "rusak".
Jadi saya memutuskan untuk membersihkannya.

k hapus ns configcluster
....
sekarang ini hang (3 jam +): /

$ kubectl dapatkan configcluster namespace -o yaml
apiVersion: v1
jenis: Namespace
metadata:
penjelasan:
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
spesifikasi:
finalisator:

• kubernetes
  status:
  kondisi:
• lastTransitionTime: "2020-06-19T09: 19: 21Z"
  pesan: 'Penemuan gagal untuk beberapa grup, 1 gagal: tidak dapat mengambil
  daftar lengkap API server: metrics.k8s.io/v1beta1: server saat ini
  tidak dapat menangani permintaan '
  alasan: DiscoveryFailed
  status: "Benar"
  ketik: NamespaceDeletionDiscoveryFailure
• lastTransitionTime: "2020-06-19T09: 19: 22Z"
  pesan: Semua jenis kube lama berhasil diurai
  alasan: ParsedGroupVersions
  status: "False"
  ketik: NamespaceDeletionGroupVersionParsingFailure
• lastTransitionTime: "2020-06-19T09: 19: 22Z"
  pesan: Semua konten berhasil dihapus
  alasan: ContentDeleted
  status: "False"
  ketik: NamespaceDeletionContentFailure
  fase: Mengakhiri

-
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/kubernetes/kubernetes/issues/60807#issuecomment-646543073 ,
atau berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/AFLKRCLHIZ77X2Z3F5GAOCTRXMXVTANCNFSM4ETUOEPA
.

@bobhenkel yah masalah ini sudah ditutup, jadi secara efektif ini berarti tidak ada masalah (sejauh menyangkut item yang dapat ditindaklanjuti). Jika Anda membutuhkan bantuan praktis untuk menghadapi situasi serupa, harap baca utas di atas, ada beberapa nasihat bagus di sana (dan juga beberapa yang buruk).

Dalam kasus saya, saya harus menghapus penyeimbang beban masuk secara manual dari konsol Layanan Jaringan GCP. Saya telah membuat frontend load balancer secara manual langsung di konsol. Setelah saya menghapus penyeimbang beban, namespace secara otomatis dihapus.

Saya curiga bahwa Kubernetes tidak ingin menghapus karena status load balancer berbeda dengan yang ada di manifes.

Saya akan mencoba untuk mengotomatiskan pembuatan frontend ingress menggunakan anotasi di sebelah untuk melihat apakah saya dapat menyelesaikan masalah ini.

Terkadang hanya mengedit manifes sumber daya secara online tidak akan berfungsi dengan baik (maksud saya hapus finalizers diajukan dan simpan).
Jadi, saya mendapat cara baru dari orang lain.

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

Setelah menjalankan perintah itu, namespace sekarang seharusnya tidak ada dari daftar namespace Anda .. Dan itu berfungsi untuk saya.

Tidak hanya namespace tetapi juga mendukung sumber daya lainnya.

Anda adalah bintang itu berhasil

Terkadang hanya mengedit manifes sumber daya secara online tidak akan berfungsi dengan baik (maksud saya hapus finalizers diajukan dan simpan).
Jadi, saya mendapat cara baru dari orang lain.

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

Setelah menjalankan perintah itu, namespace sekarang seharusnya tidak ada dari daftar namespace Anda .. Dan itu berfungsi untuk saya.

Tidak hanya namespace tetapi juga mendukung sumber daya lainnya.

Sudah mencoba banyak solusi tetapi ini yang berhasil untuk saya. Terima kasih!

curl -k -H "Jenis-Konten: application / json" -X PUT --data-binary @ tmp.json https: // kubernetes-cluster-ip / api / v1 / namespaces / mengganggu-namespace-to-delete / menyelesaikan

Lebih baik https://stackoverflow.com/a/59667608/429476

Ini harus benar-benar menjadi jawaban yang "diterima" - ini benar-benar menyelesaikan akar masalah ini!

Ambil dari tautan di atas:

Ini bukanlah cara yang benar, terutama dalam lingkungan produksi.

Hari ini saya mengalami masalah yang sama. Dengan menghapus finalizer Anda akan mendapatkan sisa makanan di berbagai negara bagian. Anda seharusnya benar-benar menemukan apa yang membuat penghapusan tidak selesai.

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

(juga, sayangnya, 'kubetctl get all' tidak melaporkan semua hal, Anda perlu menggunakan perintah serupa seperti di tautan)

Kasus saya - menghapus namespace 'cert-manager'. Pada keluaran 'kubectl get apiservice -o yaml' saya menemukan APIService 'v1beta1.admission.certmanager.k8s.io' dengan status = False. Layanan ini adalah bagian dari manajer-sertifikat, yang baru saja saya hapus. Jadi, dalam 10 detik setelah saya 'kubectl menghapus apiservice v1beta1.admission.certmanager.k8s.io', namespace menghilang.

Semoga membantu.

Dengan itu, saya menulis sedikit layanan mikro untuk dijalankan sebagai CronJob setiap jam yang secara otomatis menghapus ruang nama Pengakhiran.

Anda dapat menemukannya di sini: https://github.com/oze4/service.remove-terminating-namespaces

Saya menulis sedikit layanan mikro untuk dijalankan sebagai CronJob setiap jam yang secara otomatis menghapus ruang nama Pengakhiran.

Anda dapat menemukannya di sini: https://github.com/oze4/service.remove-terminating-namespaces

Satu lagi satu perjalanan:

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

Namun menghapus namespace yang macet bukanlah solusi yang baik. Cara yang benar adalah mencari tahu mengapa itu macet. Alasan yang sangat umum adalah tidak tersedia layanan API yang mencegah cluster menyelesaikan namespace.
Misalnya di sini saya belum menghapus Knative dengan benar:

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

Menghapusnya memecahkan masalah

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  

Saya menulis sedikit layanan mikro untuk dijalankan sebagai CronJob setiap jam yang secara otomatis menghapus ruang nama Pengakhiran.

Anda dapat menemukannya di sini: https://github.com/oze4/service.remove-terminating-namespaces

kerja bagus.

Saya memiliki masalah serupa di 1,18 di cluster lab k8s dan menambahkan catatan untuk mungkin membantu orang lain. Saya telah bekerja dengan Metrics API dan khususnya dengan metrik kustom. Setelah menghapus objek k8s tersebut untuk membuatnya kembali, ia terhenti saat menghapus namespace dengan kesalahan bahwa titik akhir api metrik tidak dapat ditemukan. Menempatkannya kembali di namespace lain, semuanya segera beres.

Ini ada di namespace di bawah 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

Satu lagi satu perjalanan:

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

Namun menghapus namespace yang macet bukanlah solusi yang baik. Cara yang benar adalah mencari tahu mengapa itu macet. Alasan yang sangat umum adalah tidak tersedia layanan API yang mencegah cluster menyelesaikan namespace.
Misalnya di sini saya belum menghapus Knative dengan benar:

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

Menghapusnya memecahkan masalah

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  

Pasti satu kapal terbersih! Penting untuk diperhatikan bahwa tidak satu pun dari "solusi" ini yang benar-benar menyelesaikan akar masalah.

Lihat di sini untuk solusi yang benar

Itulah pesan yang harus disebarkan: smile: bukan "yet another one liner".

pasti satu liner terbersih! Penting untuk diperhatikan bahwa tidak satu pun dari "solusi" ini yang benar-benar menyelesaikan akar masalah.

Solusi ini memecahkan salah satu dari semua kemungkinan. Untuk mencari semua kemungkinan akar penyebab dan memperbaikinya, saya menggunakan skrip ini: https://github.com/thyarles/knsk

@thyarles sangat bagus!

Harap jangan gunakan modify finalize untuk menghapus namespace. Itu akan menyebabkan kesalahan

Temukan penyebab penghentian namespace. Petunjuk pemecahan masalah yang saat ini diketahui

• pod mengakhiri
• blokir webhook manajer-certe

Saya mengalami masalah yang sama:

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

Anda dapat menggunakan etcdctl untuk menemukan sumber daya yang tidak terhapus

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>

Cukup salin dan tempel di terminal Anda

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

ini berhasil untuk saya, dan saya berlari setelah memverifikasi tidak ada objek k8 yang menggantung di ns. Terima kasih!

Saya menggunakan ini untuk menghapus namespace yang macet di Dihentikan

contoh:

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

Untuk semua googler yang menemukan ruang nama yang macet di Penghentian di ruang nama khusus Peternakan (misalnya sistem-ternak), perintah yang dimodifikasi berikut (asli grebois) berfungsi untuk saya:

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

Teman-teman, FYI saja, ketika video untuk kubecon talk ini keluar, saya berencana untuk menautkannya dan beberapa komentar bermanfaat di atas, dan mengunci masalah ini.

Saya merekam 10 menit penjelasan tentang apa yang sedang terjadi dan mempresentasikannya pada sesi Deep Dive SIG ini .

Ini komentar yang benar dengan 65 suara positif

Disebutkan beberapa kali di atas, postingan media ini adalah contoh cara melakukan sesuatu dengan benar. Temukan dan perbaiki layanan api yang rusak.

Semua satu liner yang hanya menghapus finalizer di namespace mengatasi akar penyebab dan meninggalkan cluster Anda secara halus rusak, yang akan menggigit Anda nanti. Jadi tolong jangan lakukan itu. Perbaikan akar penyebab biasanya lebih mudah. Tampaknya orang-orang suka memposting variasi pada tema ini meskipun sudah ada banyak jawaban yang benar di utas, jadi saya akan mengunci masalah sekarang, untuk memastikan bahwa komentar ini tetap di bagian bawah.