Helm: غير قادر على استرداد القائمة الكاملة لواجهات برمجة تطبيقات الخادم

لدي نفس المشكلة على AKS ، على الرغم من أن رسالة الخطأ هي

خطأ: تعذر الحصول على ApiVersions من Kubernetes: تعذر استرداد القائمة الكاملة لواجهات برمجة تطبيقات الخادم: metrics.k8s.io/v1beta1: يتعذر على الخادم حاليًا معالجة الطلب

التكوين الخاص بي:

• نسخة kubectl:

إصدار العميل: version.Info {Major: "1"، Minor: "15"، GitVersion: "v1.15.2"، GitCommit: "f6278300bebbb750328ac16ee6dd3aa7d3549568"، GitTreeState: "clean"، BuildDate: "2019-08-05T09: 23: 26Z "، GoVersion:" go1.12.5 "، المترجم:" gc "، النظام الأساسي:" windows / amd64 "}
إصدار الخادم: version.Info {Major: "1"، Minor: "14"، GitVersion: "v1.14.6"، GitCommit: "96fac5cd13a5dc064f7d9f4f23030a6aeface6cc"، GitTreeState: "clean"، BuildDate: "2019-08-19T11: 05: 16Z "، GoVersion:" go1.12.9 "، المترجم:" gc "، النظام الأساسي:" linux / amd64 "}

• إصدار الدفة: alpine / docker )

• kubectl api- الموارد
  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

أعتقد في حالتي أن هذه المشكلة بدأت مؤخرًا ... يبدو أنها تتعلق بتثبيت knative في حالتي (هذا خيار مُدار في IBM Cloud IKS). لقد قمت بإلغاء تثبيت knative وأنا بخير في الوقت الحالي ، ولكن قد تكون هناك مشكلة في التشغيل المتداخل هنا

kalioz بدافع الاهتمام هل تستخدم knative على AWS؟ لا يبدو في الواقع لأنني لا أستطيع رؤية كائنات tekton

لقد رأيت للتو هذه المشكلة بنفسي. في حالتي ، كان مدير الشهادات هو الذي أثار المشكلة. ما زلت أعمل على كيفية إعادته إلى ما كان عليه.

@ planetf1 لا أستخدم knative (أو أعتقد أنني لا أستخدمها) ، لكن المشكلة موجودة فقط في الكتلة الجديدة التي قمت بنشرها لهذا الاختبار.
الاختلافات بين الكتلة العاملة وغير العاملة هي:

| | يعمل | لا يعمل |
| --- | --- | --- |
| إصدار kube | 1.13.5 | 1.14.6 |
| مصادقة Azure AD | معطل | ممكّن |
| RBAC | معطل | ممكّن |

لذلك لدي بعض التغييرات الرئيسية.

بالنسبة لي ، المشكلة هي أن helm3 تحطم بسبب عدم الوصول إلى بعض واجهات برمجة التطبيقات ، الذين لم يتم استخدامهم في الرسم البياني الذي أحاول نشره.

أنا أستخدمه في الإصدار 1.13.9 من مجموعة K8 ، يأتي نفس الخطأ لنشر أي مخطط ثابت.

إصدار الدفة
version.BuildInfo {الإصدار: "v3.0.0-beta.3" ، GitCommit: "5cb923eecbe80d1ad76399aee234717c11931d9a" ، GitTreeState: "نظيف" ، GoVersion: "go1.12.9"}

helm.go: 81: [debug] غير قادر على استرداد القائمة الكاملة لواجهات برمجة تطبيقات الخادم: metrics.k8s.io/v1beta1: يتعذر على الخادم حاليًا معالجة الطلب.

بعد حل المشكلة من جراب المقاييس (لا أتذكر كيف قمت بحلها ، أعتقد أنه قد يتعلق الأمر بوظيفة helm3 HostNetwork أو ببساطة إعادة تشغيل pod المرتبط) كما هو متوقع.
لذلك قد تكون `` ميزة '' لأنها تفرض الحفاظ على الكتلة في حالة صحية جيدة ، ولكنها تتطلب من شخص ما الانتقال يدويًا إلى المجموعة في كل مرة يتم فيها كسر واجهة برمجة التطبيقات (وبالتالي قد يمنع استخدام helm3 لنشر البودات التي يمكن إدراجها في القائمة على هذا).

إنه حقًا مزعج حقًا عندما يبدأ شخص ما بـ Kubernetes. أنا أعرض حلًا للشهادات باستخدام acme ، حيث لا يمكنني ضمان عدم تعطل مدير الشهادات حتى بعد تكوينه.

الجزء المزعج حقًا هو أنه لا يمكنني فقط استخدام الدفة لإلغاء تثبيت مدير الشهادات والعودة إلى حيث كنت! يتم كسر أي شيء يسمح لخدمة موصى بها بشدة بقطعها ، ولن يتم التراجع عن التغيير.

بالنسبة لأي شخص يصل إلى هذا ، فإن السبب في ذلك هو خدمات api التي لم تعد تعمل في الخلفية ...

في حالتي كانت KEDA ، ولكن هناك عددًا من الخدمات المختلفة التي تثبت خوادم API المجمعة.

لإصلاحها:

kubectl get apiservice

ابحث عن تلك التي يكون AVAILABLE هو False

إذا لم تعد بحاجة إلى واجهات برمجة التطبيقات هذه ، فاحذفها:

kubectl delete apiservce <service-name>

ثم يجب أن يعمل هيلم بشكل صحيح. أعتقد أن تحسين رسالة خطأ Helm لهذه الحالة قد يكون مفيدًا ...

شكرًا على التوضيح - هل هناك طريقة يمكن لـ Helm من خلالها كتابة التعليمات البرمجية حول هذا أيضًا؟

نعتقد ذلك ، على الرغم من أننا ما زلنا نحقق. تقترح نظري الأول أن هذا مرتبط فقط باستخدامنا لواجهة برمجة التطبيقات Discovery ، والتي تُستخدم لكائن 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

هذا مزعج جدا سيكون التحذير بدلاً من الفشل أفضل بكثير بالفعل.
أي تحديثات على هذا حتى الآن؟

تحرير: هل يمكن لـ / س تأكيد تأثر 2.15 أيضًا؟ ثم أقترح تعديل ملصقات هذه التذكرة.

sjentzsch أرى أيضًا نفس الشيء باستخدام Helm 2.15.0 و k8s 1.16.0 .

إذا كان هذا يؤثر أيضًا على 2.x ، فسيواجه كل شخص يستخدم "cert-manager" (ربما التكوين المسبق فقط) وقتًا سيئًا.

__هنا لدينا حالتان مختلفتان لهما نفس السلوك من جانب الدفة.
يتأثر كلا الإصدارين 2.15.1 و 3 beta .__

كما ذكر technosophos ، يستخدم helm وظيفة واجهة برمجة التطبيقات للاكتشاف ويفشل في حالة فشل أي من استجابة API https://github.com/helm/helm/blob/f1dc84773f9a34fe59a504fdb32428ce1d56a2e8/pkg/action/action.go#L105 -L118

1. يُعد admission.certmanager.k8s.io/v1beta1 الخاص بـ cert-manager مثالاً جيدًا:

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. حالة أخرى من الفشل عندما يتعذر على helm استرداد الاستجابة من أي خدمة من خدمات api
   على سبيل المثال "metrics.k8s.io/v1beta1: الخادم غير قادر حاليًا على معالجة الطلب" ويحدث ذلك من حالة إلى أخرى

حاليًا ، هو على قيد الحياة ويعمل ولكن تم إيقافه عن طريق الخطأ أثناء طلب القيادة.

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

أنا متأكد من أن القيادة يجب أن تكون أكثر قوة لمثل هذا النوع من المشكلات ،
1) ربما يكون من الجيد تحويل الخطأ إلى تحذير (لا أعرف كيف تستخدم المعلومات من خدمة api أثناء عرض القالب)
2) تنفيذ عمليات إعادة المحاولة لهذا النوع من الطلبات

لدينا مشكلة مماثلة مع 2.15.1 على Kubernetes 1.15.5 ، ولكن ليس مع الدفة 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 على مجموعة متطابقة في الغالب تعمل بشكل موثوق.

لقد واجهنا هذه المشكلة عند محاولة الترقية إلى Helm 2.15.2 في مجموعة الرسوم البيانية CI. لذا ، فهي ليست مشكلة Helm 3 فقط. أدى حذف خدمة API المفقودة إلى إصلاحها. أتساءل عما إذا كان هيلم يمكن أن يكون أكثر رشاقة هنا ، خاصة وأن هذا قد يظهر مرة أخرى في أي وقت.

واجهت مشكلة مماثلة في تثبيت مخطط خادم ثابت / متري على مجموعة تثبيت kubeadm.

عندما تحاول إلغاء تثبيت المخطط ، تفشل عملية الإزالة بسبب خطأ خادم api (لأن خادم المقاييس هو fubar) ، وهذا يترك حمولة من الموارد المتدلية التي يجب عليك تنظيفها يدويًا - نظرًا لأن helm قد أزال الإصدار من قاعدة بياناته على أي حال.

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

بدأت في الوصول إلى هذا مؤخرًا في مجموعات GKE التي تم إنشاؤها حديثًا ، باستخدام 2.15.1 (ربما تمت ترقيتها مؤخرًا عبر Snap). تم الإبلاغ أيضًا باسم 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 في حالتك ، هل يحدث ذلك فقط عند إنشاء المجموعة لأول مرة؟

تكمن المشكلة في أعماق عميل الاكتشاف Kubernetes Go. أنا أجرب فقط طباعة تحذير. ومع ذلك ، قد يكون لذلك عواقب سلبية على الرسوم البيانية التي تعتمد بشكل كبير على كائن القدرات.

في حالتك ، هل يحدث ذلك فقط عندما يتم إنشاء الكتلة لأول مرة؟

نعم. لدي برنامج نصي يقوم بإنشاء مجموعة ، وتثبيت Tiller ، وإنشاء إصدارات Helm. لذلك يبدو وكأنه حالة سباق في تهيئة الكتلة.

jglick من المحتمل جدًا أن يؤدي التنفيذ الذي قمت به بالأمس إلى تجنب المشكلة ما لم تكن تكتب مخططات تشير مباشرة إلى مجموعة واجهة برمجة التطبيقات المسيئة.

technosophos شكرا على هذا الدمج. أعتقد أنه سيحسن من مرونة الدفة.

هل لدينا إصلاح 2.15 / 2.16؟

رؤية هذا في 2.16 أيضًا. إصدار GKE Master 1.14.8-gke.12.0

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. إذا كنت ترغب في نقل الإصلاح من Helm 3 ، فسيكون هذا تغييرًا مرحبًا به.

بالنسبة لمستخدمي GKE ، تواجه Google مشكلات مع خادم heapster و metric. هذا هو سبب فشل الدفة ويشرح سبب نجاحها في بعض الأحيان دون غيرها.

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

أنا فقط استخدم helm 3.0.0 Stable وركضت في المشكلة:

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 صحية ب / ج كان Availabiliy يظهر "true" في kubectl get apiservices | grep certmanager .

بعد "إعادة التشغيل" بـ kubectl delete apiservice v1beta1.admission.certmanager.k8s.io اختفت المشكلة.

تم دمج الإصلاح في الفرع الرئيسي ، ولكن لم يتم دمجه في 3.0.0. التصحيح سيكون في 3.1.

ابحث عن الأدوات المتوفرة خطأ

إذا لم تعد بحاجة إلى واجهات برمجة التطبيقات هذه ، فاحذفها:

kubectl حذف 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 for windows.

أظن أنه كان هناك خطأ مطبعي في التعليمات. ربما يجب أن يكون
kubectl delete apiservice (مفقود أنا في الخدمة)

نتعرض أيضًا لسلوك غير متسق عند الحذف. على سبيل المثال

1. نقوم بتثبيت خادم المقاييس الذي تم تكوينه بشكل خاطئ عن قصد
   1 أ. يتم إنشاء الموارد ولكن ينتهي جراب خادم المقاييس في كراش لوبباكوف (متوقع)
2. نحن نحذف مقاييس الخادم
   2 أ. نعود "خطأ: اكتملت عملية الإزالة بخطأ (أخطاء) واحد: تعذر الحصول على إصدارات من Kubernetes: تعذر الحصول على إصدارات من Kubernetes: تعذر استرداد القائمة الكاملة لواجهات برمجة تطبيقات الخادم: metrics.k8s.io/v1beta1: الخادم هو حاليا غير قادر على التعامل مع الطلب "
   2 ب. تمت إزالة سر الإفراج عن هيلم
   2 ج. لا تزال جميع الموارد في المخطط موجودة في المجموعة
   2 د. التنظيف اليدوي ضروري

الجزء الوحيد من "إلغاء التثبيت" الذي اكتمل هو إزالة سر الإصدار.

العلاقات العامة التي تم إصلاحها هنا: https://github.com/helm/helm/pull/6908 راجع المناقشة الإضافية حول ما إذا كانت لا تزال هناك حالة إضافية واحدة.

@ أين يمكننا دعم هذا الإصلاح إلى الإصدار 2؟

إذا كان أي شخص متاحًا لاختبار إصلاح Helm 2 ، فهو هنا: # 7196

bacongobbler حسب تعليقك هنا https://github.com/helm/helm/issues/6361#issuecomment -554480815 هل تعرف متى سيكون الإصدار 3.1 متاحًا؟ لقد قمت للتو بتثبيت 3.0.1 وما زلت أتغلب على المشكلة - لقد فوجئت أن هذا الإصلاح لم يصل إلى الإصدار 3.0.1 لأنه يبدو أنه مشكلة منتشرة إلى حد كبير. هل هناك أي فرصة لجعله في إصدار v3.0.x إذا كان ذلك قبل الإصدار 3.1؟

نفس السؤال مثل 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 ، عندما واجهت خدمة Linkerd بعض المشكلات الداخلية ولا يمكنها الاستجابة لطلبات خدمة API. تم إصلاحه عن طريق إعادة تشغيل السنفات.

@ kivagant-ba هل تمانع في فتح عدد جديد لذلك؟ إنها حالة مختلفة قليلاً ، وعلينا أن نقرر ما يجب أن يكون عليه السلوك "الصحيح" من جانب هيلم. أعتقد أن الإصلاح الحالي سيظل يعتبر ما ورد أعلاه خطأ فادحًا.

بالنسبة لأي شخص يصل إلى هذا ، فإن السبب في ذلك هو خدمات api التي لم تعد تعمل في الخلفية ...

في حالتي كانت KEDA ، ولكن هناك عددًا من الخدمات المختلفة التي تثبت خوادم API المجمعة.

لإصلاحها:

kubectl get apiservice

ابحث عن تلك التي يكون AVAILABLE هو False

إذا لم تعد بحاجة إلى واجهات برمجة التطبيقات هذه ، فاحذفها:

kubectl delete apiservice <service-name>

ثم يجب أن يعمل هيلم بشكل صحيح. أعتقد أن تحسين رسالة خطأ Helm لهذه الحالة قد يكون مفيدًا ...

مجرد تصحيح بسيط في تهجئة "الخدمة". تصحيحه.

هل تمانع في فتح عدد جديد لذلك؟

إنها ليست مشكلة للأشخاص الذين يستخدمون إصدارًا أحدث من Linkerd. لقد تركت تعليقي هنا لأولئك الذين سيبحثون عن عبارة الخطأ لأنها تبدو متشابهة ولكن السبب الأساسي مختلف.

أوه! تمام. شكرا لك!

technosophos ما هو الإصلاح لهذا؟ هل يجب علينا grep kubectl get apiservice ثم الحظر حتى تصبح جميع الخدمات في حالة Ready ؟ هل هناك شيء آخر يمكننا فعله بدلاً من ذلك؟

نحن نعمل على أداة OSS التي تثبت عددًا من مخططات الدفة لإقلاع النظام ويبدو أن هذه المشكلة تتسبب في فشل العملية برمتها بشكل متقطع.

لقد واجهت للتو هذه المشكلة أثناء عمل helm delete . لقد تسبب في تأثير سيء للغاية. تمت إزالة إصدار Helm ، ولكن تم الاحتفاظ بجميع كائنات K8s تعمل في المجموعة. لذلك كان علينا إزالة كل شيء باليد. وبما أنها كانت عاملاً ، فقد تطلب هذا الإجراء جهدًا كبيرًا.

andrewnazarov يرجى تقديم مزيد من المعلومات حول ما حاولت حذفه وما حدث. قد تكون رسائل الخطأ مفيدة ، كما هو الحال مع إصدار Helm وإصدار Kube وما إلى ذلك.

alexellis ما الذي يسبب مشكلة بالضبط؟ هل تقوم بتثبيت مخطط Helm يقوم بتثبيت خدمة API وتتساءل كيف تنتظر حتى تصبح متاحة؟ الإجابة المختصرة هي أنك ستحتاج بالتأكيد إلى وضع استراتيجية للانتظار ، أو ربما تقسيمها إلى مخططين. لا تعطينا Kubernetes الكثير من الأدوات لنتمكن من التعامل مع الأخطاء في واجهة برمجة التطبيقات للاكتشاف ، ولكن إذا لم يكن وصف الخدمة مدعومًا بواسطة خدمة ، فستفشل استدعاء الاستكشاف بالتأكيد ولن تعيد الخدمة في الخريطة التي تعيدها.

يرجى تقديم مزيد من المعلومات حول ما حاولت حذفه وما حدث. قد تكون رسائل الخطأ مفيدة ، كما هو الحال مع إصدار Helm وإصدار Kube وما إلى ذلك.

بالتأكيد.

خوذة: 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

بعد ذلك ، اختفى إصدار الدفة من قائمة إصدارات Helm وأصبحت جميع العناصر المتعلقة بمشغل Prometheus يتيمة.

حسنًا ، أرى أنه قد يكون مشكلة في الإصدار. سيتم ترقية Helm إلى أحدث إصدار 3.0.2 في أسرع وقت ممكن.

نعم ، هذه بالتأكيد مشكلة عدم تطابق الإصدار. تم توفير هذا التصحيح في 3.0.2. في المستقبل ، يرجى التأكد من الاختبار باستخدام أحدث إصدار من التصحيح (أو الأفضل من ذلك ، في الإصدار الرئيسي). شكرا!

إذا كنت تواجه مشكلات أخرى ، فيرجى فتح تذكرة جديدة.

kubectl get apiservice

إذا كانت إحدى الخدمات "AVAILABLE = false" ، يمكنك محاولة حذف البودات ذات الصلة لإعادة تشغيلها.
لقد حلت مشكلتي مع خدمة kube-system / metrics.

مرحبًاtechnosophos. ربما فاتني شيء ما ، لكنني لا أرى هذه العلاقات العامة https://github.com/helm/helm/pull/6908/files يتم نقلها إلى 2.16.3 ، على الرغم من حدوث ذلك مع helm 2 أيضًا. هل تخطط لتنفيذ هذا الحل البديل في الدفة 2 أيضًا؟

تم دمجها في dev-v2 قبل بضعة أشهر. يمكنك البناء من هذا الفرع واختباره إذا أردت.

سيكون من الرائع رؤية هذا مدمجًا في Helm 2 ومزود Terraform . أنا قادر على إعادة هذا الخطأ في كل مرة يتم فيها إنشاء كتلة.

هل اختبرت الفرع dev-v2 ؟ ليس لدينا حاليًا أي تأكيد (بخلاف اختباراتنا الخاصة) على أن الحل هناك يعمل ، على الرغم من أنه في جوهره هو نفس الحل.

لم أفعل ، يمكنني أن أجربها هذا الأسبوع. نظرًا لأنني أستخدم هذا مع Terraform ، هل يمكنني إنشاء / تشغيل الفرع dev-v2 وتعيين متغير المستودع لمورد helm_release على "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"

تم تعطيل Helm 2 مع مزود Terraform بسبب هذه المشكلة في الوقت الحالي و. آمل أن تتمكن أيضًا من توفير حل لها ، يبدو أن هذه حالة استخدام شائعة.

يمكن أن أؤكد أنني أواجه هذه المشكلة أيضًا. تأمل في الإصلاح.

حل:

الخطوات التي اتبعتها هي:

1. kubectl get apiservices : إذا كانت خدمة الخادم المتري معطلة بسبب الخطأ CrashLoopBackOff ، فحاول اتباع الخطوة 2 وإلا فحاول فقط إعادة تشغيل خدمة الخادم المتري باستخدام kubectl delete apiservice/"service_name" . بالنسبة لي كان v1beta1.metrics.k8s.io.

2. kubectl get pods -n kube-system واكتشفت أن البودات مثل خادم المقاييس ولوحة تحكم kubernetes معطلة بسبب تعطل حجرة coreDNS الرئيسية.

بالنسبة لي كان:

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

1. استخدم kubectl describe pod/"pod_name" للتحقق من الخطأ في coreDNS pod وإذا كان معطلاً بسبب / etc / coredns / Corefile: 10 - خطأ أثناء التحليل: وكيل توجيه غير معروف ، فنحن بحاجة إلى استخدام إعادة التوجيه بدلاً من الوكيل في yaml الملف حيث يوجد coreDNS config. لأن CoreDNS الإصدار 1.5x المستخدم بواسطة الصورة لم يعد يدعم الكلمة الأساسية للوكيل.

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