Helm: Die vollständige Liste der Server-APIs kann nicht abgerufen werden

Ich habe das gleiche Problem bei AKS, obwohl die Fehlermeldung lautet

Fehler: ApiVersions konnte nicht von Kubernetes abgerufen werden: Die vollständige Liste der Server-APIs konnte nicht abgerufen werden :metrics.k8s.io/v1beta1: Der Server kann die Anforderung derzeit nicht verarbeiten

meine Konfiguration:

• kubectl version:

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

• Steuerversion : alpine /

• 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

Ich glaube, in meinem Fall hat dieses Problem vor kurzem begonnen ... es scheint damit zu tun zu haben, dass Knative in meinem Fall installiert wurde (unter IBM Cloud IKS ist dies eine verwaltete Option). Ich habe knative deinstalliert und bin vorerst in Ordnung, aber hier könnte es ein Interop-Problem geben

@kalioz aus Interesse verwenden Sie Knative auf AWS? Es sieht eigentlich nicht so aus, da ich die Tekton-Objekte nicht sehen kann

Ich habe dieses Problem gerade selbst gesehen. In meinem Fall war es der Cert-Manager, der das Problem auslöste. Ich arbeite immer noch daran, wie ich es wieder so machen kann, wie es war.

@ planetf1 Ich verwende kein Knative (oder ich glaube nicht), aber das Problem besteht nur auf dem neuen Cluster, den ich für diesen Test bereitgestellt habe.
Die Unterschiede zwischen dem Arbeitscluster und dem Nichtarbeitscluster sind:

| | arbeiten | nicht arbeiten |
| --- | --- | --- |
| kube version | 1.13.5 | 1.14.6 |
| Azure AD-Authentifizierung | deaktiviert | aktiviert |
| RBAC | deaktiviert | aktiviert |

Ich habe also einige wichtige Änderungen.

Für mich ist das Problem, dass helm3 aufgrund des fehlenden Zugriffs auf einige APIs abstürzt, die nicht für das Diagramm verwendet werden, das ich bereitstellen möchte.

Ich verwende es auf k8 Cluster Version 1.13.9. Der gleiche Fehler tritt beim Bereitstellen eines stabilen Diagramms auf.

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

helm.go: 81: [Debug] kann die vollständige Liste der Server-APIs nicht abrufen :metrics.k8s.io/v1beta1: Der Server kann die Anforderung derzeit nicht verarbeiten.

Nach der Behebung des Problems aus dem Metrik-Pod (ich kann mich nicht erinnern, wie ich es gelöst habe, denke ich, dass es möglicherweise mit hostNetwork oder dem Neustart des zugehörigen Pods zu tun hat) funktioniert helm3 wie erwartet.
Es kann sich also um eine "Funktion" handeln, da der Cluster in gutem Zustand gehalten werden muss. Es ist jedoch erforderlich, dass bei jeder API-Unterbrechung jemand manuell in den Cluster wechselt (und somit möglicherweise verhindert wird, dass helm3 zum Bereitstellen von Pods verwendet wird, die aufgelistet werden können dazu).

Es ist wirklich sehr, sehr ärgerlich, wenn jemand mit Kubernetes anfängt. Ich arbeite an einer Lösung für Zertifikate mit acme, da ich nicht garantieren kann, dass der Zertifikatsmanager auch nach der Konfiguration nicht beschädigt wird.

Der wirklich nervige Teil ist, dass ich nicht einfach den Helm verwenden kann, um den Zertifizierungsmanager zu deinstallieren und dorthin zurückzukehren, wo ich war! Alles, was es einem dringend empfohlenen Dienst ermöglicht, ihn zu beschädigen und die Änderung nicht rückgängig zu machen, ist fehlerhaft.

Für jeden, der dies trifft, liegt es an API-Diensten, auf denen keine Backends mehr ausgeführt werden ...

In meinem Fall war es KEDA, aber es gibt eine Reihe verschiedener Dienste, die aggregierte API-Server installieren.

Etwas reparieren:

kubectl get apiservice

Suchen Sie nach denen, bei denen AVAILABLE False

Wenn Sie diese APIs nicht mehr benötigen, löschen Sie sie:

kubectl delete apiservce <service-name>

Dann sollte Helm richtig funktionieren. Ich denke, die Verbesserung der Helm-Fehlermeldung für diesen Fall kann sich lohnen ...

Vielen Dank für die Erklärung - gibt es eine Möglichkeit, wie Helm dies auch umgehen kann?

Wir denken schon, obwohl wir noch nachforschen. Mein erster Blick deutet darauf hin, dass dies nur mit unserer Verwendung der Discovery-API zusammenhängt, die für das Capabilities -Objekt beim Rendern von Vorlagen verwendet wird. Möglicherweise können wir diesen bestimmten Fehler abfangen und den Benutzer warnen, anstatt zu versagen.

Gleiches gilt jetzt für 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

Das ist ziemlich nervig. Warnung statt Versagen wäre in der Tat viel besser.
Irgendwelche Updates dazu bisher?

BEARBEITEN: Kann s / o bestätigen, dass 2.15 ebenfalls betroffen ist? Dann würde ich vorschlagen, die Etiketten dieses Tickets anzupassen.

@sjentzsch Ich 2.15.0 und k8s 1.16.0 .

Wenn dies auch 2.x betrifft, wird jeder, der "cert-manager" verwendet (möglicherweise nur eine Vorkonfiguration), eine schlechte Zeit haben.

__Hier haben wir zwei verschiedene Fälle mit dem gleichen Verhalten von der Steuerseite.
Sowohl die Versionen 2.15.1 als auch 3 beta sind betroffen .__

Wie von @technosophos erwähnt, verwendet der Helm die Discovery-API-Funktionalität und schlägt fehl, wenn eine der API-Antworten fehlschlägt. Https://github.com/helm/helm/blob/f1dc84773f9a34fe59a504fdb32428ce1d56a2e8/pkg/action/action.go#L105 -L118

1. admission.certmanager.k8s.io/v1beta1 cert-manager ist ein gutes Beispiel:

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

und für diesen Fall können Sie es leicht durch kubectl delete apiservice v1beta1.admission.certmanager.k8s.io beheben
wie @brendandburns beschrieben.

1. Ein weiterer Fehlerfall, bei dem das Ruder die Antwort von keinem API-Dienst abrufen kann
   Beispiel: "metrics.k8s.io/v1beta1: Der Server kann die Anforderung derzeit nicht verarbeiten "und dies geschieht von Fall zu Fall

Derzeit ist es am Leben und läuft, war aber während der Anfrage des Ruders versehentlich ausgefallen.

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

Ich bin sicher, dass das Ruder für solche Probleme robuster sein muss.
1) Vielleicht ist es eine gute Idee, den Fehler in eine Warnung umzuwandeln (ich weiß nicht, wie die Informationen vom API-Dienst während des Renderns der Vorlage verwendet werden).
2) Implementieren Sie Wiederholungsversuche für diese Art von Anforderungen

Wir haben ein ähnliches Problem mit 2.15.1 unter Kubernetes 1.15.5, aber NICHT mit Helm 2.14.3.

Das Problem ist schwebend: Einige Diagramme sind in Ordnung installiert, aber dann beginnen sie zu scheitern.
Unsere Botschaft lautet:

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 listet metrics.k8s.io/v1beta1 als verfügbar auf. Möglicherweise haben wir ein vorübergehendes Problem mit diesem Dienst, aber Helm 2.14.3 auf größtenteils identischen Clustern funktioniert zuverlässig.

Dieses Problem trat auf, als wir versuchten, ein Upgrade auf Helm 2.15.2 im CI-Cluster für Diagramme durchzuführen. Es ist also nicht nur ein Helm 3-Problem. Durch das Löschen des fehlenden API-Dienstes wurde das Problem behoben. Ich frage mich, ob Helm hier anmutiger sein könnte, zumal dies wahrscheinlich jederzeit wieder auftauchen könnte.

Bei der Installation des Stable / Metrics-Server-Diagramms auf einem in kubeadm installierten Cluster ist ein ähnliches Problem aufgetreten.

Wenn Sie versuchen, das Diagramm zu deinstallieren, schlägt die Deinstallation mit einem API-Server-Fehler fehl (da der Metrics-Server fubar ist), und es verbleiben eine Menge baumelnder Ressourcen, die Sie von Hand bereinigen müssen, da das Ruder die Version entfernt hat aus seiner Datenbank sowieso.

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

Begann dies kürzlich in frisch erstellten GKE-Clustern mit 2.15.1 (möglicherweise kürzlich über Snap aktualisiert). Wird auch als https://github.com/kubernetes/kubernetes/issues/72051#issuecomment -521157642 gemeldet. Scheint in der Lage zu sein, das Problem zu umgehen, indem Sie jedem Befehl helm install Folgendes voranstellen:

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

@jglick In Ihrem Fall geschieht dies nur, wenn der Cluster zum ersten Mal erstellt wird?

Das Problem liegt tief im Kubernetes Go Discovery Client. Ich experimentiere damit, nur eine Warnung auszudrucken. Dies könnte jedoch negative Folgen für Diagramme haben, die stark vom Capabilities-Objekt abhängen.

In Ihrem Fall geschieht dies nur, wenn der Cluster zum ersten Mal erstellt wird?

Ja. Ich habe ein Skript, das einen Cluster erstellt, Tiller installiert und Helm-Releases erstellt. Es scheint also eine Race-Bedingung bei der Cluster-Initialisierung zu sein.

@jglick Die Implementierung, die ich gestern durchgeführt habe, wird das Problem höchstwahrscheinlich für Sie vermeiden, es sei denn, Sie schreiben Diagramme, die direkt auf die betreffende API-Gruppe verweisen.

@technosophos danke für die Zusammenführung. Ich denke, es wird die Widerstandsfähigkeit des Ruders verbessern.

Haben wir einen Fix für 2.15 / 2.16?

Dies auch in 2.16 zu sehen. 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

Für 2.16 wurde kein Fix zur Verfügung gestellt. Wenn Sie das Update von Helm 3 übernehmen möchten, ist dies eine willkommene Änderung.

Für GKE-Nutzer hat Google Probleme mit Heapster und Metricserver. Dies ist der Grund für das Versagen des Ruders und erklärt, warum es manchmal funktioniert und nicht bei anderen.

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

Ich benutze nur Helm 3.0.0 Stable und lief in der Ausgabe:

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

Der Apiservice schien gesund zu sein, da die Verfügbarkeit in kubectl get apiservices | grep certmanager "wahr" war.

Nach dem "Neustart" mit kubectl delete apiservice v1beta1.admission.certmanager.k8s.io das Problem behoben.

Das Update wurde in den Hauptzweig eingefügt, aber nicht in 3.0.0. Der Patch wird in 3.1 sein.

Suchen Sie nach solchen, die VERFÜGBAR sind

Wenn Sie diese APIs nicht mehr benötigen, löschen Sie sie:

kubectl löschen 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 für Windows.

Ich vermute, es gab einen Tippfehler in der Anleitung. Sollte wohl sein
kubectl delete apiservice (fehlt i im Dienst)

Wir sind auch von inkonsistentem Verhalten beim Löschen betroffen. Beispielsweise

1. Wir führen die Installation eines absichtlich falsch konfigurierten Metrics-Servers durch
   1a. Ressourcen werden erstellt, aber der Metrics-Server-Pod landet in crashloopbackoff (erwartet)
2. Wir helfen, Metrics-Server zu löschen
   2a. Wir erhalten zurück "Fehler: Deinstallation mit 1 Fehler abgeschlossen: API-Versionen von Kubernetes konnten nicht abgerufen werden: API-Versionen von Kubernetes konnten nicht abgerufen werden: Die vollständige Liste der Server-APIs konnte nicht abgerufen werden :metrics.k8s.io/v1beta1: Der Server ist derzeit nicht in der Lage, die Anfrage zu bearbeiten "
   2b. Das Geheimnis der Helmfreigabe wurde entfernt
   2c. Alle Ressourcen im Diagramm sind noch im Cluster vorhanden
   2d. Manuelle Bereinigung ist erforderlich

Der einzige Teil der "Deinstallation", der abgeschlossen wurde, war das Entfernen des Release-Geheimnisses.

Die PR, die dies behoben hat, war hier: https://github.com/helm/helm/pull/6908 Siehe die zusätzliche Diskussion darüber, ob noch ein weiterer Fall übrig ist.

@hier können wir dieses zurückportieren ?

Wenn jemand verfügbar ist, um das Helm 2-Update zu testen, finden Sie es hier: # 7196

@bacongobbler gemäß Ihrem Kommentar hier https://github.com/helm/helm/issues/6361#issuecomment -554480815 Wissen Sie, wann v3.1 verfügbar sein wird? Ich habe gerade 3.0.1 installiert und stoße immer noch auf das Problem. Ich war überrascht, dass dieses Update es nicht in Version 3.0.1 geschafft hat, da es ein ziemlich weit verbreitetes Problem zu sein scheint. Gibt es eine Chance, dass es zu einer Version 3.0.x wird, wenn dies vor Version 3.1 sein wird?

Gleiche Frage wie @mcginne . Ich benutze den Master-Zweig schon seit einiger Zeit und warte darauf, dass dieses Update veröffentlicht wird. Aber ich würde gerne wieder eine Veröffentlichung machen. Dieser Fehler macht das Schreiben von Automatisierung mit helm ziemlich schwierig (es sei denn, Sie möchten nur Ihr Glück versuchen und Schlaf und Kellner überall hinstellen).

Auch nur wie ein 3.1alpha oder so was wäre schön :)

Schließen dieses Problems, da es auf master behoben ist

Noch ein Fall:

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

Es bezog sich auf https://github.com/linkerd/linkerd2/issues/3497 , als der Linkerd-Dienst einige interne Probleme hatte und nicht auf die API-Dienstanforderungen antworten konnte. Behoben durch Neustart der Pods.

@ kivagant-ba würde es Ihnen etwas ausmachen, eine neue Ausgabe für diese zu eröffnen? Es ist ein etwas anderer Fall, und wir müssen entscheiden, wie das "richtige" Verhalten auf Helms Seite aussehen soll. Ich denke, das aktuelle Update wird das oben Gesagte immer noch als schwerwiegenden Fehler betrachten.

Für jeden, der dies trifft, liegt es an API-Diensten, auf denen keine Backends mehr ausgeführt werden ...

In meinem Fall war es KEDA, aber es gibt eine Reihe verschiedener Dienste, die aggregierte API-Server installieren.

Etwas reparieren:

kubectl get apiservice

Suchen Sie nach denen, bei denen AVAILABLE False

Wenn Sie diese APIs nicht mehr benötigen, löschen Sie sie:

kubectl delete apiservice <service-name>

Dann sollte Helm richtig funktionieren. Ich denke, die Verbesserung der Helm-Fehlermeldung für diesen Fall kann sich lohnen ...

Nur eine kleine Korrektur in der Schreibweise des "Dienstes". korrigierte es.

Würde es Ihnen etwas ausmachen, eine neue Ausgabe für diese zu eröffnen?

Dies ist kein Problem für Benutzer, die eine neuere Version von Linkerd verwenden. Ich habe meinen Kommentar hier für diejenigen hinterlassen, die nach der Fehlerphrase suchen, weil sie ähnlich aussieht, aber die Grundursache anders ist.

Oh! Okay. Vielen Dank!

@technosophos was ist das kubectl get apiservice erfassen und dann blockieren, bis sich alle Dienste in einem Ready -Zustand befinden? Gibt es noch etwas, was wir stattdessen tun könnten?

Wir arbeiten an einem OSS-Tool, das eine Reihe von Helmdiagrammen installiert, um ein System zu booten. Dieses Problem scheint dazu zu führen, dass der gesamte Prozess zeitweise fehlschlägt.

Ich habe gerade dieses Problem mit helm delete konfrontiert. Es verursachte einen sehr schlechten Effekt. Die Helm-Version wurde entfernt, aber alle K8-Objekte wurden im Cluster weiter ausgeführt. Also mussten wir alles von Hand entfernen. Und da es sich um einen Bediener handelte, war für diese Aktion ein erheblicher Aufwand erforderlich.

@andrewnazarov Bitte geben Sie weitere Informationen darüber an, was Sie zu löschen versucht haben und was passiert ist. Fehlermeldungen wären hilfreich, ebenso wie die Helm-Version, die Kube-Version usw.

@alexellis Was genau verursacht ein Problem? Installieren Sie ein Helmdiagramm, das einen API-Dienst installiert, und fragen sich, wie Sie warten sollen, bis er verfügbar ist? Die kurze Antwort lautet, dass Sie auf jeden Fall eine Strategie entwickeln müssen, um zu warten, oder sie möglicherweise in zwei Diagramme aufteilen müssen. Kubernetes bietet uns nicht viele Tools, um Fehler in der Erkennungs-API zu beheben. Wenn eine Dienstbeschreibung jedoch nicht von einem Dienst unterstützt wird, schlägt ein Erkennungsaufruf definitiv fehl und gibt den Dienst in der zurückgegebenen Zuordnung nicht zurück.

Bitte geben Sie weitere Informationen darüber an, was Sie zu löschen versucht haben und was passiert ist. Fehlermeldungen wären hilfreich, ebenso wie die Helm-Version, die Kube-Version usw.

Sicher.

Helm: 3.0.0
K8s: 1.14.8

helm delete prom -n monitoring endete mit dem folgenden Fehler

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

Danach verschwand die Helmfreigabe aus der Liste der Helmfreigaben und alle Objekte, die sich auf diesen Prometheus-Operator beziehen, wurden verwaist.

Ok, ich verstehe, es könnte ein Versionsproblem sein. Aktualisiert Helm so schnell wie möglich auf die neueste Version 3.0.2.

Ja, dies ist definitiv ein Problem mit der Versionsinkongruenz. Dieser Patch wurde in 3.0.2 zur Verfügung gestellt. Bitte stellen Sie in Zukunft sicher, dass Sie mit der neuesten Patch-Version (oder noch besser mit dem Master) testen. Vielen Dank!

Wenn Sie weitere Probleme haben, öffnen Sie bitte ein neues Ticket.

kubectl get apiservice

Wenn einer der Dienste "AVAILABLE = false" ist, können Sie versuchen, die zugehörigen Pods zu löschen, um sie neu zu starten.
Es hat mein Problem mit dem Kube-System / Metrics-Service gelöst.

Hallo @technosophos. Vielleicht habe ich etwas verpasst, aber ich sehe nicht, dass diese PR https://github.com/helm/helm/pull/6908/files auf 2.16.3 portiert wird, obwohl dies auch bei Helm 2 der Fall ist. Planen Sie, diese Problemumgehung auch in Helm 2 zu portieren?

Es wurde vor einigen Monaten in dev-v2 verschmolzen. Sie können aus diesem Zweig erstellen und ihn testen, wenn Sie möchten.

Es wäre toll zu sehen, dass dies in Helm 2 und dem Terraform-Anbieter integriert ist . Ich kann diesen Fehler jedes Mal wiederholen, wenn ein Cluster erstellt wird.

Haben Sie den Zweig dev-v2 getestet? Wir haben derzeit keine Bestätigung (außer unseren eigenen Tests), dass die Lösung dort funktioniert, obwohl es sich im Wesentlichen um dieselbe Lösung handelt.

Ich habe es nicht, ich kann es diese Woche versuchen. Kann ich, da ich dies mit Terraform verwende, den Zweig dev-v2 erstellen / ausführen und die Repository-Variable der Ressource helm_release zum Simulieren auf "local" ?

@bacongobbler Wir hatten das gleiche Problem mit prometheus-adapter das den benutzerdefinierten Apiservice enthüllte. Wenn ich die Veröffentlichung mit dem benutzerdefinierten Apiservice und kubectl get apiservice nicht bestanden hätte, wäre jede dieser Listen VERFÜGBAR = Falscher Helm, der keinen neuen mehr erstellen kann Release, auch wenn es nicht mit benutzerdefiniertem Apiservice zusammenhängt:
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 mit dem Terraform-Anbieter ist aufgrund dieses Problems momentan defekt und. Ich hoffe, Sie können auch eine Lösung dafür bereitstellen. Es sieht so aus, als ob dies ein häufiger Anwendungsfall ist.

Kann bestätigen, dass ich auch dieses Problem habe. Ich hoffe auf eine Lösung.

Lösung:

Die Schritte, die ich befolgt habe, sind:

1. kubectl get apiservices : Wenn der Metrik-Server-Dienst mit dem Fehler CrashLoopBackOff nicht verfügbar ist, versuchen Sie, Schritt 2 auszuführen. Andernfalls versuchen Sie einfach, den Metrik-Server-Dienst mit kubectl delete apiservice/"service_name" neu zu starten. Für mich war es v1beta1.metrics.k8s.io.

2. kubectl get pods -n kube-system und fand heraus, dass Pods wie Metrics-Server, Kubernetes-Dashboard aufgrund des Haupt-CoreDNS-Pods nicht verfügbar sind.

Für mich war es:

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

1. Verwenden Sie kubectl describe pod/"pod_name" , um den Fehler im coreDNS-Pod zu überprüfen. Wenn er aufgrund von / etc / coredns / Corefile: 10 nicht verfügbar ist - Fehler beim Parsen: Unbekannter Direktiven-Proxy, müssen wir im yaml Forward anstelle von Proxy verwenden Datei, in der sich die coreDNS-Konfiguration befindet. Da die vom Image verwendete CoreDNS-Version 1.5x das Proxy-Schlüsselwort nicht mehr unterstützt.

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