Helm: incapaz de recuperar a lista completa de APIs de servidor

Tenho o mesmo problema no AKS, embora a mensagem de erro seja

Erro: não foi possível obter apiVersions do Kubernetes: não foi possível recuperar a lista completa de APIs do servidor: metrics.k8s.io/v1beta1: o servidor não consegue processar a solicitação no momento

minha configuração:

• versão kubectl:

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

• versão do leme: alpino / leme: 3.0.0-beta.2 (docker)

• kubectl api-resources
  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

Eu acredito que no meu caso este problema começou recentemente ... parece ser em relação a ter o knative instalado no meu caso (no IBM Cloud IKS esta é uma opção gerenciada). Desinstalei o knative e estou bem por enquanto, mas pode haver um problema de interoperabilidade aqui

@kalioz sem interesse, você está usando o knative na AWS? Parece que não, pois não consigo ver os objetos tekton

Eu mesmo acabei de ver esse problema. No meu caso, foi o cert-manager que desencadeou o problema. Ainda estou trabalhando em como voltar a ser como era.

@ planetf1 Não estou usando o knative (ou acho que não), mas o problema só existe no novo cluster que implantei para este teste.
As diferenças entre o cluster funcional e o não funcional são:

| trabalho | não trabalho |
| --- | --- | --- |
| versão kube | 1.13.5 | 1.14.6 |
| autenticação do azure AD | desativado | ativado |
| RBAC | desativado | ativado |

Portanto, tenho algumas mudanças importantes.

Para mim o problema é que o helm3 travou por falta de acesso a algumas apis, que não são usadas para o gráfico que estou tentando implantar.

Estou usando no cluster K8 versão 1.13.9, mesmo erro está chegando para implantar qualquer gráfico estável.

versão do leme
version.BuildInfo {Versão: "v3.0.0-beta.3", GitCommit: "5cb923eecbe80d1ad76399aee234717c11931d9a", GitTreeState: "clean", GoVersion: "go1.12.9"}

helm.go: 81: [debug] não foi possível recuperar a lista completa de APIs do servidor: metrics.k8s.io/v1beta1: o servidor atualmente não consegue lidar com a solicitação.

Depois de resolver o problema do pod de métricas (não me lembro como resolvi, acho que pode ter a ver com hostNetwork ou simplesmente reiniciar o pod associado) helm3 funcionar conforme o esperado.
Portanto, pode ser um 'recurso', pois força a manter o cluster em boas condições, mas exigirá que alguém vá manualmente para o cluster cada vez que uma API for interrompida (e, portanto, pode impedir o uso de helm3 para implantar pods que podem ser listados nisto).

É muito, muito irritante para quem está começando no Kubernetes. Estou lançando mão de uma solução para certificados usando acme, já que não posso garantir que o gerenciador de certificados ainda não quebrará mesmo depois de configurá-lo.

A parte realmente chata é que não posso simplesmente usar o helm para desinstalar o cert manager e voltar para onde estava! Tudo o que permite que um serviço fortemente recomendado o interrompa e não desfaça a alteração, está quebrado.

Para qualquer um que acertar isso, é causado por api-services que não têm mais back-ends em execução ...

No meu caso, foi KEDA, mas há vários serviços diferentes que instalam servidores API agregados.

Para fixar isso:

kubectl get apiservice

Procure aqueles que AVAILABLE é False

Se você não precisa mais dessas APIs, exclua-as:

kubectl delete apiservce <service-name>

Então, o Helm deve funcionar corretamente. Acho que pode valer a pena melhorar a mensagem de erro do Helm para este caso ...

Obrigado pela explicação - existe uma maneira de o Helm codificar em torno disso também?

Achamos que sim, embora ainda estejamos investigando. Minha primeira olhada sugere que isso está relacionado apenas ao nosso uso da API Discovery, que é usada para o objeto Capabilities na renderização do modelo. Podemos detectar esse erro específico e avisar o usuário em vez de falhar.

O mesmo com 2.15.0 agora:

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

Isso é muito chato. Advertir, em vez de falhar, seria muito melhor.
Alguma atualização sobre isso até agora?

EDITAR: s / o pode confirmar que 2.15 também foi afetado? Então eu sugeriria ajustar as etiquetas deste tíquete.

@sjentzsch Também estou vendo o mesmo usando Helm 2.15.0 e k8s 1.16.0 .

Se isso também afetar o 2.x, então todos que usarem o "cert-manager" (possivelmente apenas a pré-configuração) passarão por maus bocados.

__Aqui temos dois casos diferentes com o mesmo comportamento do lado do leme.
As versões 2.15.1 e 3 beta são afetadas .__

Como @technosophos mencionou, o helm usa a funcionalidade da API de descoberta e falha se alguma das respostas da API falhar https://github.com/helm/helm/blob/f1dc84773f9a34fe59a504fdb32428ce1d56a2e8/pkg/action/action.go#L105 -L118

1. admission.certmanager.k8s.io/v1beta1 cert-manager é um bom exemplo:

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

e, para este caso, você pode consertá-lo facilmente por kubectl delete apiservice v1beta1.admission.certmanager.k8s.io
como @brendandburns descrito.

1. Outro caso de falha quando o leme não consegue recuperar a resposta de nenhum serviço da API
   por exemplo, "metrics.k8s.io/v1beta1: o servidor atualmente não é capaz de lidar com a solicitação" e isso acontece caso a caso

Atualmente, ele está vivo e funcionando, mas caiu acidentalmente durante o pedido do leme.

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

Tenho certeza de que o leme deve ser mais robusto para esse tipo de problema,
1) talvez seja uma boa ideia converter o erro em aviso (não sei como as informações do serviço da API usam durante a renderização do modelo)
2) implementar novas tentativas para esse tipo de solicitação

Temos um problema semelhante com o 2.15.1 no Kubernetes 1.15.5, mas NÃO com o helm 2.14.3.

O problema é flutuante: alguns gráficos estão bem instalados, mas começam a falhar.
Nossa mensagem é:

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 lista metrics.k8s.io/v1beta1 como disponíveis. Pode ser que tenhamos um problema temporário com este serviço, mas o leme 2.14.3 no cluster quase idêntico funciona de forma confiável.

Encontramos esse problema ao tentar atualizar para o Helm 2.15.2 no cluster de gráficos de CI. Portanto, não é apenas um problema do Helm 3. A exclusão do serviço API ausente corrigiu o problema. Eu me pergunto se Helm poderia ser mais gracioso aqui, especialmente porque isso provavelmente poderia aparecer novamente a qualquer momento.

Teve um problema semelhante ao instalar o gráfico stable / metrics-server em um cluster instalado do kubeadm.

Quando você tenta desinstalar o gráfico, a desinstalação falha com um erro de servidor api (porque o servidor de métricas é fubar), e isso deixa uma carga de recursos pendentes que você precisa limpar manualmente - já que o helm removeu a versão de seu banco de dados de qualquer maneira.

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

Comecei a acertar isso recentemente em clusters GKE recém-criados, usando 2.15.1 (pode ter sido atualizado recentemente por meio do Snap). Também relatado como https://github.com/kubernetes/kubernetes/issues/72051#issuecomment -521157642. Parece ser capaz de contornar antes de cada comando helm install com:

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

@jglick No seu caso, isso está acontecendo apenas quando o cluster é criado pela primeira vez?

O problema está no fundo do cliente de descoberta do Kubernetes Go. Estou experimentando apenas imprimir um aviso. No entanto, isso pode ter consequências negativas para gráficos que dependem muito do objeto Capabilities.

No seu caso, isso está acontecendo apenas quando o cluster é criado pela primeira vez?

sim. Eu tenho um script que cria um cluster, instala o Tiller e cria versões do Helm. Portanto, parece uma condição de corrida na inicialização do cluster.

@jglick a implementação que fiz ontem muito provavelmente evitará o problema para você, a menos que você esteja escrevendo gráficos que façam referência direta ao grupo de API ofensivo.

@technosophos, obrigado por essa fusão. Acho que vai melhorar a resiliência do leme.

Temos uma correção para 2.15 / 2.16?

Vendo isso em 2.16 também. GKE Master versão 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

nenhuma correção foi disponibilizada para 2.16. Se você quiser transferir a correção do Helm 3, seria uma mudança bem-vinda.

Para usuários do GKE, o Google está tendo problemas com heapster e metric-server. Isso é o que está causando as falhas do leme e explica por que às vezes funciona e outras não.

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

Acabei de usar o helm 3.0.0 estável e executei o 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

O apiservice parecia estar bom porque a disponibilidade estava mostrando "true" em kubectl get apiservices | grep certmanager .

Depois de "reiniciar" com kubectl delete apiservice v1beta1.admission.certmanager.k8s.io o problema foi embora.

a correção foi incorporada ao branch master, mas não foi incorporada ao 3.0.0. O patch estará em 3.1.

Procure aqueles que o DISPONÍVEL é falso

Se você não precisa mais dessas APIs, exclua-as:

kubectl delete 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.

Suponho que houve um erro de digitação nas instruções. Provavelmente deveria ser
kubectl delete apiservice (faltando i em serviço)

Também somos atingidos por um comportamento inconsistente na exclusão. Por exemplo

1. Nós comandamos a instalação propositalmente mal configurada do servidor de métricas
   1a. recursos são criados, mas o pod do servidor de métricas termina em crashloopbackoff (esperado)
2. Nós comandamos a exclusão do servidor de medidas
   2a. Recebemos de volta "Erro: desinstalação concluída com 1 erro (s): não foi possível obter apiVersions do Kubernetes: não foi possível obter apiVersions do Kubernetes: impossível recuperar a lista completa de APIs do servidor: metrics.k8s.io/v1beta1: o servidor está atualmente incapaz de atender ao pedido "
   2b. O segredo de liberação do leme foi removido
   2c. Todos os recursos do gráfico ainda estão presentes no cluster
   2d. A limpeza manual é necessária

A única parte da "desinstalação" concluída foi a remoção do segredo do lançamento.

O PR que corrigiu isso estava aqui: https://github.com/helm/helm/pull/6908 Veja a discussão adicional sobre se ainda resta um caso adicional.

@onde podemos fazer o backport dessa correção para a v2?

Se alguém estiver disponível para testar a correção do Helm 2, está aqui: # 7196

@bacongobbler conforme seu comentário aqui https://github.com/helm/helm/issues/6361#issuecomment -554480815 você sabe quando a v3.1 estará disponível? Acabei de instalar o 3.0.1 e ainda estou encontrando o problema - fiquei surpreso que essa correção não chegou à v3.0.1, pois parece ser um problema bastante difundido. Alguma chance de chegar a uma versão v3.0.x se for antes da v3.1?

Mesma pergunta que @mcginne . Estou usando o branch master há um tempo, esperando que essa correção seja lançada. Mas eu gostaria de voltar a estar em um lançamento. Este bug torna a escrita de automação com helm muito difícil (a menos que você apenas queira tentar a sua sorte e colocar dorminhocos e garçons em todos os lugares).

Mesmo apenas como 3.1alpha ou algo assim seria bom :)

Fechando este problema, pois foi resolvido em master

Mais um caso:

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

Estava relacionado a https://github.com/linkerd/linkerd2/issues/3497 , quando o serviço Linkerd teve alguns problemas internos e não conseguiu responder às solicitações de serviço da API. Corrigido reiniciando seus pods.

@ kivagant-ba, você se importaria de abrir uma nova edição para esse aqui? É um caso um pouco diferente e teremos que decidir qual deve ser o comportamento "correto" do lado de Helm. Acho que a correção atual ainda considerará o acima um erro fatal.

Para qualquer um que acertar isso, é causado por api-services que não têm mais back-ends em execução ...

No meu caso, foi KEDA, mas há vários serviços diferentes que instalam servidores API agregados.

Para fixar isso:

kubectl get apiservice

Procure aqueles que AVAILABLE é False

Se você não precisa mais dessas APIs, exclua-as:

kubectl delete apiservice <service-name>

Então, o Helm deve funcionar corretamente. Acho que pode valer a pena melhorar a mensagem de erro do Helm para este caso ...

Apenas uma pequena correção ortográfica do "serviço". corrigiu isso.

você se importaria de abrir uma nova edição para esse?

Não é um problema para pessoas que estão usando uma versão mais recente do Linkerd. Deixei meu comentário aqui para quem vai pesquisar a frase de erro porque parece semelhante, mas a causa raiz é diferente.

Oh! OK. Obrigada!

@technosophos qual é a solução para isso? Devemos grep kubectl get apiservice e então bloquear até que todos os serviços estejam em um estado Ready ? Existe algo mais que poderíamos fazer em vez disso?

Estamos trabalhando em uma ferramenta OSS que instala vários gráficos de leme para inicializar um sistema e esse problema parece estar fazendo com que todo o processo falhe intermitentemente.

Acabei de enfrentar esse problema fazendo helm delete . Isso causou um efeito muito ruim. A versão do Helm foi removida, mas todos os objetos K8s foram mantidos em execução no cluster. Portanto, tivemos que remover tudo manualmente. E como se tratava de uma operadora, essa ação exigiu um esforço significativo.

@andrewnazarov Forneça mais informações sobre o que você tentou excluir e o que aconteceu. Mensagens de erro seriam úteis, assim como a versão do Helm, a versão do Kube, etc.

@alexellis O que, exatamente, está causando o problema? Você está instalando um gráfico do Helm que instala um serviço de API e quer saber como esperar até que ele esteja disponível? A resposta curta é que você definitivamente precisará planejar uma estratégia para esperar, ou possivelmente dividi-la em dois gráficos. O Kubernetes não nos fornece muitas ferramentas para lidar com erros na API de descoberta, mas se uma descrição de serviço não for apoiada por um serviço, uma chamada de descoberta com certeza falhará _e não retornará o serviço_ no mapa que retorna.

Forneça mais informações sobre o que você tentou excluir e o que aconteceu. Mensagens de erro seriam úteis, assim como a versão do Helm, a versão do Kube, etc.

Certo.

Helm: 3.0.0
K8s: 1.14.8

helm delete prom -n monitoring terminou com o seguinte erro

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

Depois disso, a liberação do Helm desapareceu da lista de liberações do Helm e todos os objetos relacionados a esse operador do Prometheus tornaram-se órfãos.

Ok, entendo, pode ser um problema de versão. Irá atualizar o Helm para a versão 3.0.2 mais recente o mais rápido possível.

Sim, este é definitivamente um problema de incompatibilidade de versão. Este patch foi disponibilizado no 3.0.2. No futuro, certifique-se de testar com a versão de patch mais recente (ou, melhor ainda, no master). Obrigado!

Se você estiver enfrentando outros problemas, abra um novo tíquete.

kubectl get apiservice

Se um dos serviços "AVAILABLE = false", você pode tentar excluir os pods relacionados para reiniciá-los.
Resolveu meu problema com o serviço kube-system / metrics.

Olá @technosophos. Pode ser que algo esteja faltando, mas não vejo esse PR https://github.com/helm/helm/pull/6908/files sendo portado para 2.16.3, embora isso aconteça com o helm 2 também. Você está planejando transportar esta solução alternativa no leme 2 também?

Ele foi mesclado com dev-v2 alguns meses atrás. Você pode construir a partir desse branch e testá-lo se quiser.

Seria ótimo ver isso incorporado ao Helm 2 e ao provedor Terraform . Consigo recuperar esse erro sempre que um cluster é criado.

Você testou a filial dev-v2 ? Atualmente não temos nenhuma confirmação (além de nossos próprios testes) de que a solução ali funciona, embora seja em essência a mesma solução.

Ainda não, posso tentar esta semana. Como estou usando isso com o Terraform, posso construir / executar o branch dev-v2 e definir a variável de repositório do recurso helm_release como "local" para simular?

@bacongobbler Enfrentamos o mesmo problema com prometheus-adapter que expôs um serviço personalizado e se eu falhou no lançamento com um serviço personalizado e kubectl get apiservice qualquer desta lista estaria DISPONÍVEL = falso leme não é mais capaz de fazer nenhum novo liberar mesmo que não esteja relacionado ao serviço 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"

O Helm 2 com o provedor Terraform está quebrado devido a esse problema no momento e. Espero que você também possa fornecer uma correção para isso, parece que este é um caso de uso comum.

Posso confirmar que também estou tendo esse problema. Esperando por uma solução.

Solução:

As etapas que segui são:

1. kubectl get apiservices : Se o serviço do servidor métrico estiver inativo com o erro CrashLoopBackOff, tente seguir a etapa 2, caso contrário, tente reiniciar o serviço do servidor métrico usando kubectl delete apiservice/"service_name" . Para mim, foi v1beta1.metrics.k8s.io.

2. kubectl get pods -n kube-system e descobriu que pods como metrics-server, kubernetes-dashboard estão inativos por causa do pod coreDNS principal.

Para mim foi:

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

1. Use kubectl describe pod/"pod_name" para verificar o erro no pod coreDNS e se ele estiver inativo por causa de / etc / coredns / Corefile: 10 - Erro durante a análise: proxy de diretiva desconhecido, então precisamos usar forward em vez de proxy no yaml arquivo onde a configuração do coreDNS está lá. Porque o CoreDNS versão 1.5x usado pela imagem não suporta mais a palavra-chave proxy.

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