Helm: impossible de récupérer la liste complète des API de serveur

J'ai le même problème sur AKS, bien que le message d'erreur soit

Erreur: impossible d'obtenir des apiVersions de Kubernetes: impossible de récupérer la liste complète des API du serveur: metrics.k8s.io/v1beta1: le serveur est actuellement incapable de gérer la demande

ma config:

• version kubectl:

Version du client: version.Info {Major: "1", Minor: "15", GitVersion: "v1.15.2", GitCommit: "f6278300bebbb750328ac16ee6dd3aa7d3549568", GitTreeState: "clean", BuildDate: "2019-08-05T09: 23: 26Z ", GoVersion:" go1.12.5 ", Compilateur:" gc ", Plate-forme:" windows / amd64 "}
Version du serveur: version.Info {Major: "1", Minor: "14", GitVersion: "v1.14.6", GitCommit: "96fac5cd13a5dc064f7d9f4f23030a6aeface6cc", GitTreeState: "clean", BuildDate: "2019-08-19T11: 05: 16Z ", GoVersion:" go1.12.9 ", Compilateur:" gc ", Plate-forme:" linux / amd64 "}

• version de la barre: alpine / barre: 3.0.0-beta.2 (docker)

• ressources api 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

Je crois que dans mon cas, ce problème a commencé récemment ... il semble être lié à l'installation de knative dans mon cas (sur IBM Cloud IKS, c'est une option gérée). J'ai désinstallé knative et je vais bien pour le moment, mais il pourrait y avoir un problème d'interopérabilité ici

@kalioz par intérêt utilisez-vous Knative sur AWS? Ça n'a pas l'air vraiment puisque je ne peux pas voir les objets tekton

Je viens de voir ce problème moi-même. Dans mon cas, c'est cert-manager qui a déclenché le problème. Je travaille toujours sur la façon de le ramener à ce qu'il était.

@ planetf1 Je n'utilise pas knative (ou je pense que non), mais le problème n'existe que sur le nouveau cluster que j'ai déployé pour ce test.
Les différences entre le cluster de travail et celui qui ne fonctionne pas sont:

| | travailler | ne pas travailler |
| --- | --- | --- |
| version kube | 1.13.5 | 1.14.6 |
| authentification Azure AD | désactivé | activé |
| RBAC | désactivé | activé |

J'ai donc quelques changements majeurs.

Pour moi, le problème est que helm3 plante à cause du manque d'accès à certaines API, qui ne sont pas utilisées pour le graphique que j'essaie de déployer.

Je l'utilise sur la version 1.13.9 du cluster k8, la même erreur se produit pour le déploiement de tout graphique stable.

version de barre
version.BuildInfo {Version: "v3.0.0-beta.3", GitCommit: "5cb923eecbe80d1ad76399aee234717c11931d9a", GitTreeState: "nettoyer", GoVersion: "go1.12.9"}

helm.go: 81: [debug] ne peut pas récupérer la liste complète des API du serveur: metrics.k8s.io/v1beta1: le serveur est actuellement incapable de traiter la requête.

Après avoir résolu le problème à partir du pod de métriques (je ne me souviens plus comment je l'ai résolu, je pense que cela pourrait avoir à voir avec hostNetwork ou simplement redémarrer le pod associé) fonctionne comme prévu.
Cela peut donc être une `` fonctionnalité '' car elle oblige à maintenir le cluster en bonne santé, mais cela nécessitera que quelqu'un se rende manuellement dans le cluster à chaque fois qu'une api s'arrête (et peut donc empêcher d'utiliser helm3 pour déployer des pods pouvant être répertoriés. sur ce).

C'est vraiment très ennuyeux en tant que débutant avec Kubernetes. Je suis en train de lancer une solution pour les certificats utilisant acme, car je ne peux pas garantir que le gestionnaire de certificats ne sera toujours pas cassé même après l'avoir configuré.

La partie la plus ennuyeuse est que je ne peux pas simplement utiliser Helm pour désinstaller le gestionnaire de certificats et revenir là où j'étais! Tout ce qui permet à un service fortement recommandé de le casser et n'annule pas le changement est cassé.

Pour tous ceux qui rencontrent ce problème, cela est causé par des services api qui n'ont plus de backends en cours d'exécution ...

Dans mon cas, c'était KEDA, mais il existe un certain nombre de services différents qui installent des serveurs API agrégés.

Réparer:

kubectl get apiservice

Recherchez ceux dont AVAILABLE est False

Si vous n'avez plus besoin de ces API, supprimez-les:

kubectl delete apiservce <service-name>

Ensuite, Helm devrait fonctionner correctement. Je pense que l'amélioration du message d'erreur Helm pour ce cas peut valoir la peine ...

Merci pour l'explication - y a-t-il un moyen pour Helm de coder aussi autour de cela?

Nous pensons que oui, même si nous enquêtons toujours. Mon premier regard suggère que cela est simplement lié à notre utilisation de l'API Discovery, qui est utilisée pour l'objet Capabilities dans le rendu du modèle. Nous pourrions être en mesure de piéger cette erreur particulière et d'avertir l'utilisateur au lieu d'échouer.

Idem avec 2.15.0 maintenant:

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

C'est assez ennuyeux. Un avertissement au lieu d'échouer serait en effet beaucoup mieux.
Des mises à jour à ce sujet jusqu'à présent?

EDIT: peut-il confirmer que 2.15 également affecté? Ensuite, je suggérerais d'ajuster les étiquettes de ce billet.

@sjentzsch Je vois également la même chose en utilisant Helm 2.15.0 et k8s 1.16.0 .

Si cela affecte également 2.x, alors tout le monde utilisant "cert-manager" (peut-être seulement la pré-configuration) va passer un mauvais moment.

__ Ici, nous avons deux cas différents avec le même comportement du côté de la barre.
Les versions 2.15.1 et 3 beta sont affectées .__

Comme @technosophos l'a mentionné, la barre utilise la fonctionnalité de l'API de découverte et échoue si l'une des réponses de l'API échoue https://github.com/helm/helm/blob/f1dc84773f9a34fe59a504fdb32428ce1d56a2e8/pkg/action/action.go#L105 -L118

1. Le admission.certmanager.k8s.io/v1beta1 cert-manager est un bon exemple:

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

et pour ce cas, vous pouvez facilement le réparer par kubectl delete apiservice v1beta1.admission.certmanager.k8s.io
comme @brendandburns l'a décrit.

1. Un autre cas d'échec lorsque helm ne peut pas récupérer la réponse de l'un des services api
   par exemple "metrics.k8s.io/v1beta1: le serveur est actuellement incapable de traiter la demande" et cela se produit au cas par cas

Actuellement, il est vivant et en marche, mais il est tombé accidentellement lors de la demande de la barre.

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

Je suis sûr que la barre doit être plus robuste pour ce type de problèmes,
1) C'est peut-être une bonne idée de convertir l'erreur en avertissement (je ne sais pas comment les informations du service api sont utilisées lors du rendu du modèle)
2) Mettre en œuvre des tentatives pour ce type de demandes

Nous avons un problème similaire avec 2.15.1 sur Kubernetes 1.15.5, mais PAS avec helm 2.14.3.

Le problème est flottant: certains graphiques sont installés correctement, mais ils commencent à échouer.
Notre message est:

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 répertorie metrics.k8s.io/v1beta1 comme disponible. Peut-être avons-nous un problème transitoire avec ce service, mais helm 2.14.3 sur un cluster presque identique fonctionne de manière fiable.

Nous avons rencontré ce problème en essayant de mettre à niveau vers Helm 2.15.2 sur le cluster CI de graphiques. Donc, ce n'est pas seulement un problème Helm 3. La suppression du service API manquant l'a corrigé. Je me demande si Helm pourrait être plus gracieux ici, d'autant plus que cela pourrait probablement réapparaître à tout moment.

Problème similaire lors de l'installation du graphique stable / metrics-server sur un cluster installé par kubeadm.

Lorsque vous essayez de désinstaller le graphique, la désinstallation échoue avec une erreur de serveur api (car le serveur de métriques est fubar), et cela laisse une charge de ressources en suspens que vous devez nettoyer à la main - puisque helm a supprimé la version de sa base de données de toute façon.

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

J'ai commencé à frapper cela récemment dans des clusters GKE récemment créés, à l'aide de la version 2.15.1 (peut-être récemment mis à niveau via Snap) Également signalé sous https://github.com/kubernetes/kubernetes/issues/72051#issuecomment -521157642. Semble pouvoir contourner en précédant chaque commande helm install avec:

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

@jglick Dans votre cas, cela se produit-il uniquement lorsque le cluster est créé pour la première fois?

Le problème est profondément ancré dans le client de découverte Kubernetes Go. J'expérimente simplement en imprimant un avertissement. Cependant, cela pourrait avoir des conséquences négatives pour les graphiques qui reposent fortement sur l'objet Capabilities.

Dans votre cas, cela se produit-il uniquement lorsque le cluster est créé pour la première fois?

Oui. J'ai un script qui crée un cluster, installe Tiller et crée des versions de Helm. Cela semble donc être une condition de concurrence dans l'initialisation du cluster.

@jglick l'implémentation que j'ai faite hier vous évitera très probablement le problème, à moins que vous

@technosophos merci pour cette fusion. Je pense que cela améliorera la résilience de la barre.

Avons-nous un correctif pour 2.15 / 2.16?

Voir cela également dans la version 2.16. GKE Master version 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

aucun correctif n'a été mis à disposition pour la version 2.16. Si vous avez envie de porter le correctif depuis Helm 3, ce serait un changement bienvenu.

Pour les utilisateurs de GKE, Google rencontre des problèmes avec le segment de mémoire et le serveur de métrique. C'est ce qui cause les pannes de barre et explique pourquoi cela fonctionne parfois et pas d'autres.

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

J'utilise juste helm 3.0.0 stable et j'ai couru dans le problème:

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

L'apiservice semblait être sain car la disponibilité montrait "vrai" dans kubectl get apiservices | grep certmanager .

Après "redémarrage" avec kubectl delete apiservice v1beta1.admission.certmanager.k8s.io le problème a disparu.

le correctif a été fusionné dans la branche principale, mais il n'a pas été fusionné dans la version 3.0.0. Le patch sera en 3.1.

Recherchez ceux dont DISPONIBLE est faux

Si vous n'avez plus besoin de ces API, supprimez-les:

kubectl supprimer 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 pour Windows.

Je suppose qu'il y avait une faute de frappe dans les instructions. Devrait probablement être
kubectl delete apiservice (i manquant en service)

Nous sommes également frappés par un comportement incohérent lors de la suppression. Par example

1. Nous pilotons l'installation d'un serveur de métriques mal configuré délibérément
   1a. les ressources sont créées mais le pod de serveur de métriques se termine par crashloopbackoff (attendu)
2. Nous gérons la suppression du serveur de métriques
   2a. Nous récupérons "Erreur: désinstallation terminée avec 1 erreur (s): impossible d'obtenir des apiVersions de Kubernetes: impossible d'obtenir des apiVersions de Kubernetes: impossible de récupérer la liste complète des API du serveur: metrics.k8s.io/v1beta1: le serveur est actuellement incapable de traiter la demande "
   2b. Le secret de libération du casque a été supprimé
   2c. Toutes les ressources du graphique sont toujours présentes dans le cluster
   2d. Un nettoyage manuel est nécessaire

La seule partie de la «désinstallation» qui a été terminée a été de supprimer le secret de publication.

Le PR qui a corrigé ce problème était ici: https://github.com/helm/helm/pull/6908 Voir la discussion supplémentaire sur la question de savoir s'il reste encore un cas supplémentaire.

@here pouvons-nous rétroporter ce correctif vers la v2?

Si quelqu'un est disponible pour tester le correctif Helm 2, c'est ici: # 7196

@bacongobbler selon votre commentaire ici https://github.com/helm/helm/issues/6361#issuecomment -554480815 savez-vous quand la v3.1 sera disponible? Je viens d'installer 3.0.1 et je rencontre toujours le problème - j'ai été surpris que ce correctif n'ait pas été intégré à la v3.0.1 car il semble être un problème assez répandu. Y a-t-il une chance que cela devienne une version v3.0.x si ce sera avant la v3.1?

Même question que @mcginne . J'utilise la branche master depuis un peu maintenant en attendant que ce correctif entre dans une version. Mais j'aimerais revenir à une sortie. Ce bogue rend l'écriture d'automatisation avec helm assez difficile (à moins que vous ne vouliez simplement tenter votre chance et mettre des dormeurs et des serveurs partout).

Même juste comme un 3.1alpha ou quelque chose serait bien :)

Clôture de ce problème, car il est résolu le master

Encore un cas:

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

Il était lié à https://github.com/linkerd/linkerd2/issues/3497 , lorsque le service Linkerd avait des problèmes internes et ne pouvait pas répondre aux demandes de service de l'API. Corrigé en redémarrant ses pods.

@ kivagant-ba cela vous dérangerait-il d'ouvrir un nouveau numéro pour celui-là? C'est un cas légèrement différent, et nous devrons décider quel devrait être le comportement "correct" du côté de Helm. Je pense que le correctif actuel considérera toujours ce qui précède comme une erreur fatale.

Pour tous ceux qui rencontrent ce problème, cela est causé par des services api qui n'ont plus de backends en cours d'exécution ...

Dans mon cas, c'était KEDA, mais il existe un certain nombre de services différents qui installent des serveurs API agrégés.

Réparer:

kubectl get apiservice

Recherchez ceux dont AVAILABLE est False

Si vous n'avez plus besoin de ces API, supprimez-les:

kubectl delete apiservice <service-name>

Ensuite, Helm devrait fonctionner correctement. Je pense que l'amélioration du message d'erreur Helm pour ce cas peut valoir la peine ...

Juste une petite correction orthographique du "service". corrigé.

cela vous dérangerait-il d'ouvrir un nouveau numéro pour celui-là?

Ce n'est pas un problème pour les personnes qui utilisent une version plus récente de Linkerd. J'ai laissé mon commentaire ici pour ceux qui chercheront la phrase d'erreur car elle semble similaire mais la cause première est différente.

Oh! D'accord. Merci!

@technosophos quelle est la solution à cela? Devrions-nous grep kubectl get apiservice puis bloquer jusqu'à ce que tous les services soient dans un état Ready ? Y a-t-il autre chose que nous pourrions faire à la place?

Nous travaillons sur un outil OSS qui installe un certain nombre de graphiques de barre pour amorcer un système et ce problème semble provoquer l'échec intermittent de l'ensemble du processus.

Je viens de faire face à ce problème en faisant helm delete . Cela a causé un très mauvais effet. La version Helm a été supprimée, mais tous les objets K8 ont continué à s'exécuter dans le cluster. Nous avons donc dû tout retirer à la main. Et comme il s'agissait d'un opérateur, cette action a nécessité un effort important.

@andrewnazarov Veuillez fournir plus d'informations sur ce que vous avez tenté de supprimer et ce qui s'est passé. Les messages d'erreur seraient utiles, tout comme la version Helm, la version Kube, etc.

@alexellis Qu'est-ce qui cause exactement un problème? Installez-vous un graphique Helm qui installe un service API et vous vous demandez comment attendre qu'il soit disponible? La réponse courte est que vous devrez certainement concevoir une stratégie pour attendre, ou éventuellement la diviser en deux graphiques. Kubernetes ne nous donne pas beaucoup d'outils pour être en mesure de traiter les erreurs sur l'API de découverte, mais si une description de service n'est pas soutenue par un service, un appel de découverte échouera certainement _et ne retournera pas le service_ dans la carte qu'il renvoie.

Veuillez fournir plus d'informations sur ce que vous avez tenté de supprimer et ce qui s'est passé. Les messages d'erreur seraient utiles, tout comme la version Helm, la version Kube, etc.

Sûr.

Heaume: 3.0.0
K8s: 1,14,8

helm delete prom -n monitoring s'est terminé par l'erreur suivante

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

Après cela, la version de Helm a disparu de la liste des versions de Helm et tous les objets liés à cet opérateur Prometheus sont devenus orphelins.

Ok, je vois, c'est peut-être un problème de version. Mettra à jour Helm vers la version 3.0.2 la plus récente dès que possible.

Oui, il s'agit certainement d'un problème de non-concordance de version. Ce correctif a été rendu disponible dans la version 3.0.2. À l'avenir, assurez-vous de tester avec la dernière version du correctif (ou, mieux encore, sur master). Merci!

Si vous rencontrez d'autres problèmes, veuillez ouvrir un nouveau ticket.

kubectl get apiservice

Si l'un des services "AVAILABLE = false", vous pouvez essayer de supprimer les pods associés pour les redémarrer.
Cela a résolu mon problème avec le service kube-system / metrics.

Salut @technosophos. Peut-être que quelque chose me manque, mais je ne vois pas ce PR https://github.com/helm/helm/pull/6908/files porté vers la version 2.16.3, bien que cela se produise également avec helm 2. Envisagez-vous également de porter cette solution de contournement dans helm 2?

Il a fusionné avec dev-v2 a quelques mois. Vous pouvez construire à partir de cette branche et la tester si vous le souhaitez.

Ce serait formidable de voir cela intégré dans Helm 2 et le fournisseur Terraform . Je suis en mesure de repo cette erreur chaque fois qu'un cluster est créé.

Avez-vous testé la branche dev-v2 ? Nous n'avons actuellement aucune confirmation (autre que nos propres tests) que la solution fonctionne, bien qu'il s'agisse essentiellement de la même solution.

Je ne l'ai pas fait, je peux essayer cette semaine. Puisque j'utilise cela avec Terraform, puis-je créer / exécuter la branche dev-v2 et définir la variable de référentiel de la ressource helm_release sur "local" pour simuler?

@bacongobbler Nous avons rencontré le même problème avec prometheus-adapter qui exposait un apiservice personnalisé et si j'échouais à la publication avec un apiservice personnalisé et kubectl get apiservice n'importe lequel de cette liste serait DISPONIBLE = le faux helm ne serait plus en mesure de créer un nouveau release même s'il n'est pas lié à un service personnalisé:
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 avec le fournisseur Terraform est interrompu à cause de ce problème pour le moment et. J'espère que vous pouvez également fournir un correctif, il semble que ce soit un cas d'utilisation courant.

Je peux également confirmer que je rencontre ce problème. En espérant une solution.

Solution:

Les étapes que j'ai suivies sont:

1. kubectl get apiservices : Si le service de serveur de métrique est en panne avec l'erreur CrashLoopBackOff, essayez de suivre l'étape 2, sinon essayez simplement de redémarrer le service de serveur de métrique en utilisant kubectl delete apiservice/"service_name" . Pour moi, c'était v1beta1.metrics.k8s.io.

2. kubectl get pods -n kube-system et a découvert que des pods tels que metrics-server, kubernetes-dashboard sont en panne car le pod principal coreDNS était en panne.

Pour moi c'était:

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

1. Utilisez kubectl describe pod/"pod_name" pour vérifier l'erreur dans le pod coreDNS et si elle est en panne à cause de / etc / coredns / Corefile: 10 - Erreur lors de l'analyse: proxy de directive inconnu, alors nous devons utiliser forward au lieu de proxy dans le yaml fichier où se trouve la configuration coreDNS. Parce que la version 1.5x de CoreDNS utilisée par l'image ne prend plus en charge le mot-clé proxy.

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