Helm: невозможно получить полный список серверных API

У меня такая же проблема с AKS, хотя сообщение об ошибке

Ошибка: не удалось получить apiVersions от Kubernetes: невозможно получить полный список серверных API: metrics.k8s.io/v1beta1: сервер в настоящее время не может обработать запрос

моя конфигурация:

• версия kubectl:

Версия клиента: version.Info {Major: «1», Minor: «15», GitVersion: «v1.15.2», GitCommit: «f6278300bebbb750328ac16ee6dd3aa7d3549568», GitTreeState: «clean», BuildDate: «2019-08-05T09: 23: 26Z ", GoVersion:" go1.12.5 ", компилятор:" gc ", платформа:" windows / amd64 "}
Версия сервера: version.Info {Major: «1», Minor: «14», GitVersion: «v1.14.6», GitCommit: «96fac5cd13a5dc064f7d9f4f23030a6aeface6cc», GitTreeState: «clean», BuildDate: «2019-08-19T11: 05: 16Z ", GoVersion:" go1.12.9 ", компилятор:" gc ", платформа:" linux / amd64 "}

• версия helm: alpine / helm: 3.0.0-beta.2 (докер)

• kubectl api-ресурсы
  NAME SHORTNAMES APIGROUP NAMESPACED KIND bindings true Binding componentstatuses cs false ComponentStatus configmaps cm true ConfigMap endpoints ep true Endpoints events ev true Event limitranges limits true LimitRange namespaces ns false Namespace nodes no false Node persistentvolumeclaims pvc true PersistentVolumeClaim persistentvolumes pv false PersistentVolume pods po true Pod podtemplates true PodTemplate replicationcontrollers rc true ReplicationController resourcequotas quota true ResourceQuota secrets true Secret serviceaccounts sa true ServiceAccount services svc true Service mutatingwebhookconfigurations admissionregistration.k8s.io false MutatingWebhookConfiguration validatingwebhookconfigurations admissionregistration.k8s.io false ValidatingWebhookConfiguration customresourcedefinitions crd,crds apiextensions.k8s.io false CustomResourceDefinition apiservices apiregistration.k8s.io false APIService controllerrevisions apps true ControllerRevision daemonsets ds apps true DaemonSet deployments deploy apps true Deployment replicasets rs apps true ReplicaSet statefulsets sts apps true StatefulSet tokenreviews authentication.k8s.io false TokenReview localsubjectaccessreviews authorization.k8s.io true LocalSubjectAccessReview selfsubjectaccessreviews authorization.k8s.io false SelfSubjectAccessReview selfsubjectrulesreviews authorization.k8s.io false SelfSubjectRulesReview subjectaccessreviews authorization.k8s.io false SubjectAccessReview horizontalpodautoscalers hpa autoscaling true HorizontalPodAutoscaler cronjobs cj batch true CronJob jobs batch true Job certificatesigningrequests csr certificates.k8s.io false CertificateSigningRequest leases coordination.k8s.io true Lease events ev events.k8s.io true Event daemonsets ds extensions true DaemonSet deployments deploy extensions true Deployment ingresses ing extensions true Ingress networkpolicies netpol extensions true NetworkPolicy podsecuritypolicies psp extensions false PodSecurityPolicy replicasets rs extensions true ReplicaSet ingresses ing networking.k8s.io true Ingress networkpolicies netpol networking.k8s.io true NetworkPolicy runtimeclasses node.k8s.io false RuntimeClass poddisruptionbudgets pdb policy true PodDisruptionBudget podsecuritypolicies psp policy false PodSecurityPolicy clusterrolebindings rbac.authorization.k8s.io false ClusterRoleBinding clusterroles rbac.authorization.k8s.io false ClusterRole rolebindings rbac.authorization.k8s.io true RoleBinding roles rbac.authorization.k8s.io true Role priorityclasses pc scheduling.k8s.io false PriorityClass csidrivers storage.k8s.io false CSIDriver csinodes storage.k8s.io false CSINode storageclasses sc storage.k8s.io false StorageClass volumeattachments storage.k8s.io false VolumeAttachment error: unable to retrieve the complete list of server APIs: metrics.k8s.io/v1beta1: the server is currently unable to handle the request

Я считаю, что в моем случае эта проблема возникла недавно ... похоже, это связано с тем, что в моем случае установлен knative (в IBM Cloud IKS это управляемый вариант). Я удалил Knative, и сейчас все в порядке, но здесь может быть проблема с взаимодействием

@kalioz из интереса, вы используете Knative на AWS? На самом деле это выглядит не так, потому что я не вижу тектонных объектов

Я только что сам видел эту проблему. В моем случае проблема возникла из-за cert-manager. Все еще работаю над тем, как вернуть его в прежнее состояние.

@ planetf1 Я не использую knative (или думаю, что не использую), но проблема существует только в новом кластере, который я развернул для этого теста.
Отличия рабочего кластера от неработающего:

| | рабочий | нерабочий |
| --- | --- | --- |
| версия kube | 1.13.5 | 1.14.6 |
| аутентификация лазурного AD | отключена | включена |
| RBAC | отключено | включено |

Итак, у меня есть несколько серьезных изменений.

Для меня проблема в том, что helm3 вылетает из-за отсутствия доступа к некоторым API, которые не используются для диаграммы, которую я пытаюсь развернуть.

Я использую его на кластере k8 версии 1.13.9, такая же ошибка возникает при развертывании любого стабильного графика.

версия руля
version.BuildInfo {Версия: "v3.0.0-beta.3", GitCommit: "5cb923eecbe80d1ad76399aee234717c11931d9a", GitTreeState: "clean", GoVersion: "go1.12.9"}

helm.go: 81: [отладка] невозможно получить полный список серверных API: metrics.k8s.io/v1beta1: сервер в настоящее время не может обработать запрос.

После решения проблемы из модуля метрик (не могу вспомнить, как я его решил, я думаю, что это может быть связано с hostNetwork или просто перезапуском связанного модуля) helm3 функционирует должным образом.
Таким образом, это может быть `` функция '', поскольку она заставляет поддерживать кластер в хорошем состоянии, но для этого потребуется, чтобы кто-то вручную заходил в кластер каждый раз, когда api ломается (и, таким образом, может препятствовать использованию helm3 для развертывания модулей, которые могут быть перечислены на этом).

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

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

Для всех, кто сталкивается с этим, это вызвано api-сервисами, у которых больше не работает серверная часть ...

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

Починить это:

kubectl get apiservice

Найдите те, которые AVAILABLE равны False

Если вам больше не нужны эти API, удалите их:

kubectl delete apiservce <service-name>

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

Спасибо за объяснение - есть ли способ, которым Хельм тоже может это исправить?

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

То же самое с 2.15.0 сейчас:

Error: Could not get apiVersions from Kubernetes: unable to retrieve the complete list of server APIs: metrics.k8s.io/v1beta1: the server is currently unable to handle the request

Это очень раздражает. На самом деле было бы гораздо лучше предупредить, чем провалиться.
Есть какие-нибудь обновления по этому поводу?

РЕДАКТИРОВАТЬ: может ли s / o подтвердить, что 2.15 также затронуты? Тогда я бы предложил скорректировать метки этого билета.

@sjentzsch Я также вижу то же самое, используя Helm 2.15.0 и k8s 1.16.0 .

Если это также повлияет на 2.x, тогда всем, кто использует "cert-manager" (возможно, только предварительную настройку), будут плохие времена.

__ Здесь у нас есть два разных случая с одинаковым поведением со стороны руля.
Обе версии 2.15.1 и 3 beta затронуты .__

Как упоминалось в @technosophos, helm использует функции API обнаружения и не работает, если какой-либо ответ API не удается https://github.com/helm/helm/blob/f1dc84773f9a34fe59a504fdb32428ce1d56a2e8/pkg/action/action.go#L105 -L118

1. admission.certmanager.k8s.io/v1beta1 cert-manager - хороший пример:

kubectl get apiservice | grep certmanager
v1beta1.admission.certmanager.k8s.io   service/cert-manager-webhook   False (ServiceNotFound)   111d

и в этом случае вы можете легко исправить это с помощью kubectl delete apiservice v1beta1.admission.certmanager.k8s.io
как описано в @brendandburns .

1. Другой случай сбоя, когда helm не может получить ответ ни от одной службы api
   например, "metrics.k8s.io/v1beta1: сервер в настоящее время не может обработать запрос", и это происходит от случая к случаю

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

⇒  k get apiservice | grep metrics
v1beta1.metrics.k8s.io                 kube-system/metrics-server     True        1y

Я уверен, что штурвал должен быть более надежным для такого рода проблем,
1) возможно, лучше преобразовать ошибку в предупреждение (я не знаю, как информация из службы api используется во время рендеринга шаблона)
2) реализовать повторы для такого типа запросов

У нас есть аналогичная проблема с 2.15.1 в Kubernetes 1.15.5, но НЕ с helm 2.14.3.

Проблема всплывает: некоторые диаграммы устанавливаются нормально, но потом начинают глючить.
Наше сообщение:

Error: Could not get apiVersions from Kubernetes: unable to retrieve the complete list of server APIs: metrics.k8s.io/v1beta1: the server is currently unable to handle the request: exit status 1

kubectl get apiservice перечисляет metrics.k8s.io/v1beta1 как доступные. Возможно, у нас временная проблема с этим сервисом, но helm 2.14.3 на в основном идентичном кластере работает надежно.

Мы столкнулись с этой проблемой при попытке обновления до Helm 2.15.2 в кластере CI Charts. Так что проблема не только в Helm 3. Это исправило удаление отсутствующей службы API. Интересно, может ли Хельм быть здесь более изящным, тем более что это, вероятно, может появиться снова в любой момент.

Решите аналогичную проблему, установив диаграмму стабильного / метрик-сервера в кластере, установленном kubeadm.

Когда вы пытаетесь удалить диаграмму, удаление завершается с ошибкой api-server (потому что сервер метрик - fubar), и в результате остается масса болтающихся ресурсов, которые вам нужно очистить вручную - поскольку helm удалил выпуск в любом случае из своей базы данных.

$ helm version
version.BuildInfo{Version:"v3.0.0-rc.2", GitCommit:"82ea5aa774661cc6557cb57293571d06f94aff0c", GitTreeState:"clean", GoVersion:"go1.13.3"}

Недавно начал работать с этим в недавно созданных кластерах GKE, используя 2.15.1 (возможно, недавно был обновлен через Snap). Также сообщается как https://github.com/kubernetes/kubernetes/issues/72051#issuecomment -521157642. Кажется, что можно обойтись, если перед каждой командой helm install вставлять:

kubectl --namespace=kube-system wait --for=condition=Available --timeout=5m apiservices/v1beta1.metrics.k8s.io

@jglick В вашем случае это происходит только при первом создании кластера?

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

В вашем случае это происходит только при первом создании кластера?

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

@jglick реализация, которую я сделал вчера, скорее всего, поможет вам избежать проблемы, если только вы не пишете диаграммы, которые напрямую ссылаются на группу API-интерфейсов.

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

Есть ли у нас исправление для 2.15 / 2.16?

Это также можно увидеть в 2.16. GKE Master версия 1.14.8-гке.12.

Error: UPGRADE FAILED: Could not get apiVersions from Kubernetes: unable to retrieve the complete list of server APIs: metrics.k8s.io/v1beta1: the server is currently unable to handle the request
UPGRADE FAILED

в версии 2.16 нет исправлений. Если вы хотите перенести исправление из Helm 3, это будет долгожданное изменение.

Для пользователей GKE у Google возникают проблемы с heapster и metric-server. Это то, что вызывает сбои руля и объясняет, почему он иногда работает, а другие нет.

Event Start: 10/30/19
Affected Products:
Cloud Services
Description:
The issue with Google Kubernetes Engine experiencing an elevated rate of errors for heapster autoscaling is in the process of being mitigated and our Engineering Team is working to deploy new versions with a fix.
Once the fixed versions become available affected customers will be able to upgrade their clusters to receive the fix.
We will provide an update on the status of the fix by Wednesday, 2019-11-13 16:30 US/Pacific with current details. In the interim, if you have questions or are impacted, please open a case with the Support Team and we will work with you until this issue is resolved.
Steps to Reproduce:
Heapster deployment may be crashing due to inaccurate resource values and then fail to resize due to an invalid name reference in the heapster-nanny container. The logs for an affected clusters will show errors like the below under the heapster-nanny container logs:
ERROR: logging before flag.Parse: E1030 14:50:59.147245 1 nanny_lib.go:110] deployments.extensions "heapster-v1.7.X" not found
Workaround:
Manually add requests/limits to the heapster container under the heapster deployment::
kubectl -n kube-system edit deployment heapster
These values can be calculated as:
* cpu: 80m + 0.5m * number of nodes
* memory: 140Mi + 4Mi * number of nodes

Я просто использую helm 3.0.0 stable и столкнулся с проблемой:

Error: Could not get apiVersions from Kubernetes: unable to retrieve the complete list of server APIs: admission.certmanager.k8s.io/v1beta1: the server is currently unable to handle the request: exit status 1

Казалось, что apiservice работает нормально, потому что Availabiliy показывал "true" в kubectl get apiservices | grep certmanager .

После "перезапуска" с kubectl delete apiservice v1beta1.admission.certmanager.k8s.io проблема исчезла.

исправление было слито с основной веткой, но не с 3.0.0. Патч будет в версии 3.1.

Ищите те, которые ДОСТУПНЫ не соответствуют действительности

Если вам больше не нужны эти API, удалите их:

kubectl удалить apiservce

$ kubectl get apiservice
NAME                                   SERVICE              AVAILABLE                 AGE
v1.                                    Local                True                      2d20h
v1.apps                                Local                True                      2d20h
v1.authentication.k8s.io               Local                True                      2d20h
v1.authorization.k8s.io                Local                True                      2d20h
v1.autoscaling                         Local                True                      2d20h
v1.batch                               Local                True                      2d20h
v1.coordination.k8s.io                 Local                True                      2d20h
v1.networking.k8s.io                   Local                True                      2d20h
v1.rbac.authorization.k8s.io           Local                True                      2d20h
v1.scheduling.k8s.io                   Local                True                      2d20h
v1.storage.k8s.io                      Local                True                      2d20h
v1alpha3.compose.docker.com            docker/compose-api   False (ServiceNotFound)   2d19h
v1beta1.admissionregistration.k8s.io   Local                True                      2d20h
v1beta1.apiextensions.k8s.io           Local                True                      2d20h
v1beta1.apps                           Local                True                      2d20h
v1beta1.authentication.k8s.io          Local                True                      2d20h
v1beta1.authorization.k8s.io           Local                True                      2d20h
v1beta1.batch                          Local                True                      2d20h
v1beta1.certificates.k8s.io            Local                True                      2d20h
v1beta1.compose.docker.com             docker/compose-api   False (ServiceNotFound)   2d19h
v1beta1.coordination.k8s.io            Local                True                      2d20h
v1beta1.events.k8s.io                  Local                True                      2d20h
v1beta1.extensions                     Local                True                      2d20h
v1beta1.networking.k8s.io              Local                True                      2d20h
v1beta1.node.k8s.io                    Local                True                      2d20h
v1beta1.policy                         Local                True                      2d20h
v1beta1.rbac.authorization.k8s.io      Local                True                      2d20h
v1beta1.scheduling.k8s.io              Local                True                      2d20h
v1beta1.storage.k8s.io                 Local                True                      2d20h
v1beta2.apps                           Local                True                      2d20h
v1beta2.compose.docker.com             docker/compose-api   False (ServiceNotFound)   2d19h
v2beta1.autoscaling                    Local                True                      2d20h
v2beta2.autoscaling                    Local                True                      2d20h


$ kubectl delete apiservce v1beta2.compose.docker.com
error: the server doesn't have a resource type "apiservce"

Windows 10, доксер для windows.

Я предполагаю, что в инструкции была опечатка. Наверное, должно быть
kubectl delete apiservice (отсутствует i в обслуживании)

Мы также сталкиваемся с непоследовательным поведением при удалении. Например

1. Мы устанавливаем намеренно неверно настроенный сервер метрик
   1а. ресурсы создаются, но модуль сервера метрик завершается аварийным завершением работы (ожидается)
2. Управляем удалением metrics-server
   2а. Мы возвращаемся: «Ошибка: удаление завершено с 1 ошибкой (-ями): не удалось получить версии API из Kubernetes: не удалось получить версии API из Kubernetes: невозможно получить полный список API сервера: metrics.k8s.io/v1beta1: сервер в настоящее время не может обработать запрос "
   2b. Секрет выпуска Helm удален
   2c. Все ресурсы на графике по-прежнему присутствуют в кластере
   2г. Требуется ручная очистка

Единственная часть «удаления», которая была завершена, - это удаление секрета выпуска.

PR, который исправил это, был здесь: https://github.com/helm/helm/pull/6908 См. Дополнительное обсуждение того, остается ли еще один дополнительный случай.

@ где мы можем

Если у кого-то есть возможность протестировать исправление Helm 2, то оно здесь: # 7196

@bacongobbler согласно вашему комментарию здесь https://github.com/helm/helm/issues/6361#issuecomment -554480815 вы знаете, когда будет доступна версия 3.1? Я только что установил 3.0.1 и все еще сталкиваюсь с проблемой - я был удивлен, что это исправление не вошло в v3.0.1, поскольку это, кажется, довольно распространенная проблема. Есть ли шанс, что он попадет в выпуск v3.0.x, если он будет до v3.1?

Тот же вопрос, что и @mcginne . Я уже немного использую основную ветку, ожидая, когда это исправление войдет в релиз. Но я бы хотел вернуться к выпуску. Эта ошибка затрудняет автоматизацию написания с помощью helm (если только вы не хотите просто испытать удачу и повсюду поставить спящих и официантов).

Даже просто как 3.1alpha или еще что-нибудь было бы неплохо :)

Закрытие этой проблемы, поскольку она решена на master

Еще один случай:

Error: failed to fetch api groups from kubernetes: unable to retrieve the complete list of server APIs: tap.linkerd.io/v1alpha1: the server is currently unable to handle the request

Это было связано с https://github.com/linkerd/linkerd2/issues/3497 , когда служба Linkerd имела некоторые внутренние проблемы и не могла отвечать на запросы службы API. Исправлено перезапуском его подов.

@ kivagant-ba, не могли бы вы открыть для этого новый номер? Это немного другой случай, и нам нужно решить, каким должно быть «правильное» поведение со стороны Хелма. Я думаю, что в текущем исправлении вышеуказанная ошибка будет по-прежнему считаться фатальной.

Для всех, кто сталкивается с этим, это вызвано api-сервисами, у которых больше не работает серверная часть ...

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

Починить это:

kubectl get apiservice

Найдите те, которые AVAILABLE равны False

Если вам больше не нужны эти API, удалите их:

kubectl delete apiservice <service-name>

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

Небольшая поправка в написании слова «сервис». исправил.

не могли бы вы открыть для этого новый выпуск?

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

Ой! Хорошо. Спасибо!

@technosophos, что исправить? Должны ли мы выполнить grep kubectl get apiservice а затем заблокировать, пока все службы не перейдут в состояние Ready ? Что мы могли бы сделать вместо этого?

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

Я только что столкнулся с этой проблемой при выполнении helm delete . Это вызвало очень плохой эффект. Релиз Helm был удален, но все объекты K8s продолжали работать в кластере. Так что пришлось все снимать вручную. А так как это был оператор, это действие потребовало значительных усилий.

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

@alexellis Что именно вызывает проблему? Вы устанавливаете диаграмму Helm, которая устанавливает службу API, и задаетесь вопросом, как дождаться ее доступности? Короткий ответ заключается в том, что вам обязательно нужно будет разработать стратегию ожидания или, возможно, разбить ее на два графика. Kubernetes не дает нам большого количества инструментов, чтобы иметь возможность справляться с ошибками в API обнаружения, но если описание службы не поддерживается службой, вызов обнаружения обязательно завершится ошибкой _ и не вернет службу_ на карте, которую он возвращает.

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

Конечно.

Шлем: 3.0.0
K8s: 1.14.8

helm delete prom -n monitoring завершился следующей ошибкой

Error: uninstallation completed with 1 error(s): could not get apiVersions from Kubernetes: could not get apiVersions from Kubernetes: unable to retrieve the complete list of server APIs: admission.stash.appscode.com/v1alpha1: the server is currently unable to handle the request, admission.stash.appscode.com/v1beta1: the server is currently unable to handle the request, repositories.stash.appscode.com/v1alpha1: the server is currently unable to handle the request

После этого релиз Helm исчез из списка релизов Helm, и все объекты, связанные с этим оператором Prometheus, стали сиротами.

Хорошо, понятно, это может быть проблема с версией. Обновит Helm до последней версии 3.0.2 как можно скорее.

Да, это определенно проблема несоответствия версий. Этот патч стал доступен в версии 3.0.2. В будущем обязательно используйте последнюю версию патча (или, что еще лучше, мастер-версию). Спасибо!

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

kubectl get apiservice

Если одна из служб «AVAILABLE = false», вы можете попытаться удалить связанные модули, чтобы перезапустить их.
Это решило мою проблему с сервисом kube-system / metrics.

Привет @technosophos. Может быть, я что-то упустил, но я не вижу, чтобы этот PR https://github.com/helm/helm/pull/6908/files переносился на 2.16.3, хотя такое случается и с helm 2. Планируете ли вы перенести этот обходной путь и на Helm 2?

Несколько месяцев назад он был объединен с dev-v2 . Вы можете построить из этой ветки и протестировать ее, если хотите.

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

Вы тестировали ветку dev-v2 ? В настоящее время у нас нет никаких подтверждений (кроме наших собственных тестов), что решение там работает, хотя, по сути, это то же самое решение.

У меня нет, я могу попробовать на этой неделе. Поскольку я использую это с Terraform, могу ли я создать / запустить ветку dev-v2 и установить для переменной репозитория ресурса helm_release значение "local" для моделирования?

@bacongobbler. Мы столкнулись с той же проблемой с prometheus-adapter которая предоставила настраиваемый apiservice, и если я не смогу выпустить с настраиваемым apiservice и kubectl get apiservice любой из этого списка будет AVAILABLE = false Helm больше не сможет создавать новые выпустить, даже если это не связано с настраиваемым apiservice:
err="Could not get apiVersions from Kubernetes: unable to retrieve the complete list of server APIs: custom.metrics.k8s.io/v1beta1: the server is currently unable to handle the request"

Helm 2 с провайдером Terraform сейчас не работает из-за этой проблемы и. Надеюсь, вы также можете исправить это, похоже, это обычный вариант использования.

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

Решение:

Я выполнил следующие шаги:

1. kubectl get apiservices : Если служба сервера метрик не работает с ошибкой CrashLoopBackOff, попробуйте выполнить шаг 2, в противном случае просто попробуйте перезапустить службу сервера метрик с помощью kubectl delete apiservice/"service_name" . Для меня это был v1beta1.metrics.k8s.io.

2. kubectl get pods -n kube-system и обнаружил, что модули, такие как metrics-server, kubernetes-dashboard, не работают из-за отказа основного модуля coreDNS.

Для меня это было:

NAME                          READY   STATUS             RESTARTS   AGE
pod/coredns-85577b65b-zj2x2   0/1     CrashLoopBackOff   7          13m

1. Используйте kubectl describe pod/"pod_name" чтобы проверить ошибку в модуле coreDNS, и если он не работает из-за / etc / coredns / Corefile: 10 - Ошибка во время синтаксического анализа: Неизвестная директива прокси, тогда нам нужно использовать пересылку вместо прокси в yaml файл, в котором находится конфигурация coreDNS. Поскольку CoreDNS версии 1.5x, используемый изображением, больше не поддерживает ключевое слово proxy.

https://stackoverflow.com/questions/62442679/could-not-get-apiversions-from-kubernetes-unable-to-retrieve-the-complete-list