Kubernetes: удаление пространства имен, застрявшего в состоянии "Завершение"

/ sig api-machinery

@ shean-guangchang У вас есть способ воспроизвести это?

И из любопытства используете ли вы какие-нибудь CRD? Мы уже сталкивались с этой проблемой с TPR ранее.

/ добрый баг

Кажется, у меня возникла эта проблема с размещением ладьи:

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

Я думаю, это как-то связано с их CRD, я вижу это в журналах сервера API:

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

Сейчас я развернул ладью в другом пространстве имен, но я не могу создать кластерный CRD:

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

Похоже, CRD так и не очистили:

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

У меня есть пространство имен деления в аналогичном состоянии:

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

Деление также использует CRD, однако, похоже, они очищаются.

@ shean-guangchang - У меня была такая же проблема. Я удалил все в пространствах имен вручную, удалил и очистил все от "helm" и перезапустил главные узлы один за другим, и это устранило проблему.

Я предполагаю, что то, с чем я столкнулся, как-то связано с "ark", "tiller" и Kuberenets, которые работают вместе (я загрузился с помощью helm и сделал резервную копию с помощью ark), так что это может не быть проблемой Kuberenets, скажем, с другой стороны, было практически невозможно устранить неполадки из-за отсутствия соответствующих журналов.

если ладья, взгляните на это: https://github.com/rook/rook/issues/1488#issuecomment -365058080

Я предполагаю, что это имеет смысл, но кажется ошибочным, что можно перевести пространство имен в состояние, которое невозможно удалить.

У меня аналогичная среда (Ark & Helm) с @barakAtSoluto и такая же проблема. Однако очистка и перезапуск мастеров не помогли мне. Все еще не могу завершить работу.

У меня тоже было это, когда я пытался воссоздать проблему. В конце концов мне пришлось создать новый кластер ....
Исключить - default, kube-system / public и все связанные пространства имен ark из резервного копирования и восстановления, чтобы этого не произошло ...

Я тоже это вижу на кластере, обновленном с 1.8.4 до 1.9.6. Я даже не знаю, какие журналы смотреть

Та же проблема с 1.10.1 :(

Та же проблема с 1.9.6

Изменить: пространство имен не может быть удалено из-за зависания некоторых модулей. Я удалил их все с помощью --grace-period = 0 --force, и через пару минут пространство имен также было удалено.

Привет,

У меня это снова и снова, и в большинстве случаев возникают проблемы с финализаторами.

Если пространство имен застряло, попробуйте kubectl get namespace XXX -o yaml и проверьте, есть ли на нем финализатор. Если это так, отредактируйте пространство имен и удалите финализатор (передав пустой массив), а затем пространство имен будет удалено.

@xetys это безопасно? в моем случае есть только один финализатор с именем «кубернетес».

Странно, такого финализатора не встречал. Я просто могу говорить, основываясь на своем опыте. Я делал это несколько раз в производственном кластере, и он все еще жив

Та же проблема с 1.10.5. Я испробовал все советы в этом вопросе, но безрезультатно. Мне удалось избавиться от модулей, но пространство имен все еще висит.

Собственно, через некоторое время нс тоже удалили.

Было бы неплохо понять, что вызывает такое поведение, единственный финализатор, который у меня был, - это кубернеты. У меня также есть динамические веб-перехватчики, могут ли они быть связаны?

@xetys Ну, наконец, я применил ваш трюк с репликами внутри этого пространства имен. У них был какой-то специальный финализатор, которого, вероятно, больше не существовало, поэтому я не мог их удалить. Когда я удалил ссылки на этот финализатор, они исчезли, как и пространство имен. Благодаря! :)

Та же проблема в кластере EKS 1.10.3:

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

Та же проблема на кластере без оборудования:

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

Мое пространство имен выглядит так:

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

На самом деле это второе пространство имен, с которым у меня возникла эта проблема.

Попробуйте это, чтобы получить фактический список всего в вашем пространстве имен: https://github.com/kubernetes/kubectl/issues/151#issuecomment -402003022

Затем для каждого объекта выполните kubectl delete или kubectl edit чтобы удалить финализаторы.

удаление инициализатора помогло мне ...

Когда я делаю kubectl edit namespace annoying-namespace-to-delete и удаляю финализаторы, они снова добавляются, когда я проверяю с помощью kubectl get -o yaml .

Кроме того, при попытке того, что вы предложили @adampl, я не получаю вывода (удаление --ignore-not-found подтверждает, что в пространстве имен не найдены ресурсы любого типа).

@ManifoldFR , у меня была та же проблема, что и у вас, и мне удалось заставить ее работать, выполнив вызов API с файлом json.
kubectl get namespace annoying-namespace-to-delete -o json > tmp.json
затем отредактируйте tmp.json и удалите "kubernetes"

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

и он должен удалить ваше пространство имен,

@slassh Сработало ! Надо было подумать о вызове API: большое спасибо! Мы будем петь тебе хвалу вечно

Проблема существует в v1.11.1. У меня застряло развертывание dokuwiki на ранчо / у руля. Сначала мне пришлось принудительно удалить модули, как это было предложено @slassh . Теперь все хорошо.

@slassh как посмотреть кубернетес-кластер-ip? Я использую один из IP-адресов узла, на котором развернута замена кластера Kubernetes, и он сообщает 404.

привет @jiuchongxiao , под kubernetes-cluster-ip я имел в виду IP одного из ваших мастеров узлов.
извините, если это сбивает с толку!

Если вы сначала запустите kubectl proxy, вы можете направить curl на http://127.0.0.1 : 8001 / api / v1 / namespaces / annoying-namespace-to-delete / finalize. Я не мог заставить аутентификацию работать, пока не сделал это таким образом.

хорошие советы @ 2stacks. Просто нужно заменить https на http .

Я все еще вижу эту проблему в 1.11.2.

Чтобы дать больше контекста для воспроизведения, я видел это только с CRD. Удалив объект CRD, я оказался в странном состоянии, когда принадлежащие ему объекты не были удалены. Я не заметил, поэтому удалил пространство имен. Затем я удалил все объекты в пространстве имен с помощью kubectl delete all --all -n my-namespace . На этом этапе удаление пространства имен застряло. Надеюсь, это хоть как-то поможет.

Просматривая журналы, я только что обнаружил, что эта конкретная проблема связана с неисправностью диспетчера контроллеров. В моем случае, скорее всего, это не была ошибка. Когда диспетчер контроллеров снова заработал, все было правильно очищено.

@slassh Отличное решение! большое тебе спасибо!!!!

Я также вижу эту проблему с 1.10.x. Я считаю комментарий @slassh обходным путем, который скрывает только реальную проблему. Почему пространства имен застревают в Terminating ?

Мы обнаружили причину зависания удаленных пространств имен в нашем случае (@palmerabollo)

Если у пространства имен есть финализатор kubernetes , это означает, что это внутренняя проблема с сервером API.

Запустите kubectl api-resources , если он вернет следующее, это означает, что пользовательский API недоступен.

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

Запустите kubectl get apiservices v1beta1.metrics.k8s.io -o yaml , чтобы проверить условия его статуса.

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

Вышеупомянутая ошибка должна быть вызвана аварийным завершением работы, затрагивающим metrics-server. Это будет похоже на другие пользовательские API, зарегистрированные в Kubernetes.

Проверьте работоспособность своих служб в kube-system для восстановления операций среды выполнения кластера, таких как удаление пространств имен.

Я столкнулся с этой проблемой в версии 1.11.3. В финализаторах присутствуют только кубернеты для проблемного пространства имен.

spec:
  finalizers:
  - kubernetes

@slassh Большое спасибо, ваше решение работает хорошо!
У меня такая же проблема в моем кластере с ковчегом, румпелем и кубедом. Я подозреваю, что проблема может быть связана с api kubed, который выдает ошибку, хотя я не уверен, почему это влияет на удаление другого пространства имен.

@javierprovecho Я просто играл с сервером метрик, и, поскольку он не работал, я попытался удалить службу и еще много чего, но мое пространство имен все еще не удаляется, ошибка

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

Вы знаете, как выйти из этого состояния?

edit: Я узнал ... Мне пришлось удалить _everything_, даже удаленно связанное с метриками / HPA, а затем перезапустить всю плоскость управления (пришлось удалить все мои реплики, прежде чем загружать их.), это включало удаление apiservice v1beta1.metrics.k8s.io сам.

@ 2rs2ts

$ kubectl delete apiservice v1beta1.metrics.k8s.io

Избавившись от нефункционирующей службы API metrics диспетчер-контроллер сможет удалить устаревшие пространства имен.

Перезапускать уровень управления не нужно.

@antoineco нет, это было необходимо; Я удалил apiservice и немного подождал, но пространство имен не будет удалено, пока я не перезапущу плоскость управления.

сначала возьмите немного кофе и расслабьтесь, теперь перейдите к вашим мастер-узлам k8s

1. информация о кластере kubectl
   Мастер Kubernetes работает по адресу https: // localhost : 6443
   KubeDNS работает по адресу https: // localhost : 6443 / api / v1 / namespaces / kube-system / services / kube- dns: dns / proxy.

Для дальнейшей отладки и диагностики проблем кластера используйте kubectl cluster-info dump.

1. теперь запустите kube-proxy
   kubectl прокси &
   Начало обслуживания на 127.0.0.1:8001

сохраните идентификатор, чтобы удалить его позже :)

1. найдите свое пространство имен, которое решили не удалять :) для нас это будет cattle-system
   kubectl получить нс
   система крупного рогатого скота Прекращение 1d

поместите это в файл

1. kubectl получить пространство имен cattle-system -o json> tmp.json

1. отредактируйте файл и удалите финализаторы
   },
   "spec": {
   "финализаторы": [
   "кубернетес"
   ]
   },
   после редактирования он должен выглядеть так 👍
   },
   "spec": {
   "финализаторы": [
   ]
   },
   мы почти там 👍

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

и его нет 👍

Эй, финализатор kubernetes здесь не зря. Для нас это было неправильно настроенное имя службы API метрик. Возможно, для вас есть что-то еще, что вы можете обнаружить, просмотрев журналы своей плоскости управления. Без подтверждения ошибки удаление финализатора может привести к нежелательным последствиям, таким как создание созданного материала, который больше не может быть снова доступен для целей удаления.

поскольку этот вопрос все еще открыт:
в моем кластере minikube, работающем с "none", это произошло после того, как хост вышел из спящего режима.

мое предположение:
в моем случае спящий режим вызвал те же проблемы, подойдет включенный своп.

что дает предположение:
своп может быть включен в затронутых кластерах?

но это всего лишь предположение. важная вещь для меня и всех, кто попадает в эту ошибку с моей локальной настройкой:

сначала возьмите немного кофе и расслабьтесь, теперь перейдите к вашим мастер-узлам k8s

1. информация о кластере kubectl
   Мастер Kubernetes работает по адресу https: // localhost : 6443
   KubeDNS работает по адресу https: // localhost : 6443 / api / v1 / namespaces / kube-system / services / kube- dns: dns / proxy.

Для дальнейшей отладки и диагностики проблем кластера используйте kubectl cluster-info dump.

1. теперь запустите kube-proxy
   kubectl прокси &
   Начало обслуживания на 127.0.0.1:8001

сохраните идентификатор, чтобы удалить его позже :)

1. найдите свое пространство имен, которое решили не удалять :) для нас это будет cattle-system
   kubectl получить нс
   система крупного рогатого скота Прекращение 1d

поместите это в файл

1. kubectl получить пространство имен cattle-system -o json> tmp.json

1. отредактируйте файл и удалите финализаторы
   },
   "spec": {
   "финализаторы": [
   "кубернетес"
   ]
   },
   после редактирования он должен выглядеть так 👍
   },
   "spec": {
   "финализаторы": [
   ]
   },
   мы почти там 👍

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

и его нет 👍

Большой!!
Работает

Я периодически сталкиваюсь с этой проблемой, если мы меняем наши экземпляры gcloud (например, при обновлении узлов). Это заменяет старый узел из gcloud instances list на новый, но оставляет модули в пространстве имен k8s висящими:

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

Это оставляет капсулы в неизвестном состоянии:

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

Из-за этого пространство имен никогда не завершится. Не уверен, означает ли это, что мы должны изменить наши финализаторы, или есть реальная ошибка, связанная с завершением, которая должна обрабатывать поды в состоянии UNKNOWN (или если должен быть способ принудительного завершения пространства имен для таких случаев ).

Я периодически сталкиваюсь с этой проблемой, если мы меняем наши экземпляры gcloud (например, при обновлении узлов). Это заменяет старый узел из gcloud instances list на новый, но оставляет модули в пространстве имен k8s висящими:

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

Это оставляет капсулы в неизвестном состоянии:

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

Из-за этого пространство имен никогда не завершится. Не уверен, означает ли это, что мы должны изменить наши финализаторы, или есть реальная ошибка, связанная с завершением, которая должна обрабатывать поды в состоянии UNKNOWN (или если должен быть способ принудительного завершения пространства имен для таких случаев ).

круто, это не та же проблема
вам нужно перевести узлы в режим обслуживания, а затем, после того, как он перейдет в режим обслуживания, все поды будут эвакуированы, а затем вы сможете удалить / обновить

посмотри ， https://kubernetes.io/docs/concepts/workloads/controllers/garbage-collection/ ,
отредактируйте ресурс и удалите метаданные. финализаторы ， и удалите ненужный crd ， вы можете удалить его принудительно

Но что именно делает финализатор kubernetes ? Есть ли риск того, что ресурсы не будут правильно очищены с помощью этого взлома?

При застревании ладьи это помогло https://github.com/rook/rook/blob/master/Documentation/ceph-teardown.md

curl -k -H "Content-Type: application / json" -X PUT --data-binary @ tmp.json https: // kubernetes-cluster-ip / api / v1 / namespaces / annoying-namespace-to-delete / завершить

Ошибка сервера (NotFound): пространства имен "раздражающее-пространство-имен-удаление" не найдено

сначала возьмите немного кофе и расслабьтесь, теперь перейдите к вашим мастер-узлам k8s

1. информация о кластере kubectl
   Мастер Kubernetes работает по адресу https: // localhost : 6443
   KubeDNS работает по адресу https: // localhost : 6443 / api / v1 / namespaces / kube-system / services / kube- dns: dns / proxy.

Для дальнейшей отладки и диагностики проблем кластера используйте kubectl cluster-info dump.

1. теперь запустите kube-proxy
   kubectl прокси &
   Начало обслуживания на 127.0.0.1:8001

сохраните идентификатор, чтобы удалить его позже :)

1. найдите свое пространство имен, которое решили не удалять :) для нас это будет cattle-system
   kubectl получить нс
   система крупного рогатого скота Прекращение 1d

поместите это в файл

1. kubectl получить пространство имен cattle-system -o json> tmp.json

1. отредактируйте файл и удалите финализаторы
   },
   "spec": {
   "финализаторы": [
   "кубернетес"
   ]
   },
   после редактирования он должен выглядеть так 👍
   },
   "spec": {
   "финализаторы": [
   ]
   },
   мы почти там 👍

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

и его нет 👍

Недопустимое значение: «Отредактированный файл не прошел проверку»: ValidationError (Namespace.spec): недопустимый тип для io.k8s.api.core.v1.NamespaceSpec: получено «строка», ожидается «карта»

Если у вас есть много пространств имен, застрявших в завершении, вы можете автоматизировать это:

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

убедитесь, что все пространства имен, которые вы хотите удалить финализатором, действительно являются Terminating .

Вам нужны kubectl proxy running и jq чтобы вышеперечисленное работало.

В нашем случае служба api метрик не работает, и я могу видеть этот журнал ошибок из подробного журнала.

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

После фиксации метрик в сервисе завершаются завершающие.
Не совсем уверен, почему удаление зависит от apiservice метрик, также интересно узнать, как это работает, если apiservice метрик не установлен в кластере

Не совсем уверен, почему удаление зависит от службы метрик,

@manojbadam, поскольку метрики зарегистрированы на сервере api, при выполнении удаления пространства имен он должен запрашивать у этого внешнего API ресурсы (с пространством имен) для удаления (если они существуют), связанные с этим пространством имен. Если сервер расширений недоступен, Kubernetes не может гарантировать, что все объекты были удалены, и у него нет постоянного механизма (в памяти или на диске) для согласования позже, потому что корневой объект был бы удален. Это происходит с любой зарегистрированной службой расширения API.

Поскольку я постоянно сталкивался с этим, я автоматизировал это с помощью небольшого сценария оболочки:

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

Он загружает проект, исправляет JSON, запускает и должным образом останавливает «kubectl proxy»,…

Спасибо всем, кто указывал мне правильное направление!

Поскольку я постоянно сталкивался с этим, я автоматизировал это с помощью небольшого сценария оболочки:

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

Он загружает проект, исправляет JSON, запускает и должным образом останавливает «kubectl proxy»,…

Спасибо всем, кто указывал мне правильное направление!

мой герой! <3

Я тоже столкнулся с этой проблемой. Я использую Google Kubernetes Engine и использую Terraform для раскрутки кластеров Kubernetes и создания пространств имен и подов внутри кластера. Проблема началась через некоторое время после запуска terraform destroy .

В моем случае это проблема с порядком, в котором Terraform выполняет уничтожение. Terraform сначала удаляет пул узлов, а затем удаляет пространства имен и поды. Но из-за удаления (единственного) пула узлов кластер Kubernetes сломался, и это привело к тому, что удаление пространства имен застряло на «завершении» навсегда.

@FooBarWidget такая же проблема для меня :(

Поскольку я постоянно сталкивался с этим, я автоматизировал это с помощью небольшого сценария оболочки:

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

Он загружает проект, исправляет JSON, запускает и должным образом останавливает «kubectl proxy»,…

Спасибо всем, кто указывал мне правильное направление!

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

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

Получил код возврата 403, что делать :(

Поскольку я постоянно сталкивался с этим, я автоматизировал это с помощью небольшого сценария оболочки:
https://github.com/ctron/kill-kube-ns/blob/master/kill-kube-ns
Он загружает проект, исправляет JSON, запускает и должным образом останавливает «kubectl proxy»,…
Спасибо всем, кто указывал мне правильное направление!

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

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

Получил код возврата 403, что делать :(

Слава богу, конечное пространство имен наконец исчезло. Мне нужен следующий метод.

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

У меня такая же проблема, но я не вижу службы метрик.

Я играю с k8s от digitalocean и gitlab auto DevOps. Я предполагаю, что это какое-то хранилище BLOB-объектов цифрового океана, но я не знаю, как его анализировать или исправлять.

@mingxingshi tx. Сделал пространство имен редактирования, которое не помогло. Ваш сценарий сделал это.

Вау, наконец-то избавился от него. Спасибо за команды @mingxingshi !

Решение для меня было:

kubectl delete apiservice v1beta1.metrics.k8s.io

просто подумал, что я должен оставить свой опыт здесь:

я делал terraform apply со следующим ресурсом:

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

но я новичок, и у меня был шаблон с шаблоном, который создавал пространство имен с именем servicer . Это привело к тому, что terraform и k8s оказались в этом плохом состоянии, когда terraform завершился ошибкой, тогда k8s навсегда оставил бы пространство имен servicer в состоянии Terminating . Выполнение того, что предлагает @mingxingshi выше,

эта проблема перестала возникать для меня, когда я удалил этот шаблон, который создавал пространство имен, и оставил его на руль для его создания.

Для меня проблема полностью повторяется. Сначала клонируйте прометей-оператор . Потом:

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

Зависает. Однако если я использую kubectl delete -f manifests/ , то очистка прошла успешно.

Ага, было такое же зависание с прометеем-оператором. Нужно kubectl delete -f manifests/ чтобы отклеиться.
Я думаю, что есть некоторые финализаторы в CRD Prometheus, которые плохо себя ведут, в этом конкретном сценарии это вряд ли ошибка Kubernetes. Однако кубернеты должны упростить поиск виновных, потому что длина этой цепочки показывает, что может быть много причин, и нелегко добраться до сути в каждом конкретном сценарии.

Я нуб kubernetes, поэтому я не могу предложить здесь много информации, но у меня также есть 2 пространства имен, застрявших в статусе завершения. Моя установка kubernetes использует IBM Cloud Private 3.1.2 Community Edition

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

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

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

У меня два пространства имен застряли в состоянии завершения

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

Когда я проверяю финализаторы, как описано в этом комментарии, я вижу только kubernetes .

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

Несмотря на это, я попытался удалить kubernetes из финализаторов, и это не сработало. Я также пробовал использовать подход json / api, описанный в этом комментарии . Тоже не сработало. Я попытался перезапустить все узлы, но это тоже не сработало.

Я также попытался выполнить принудительное удаление, и это тоже не сработало

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

В моем случае пространство имен - rook-ceph, у меня работает kubectl -n rook-ceph patch cephclusters.ceph.rook.io rook-ceph -p '{"metadata":{"finalizers": []}}' --type=merge . В других случаях тоже должно работать.

Источник: https://github.com/rook/rook/blob/master/Documentation/ceph-teardown.md

@ManifoldFR , у меня была та же проблема, что и у вас, и мне удалось заставить ее работать, выполнив вызов API с файлом json.
kubectl get namespace annoying-namespace-to-delete -o json > tmp.json
затем отредактируйте tmp.json и удалите "kubernetes"

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

и он должен удалить ваше пространство имен,

У меня возникли проблемы при использовании вашего подхода, что мне делать для следующего этапа устранения неполадок?

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

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

@ManifoldFR , у меня была та же проблема, что и у вас, и мне удалось заставить ее работать, выполнив вызов API с файлом json.
kubectl get namespace annoying-namespace-to-delete -o json > tmp.json
затем отредактируйте tmp.json и удалите "kubernetes"
curl -k -H "Content-Type: application/json" -X PUT --data-binary @tmp.json https://kubernetes-cluster-ip/api/v1/namespaces/annoying-namespace-to-delete/finalize
и он должен удалить ваше пространство имен,

У меня возникли проблемы при использовании вашего подхода, что мне делать для следующего этапа устранения неполадок?

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

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

Моя проблема может быть решена с помощью этого скрипта: https://github.com/ctron/kill-kube-ns/blob/master/kill-kube-ns .

да https://github.com/ctron/kill-kube-ns/blob/master/kill-kube-ns делает свое дело

set -eo pipefail

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

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

# checking pre-reqs

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

PROJECT="$1"
shift

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

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

sleep 1 # give the proxy a second

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

Кажется, что пространства имен на самом деле не удаляются.
В моем случае kubectl get ns не показывает удаленное пространство имен, а kubectl get all -n <namespace> показывает все ресурсы в целости и сохранности.
Я проверил узлы, и контейнеры докеров все еще работали ...

@glouis это потому, что вы обошли финализаторы, используя описанный выше метод, поэтому Kubernetes не успел выполнить все эти важные задачи удаления.

Очень грустно видеть, как так много людей слепо пропагандируют этот метод, не понимая его последствий. Это крайне уродливо и потенциально может оставить в кластере массу остатков. @javierprovecho уже упоминал об этом выше, а @liggitt также упомянул об этом в другом выпуске GitHub.

Вам лучше исправить сломанную службу v1beta1.metrics.k8s.io API или удалить ее, если

См. Также # 73405

Второе сообщение @antoineco . Я протестировал это в одной из наших сред песочницы, потому что у нас постоянно возникали проблемы с пространствами имен. примерно через месяц все демоны докеров зависали без причины. Оказывается, мы создали огромные утечки памяти, оставив ресурсы позади.

После множества проб и ошибок и чтения этих комментариев оказалось, что это пользовательское определение ресурса для стека coreos grafana для пространств имен. Перечисление CRD показывает конкретные ресурсы для этого пространства имен. Мне очень повезло, что в имени CRD было застрявшее пространство имен.

Также оказалось, что наличие одного застрявшего пространства имен останавливает удаление других пространств имен. Таким образом, даже если у вас есть пространство имен A, в котором CRD не застревает, и есть пространство имен B с застрявшим CRD, все ресурсы в A останутся, пока B не исчезнет. Я думаю, что, должно быть, сделал описанное выше исправление в пространстве имен A, оставляя каждый раз массу ресурсов.

Что меня до сих пор убивает, так это то, что я не могу найти ни одного журнала, в котором упоминается, что очистка пространства имен не удалась при удалении CRD или даже о том, что он сейчас делает. Мне пришлось потратить час на то, чтобы выяснить, на каком CRD он застрял. Если у кого-то есть идея, как получить больше информации, мне не нужно тратить много времени на выяснение застрявшего ресурса, это было бы здорово.

@jecafarelli хороший

Я попытался проанализировать проблему, но ничто в этой теме не помогло мне решить ее другими способами.

Мне помогло это официальное решение: https://success.docker.com/article/kubernetes-namespace-stuck-in-terminating
Это не то же самое, что kubectl edit namespace rook-ceph . Мне не удалось решить эту проблему, пока я не запросил PUT с удаленными _ "финализаторами" _

Хорошо, так что я снова столкнулся с этим с Coreos, и я копнул немного глубже. это наиболее определенно из-за определения ресурса в масштабе кластера, которое имеет пространство имен, и, более того, возможно, он не может удалить его, потому что он не может запрашивать информацию о coreos. Я обнаружил ошибки в журналах apiserver, которые показывают ошибки при попытке получить информацию о группе api. Я использовал упомянутую выше проблему, чтобы создать быстрый сценарий, в котором перечислены ресурсы, из-за которых у меня застряли ns.

ill, вероятно, просто воспользуюсь этим в будущем, если я снова столкнусь с этим и продолжу добавлять любые другие ресурсы с именами, с которыми я сталкиваюсь.

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

Большое спасибо @jecafarelli , вы помогли мне правильно решить мою проблему ;-)

Я установил cert-manager в кластере OpenShift внутри пространства имен cert-manager, и когда я попытался удалить это пространство имен, он застрял в состоянии завершения. Выполнение oc delete apiservices v1beta1.admission.certmanager.k8s.io похоже, решило проблему, пространство имен исчезло.

Большое спасибо @jecafarelli , вы помогли мне правильно решить мою проблему ;-)

Я установил cert-manager в кластере OpenShift внутри пространства имен cert-manager, и когда я попытался удалить это пространство имен, он застрял в состоянии завершения. Выполнение oc delete apiservices v1beta1.admission.certmanager.k8s.io похоже, решило проблему, пространство имен исчезло.

То же самое здесь, помогло запустить kubectl delete -f https://raw.githubusercontent.com/jetstack/cert-manager/release-0.8/deploy/manifests/00-crds.yaml

Просто хочу сказать, что я также встречал эту ошибку в версии 1.13.6 с GKE. Это произошло после того, как я отключил аддон Istio от GKE, чтобы установить его вручную для полного контроля.
Это самая длинная ветка проблем, которую я когда-либо читал, и я потрясен тем, что в корне этой проблемы нет реального консенсуса или шагов по воспроизведению. Кажется, его можно споткнуть по-разному :(

Меня спасли методы JSON и curl / proxy, которые неоднократно упоминались выше и задокументированы на https://success.docker.com/article/kubernetes-namespace-stuck-in-terminating .

Совет на https://success.docker.com/article/kubernetes-namespace-stuck-in-terminating является активно вредным и может привести к тому, что потерянные ресурсы не будут очищены и не обновятся, если пространство имен с таким же именем позже будет воссоздано. .

В настоящее время ведется работа, чтобы выявить конкретную причину зависшего удаления, но основная проблема заключается в том, что существуют типы API, которые нельзя проверить на предмет очистки, поэтому удаление пространства имен блокируется до тех пор, пока они не будут проверены.

Мы также достигли этого с Knative, который устанавливает этот apiservice с пространством имен.

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

После его удаления были очищены как нативные серверы, так и множество других застрявших пространств имен. Спасибо @jecafarelli за приведенный выше сценарий bash.
Вот ужасная версия PowerShell.

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

Сегодня у меня была такая же проблема, и этот сценарий у меня сработал.

@ kubernetes / sig-api-machinery-разное

Эта ошибка существует более года и до сих пор является проблемой ... Как вы планируете устранять такие входящие проблемы, как эта?

Это может помочь хотя бы понять, что происходит: https://github.com/kubernetes/kubernetes/pull/80962

Я сталкиваюсь с той же проблемой

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

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

Контроллер пространства имен должен сообщать об условиях в состояние пространства имен, и клиенты должны сообщать об этом. Требуется KEP, но он должен быть довольно простым, если кто-то может взять и утвердить его.

@timothysc есть (или был) PR в полете (где-то), делающий именно то, что говорит @smarterclayton .

Я почти уверен, что здесь есть еще одна проблема с github?

Да, PR здесь: https://github.com/kubernetes/kubernetes/pull/73405

Проблема, которую я считаю канонической, находится здесь: https://github.com/kubernetes/kubernetes/issues/70916

Вот ресурс, который мне помог: https://www.ibm.com/support/knowledgecenter/en/SSBS6K_3.1.1/troubleshoot/ns_terminating.html

Это похоже на решение, предложенное @slassh , но оно использует kubectl proxy для создания локального прокси и делает целевой IP-адрес команды curl предсказуемым.

-

Изменить: как указано несколько раз ниже этого ответа, это решение является грязным взломом и, возможно, оставит некоторые зависимые ресурсы в кластере. Используйте на свой страх и риск и, возможно, используйте его только как быстрый выход в кластере разработки (не используйте его в производственном кластере).

удаление финализатора напрямую, как описано в документе выше, может иметь последствия. Ресурсы, ожидающие удаления, по-прежнему будут определены в кластере даже после того, как пространство имен будет освобождено. Это цель финализатора. Чтобы убедиться, что все иждивенцы удалены до разрешения удаления ns.

Нашел обходной путь в похожих вопросах:

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

Нашел обходной путь в похожих вопросах:

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

Спасибо!
Работает хорошо.
Я создаю простое приложение, используя этот обходной путь: https://github.com/jenoOvchi/k8sdelns
Я использую его для быстрого удаления и надеюсь, что он будет кому-то полезен.

Пространства имен Kubernetes 1.12.2 находятся в состоянии завершения. Иногда финализаторы можно удалить, изменив yaml в ns. Его нельзя удалить с помощью api. Его можно удалить? Что за ситуация? Проследили ли мы это специально (обязательное условие: в этой нс нет ресурсов), надеюсь смогу получить указатели, спасибо!

Опять же, пожалуйста, не удаляйте финализатор, он не зря. Вместо этого попытайтесь выяснить, какие ресурсы в NS ожидают удаления:

• Проверка того, недоступен ли какой-либо apiservice и, следовательно, не обслуживает его ресурсы: kubectl get apiservice|grep False
• Поиск всех ресурсов, которые все еще существуют, с помощью kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get -n $your-ns-to-delete (Престижность Иордании за это)

Решение этой проблемы не в коротком замыкании механизма очистки, а в том, чтобы выяснить, что мешает очистке.

Опять же, пожалуйста, не удаляйте финализатор, он не зря. Вместо этого попытайтесь выяснить, какие ресурсы в NS ожидают удаления:

• Проверка того, недоступен ли какой-либо apiservice и, следовательно, не обслуживает его ресурсы: kubectl get apiservice|grep False
• Поиск всех ресурсов, которые все еще существуют, с помощью kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get -n $your-ns-to-delete (Престижность Иордании за это)

Решение этой проблемы не в коротком замыкании механизма очистки, а в том, чтобы выяснить, что мешает очистке.

Как ты прав.
В моем случае pod apiservice Operator Framework был удален и блокировал завершающий процесс.
Удаление неиспользуемого apiservice (kubectl delete apiservice) решил проблему.

Привет всем, заморозка кода приближается через несколько дней (четверг, конец дня, тихоокеанское стандартное время), поэтому нам нужно убедиться, что эта проблема будет решена для версии 1.16 или перенесена на версию 1.17. Вы можете прокомментировать его статус?

Будет ли это перенесено в текущую версию GKE? У меня есть кластер, в котором есть несколько пространств имен, которые все еще «завершаются».

@squarelover даже после этого? https://github.com/kubernetes/kubernetes/issues/60807#issuecomment -524772920

@josiahbjorgaard Я только что одобрил PR, и это все, что мы будем делать для 1.16.

https://github.com/kubernetes/kubernetes/pull/73405 - вышеупомянутый PR

Он слит. Я думаю, что мы можем сделать больше, но присылайте будущие комментарии на # 70916.

Опять же, пожалуйста, не удаляйте финализатор, он не зря. Вместо этого попытайтесь выяснить, какие ресурсы в NS ожидают удаления:

• Проверка того, недоступен ли какой-либо apiservice и, следовательно, не обслуживает его ресурсы: kubectl get apiservice|grep False
• Поиск всех ресурсов, которые все еще существуют, с помощью kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get -n $your-ns-to-delete (Престижность Иордании за это)

Решение этой проблемы не в коротком замыкании механизма очистки, а в том, чтобы выяснить, что мешает очистке.

Во многих случаях у вас может быть установлен Metric-Server. Когда модули, которые вы развертываете в определенных пространствах имен, ищут сбор метрик. Зависает с Metric-сервером. Таким образом, даже после того, как вы удалите все ресурсы в этом пространстве имен, сервер метрик каким-то образом связан с этим пространством имен. Это не позволит вам удалить пространство имен.
Этот пост поможет вам определить причину, по которой вы не можете удалить пространство имен. Итак, обрядовый путь.

Попробуйте это, чтобы получить фактический список всего в вашем пространстве имен: kubernetes / kubectl # 151 (комментарий)

Затем для каждого объекта выполните kubectl delete или kubectl edit чтобы удалить финализаторы.

Это решение пригодилось мне, спасибо.

Привет, ребята,

Я сделал сценарий, чтобы упростить удаление пространств имен в статусе завершения: https://github.com/thyarles/knsk.

Благодарю.

Мы столкнулись с той же проблемой: при удалении пространства имен оно зависало в состоянии «Завершение». Я выполнил шаги, описанные выше, чтобы удалить «кубернетес» в финализаторе в файле yaml. Оно работает.

Однако мы не знаем, зачем нам делать дополнительные шаги. Он должен выполнить kubectl delete ns foonamespace и удалить. Кто-нибудь может назвать мне причину? Спасибо!

Привет @ xzhang007 ,

Если вы обнаружите, почему удаление пространства имен зависает в состоянии завершения, дайте мне знать. Какое-то время я пытался дать хороший ответ, но ничего. Затем я сделал сценарий, чтобы облегчить себе жизнь, пока не обнаружил и не исправил причину.

Спасибо.

@thyales, похоже, я до сих пор не нашел ответа.

В нашем случае мы обнаружили, что одним из вебхоков и финализаторов мы были
using обращался к модулю, который жил в пространствах имен, которые получили
удалено.
Как только модуль был удален, завершение зависло.

>

@ xzhang007 вы смотрели ответ, предоставленный @alvaroaleman ? Для нас этого было достаточно, чтобы выяснить, в чем причина.

Опять же, пожалуйста, не удаляйте финализатор, он не зря. Вместо этого попытайтесь выяснить, какие ресурсы в NS ожидают удаления:

• Проверка того, недоступен ли какой-либо apiservice и, следовательно, не обслуживает его ресурсы: kubectl get apiservice|grep False
• Поиск всех ресурсов, которые все еще существуют, с помощью kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get -n $your-ns-to-delete (Престижность Иордании за это)

Решение этой проблемы не в коротком замыкании механизма очистки, а в том, чтобы выяснить, что мешает очистке.

Кроме того, когда эта проблема была закрыта, появилась ссылка на новый тикет, чтобы обсудить, как прояснить, почему пространство имен застревает при завершении. Предлагаю вам вместо этого закрытого вопроса вести разговор туда.

Он слит. Я думаю, что мы можем сделать больше, но присылайте будущие комментарии на # 70916.

@ jeff-knurek Так должно быть правильно. Спасибо.

В нашем случае это было неудачное обновление cert-manager которое сломало финализатор. https://github.com/jetstack/cert-manager/issues/1582

$ kube get apiservice

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

Привет.
В моем случае пространство имен зависает при завершении, когда https://github.com/rancher/rancher/issues/21546#issuecomment -553635629

Может, поможет.

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

Это сработало для меня как чемпион

Я также столкнулся с той же проблемой, теперь она у меня работает нормально. Пожалуйста, обратитесь к следующему документу и решите свою проблему

@zerkms ну иногда это законный совет, не так ли? Часто ожидаемые финализаторы обслуживаются объектами, которые были удалены как часть удаления пространства имен. В этом случае, поскольку больше нет смысла ждать - больше нет ничего, что могло бы делать финализацию - исправление объектов так, как описано в статье, _ является единственным вариантом_.

Обратите внимание, что статья применима только в том случае, если проблема _ не была решена_ с помощью действий, перечисленных на странице "Известные проблемы", ссылка на которую находится в верхней части статьи, что, по сути, является советом, который повторяется в связанном вами комментарии.

@zerkms ну иногда это законный совет, не так ли? Часто ожидаемые финализаторы обслуживаются объектами, которые были удалены как часть удаления пространства имен.

Я никогда не видел, чтобы это было верно для spec.finalizer в пространстве имен. В каждом случае, который я видел, задействован контроллер очистки пространства имен, и он был вызван либо постоянным объектом в пространстве имен (который этот совет привнесет в etcd), либо неотвечающим агрегированным API (который при удалении spec.finalizer пространства имен пропустит ожидание, а также привязка любых сохраненных ресурсов из этого API)

В статье не содержится предупреждений о том, что обход финализации пространства имен может привести к тому, что ресурсы пространства имен останутся в хранилище, и это не рекомендуется.

Я никогда не видел, чтобы это было верно для spec.finalizer в пространстве имен

Да, верно, это потому, что этот финализатор реализован самими кубернетами, но могут быть другие финализаторы для объектов внутри этого пространства имен, которые могут быть реализованы объектами в этом пространстве имен. Один из примеров, с которым я недавно столкнулся, был https://appscode.com/products/stash/ .

Он помещает финализаторы в некоторые из своих CRD, которые должны обслуживаться развертыванием оператора тайника. Но с уже удаленным оператором stash нет ничего, что могло бы удалить метку финализатора из этих CRD, и удаление пространства имен застревает. В этом случае исправление этих финализаторов (не в самом пространстве имен, а в этих объектах) - единственное разумное решение.

Надеюсь, это имеет смысл.

В этом случае исправление этих финализаторов (не в самом пространстве имен, а в этих объектах) - единственное разумное решение.

Верный. Я бы не стал возражать против этого в сценарии очистки «удалить все ресурсы», но это не то, через что идет связанная статья ... в ней описывается, как удалить spec.finalizer из пространства имен.

сначала возьмите немного кофе и расслабьтесь, теперь перейдите к вашим мастер-узлам k8s

информация о кластере kubectl
Мастер Kubernetes работает по адресу https: // localhost : 6443
KubeDNS работает по адресу https: // localhost : 6443 / api / v1 / namespaces / kube-system / services / kube- dns: dns / proxy.
Для дальнейшей отладки и диагностики проблем кластера используйте kubectl cluster-info dump.

теперь запустите kube-proxy
kubectl прокси &
Начало обслуживания на 127.0.0.1:8001
сохраните идентификатор, чтобы удалить его позже :)

1. найдите свое пространство имен, которое решили не удалять :) для нас это будет cattle-system
   kubectl получить нс
   система крупного рогатого скота Прекращение 1d

поместите это в файл

1. kubectl получить пространство имен cattle-system -o json> tmp.json

отредактируйте файл и удалите финализаторы
},
"spec": {
"финализаторы": [
"кубернетес"
]
},
после редактирования он должен выглядеть так 👍
},
"spec": {
"финализаторы": [
]
},
мы почти там 👍
curl -k -H "Content-Type: application / json" -X PUT --data-binary @ tmp.json http://127.0.0.1 : 8001 / api / v1 / namespaces / $ {NAMESPACE} / finalize

и его нет 👍

Опять же, пожалуйста, не удаляйте финализатор, он не зря. Вместо этого попытайтесь выяснить, какие ресурсы в NS ожидают удаления:

• Проверка того, недоступен ли какой-либо apiservice и, следовательно, не обслуживает его ресурсы: kubectl get apiservice|grep False
• Поиск всех ресурсов, которые все еще существуют, с помощью kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get -n $your-ns-to-delete (Престижность Иордании за это)

Решение этой проблемы не в коротком замыкании механизма очистки, а в том, чтобы выяснить, что мешает очистке.

Эй, ребята! Я следую советам @alvaroaleman и создал сценарий, который проверяет и пытается выполнить чистое удаление, прежде чем выполнять жесткое удаление застрявшего пространства имен .

Что делает скрипт https://github.com/thyarles/knsk :

1. Проверьте наличие недоступных исходников apires и попросите удалить его
2. Проверьте наличие ожидающих ресурсов в пространстве имен и попросите удалить их
3. Подождите около 5 минут, чтобы увидеть, выполняет ли Kubernetes чистое удаление, если сценарий выполняет какое-либо удаление
4. Принудительное удаление застрявшего пространства имен

Надеюсь, поможет.

@thyarles Большое вам спасибо. Я использовал твой способ для решения проблемы.

$ kubectl get apiservices для проверки того, какая служба недоступна, удаление доступных - false с помощью $ kubectl delete apiservice [имя-службы], и после этого не возникнет проблем с удалением пространства имен.

Для нашей команды есть 3 недоступных apiservices: v1beta1.admission.certmanager.k8s.io, v1beta1.metrics.k8s.io и v1beta1.webhook.certmanager.k8s.io.

Обратите внимание, что ваш кластер несколько сломан, если apiserver метрик не работает, простое удаление APIService на самом деле не устраняет основную причину.

@lavalamp метрики - недоступный сервис.

Да, это означает, что apiserver метрик не работает, что означает, что HPA не работает в вашем кластере, и, возможно, другие вещи тоже.

Да. HPA сейчас не работает. Я не должен удалять метрики и искать способ исправить это.

@thyarles Большое вам спасибо. Я использовал твой способ для решения проблемы.

$ kubectl get apiservices для проверки того, какая служба недоступна, удаление доступных - false с помощью $ kubectl delete apiservice [имя-службы], и после этого не возникнет проблем с удалением пространства имен.

Для нашей команды есть 3 недоступных apiservices: v1beta1.admission.certmanager.k8s.io, v1beta1.metrics.k8s.io и v1beta1.webhook.certmanager.k8s.io.

@ xzhang007 рад это слышать! Теперь вы должны проверить, почему ваш v1beta1.metrics.k8s.io вышел из строя. Проверь, как бы ему хотелось:

``
$ kubectl -n kube-system получить все | показатели grep

pod / metrics-server-64f74f8d47-r5vcq 2/2 Выполняется 9 119d
сервис / метрики-сервер ClusterIP xx.xx.xx.xx443 / TCP 201d
развертывание.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 получить все | показатели grep

pod / metrics-server-5dcfd4dd9f-m2v9k 1/1 Выполняется 0 2d20h

сервис / метрики-сервер ClusterIP xx.xx.xx.xx443 / TCP 27d

развертывание.apps / metrics-server 1/1 1 1 27d

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

Да. HPA сейчас не работает. Я не должен удалять метрики и искать способ исправить это.

@ xzhang007 на самом деле он не работает до того, как вы заметили проблему ... вы просто заметили, потому что он помещает ваши удаленные пространства имен в режим зависания. Просто используйте диспетчер пакетов helm для повторного развертывания вашего сервера метрик или просто вызовите команду ниже, чтобы исправить это ( проверьте файл развертывания перед применением ):

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

Решение @slassh работало для меня на Kubernetes 1.15

Удалите v1beta1.metrics.k8s.io APIService.

kubectl get ns ns-to-delete -o yaml

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

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

 kubectl delete v1beta1.metrics.k8s.io APIService

Cert-manager был недоступен, возможно, потому, что он был настроен неправильно. Например, используйте неправильный синтаксис в контроллере входящего трафика. Для нашей системы это было

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

и он был изменен на

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

сделать его доступным.

Как упоминалось ранее в этом выпуске, есть другой способ завершить пространство имен с помощью API, не предоставляемого kubectl, с помощью современной версии kubectl, где доступен kubectl replace --raw (не уверен, из какой версии). Таким образом, вам не придется запускать процесс kubectl proxy и избегать зависимости от curl (что в некоторых средах, таких как busybox, недоступно). В надежде, что это поможет кому-то другому, я оставил это здесь:

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

Установлено, можно ли это исправить? Кажется, здесь много хакерских решений, но ничего не решает основную проблему, заключающуюся в том, что никто из нас не может удалить наши пространства имен ....
У меня это на кластере EKS v1.14

Установлено, можно ли это исправить? Кажется, здесь много хакерских решений, но ничего не решает основную проблему, заключающуюся в том, что никто из нас не может удалить наши пространства имен.

Основная проблема заключается в том, что агрегированная группа API в вашем кластере недоступна. Контроллер очистки пространства имен намеренно блокируется до тех пор, пока не будут доступны все API-интерфейсы, чтобы он мог проверить, что все ресурсы из всех групп API очищены для этого пространства имен.

для ppl, пытающихся скрутить API:

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

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

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

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

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

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

Вот сценарий, который сделает это автоматически. Требуется jq :

#!/bin/bash

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

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

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

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

kill -15 $PID

Всем: скрипты для автоматизации удаления финализатора приносят больше вреда, чем пользы . Они могут оставлять бомбы замедленного действия в агрегированных apiserver (ах), которые недоступны; если кто-то воссоздает пространство имен, внезапно может снова появиться куча старых объектов.

Настоящее решение:

$ kubectl get api-services

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

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

Всем: скрипты для автоматизации удаления финализатора приносят больше вреда, чем пользы . Они могут оставлять бомбы замедленного действия в агрегированных apiserver (ах), которые недоступны; если кто-то воссоздает пространство имен, внезапно может снова появиться куча старых объектов.

Настоящее решение:

$ kubectl get api-services

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

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

https://github.com/thyarles/knsk

Этот сценарий выполняет все проверки и пытается выполнить полное удаление, включая поиск потерянных ресурсов. Если пользователь хочет рискнуть, сценарий предлагает параметр --force для выполнения нерекомендуемого способа удаления.

опечатка, должны быть услуги

Эта команда показывает недоступные API:

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

Эта статья обязательно будет вам полезна:

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

На самом деле существует конфликт в apiservices, они могут проверить состояние работоспособности apis в openshift:

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

сбойному api потребуется перезапустить его, перезапустив модуль или развертывание, принадлежащее этому API, после чего попробуйте удалить пространство имен.

$ oc удалить пространство имен

и готово, дело исправлено !!

Довольно неуважительно использовать свой родной язык в месте, где все согласны говорить по-английски. 👎

Где все согласны говорить по-английски?

30 апреля 2020 г., в 17:58 theAkito [email protected] написал:

Довольно неуважительно использовать свой родной язык в месте, где все
соглашается говорить по-английски. 👎

-
Вы получили это, потому что оставили комментарий.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/kubernetes/kubernetes/issues/60807#issuecomment-622137770 ,
или отказаться от подписки
https://github.com/notifications/unsubscribe-auth/ALGMKB6K4OU4X3XOYMALOBLRPHYCDANCNFSM4ETUOEPA
.

>

Крис, ведущий архитектор @ brace.ai

-

Уведомление о конфиденциальности: это электронное письмо предназначено исключительно для использования
предполагаемый получатель (и) и может содержать конфиденциальные, служебные или
привилегированная информация. Если вы не являетесь предполагаемым получателем, вы
уведомлен о том, что любое использование, просмотр, распространение, копирование или действия, предпринятые на основе
на это сообщение или его вложения, если таковые имеются, запрещено. Если вы не
предполагаемому получателю, пожалуйста, свяжитесь с отправителем по электронной почте и
уничтожить или удалить все копии исходного сообщения и все вложения.

готов, извините это было для моей скорости, это было исправлено

У нас многоязычная пользовательская база, и это плохо, что ни один из наших инструментов не является интернационализированным, мы, по крайней мере, можем быть хорошими здесь, на github, пожалуйста.

@teoincontatto

Как упоминалось ранее в этом выпуске, есть другой способ завершить пространство имен с помощью API, не предоставляемого kubectl, с помощью современной версии kubectl, где доступен kubectl replace --raw (не уверен, из какой версии). Таким образом, вам не придется запускать процесс kubectl proxy и избегать зависимости от curl (что в некоторых средах, таких как busybox, недоступно). В надежде, что это поможет кому-то другому, я оставил это здесь:

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

Это сработало отлично!

У нас многоязычная пользовательская база, и это плохо, что ни один из наших инструментов не является интернационализированным, мы, по крайней мере, можем быть хорошими здесь, на github, пожалуйста.

У нас многоязычная пользовательская база, и это плохо, что ни один из наших инструментов не является интернационализированным, мы, по крайней мере, можем быть хорошими здесь, на github, пожалуйста.

Все еще пытаюсь понять. Прости меня. Возможно, я по ошибке щелкнул пальцем вниз.
Да, действительно, инструменты не доведены до совершенства.
В тех, кто ставит палец вниз без объяснения причин, нет смысла.

Почти все время, когда я сталкиваюсь с этой проблемой, это зависит от CRD. Удалите CRD, если они используются только в этом пространстве имен, а затем вы можете продолжить удаление финализатора и пространства имен.

Как упоминалось ранее в этом выпуске, есть другой способ завершить пространство имен с помощью API, не предоставляемого kubectl, с помощью современной версии kubectl, где доступен kubectl replace --raw (не уверен, из какой версии). Таким образом, вам не придется запускать процесс kubectl proxy и избегать зависимости от curl (что в некоторых средах, таких как busybox, недоступно). В надежде, что это поможет кому-то другому, я оставил это здесь:

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

@teoincontatto Спасибо! Это наконец сработало!

Иногда только редактирование манифеста ресурса в режиме онлайн не работает очень хорошо (я имею в виду удалить finalizers и сохранить).
Итак, я получил новый способ от других.

kubectl get namespace linkerd -o json > linkerd.json

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

После выполнения этой команды пространство имен теперь должно отсутствовать в вашем списке пространств имен .. И это работает для меня.

Не только namespace но и поддержка других ресурсов.

Я исправил проблему, удалив строки финализаторов, используя: kubectl edit annoying-ns

Хм ... У меня сейчас такая проблема :)
Сегодня сделал обновление своего кластера экш с 1.15 до 1.16.
Пока все выглядит нормально.
Но моя разработка ns "configcluster" была своего рода "поврежденной".
Поэтому я решаю навести порядок.

k удалить ns configcluster
....
теперь это зависает (3h +): /

$ kubectl get namespace configcluster -o yaml
apiVersion: v1
kind: Namespace
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","kind":"Namespace","metadata":{"annotations":{},"name":"configcluster"}}
  creationTimestamp: "2020-06-19T06:40:15Z"
  deletionTimestamp: "2020-06-19T09:19:16Z"
  name: configcluster
  resourceVersion: "22598109"
  selfLink: /api/v1/namespaces/configcluster
  uid: e50f0b53-b21e-4e6e-8946-c0a0803f031b
spec:
  finalizers:
  - kubernetes
status:
  conditions:
  - lastTransitionTime: "2020-06-19T09:19:21Z"
    message: 'Discovery failed for some groups, 1 failing: unable to retrieve the
      complete list of server APIs: metrics.k8s.io/v1beta1: the server is currently
      unable to handle the request'
    reason: DiscoveryFailed
    status: "True"
    type: NamespaceDeletionDiscoveryFailure
  - lastTransitionTime: "2020-06-19T09:19:22Z"
    message: All legacy kube types successfully parsed
    reason: ParsedGroupVersions
    status: "False"
    type: NamespaceDeletionGroupVersionParsingFailure
  - lastTransitionTime: "2020-06-19T09:19:22Z"
    message: All content successfully deleted
    reason: ContentDeleted
    status: "False"
    type: NamespaceDeletionContentFailure
  phase: Terminating

Как мы можем больше узнать об этой шипе в стопе?

В пятницу, 19 июня 2020 г., в 4:46 Андреас Хеманн [email protected]
написал:

Хм ... У меня сейчас такая проблема :)
Сегодня сделал обновление своего кластера экш с 1.15 до 1.16.
Пока все выглядит нормально.
Но моя разработка ns "configcluster" была своего рода "поврежденной".
Поэтому я решаю навести порядок.

k удалить ns configcluster
....
теперь это зависает (3h +): /

$ kubectl получить конфигурацию пространства имен -o yaml
apiVersion: v1
kind: Пространство имен
метаданные:
аннотации:
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"
имя: configcluster
resourceVersion: "22598109"
selfLink: / api / v1 / пространства имен / configcluster
uid: e50f0b53-b21e-4e6e-8946-c0a0803f031b
спецификации:
финализаторы:

• Кубернеты
  положение дел:
  условия:
• lastTransitionTime: "2020-06-19T09: 19: 21Z"
  сообщение: 'Ошибка обнаружения для некоторых групп, 1 ошибка: невозможно получить
  полный список серверных API: metrics.k8s.io/v1beta1: сервер в настоящее время
  не может обработать запрос '
  причина: DiscoveryFailed
  статус: "Верно"
  Тип: NamespaceDeletionDiscoveryFailure
• lastTransitionTime: "2020-06-19T09: 19: 22Z"
  сообщение: все устаревшие типы кубов успешно проанализированы
  причина: ParsedGroupVersions
  статус: «Ложь»
  Тип: NamespaceDeletionGroupVersionParsingFailure
• lastTransitionTime: "2020-06-19T09: 19: 22Z"
  сообщение: Все содержимое успешно удалено
  причина: ContentDeleted
  статус: «Ложь»
  тип: NamespaceDeletionContentFailure
  фаза: Завершение

-
Вы получили это, потому что оставили комментарий.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/kubernetes/kubernetes/issues/60807#issuecomment-646543073 ,
или отказаться от подписки
https://github.com/notifications/unsubscribe-auth/AFLKRCLHIZ77X2Z3F5GAOCTRXMXVTANCNFSM4ETUOEPA
.

@bobhenkel ну, эта проблема закрыта, так что фактически это означает, что проблемы нет (что касается каких-либо действий). Если вам нужна практическая помощь в подобной ситуации, прочтите ветку выше, там есть несколько хороших советов (а также несколько плохих).

В моем случае мне пришлось вручную удалить мой входящий балансировщик нагрузки из консоли GCP Network Service. Я вручную создал интерфейс балансировщика нагрузки прямо в консоли. Как только я удалил балансировщик нагрузки, пространство имен было автоматически удалено.

Я подозреваю, что Kubernetes не хотел удалять, поскольку состояние балансировщика нагрузки отличалось от состояния в манифесте.

Я попытаюсь автоматизировать создание входящего интерфейса, используя аннотации рядом, чтобы посмотреть, смогу ли я решить эту проблему.

Иногда только редактирование манифеста ресурса в режиме онлайн не работает очень хорошо (я имею в виду удалить finalizers и сохранить).
Итак, я получил новый способ от других.

kubectl get namespace linkerd -o json > linkerd.json

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

После выполнения этой команды пространство имен теперь должно отсутствовать в вашем списке пространств имен .. И это работает для меня.

Не только namespace но и поддержка других ресурсов.

ты звезда, это сработало

Иногда только редактирование манифеста ресурса в режиме онлайн не работает очень хорошо (я имею в виду удалить finalizers и сохранить).
Итак, я получил новый способ от других.

kubectl get namespace linkerd -o json > linkerd.json

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

После выполнения этой команды пространство имен теперь должно отсутствовать в вашем списке пространств имен .. И это работает для меня.

Не только namespace но и поддержка других ресурсов.

Пробовал много решений, но это то, что у меня сработало. Спасибо!

curl -k -H "Content-Type: application / json" -X PUT --data-binary @ tmp.json https: // kubernetes-cluster-ip / api / v1 / namespaces / annoying-namespace-to-delete / завершить

Лучше https://stackoverflow.com/a/59667608/429476

Это действительно должен быть «принятый» ответ - он полностью устранил корень проблемы!

Взять по ссылке выше:

Это неправильный путь, особенно в производственной среде.

Сегодня столкнулся с той же проблемой. Удалив финализатор, вы останетесь с остатками в разных состояниях. Вы действительно должны найти, что мешает удалению.

См. Https://github.com/kubernetes/kubernetes/issues/60807#issuecomment -524772920

(также, к сожалению, kubetctl get all не сообщает обо всем, вам нужно использовать аналогичные команды, как в ссылке)

Мой случай - удаление пространства имен cert-manager. В выводе 'kubectl get apiservice -o yaml' я обнаружил APIService 'v1beta1.admission.certmanager.k8s.io' со статусом = False. Этот apiservice был частью cert-manager, который я только что удалил. Итак, через 10 секунд после того, как я «kubectl delete apiservice v1beta1.admission.certmanager.k8s.io», пространство имен исчезло.

Надеюсь, это поможет.

С учетом вышесказанного, я написал небольшой микросервис, который запускается как CronJob каждый час, который автоматически удаляет завершающие пространства имен.

Вы можете найти его здесь: https://github.com/oze4/service.remove-terminating-namespaces

Я написал небольшой микросервис, который запускается как CronJob каждый час, который автоматически удаляет завершающие пространства имен.

Вы можете найти его здесь: https://github.com/oze4/service.remove-terminating-namespaces

Еще один лайнер:

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

Но удаление застрявших пространств имен - не лучшее решение. Правильный способ - выяснить, почему он застрял. Очень распространенная причина заключается в том, что недоступны службы API, которые не позволяют кластеру завершить завершение пространств имен.
Например, здесь я не удалил Knative должным образом:

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

Удаление решило проблему

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

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

Я написал небольшой микросервис, который запускается как CronJob каждый час, который автоматически удаляет завершающие пространства имен.

Вы можете найти его здесь: https://github.com/oze4/service.remove-terminating-namespaces

Молодец.

У меня была аналогичная проблема на 1.18 в лабораторном кластере k8s и я добавил примечание, чтобы, возможно, помочь другим. Я работал с API метрик и, в частности, с пользовательскими метриками. После удаления этих объектов k8s для его воссоздания он остановился на удалении пространства имен с ошибкой, что не удалось найти конечную точку api метрик. Поместив это обратно в другое пространство имен, все сразу прояснилось.

Это было в пространстве имен в status.conditions.message:

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

Еще один лайнер:

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

Но удаление застрявших пространств имен - не лучшее решение. Правильный способ - выяснить, почему он застрял. Очень распространенная причина заключается в том, что недоступны службы API, которые не позволяют кластеру завершить завершение пространств имен.
Например, здесь я не удалил Knative должным образом:

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

Удаление решило проблему

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

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

Определенно самый чистый лайнер! Важно отметить, что ни одно из этих «решений» на самом деле не решает основную проблему.

См. Здесь для правильного решения

То есть сообщение должно распространяться: smile: а не "еще один лайнер".

безусловно, самый чистый лайнер! Важно отметить, что ни одно из этих «решений» на самом деле не решает основную проблему.

Это решение решает одну из всех возможностей. Чтобы найти все возможные первопричины и исправить их, я использую этот скрипт: https://github.com/thyarles/knsk

@thyarles очень мило!

Пожалуйста, не используйте modify finalize для удаления пространства имен. Это вызовет ошибку

Пожалуйста, выясните причину завершения пространства имен. Известные в настоящее время направления устранения неполадок

• завершение стручка
• Cert-Manager блокировка веб-перехватчика secrte

У меня такая же проблема:

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

#  sudo kubectl version

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

Вы можете использовать etcdctl для поиска восстановленных ресурсов

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

Просто скопируйте и вставьте в свой терминал

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

/tmp/$NS.json

это сработало для меня, и я побежал, убедившись, что в ns нет болтающихся объектов k8s. Благодаря!

Я использовал это, чтобы удалить пространство имен, застрявшее на Terminated

пример :

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

Для всех гуглеров, которые столкнулись с застрявшими пространствами имен при завершении работы с конкретными пространствами имен (например, cattle-system), у меня работала следующая измененная команда (оригинал Grebois):

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

Ребята, к вашему сведению, когда выйдет видео для этого kubecon , я планирую разместить ссылку на него и некоторые полезные комментарии выше и заблокировать эту проблему.

Я записал 10-минутное объяснение того, что происходит, и представил его на этой сессии SIG Deep Dive .

Вот правильный комментарий с 65 положительными голосами

Упомянутый выше несколько раз, этот средний пост является примером того, как все делать правильно. Найдите и исправьте сломанный сервис API.

Все одинарные лайнеры, которые просто удаляют финализаторы в пространстве имен , устраняют основную причину и оставляют ваш кластер слегка сломанным, что вас укусит позже. Так что, пожалуйста, не делай этого. В любом случае устранить первопричину обычно проще. Кажется, что людям нравится публиковать варианты этой темы, хотя в ветке уже есть множество правильных ответов, поэтому я собираюсь заблокировать проблему сейчас, чтобы этот комментарий оставался внизу.