Helm: सर्वर API की पूरी सूची पुनर्प्राप्त करने में असमर्थ

मुझे AKS पर एक ही मुद्दा है, हालांकि त्रुटि संदेश है

त्रुटि: कुबेरनेट्स से एपीवीर्स नहीं मिल सका: सर्वर एपीआई की पूरी सूची को पुनर्प्राप्त करने में असमर्थ: metrics.k8s.io/v1beta1: सर्वर वर्तमान में अनुरोध को संभालने में असमर्थ है

मेरा विन्यास:

• kubectl संस्करण:

क्लाइंट संस्करण: version.Info {मेजर: "1", माइनर: "15", GitVersion: "v1.15.2", GitCommit: "f6278300bebb750328ac16ee6a7d749568", GitTreeState: "Clean", BuildDate: "2019-05-05" 26Z ", GoVersion:" go1.12.5 ", कंपाइलर:" gc ", प्लेटफ़ॉर्म:" विंडोज़ / amp64 "}
सर्वर संस्करण: version.Info {मेजर: "1", माइनर: "14", GitVersion: "v1.14.6", GitCommit: "96fac5cd13a5dc064f7d9d4f23030a6aeface6cc", GitTreeState: "Clean", BuildDate: Builde: 16Z ", GoVersion:" go1.12.9 ", कंपाइलर:" gc ", प्लेटफ़ॉर्म:" linux / am6464 "}

• पतवार संस्करण: अल्पाइन / पतवार: ३.०.०-बीटा २ (

• कुबेटेल आपी-संसाधन
  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

मेरा मानना ​​है कि मेरे मामले में यह मुद्दा हाल ही में शुरू हुआ ... यह मेरे मामले में स्थापित होने के संबंध में लगता है (आईबीएम क्लाउड आईकेएस पर यह एक प्रबंधित विकल्प है)। मैंने चाकू की स्थापना रद्द कर दी है और अभी के लिए ठीक हूं, लेकिन यहां एक इंटरोप मुद्दा हो सकता है

@kalioz ब्याज से बाहर आप AWS पर चाकू का उपयोग कर रहे हैं? यह वास्तव में नहीं दिखता है क्योंकि मैं टेक्टन ऑब्जेक्ट नहीं देख सकता हूं

मैंने खुद इस मुद्दे को देखा है। मेरे मामले में यह प्रमाणित-प्रबंधक था जिसने समस्या को ट्रिगर किया। फिर भी इस पर काम किया जा रहा है कि इसे वापस कैसे लाया जाए।

@ planetf1 मैं knative (या मुझे लगता है कि मैं नहीं) का उपयोग नहीं कर रहा हूँ, लेकिन समस्या केवल इस परीक्षण के लिए तैनात नए क्लस्टर पर मौजूद है।
काम करने वाले क्लस्टर और न काम करने वाले के बीच अंतर हैं:

| | काम करना | काम नहीं करना |
| --- | --- | --- |
| क्यूब संस्करण | 1.13.5 | 1.14.6 |
| azure AD प्रमाणीकरण | अक्षम | सक्षम |
| RBAC | विकलांग | सक्षम |

इसलिए मेरे कुछ बड़े बदलाव हैं।

मेरे लिए समस्या यह है कि हेल्म 3 दुर्घटना कुछ एपीसियों की पहुंच की कमी के कारण है, जो चार्ट के लिए उपयोग नहीं किए जाते हैं, मैं तैनात करने की कोशिश कर रहा हूं।

मैं इसे k8 क्लस्टर संस्करण 1.13.9 पर उपयोग कर रहा हूं, वही त्रुटि किसी भी स्थिर चार्ट को तैनात करने के लिए आ रही है।

पतवार संस्करण
version.BuildInfo {संस्करण: "v3.0.0-beta.3", GitCommit: "5cb923eecbe80d1ad76399aee234717c11931d9a", GitTreeState: "क्लीन", GoVersion: "go1.12.9" "}

helm.go: 81: [debug] सर्वर API की पूरी सूची को पुनः प्राप्त करने में असमर्थ: metrics.k8s.io/v1beta1: सर्वर वर्तमान में अनुरोध को संभालने में असमर्थ है।

मेट्रिक्स पॉड से समस्या को हल करने के बाद (यह याद नहीं कर सकता कि मैंने इसे कैसे हल किया, मुझे लगता है कि इसे hostNetwork के साथ करना पड़ सकता है या बस संबंधित पॉड को पुनरारंभ करना पड़ सकता है) helm3 फ़ंक्शन के रूप में अपेक्षित।
इसलिए यह एक 'विशेषता' हो सकती है क्योंकि यह क्लस्टर को अच्छे स्वास्थ्य को बनाए रखने के लिए मजबूर करती है, लेकिन इसे हर बार किसी एपीआई ब्रेक (और इस प्रकार सूचीबद्ध करने में सक्षम पॉड्स को तैनात करने में हेल्म 3 का उपयोग करने से रोका जा सकता है) इस पर)।

यह वास्तव में, कुबेरनेट्स के साथ शुरू होने वाले किसी व्यक्ति के रूप में वास्तव में कष्टप्रद है। मैं acme का उपयोग करते हुए प्रमाण पत्र के लिए एक समाधान रोल कर रहा हूं, क्योंकि मैं यह गारंटी नहीं दे सकता कि प्रमाणित प्रबंधक इसे कॉन्फ़िगर करने के बाद भी टूट नहीं जाएगा।

वास्तव में कष्टप्रद हिस्सा यह है कि मैं प्रमाणित प्रबंधक की स्थापना रद्द करने और जहां मैं था वहां वापस जाने के लिए हेल्म का उपयोग नहीं कर सकता! कुछ भी जो इसे तोड़ने के लिए दृढ़ता से अनुशंसित सेवा की अनुमति देता है, और जो परिवर्तन नहीं हुआ है उसे पूर्ववत नहीं करेगा।

जो कोई भी इसे हिट करता है, वह एपीआई-सेवाओं के कारण होता है, जिनके पास अब बैकएंड नहीं है ...

मेरे मामले में यह केडीए था, लेकिन कई अलग-अलग सेवाएं हैं जो कुल एपीआई सर्वर स्थापित करती हैं।

ठीक करना:

kubectl get apiservice

लोगों को देखो AVAILABLE False

यदि आपको उन API की आवश्यकता नहीं है, तो उन्हें हटा दें:

kubectl delete apiservce <service-name>

फिर हेल्म को ठीक से काम करना चाहिए। मुझे लगता है कि इस मामले के लिए हेल्म त्रुटि संदेश में सुधार करना सार्थक हो सकता है ...

स्पष्टीकरण के लिए धन्यवाद - क्या कोई ऐसा तरीका है जिससे हेल्म इसके आसपास भी कोड कर सके?

हम ऐसा सोचते हैं, हालांकि हम अभी भी जांच कर रहे हैं। मेरा पहला लुक बताता है कि यह सिर्फ डिस्कवरी एपीआई के हमारे उपयोग से संबंधित है, जिसका उपयोग टेम्पलेट रेंडरिंग में Capabilities ऑब्जेक्ट के लिए किया जाता है। हम इस विशेष त्रुटि को फंसाने और उपयोगकर्ता को विफल करने के बजाय चेतावनी दे सकते हैं।

2.15.0 अब:

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

यह बहुत कष्टप्रद है। असफल होने के बजाय चेतावनी वास्तव में बहुत बेहतर होगी।
इस पर अभी तक कोई अपडेट?

संपादित करें: s / o पुष्टि कर सकते हैं 2.15 भी प्रभावित हो रहे हैं? फिर मैं इस टिकट के लेबल को समायोजित करने का सुझाव दूंगा।

@sjentzsch मैं भी Helm 2.15.0 और k8s 1.16.0 का उपयोग करके देख रहा हूँ।

यदि यह 2.x को भी प्रभावित करता है, तो "सर्टिफिकेट-मैनेजर" (संभवतः केवल पूर्व-विन्यास) का उपयोग करने वाले सभी लोगों का बुरा समय चल रहा है।

__ हमारे पास हेल्म की ओर से एक ही व्यवहार के साथ दो अलग-अलग मामले हैं।
दोनों 2.15.1 और 3 beta संस्करण प्रभावित हैं। ----

जैसा कि @technosophos ने उल्लेख किया है कि हेल्म डिस्कवरी एपीआई कार्यक्षमता का उपयोग करता है और यदि कोई भी एपीआई प्रतिक्रिया विफल हो जाती है तो https://github.com/helm/helm/blob/f1dc84773f9a34fe59a504fdb328281.156562/8/pkg/action/go.go#L105 -L118118 पर विफल रहता है।

1. प्रमाणित-प्रबंधक का admission.certmanager.k8s.io/v1beta1 एक अच्छा उदाहरण है:

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

और इस मामले के लिए आप इसे kubectl delete apiservice v1beta1.admission.certmanager.k8s.io आसानी से ठीक कर सकते हैं
जैसा कि @brendandburns में वर्णित है।

1. विफलता का एक और मामला जब पतवार किसी भी एप सेवा से प्रतिक्रिया प्राप्त नहीं कर सकता है
   उदाहरण के लिए "metrics.k8s.io/v1beta1: सर्वर वर्तमान में अनुरोध को संभालने में असमर्थ है" और यह मामले के मामले में होता है

वर्तमान में, यह जीवित है और चल रहा है लेकिन हेलमेट के अनुरोध के दौरान गलती से नीचे आ गया था।

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

मुझे यकीन है कि इस तरह के मुद्दों के लिए पतवार को अधिक मजबूत होना चाहिए,
1) हो सकता है कि त्रुटि को चेतावनी में परिवर्तित करना एक अच्छा विचार है (मुझे नहीं पता कि टेम्प्लेट रेंडरिंग के दौरान एपीआई सेवा की जानकारी कैसे उपयोग होती है)
2) इस तरह के अनुरोधों के लिए रिटायर लागू करें

हमारे पास Kubernetes 1.15.5 पर 2.15.1 के साथ ऐसा ही मुद्दा है, लेकिन 2.14.3 पतवार के साथ नहीं।

समस्या फ़्लोटिंग है: कुछ चार्ट ठीक हैं, लेकिन फिर वे विफल होने लगते हैं।
हमारा संदेश है:

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

kubectl get apiservice सूचियाँ metrics.k8s.io/v1beta1 उपलब्ध के रूप में। हो सकता है कि हमारे पास इस सेवा के साथ क्षणिक समस्या है, लेकिन ज्यादातर समान क्लस्टर पर हेल्म 2.14.3 मज़बूती से काम करता है।

हमने इस मुद्दे को हिट किया जब चार्ट CI क्लस्टर पर Helm 2.15.2 में अपग्रेड करने का प्रयास किया गया। तो, यह केवल एक हेल 3 मुद्दा नहीं है। अनुपलब्ध API सेवा को हटाकर इसे ठीक कर दिया गया। मुझे आश्चर्य है कि यदि हेल्म यहाँ अधिक सुंदर हो सकता है, खासकर जब से यह शायद किसी भी समय फिर से पॉप अप कर सकता है।

Kubeadm स्थापित क्लस्टर पर स्थिर / मैट्रिक्स-सर्वर चार्ट स्थापित करने में इसी तरह की समस्या को मारो।

जब आप चार्ट को अनइंस्टॉल करने का प्रयास करते हैं, तो एक सर्वर-सर्वर त्रुटि (क्योंकि मेट्रिक्स सर्वर फ़्यूबर है) के साथ अनइंस्टॉल विफल हो जाता है, और जो झूलने वाले संसाधनों का भार छोड़ देता है, जिसे आपको हाथ से साफ करना पड़ता है - चूंकि हेल्म ने रिलीज को हटा दिया है वैसे भी इसके डेटाबेस से।

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

2.15.1 (संभवतः स्नैप के माध्यम से हाल ही में अपग्रेड हो सकता है) का उपयोग करके हाल ही में नए सिरे से बनाए गए जीकेई क्लस्टर में इसे मारना शुरू कर दिया। Https://github.com/kubernetes/kubernetes/issues/72051#issuecomment -521157642 के रूप में भी रिपोर्ट किया गया। हर helm install कमांड के साथ पहले से काम करने में सक्षम होने का प्रयास करें:

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

@jglick आपके मामले में यह केवल तभी हो रहा है जब क्लस्टर पहली बार बनाया गया है?

कुबेरनेट्स गो डिस्कवरी क्लाइंट में समस्या गहरी है। मैं सिर्फ एक चेतावनी छापने के साथ प्रयोग कर रहा हूं। हालाँकि, चार्ट के लिए नकारात्मक परिणाम हो सकते हैं जो क्षमता ऑब्जेक्ट पर बहुत अधिक निर्भर करते हैं।

आपके मामले में यह केवल तब हो रहा है जब क्लस्टर पहली बार बनाया गया है?

हाँ। मेरे पास एक स्क्रिप्ट है जो एक क्लस्टर बनाता है, टिलर स्थापित करता है, और हेल्म रिलीज बनाता है। तो यह क्लस्टर आरंभीकरण में एक दौड़ की स्थिति की तरह लगता है।

@ मैंने कल जो क्रियान्वयन किया था, उस पर

उस विलय के लिए @technosophos धन्यवाद। मुझे लगता है कि यह पतवार की लचीलापन में सुधार करेगा।

क्या हमारे पास 2.15 / 2.16 के लिए फिक्स है?

२.१६ में भी यह देखना। GKE मास्टर संस्करण 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

2.16 के लिए कोई फिक्स उपलब्ध नहीं कराया गया है। यदि आपको लगता है कि हेल्म 3 से फिक्स ओवर पोर्ट करना है, तो यह एक स्वागत योग्य बदलाव होगा।

GKE उपयोगकर्ताओं के लिए, Google हीस्टर और मीट्रिक-सर्वर के साथ समस्याएँ रखता है। यही वह कारण है जो पतवार की विफलता का कारण बनता है और बताता है कि यह कभी-कभी काम करता है और दूसरों को नहीं।

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

मैं सिर्फ हेल 3.0.0 स्थिर का उपयोग करता हूं और इस मुद्दे में भाग गया:

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

Apiservice स्वस्थ लग रहा था b / c Availabiliy kubectl get apiservices | grep certmanager में "सही" दिखा रहा था।

kubectl delete apiservice v1beta1.admission.certmanager.k8s.io के साथ "पुनरारंभ" होने के बाद समस्या दूर हो गई।

फिक्स को मास्टर शाखा में विलय कर दिया गया था, लेकिन इसे 3.0.0 में विलय नहीं किया गया था। पैच 3.1 में होगा।

उन लोगों के लिए खोजें जो उपलब्ध नहीं है, गलत है

यदि आपको उन API की आवश्यकता नहीं है, तो उन्हें हटा दें:

kubectl एपिसर्वेस हटाएं

$ 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"

विंडोज़ 10, विंडोज़ के लिए डॉकसर।

मुझे लगता है कि निर्देशों में एक टाइपो था। शायद होना चाहिए
kubectl delete apiservice (सेवा में गुम)

हम डिलीट पर असंगत व्यवहार से भी प्रभावित हैं। उदाहरण के लिए

1. हम हेलम को जानबूझकर गलत तरीके से स्थापित मैट्रिक्स-सर्वर स्थापित करते हैं
   1 ए। संसाधन बनते हैं, लेकिन मेट्रिक्स-सर्वर पॉड क्रैशलूपबैकॉफ़ (अपेक्षित) में समाप्त होता है
2. हम मैट्रिक्स-सर्वर को हटाते हैं
   २ अ। हमें "त्रुटि: 1 त्रुटि के साथ अनइंस्टॉल पूर्ण हो गया है: Kubernetes से apiVersions नहीं मिल सका: Kubernetes से apiVersions नहीं मिल सका: सर्वर APIs की पूरी सूची को पुनर्प्राप्त करने में असमर्थ: metrics.k8s.io/v1beta1: सर्वर है वर्तमान में अनुरोध को संभालने में असमर्थ "
   २ ब। हेल्म रिलीज रिलीज को हटा दिया गया था
   2 सी। चार्ट में सभी संसाधन अभी भी क्लस्टर में मौजूद हैं
   2 डी। मैनुअल सफाई आवश्यक है

"अनइंस्टॉलेशन" का एकमात्र हिस्सा जो पूरा हो गया था, रिलीज रहस्य को हटा रहा था।

यह निर्धारित करने वाला PR यहां था: https://github.com/helm/helm/pull/6908 इसके आसपास की अतिरिक्त चर्चा देखें कि क्या अभी भी एक अतिरिक्त मामला बना हुआ है।

@ हम इस फिक्स को v2 पर

यदि कोई भी हेल्म 2 फिक्स का परीक्षण करने के लिए उपलब्ध है, तो यह यहां है: # 7196

@bacongobbler अपनी टिप्पणी के अनुसार यहां https://github.com/helm/helm/issues/6361#issuecomment -554480815 क्या आप जानते हैं कि v3.1 कब उपलब्ध होगा? मैं सिर्फ 3.0.1 स्थापित किया है और अभी भी इस मुद्दे को मार रहा हूँ - मुझे आश्चर्य था कि यह फिक्स v3.0.1 में नहीं बना था क्योंकि यह एक बहुत व्यापक मुद्दा लगता है। अगर यह v3.1 से पहले होगा v3.0.x रिलीज में इसे बनाने का कोई भी मौका?

एक ही सवाल @mcginne के रूप में। मैं थोड़ी देर के लिए मास्टर ब्रांच का उपयोग कर रहा हूं अब इस फिक्स के रिलीज होने का इंतजार कर रहा हूं। लेकिन मैं एक रिलीज पर वापस होना चाहता हूं। यह बग helm बहुत मुश्किल से ऑटोमेशन लिखता है (जब तक आप सिर्फ अपनी किस्मत आज़माना नहीं चाहते और हर जगह नींद और इंतजार करना)।

यहां तक ​​कि एक 3.1alpha या कुछ अच्छा होगा :)

इस समस्या को बंद करते हुए, इसे master पर हल किया गया है

एक और मामला:

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

यह https://github.com/linkerd/linkerd2/issues/3497 से संबंधित था, जब लिंकरड सेवा में कुछ आंतरिक समस्याएं थीं और वह एपीआई सेवा अनुरोधों पर प्रतिक्रिया नहीं दे सकी। इसकी फली को पुनः आरंभ करके निश्चित किया गया।

@ kivagant-ba क्या आप उस एक के लिए एक नया मुद्दा खोलना चाहेंगे? यह थोड़ा अलग मामला है, और हमें यह तय करना होगा कि हेल्म के पक्ष में "सही" व्यवहार क्या होना चाहिए। मुझे लगता है कि वर्तमान फिक्स अभी भी ऊपर एक घातक त्रुटि पर विचार करेगा।

जो कोई भी इसे हिट करता है, वह एपीआई-सेवाओं के कारण होता है, जिनके पास अब बैकएंड नहीं है ...

मेरे मामले में यह केडीए था, लेकिन कई अलग-अलग सेवाएं हैं जो कुल एपीआई सर्वर स्थापित करती हैं।

ठीक करना:

kubectl get apiservice

लोगों को देखो AVAILABLE False

यदि आपको उन API की आवश्यकता नहीं है, तो उन्हें हटा दें:

kubectl delete apiservice <service-name>

फिर हेल्म को ठीक से काम करना चाहिए। मुझे लगता है कि इस मामले के लिए हेल्म त्रुटि संदेश में सुधार करना सार्थक हो सकता है ...

"सेवा" की वर्तनी में बस एक छोटा सुधार। इसे ठीक किया।

क्या आप उस एक के लिए एक नया मुद्दा खोलना चाहेंगे?

यह उन लोगों के लिए कोई समस्या नहीं है जो लिंकरड के नए संस्करण का उपयोग कर रहे हैं। मैंने अपनी टिप्पणी यहां उन लोगों के लिए छोड़ दी जो त्रुटि वाक्यांश की खोज करेंगे क्योंकि यह समान दिखता है लेकिन मूल कारण अलग है।

ओह! अच्छा जी। धन्यवाद!

@technosophos इसके लिए क्या ठीक है? क्या हमें kubectl get apiservice और तब तक ब्लॉक करना चाहिए जब तक कि सभी सेवाएँ Ready राज्य में न हों? क्या इसके बजाय हम कुछ और कर सकते हैं?

हम एक ओएसएस टूल पर काम कर रहे हैं जो एक सिस्टम को बूटस्ट्रैप करने के लिए कई हेलम चार्ट स्थापित करता है और यह समस्या पूरी प्रक्रिया को रुक-रुक कर विफल होने के लिए प्रकट होती है।

मैंने अभी helm delete कर इस समस्या का सामना किया है। इसका बहुत बुरा असर हुआ। हेल्म रिलीज को हटा दिया गया, लेकिन सभी K8 वस्तुओं को क्लस्टर में चालू रखा गया था। इसलिए हमें सब कुछ हाथ से निकालना पड़ा। और जैसा कि यह एक ऑपरेटर था, इस कार्रवाई को एक महत्वपूर्ण प्रयास की आवश्यकता थी।

@andrewnazarov कृपया अधिक जानकारी प्रदान करें कि आपने क्या हटाने का प्रयास किया और क्या हुआ। त्रुटि संदेश सहायक होगा, जैसे हेलम संस्करण, क्यूब संस्करण, आदि।

@alexellis क्या, वास्तव में, एक समस्या पैदा कर रहा है? क्या आप एक हेल्म चार्ट स्थापित कर रहे हैं जो एक एपीआई सेवा स्थापित करता है और सोच रहा है कि यह उपलब्ध होने तक इंतजार कैसे करें? संक्षिप्त उत्तर यह है कि आपको निश्चित रूप से प्रतीक्षा करने की रणनीति तैयार करनी होगी, या संभवत: इसे दो चार्ट में तोड़ना होगा। कुबेरनेट्स हमें खोज एपीआई पर त्रुटियों से निपटने में सक्षम होने के लिए बहुत टूलींग नहीं देता है, लेकिन यदि सेवा विवरण सेवा द्वारा समर्थित नहीं है, तो एक खोज कॉल निश्चित रूप से विफल हो जाएगी और सेवा_ को उस नक्शे पर वापस नहीं लौटाती है जिसमें वह वापस लौटता है।

कृपया इस बारे में अधिक जानकारी प्रदान करें कि आपने क्या हटाने का प्रयास किया और क्या हुआ। त्रुटि संदेश सहायक होगा, जैसे हेलम संस्करण, क्यूब संस्करण, आदि।

ज़रूर।

पतवार: 3.0.0
K8s: 1.14.8

helm delete prom -n monitoring निम्नलिखित त्रुटि के साथ समाप्त हुआ

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

उसके बाद, हेल्म रिलीज हेल्म रिलीज की सूची से गायब हो गई और प्रोमेथियस ऑपरेटर से संबंधित सभी ऑब्जेक्ट अनाथ हो गए।

ठीक है, मैं देखता हूं, यह एक संस्करण मुद्दा हो सकता है। सबसे हाल के संस्करण 3.0.2 asap में हेल्म को अपग्रेड करेगा।

हां, यह निश्चित रूप से एक संस्करण बेमेल मुद्दा है। यह पैच 3.0.2 में उपलब्ध कराया गया था। भविष्य में, कृपया नवीनतम पैच रिलीज़ (या बेहतर, अभी तक, मास्टर पर) के साथ परीक्षण करना सुनिश्चित करें। धन्यवाद!

यदि आप आगे के मुद्दों का सामना कर रहे हैं, तो कृपया एक नया टिकट खोलें।

kubectl get apiservice

यदि कोई सेवा "AVAILABLE = गलत" है, तो आप उन्हें पुनः आरंभ करने के लिए संबंधित पॉड्स को हटाने का प्रयास कर सकते हैं।
इसने क्यूब-सिस्टम / मेट्रिक्स सेवा के साथ मेरी समस्या को हल किया।

हाय @technosophos। हो सकता है कि मैं कुछ याद कर रहा हूं, लेकिन मैं इस पीआर को नहीं देखता हूं https://github.com/helm/helm/pull/6908/files को 2.16.3 पर पोर्ट किया जा रहा है, हालांकि यह हेल्म 2 के साथ भी होता है। क्या आप इस वर्कअराउंड को हेल्म 2 में भी पोर्ट कर रहे हैं?

यह कुछ महीने पहले dev-v2 में विलीन हो गया था। आप उस शाखा से निर्माण कर सकते हैं और यदि चाहें तो इसका परीक्षण कर सकते हैं।

यह हेल्म 2 और टेराफॉर्म प्रदाता में शामिल देखकर बहुत अच्छा लगेगा। जब भी कोई क्लस्टर बनाया जाता है, मैं इस त्रुटि को पुन: उत्पन्न करने में सक्षम होता हूं।

क्या आपने dev-v2 शाखा का परीक्षण किया है? वर्तमान में हमारे पास कोई पुष्टि नहीं है (हमारे स्वयं के परीक्षणों के अलावा) जो समाधान वहां काम करता है, हालांकि यह समान समाधान में है।

मेरे पास नहीं है, मैं इसे इस सप्ताह कोशिश कर सकता हूं। जब से मैं टेराफॉर्म के साथ इसका उपयोग कर रहा हूं, क्या मैं dev-v2 ब्रांच बना / चला सकता हूं और अनुकरण करने के लिए helm_release resource का "local" का रिपॉजिटरी वैरिएबल सेट कर सकता हूं?

@bacongobbler हमने prometheus-adapter साथ एक ही मुद्दे का सामना किया, जिसने कस्टम एपिस सर्विस को उजागर किया और अगर मैं कस्टम एपिस सर्विस और kubectl get apiservice साथ रिलीज़ नहीं हुआ, तो इस सूची में से कोई भी उपलब्ध नहीं होगा = झूठी मदद करने वाला कोई नया नहीं बना सके भले ही यह रिवाज से संबंधित नहीं है, जारी करें:
err="Could not get apiVersions from Kubernetes: unable to retrieve the complete list of server APIs: custom.metrics.k8s.io/v1beta1: the server is currently unable to handle the request"

Terraform प्रदाता के साथ Helm 2 इस समय इस मुद्दे के कारण टूट गया है और। मुझे उम्मीद है कि आप भी इसके लिए एक फिक्स प्रदान कर सकते हैं, ऐसा लगता है कि यह एक सामान्य उपयोग-मामला है।

पुष्टि कर सकता हूँ कि मैं इस मुद्दे पर भी हूँ। एक तय करने की उम्मीद है।

समाधान:

मैंने जिन चरणों का पालन किया है वे हैं:

1. kubectl get apiservices : यदि मीट्रिक-सर्वर सेवा त्रुटि के साथ बंद हो जाती है, तो CrashLoopBackOff चरण 2 का अनुसरण करने का प्रयास करें अन्यथा kubectl delete apiservice/"service_name" का उपयोग करके मीट्रिक-सर्वर सेवा को पुनः आरंभ करने का प्रयास करें। मेरे लिए यह v1beta1.metrics.k8s.io था।

2. kubectl get pods -n kube-system और यह पता चला कि पॉड्स मेट्रिक्स-सर्वर, कुबेरनेट्स-डैशबोर्ड मुख्य कोरडाउन पॉड डाउन होने के कारण नीचे हैं।

मेरे लिए यह था:

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

1. CoreDNS पॉड में त्रुटि की जांच करने के लिए kubectl describe pod/"pod_name" का उपयोग करें और अगर / / / coredns / Corefile के कारण नीचे है

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