Helm: no se puede recuperar la lista completa de API del servidor

Tengo el mismo problema en AKS, aunque el mensaje de error es

Error: no se pudo obtener apiVersions de Kubernetes: no se pudo recuperar la lista completa de API del servidor: metrics.k8s.io/v1beta1: el servidor actualmente no puede manejar la solicitud

mi configuración:

• versión kubectl:

Versión del cliente: version.Info {Major: "1", Minor: "15", GitVersion: "v1.15.2", GitCommit: "f6278300bebbb750328ac16ee6dd3aa7d3549568", GitTreeState: "clean", BuildDate: "2019-08-05T09: 23: 26Z ", GoVersion:" go1.12.5 ", Compilador:" gc ", Plataforma:" windows / amd64 "}
Versión del servidor: version.Info {Major: "1", Minor: "14", GitVersion: "v1.14.6", GitCommit: "96fac5cd13a5dc064f7d9f4f23030a6aeface6cc", GitTreeState: "clean", BuildDate: "2019-08-19T11: 05: 16Z ", GoVersion:" go1.12.9 ", Compilador:" gc ", Plataforma:" linux / amd64 "}

• versión del timón: alpine / helm: 3.0.0-beta.2 (docker)

• recursos api de kubectl
  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

Creo que en mi caso, este problema comenzó recientemente ... parece estar relacionado con tener Knative instalado en mi caso (en IBM Cloud IKS, esta es una opción administrada). He desinstalado Knative y estoy bien por ahora, pero podría haber un problema de interoperabilidad aquí.

@kalioz por interés, ¿está usando knative en AWS? En realidad no parece porque no puedo ver los objetos de tekton.

Yo mismo acabo de ver este problema. En mi caso, fue cert-manager el que desencadenó el problema. Todavía estoy trabajando en cómo volver a ser como estaba.

@ planetf1 No estoy usando knative (o creo que no), pero el problema solo existe en el nuevo clúster que implementé para esta prueba.
Las diferencias entre el grupo de trabajo y el que no funciona son:

| | trabajando | no trabajando |
| --- | --- | --- |
| versión kube | 1.13.5 | 1.14.6 |
| autenticación AD azure | deshabilitado | habilitado |
| RBAC | deshabilitado | habilitado |

Entonces tengo algunos cambios importantes.

Para mí, el problema es que helm3 se bloquea debido a la falta de acceso a algunas apis, que no se utilizan para el gráfico que estoy tratando de implementar.

Lo estoy usando en la versión 1.13.9 del clúster k8, se produce el mismo error para implementar cualquier gráfico estable.

versión de timón
version.BuildInfo {Versión: "v3.0.0-beta.3", GitCommit: "5cb923eecbe80d1ad76399aee234717c11931d9a", GitTreeState: "clean", GoVersion: "go1.12.9"}

helm.go: 81: [debug] no puede recuperar la lista completa de API del servidor: metrics.k8s.io/v1beta1: el servidor actualmente no puede manejar la solicitud.

Después de resolver el problema desde el pod de métricas (no recuerdo cómo lo resolví, creo que podría tener que ver con hostNetwork o simplemente reiniciar el pod asociado) helm3 funciona como se esperaba.
Por lo tanto, podría ser una 'característica', ya que obliga a mantener el clúster en buen estado, pero requerirá que alguien ingrese manualmente al clúster cada vez que se rompa la API (y, por lo tanto, podría evitar el uso de helm3 para implementar pods que se pueden enumerar en este).

Es muy, muy molesto para alguien que empieza con Kubernetes. Estoy implementando una solución para certificados que usan acme, ya que no puedo garantizar que el administrador de certificados no se rompa incluso después de configurarlo.

¡La parte realmente molesta es que no puedo usar helm para desinstalar el administrador de certificados y volver a donde estaba! Todo lo que permita que un servicio altamente recomendado lo rompa y no deshaga el cambio está roto.

Para cualquiera que llegue a esto, es causado por api-services que ya no tienen backends en ejecución ...

En mi caso fue KEDA, pero hay varios servicios diferentes que instalan servidores API agregados.

Arreglarlo:

kubectl get apiservice

Busque los que el AVAILABLE es False

Si ya no necesita esas API, elimínelas:

kubectl delete apiservce <service-name>

Entonces Helm debería funcionar correctamente. Creo que puede valer la pena mejorar el mensaje de error de Helm para este caso ...

Gracias por la explicación, ¿hay alguna forma de que Helm pueda codificar esto también?

Creemos que sí, aunque todavía estamos investigando. Mi primer vistazo sugiere que esto solo está relacionado con nuestro uso de Discovery API, que se usa para el objeto Capabilities en la representación de plantillas. Es posible que podamos atrapar este error en particular y advertir al usuario en lugar de fallar.

Lo mismo con 2.15.0 ahora:

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

Esto es bastante molesto. Sería mucho mejor advertir en lugar de fallar.
¿Alguna actualización sobre esto hasta ahora?

EDITAR: ¿puede s / o confirmar que 2.15 también se ve afectado? Entonces sugeriría ajustar las etiquetas de este boleto.

@sjentzsch También veo lo mismo usando Helm 2.15.0 y k8s 1.16.0 .

Si esto también afecta a 2.x, entonces todos los que utilicen "cert-manager" (posiblemente solo la preconfiguración) lo pasarán mal.

__Aquí tenemos dos casos diferentes con el mismo comportamiento desde el lado del timón.
Ambas versiones 2.15.1 y 3 beta se ven afectadas .__

Como mencionó @technosophos, helm usa la funcionalidad de la API de descubrimiento y falla si alguna de las respuestas de la API falla https://github.com/helm/helm/blob/f1dc84773f9a34fe59a504fdb32428ce1d56a2e8/pkg/action/action.go#L105 -L118

1. cert-manager's admission.certmanager.k8s.io/v1beta1 es un buen ejemplo:

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

y para este caso, puede solucionarlo fácilmente con kubectl delete apiservice v1beta1.admission.certmanager.k8s.io
como lo describió

1. Otro caso de falla cuando helm no puede recuperar la respuesta de ningún servicio de API
   por ejemplo, "metrics.k8s.io/v1beta1: el servidor actualmente no puede manejar la solicitud" y sucede de un caso a otro

Actualmente, está vivo y funcionando, pero se cayó accidentalmente durante la solicitud del timón.

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

Estoy seguro de que el timón debe ser más robusto para este tipo de problemas,
1) tal vez sea una buena idea convertir el error en advertencia (no sé cómo se usa la información del servicio api durante la representación de la plantilla)
2) implementar reintentos para este tipo de solicitudes

Tenemos un problema similar con 2.15.1 en Kubernetes 1.15.5, pero NO con helm 2.14.3.

El problema es flotante: algunos gráficos están instalados correctamente, pero luego comienzan a fallar.
Nuestro mensaje es:

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 enumera metrics.k8s.io/v1beta1 como disponibles. Puede ser que tengamos un problema transitorio con este servicio, pero helm 2.14.3 en clústeres en su mayoría idénticos funciona de manera confiable.

Nos topamos con este problema al intentar actualizar a Helm 2.15.2 en el clúster de CI de gráficos. Entonces, no es solo un problema de Helm 3. Eliminar el servicio de API que faltaba lo solucionó. Me pregunto si Helm podría ser más elegante aquí, especialmente porque esto probablemente podría volver a aparecer en cualquier momento.

Tiene un problema similar al instalar el gráfico estable / metrics-server en un clúster instalado de kubeadm.

Cuando intenta desinstalar el gráfico, la desinstalación falla con un error de api-server (porque el servidor de métricas es fubar), y eso deja una gran cantidad de recursos colgando por ahí que debe limpiar a mano, ya que helm ha eliminado la versión. de su base de datos de todos modos.

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

Comencé a hacer esto recientemente en clústeres de GKE recién creados, usando 2.15.1 (es posible que se haya actualizado recientemente a través de Snap). También se informa como https://github.com/kubernetes/kubernetes/issues/72051#issuecomment -521157642. Parece ser capaz de solucionarlo anteponiendo cada comando helm install con:

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

@jglick En su caso, ¿está sucediendo solo cuando se crea el clúster por primera vez?

El problema está en el fondo del cliente de descubrimiento de Kubernetes Go. Estoy experimentando con solo imprimir una advertencia. Sin embargo, eso podría tener consecuencias negativas para los gráficos que dependen en gran medida del objeto Capacidades.

En su caso, ¿está sucediendo solo cuando se crea el clúster por primera vez?

Si. Tengo un script que crea un clúster, instala Tiller y crea lanzamientos de Helm. Entonces parece una condición de carrera en la inicialización del clúster.

@jglick, la implementación que hice ayer probablemente evitará el problema para usted a menos que esté escribiendo gráficos que hagan referencia directamente al grupo de API ofensivo.

@technosophos gracias por esa fusión. Creo que mejorará la resistencia del timón.

¿Tenemos una solución para 2.15 / 2.16?

Ver esto también en 2.16. GKE Master versión 1.14.8-gke.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

no se ha puesto a disposición ninguna corrección para 2.16. Si tiene ganas de transferir la solución desde Helm 3, sería un cambio bienvenido.

Para los usuarios de GKE, Google tiene problemas con el servidor de métricas y el heapster. Esto es lo que está causando las fallas del timón y explica por qué funciona a veces y no a otras.

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

Solo uso helm 3.0.0 estable y ejecuté el problema:

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

El servicio parecía estar saludable porque la disponibilidad mostraba "verdadera" en kubectl get apiservices | grep certmanager .

Después de "reiniciar" con kubectl delete apiservice v1beta1.admission.certmanager.k8s.io el problema desapareció.

la solución se fusionó con la rama maestra, pero no se fusionó con la 3.0.0. El parche estará en 3.1.

Busque los que el DISPONIBLE es falso

Si ya no necesita esas API, elimínelas:

kubectl eliminar 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, dokcer para windows.

Supongo que hubo un error tipográfico en las instrucciones. Probablemente debería ser
kubectl delete apiservice (falta i en servicio)

También nos afecta un comportamiento inconsistente al eliminar. Por ejemplo

1. Nos encargamos de instalar el servidor de métricas deliberadamente mal configurado
   1a. los recursos se crean pero el pod del servidor de métricas termina en crashloopbackoff (esperado)
2. Nos encargamos de eliminar el servidor de métricas
   2a. Regresamos "Error: desinstalación completada con 1 error (s): no se pudo obtener apiVersions de Kubernetes: no se pudo obtener apiVersions de Kubernetes: no se pudo recuperar la lista completa de API del servidor: metrics.k8s.io/v1beta1: el servidor es actualmente no puede manejar la solicitud "
   2b. Se eliminó el secreto de liberación del timón
   2c. Todos los recursos del gráfico todavía están presentes en el clúster.
   2d. La limpieza manual es necesaria

La única parte de la "desinstalación" que se completó fue eliminar el secreto de la versión.

El PR que solucionó esto estaba aquí: https://github.com/helm/helm/pull/6908 Vea la discusión adicional sobre si todavía queda un caso adicional.

@ ¿ exportar esta solución a la

Si alguien está disponible para probar la corrección de Helm 2, está aquí: # 7196

@bacongobbler según su comentario aquí https://github.com/helm/helm/issues/6361#issuecomment -554480815 ¿sabe cuándo estará disponible la v3.1? Acabo de instalar 3.0.1 y todavía tengo el problema; me sorprendió que esta solución no llegara a la v3.0.1, ya que parece ser un problema bastante generalizado. ¿Alguna posibilidad de que se convierta en una versión v3.0.x si será antes de la v3.1?

Misma pregunta que @mcginne . He estado usando la rama maestra por un tiempo esperando que esta solución se publique. Pero me gustaría volver a estar en un comunicado. Este error hace que la automatización de la escritura con helm bastante difícil (a menos que solo quiera probar suerte y poner camas y camareros en todas partes).

Incluso como un 3.1alpha o algo sería bueno :)

Cerrando este problema, ya que se resolvió en master

Un caso más:

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

Estaba relacionado con https://github.com/linkerd/linkerd2/issues/3497 , cuando el servicio Linkerd tuvo algunos problemas internos y no pudo responder a las solicitudes del servicio API. Se corrigió reiniciando sus pods.

@ kivagant-ba, ¿te importaría abrir un nuevo número para ese? Es un caso ligeramente diferente, y tendremos que decidir cuál debería ser el comportamiento "correcto" por parte de Helm. Creo que la solución actual seguirá considerando lo anterior como un error fatal.

Para cualquiera que llegue a esto, es causado por api-services que ya no tienen backends en ejecución ...

En mi caso fue KEDA, pero hay varios servicios diferentes que instalan servidores API agregados.

Arreglarlo:

kubectl get apiservice

Busque los que el AVAILABLE es False

Si ya no necesita esas API, elimínelas:

kubectl delete apiservice <service-name>

Entonces Helm debería funcionar correctamente. Creo que puede valer la pena mejorar el mensaje de error de Helm para este caso ...

Sólo una pequeña corrección en la ortografía del "servicio". lo corrigió.

¿Le importaría abrir un nuevo número para ese?

No es un problema para las personas que utilizan una versión más reciente de Linkerd. Dejé mi comentario aquí para aquellos que buscarán la frase de error porque se ve similar pero la causa raíz es diferente.

¡Oh! Bueno. ¡Gracias!

@technosophos ¿cuál es la solución para esto? ¿Debemos grep kubectl get apiservice y luego bloquear hasta que todos los servicios estén en un estado Ready ? ¿Hay algo más que podamos hacer en su lugar?

Estamos trabajando en una herramienta OSS que instala una serie de gráficos de timón para iniciar un sistema y este problema parece estar causando que todo el proceso falle de forma intermitente.

Acabo de enfrentar este problema al hacer helm delete . Causó un efecto muy malo. La versión de Helm se eliminó, pero todos los objetos de K8 se mantuvieron ejecutándose en el clúster. Entonces tuvimos que quitar todo a mano. Y como se trataba de un operador, esta acción requirió un esfuerzo importante.

@andrewnazarov Proporcione más información sobre lo que intentó eliminar y lo que sucedió. Los mensajes de error serían útiles, al igual que la versión de Helm, la versión de Kube, etc.

@alexellis ¿Qué es exactamente lo que está causando un problema? ¿Está instalando un gráfico de Helm que instala un servicio API y se pregunta cómo esperar hasta que esté disponible? La respuesta corta es que definitivamente necesitará diseñar una estrategia para esperar, o posiblemente dividirla en dos gráficos. Kubernetes no nos brinda muchas herramientas para poder lidiar con errores en la API de descubrimiento, pero si la descripción de un servicio no está respaldada por un servicio, una llamada de descubrimiento definitivamente fallará _y no devolverá el servicio_ en el mapa que devuelve.

Proporcione más información sobre lo que intentó eliminar y lo que sucedió. Los mensajes de error serían útiles, al igual que la versión de Helm, la versión de Kube, etc.

Seguro.

Timón: 3.0.0
K8s: 1.14.8

helm delete prom -n monitoring terminó con el siguiente error

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

Después de eso, el lanzamiento de Helm desapareció de la lista de lanzamientos de Helm y todos los objetos relacionados con ese operador de Prometheus quedaron huérfanos.

Ok, ya veo, podría ser un problema de versión. Actualizará Helm a la versión más reciente 3.0.2 lo antes posible.

Sí, definitivamente se trata de un problema de desajuste de versiones. Este parche estuvo disponible en 3.0.2. En el futuro, asegúrese de probar con la última versión del parche (o, mejor aún, en la versión maestra). ¡Gracias!

Si tiene más problemas, abra un nuevo ticket.

kubectl get apiservice

Si uno de los servicios "AVAILABLE = false", puede intentar eliminar los pods relacionados para reiniciarlos.
Resolvió mi problema con el servicio kube-system / metrics.

Hola @technosophos. Puede que me haya perdido algo, pero no veo que este PR https://github.com/helm/helm/pull/6908/files se transfiera a 2.16.3, aunque también sucede con helm 2. ¿Está planeando portar esta solución alternativa también en helm 2?

Se fusionó en dev-v2 hace unos meses. Puede construir a partir de esa rama y probarla si lo desea.

Sería genial ver esto incorporado en Helm 2 y el proveedor de Terraform . Puedo repoblar este error cada vez que se crea un clúster.

¿Ha probado la rama dev-v2 ? Actualmente no tenemos ninguna confirmación (aparte de nuestras propias pruebas) de que la solución allí funcione, aunque en esencia es la misma solución.

No lo he hecho, puedo intentarlo esta semana. Ya que estoy usando esto con Terraform, ¿puedo construir / ejecutar la rama dev-v2 y establecer la variable de repositorio del recurso helm_release en "local" para simular?

@bacongobbler Nos enfrentamos al mismo problema con prometheus-adapter que exponía un servicio personalizado y si fallaba el lanzamiento con un servicio personalizado y kubectl get apiservice cualquiera de esta lista estaría DISPONIBLE = el timón falso ya no puede hacer nada nuevo lanzamiento incluso si no está relacionado con un servicio personalizado:
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 con el proveedor de Terraform está roto debido a este problema en este momento y. Espero que también pueda proporcionarle una solución, parece que este es un caso de uso común.

Puedo confirmar que también tengo este problema. Esperando una solución.

Solución:

Los pasos que seguí son:

1. kubectl get apiservices : Si el servicio del servidor de métricas no funciona con el error CrashLoopBackOff, intente seguir el paso 2; de lo contrario, intente reiniciar el servicio del servidor de métricas usando kubectl delete apiservice/"service_name" . Para mí fue v1beta1.metrics.k8s.io.

2. kubectl get pods -n kube-system y descubrió que pods como metrics-server, kubernetes-dashboard están inactivos debido a que el pod coreDNS principal estaba inactivo.

Para mi fue:

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

1. Use kubectl describe pod/"pod_name" para verificar el error en el pod coreDNS y si está inactivo debido a / etc / coredns / Corefile: 10 - Error durante el análisis: proxy de directiva desconocida, entonces debemos usar adelante en lugar de proxy en el yaml archivo donde está la configuración de coreDNS. Porque la versión 1.5x de CoreDNS utilizada por la imagen ya no admite la palabra clave proxy.

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