Helm: tidak dapat mengambil daftar lengkap API server

Saya memiliki masalah yang sama di AKS, meskipun pesan kesalahannya adalah

Kesalahan: tidak bisa mendapatkan apiVersions dari Kubernetes: tidak dapat mengambil daftar lengkap API server: metrics.k8s.io/v1beta1: server saat ini tidak dapat menangani permintaan

konfigurasi saya:

• versi kubectl:

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

• versi helm: alpine / helm: 3.0.0-beta.2 (buruh pelabuhan)

• 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

Saya percaya dalam kasus saya, masalah ini dimulai baru-baru ini ... tampaknya terkait dengan pemasangan knative dalam kasus saya (Di IBM Cloud IKS ini adalah opsi yang dikelola). Saya telah mencopot pemasangan knative dan baik-baik saja untuk saat ini, tetapi mungkin ada masalah interop di sini

@kalioz karena tertarik, apakah Anda menggunakan knative di AWS? Sebenarnya tidak terlihat karena saya tidak bisa melihat objek tekton

Saya baru saja melihat masalah ini sendiri. Dalam kasus saya, manajer-sertifikatlah yang memicu masalah. Masih mengerjakan cara mengembalikannya seperti semula.

@ planetf1 Saya tidak menggunakan knative (atau saya rasa saya tidak), tetapi masalahnya hanya ada di cluster baru yang saya gunakan untuk pengujian ini.
Perbedaan antara cluster kerja dan yang tidak berfungsi adalah:

| | bekerja | tidak bekerja |
| --- | --- | --- |
| Versi kube | 1.13.5 | 1.14.6 |
| otentifikasi AD azure | dinonaktifkan | diaktifkan |
| RBAC | dinonaktifkan | diaktifkan |

Jadi saya punya beberapa perubahan besar.

Bagi saya masalahnya adalah helm3 crash karena kurangnya akses ke beberapa apis, yang tidak digunakan untuk grafik yang saya coba terapkan.

Saya menggunakannya pada cluster k8 versi 1.13.9, kesalahan yang sama akan datang untuk menerapkan bagan stabil apa pun.

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

helm.go: 81: [debug] tidak dapat mengambil daftar lengkap API server: metrics.k8s.io/v1beta1: server saat ini tidak dapat menangani permintaan.

Setelah menyelesaikan masalah dari pod metrik (tidak dapat mengingat bagaimana saya menyelesaikannya, saya pikir itu mungkin ada hubungannya dengan hostNetwork atau cukup dengan memulai ulang pod terkait) fungsi helm3 seperti yang diharapkan.
Jadi ini mungkin sebuah 'fitur' karena memaksa untuk menjaga cluster dalam kondisi yang baik, tetapi itu akan membutuhkan seseorang untuk secara manual masuk ke dalam cluster setiap kali api rusak (dan dengan demikian dapat mencegah penggunaan helm3 untuk menyebarkan pod yang dapat didaftarkan hal ini).

Benar-benar menjengkelkan ketika seseorang memulai dengan Kubernetes. Saya langsung memberikan solusi untuk sertifikat yang menggunakan acme, karena saya tidak dapat menjamin bahwa manajer sertifikat tidak akan tetap rusak bahkan setelah mengonfigurasinya.

Bagian yang benar-benar menjengkelkan adalah saya tidak bisa hanya menggunakan helm untuk menghapus manajer sertifikat dan kembali ke tempat saya dulu! Apa pun yang memungkinkan layanan yang sangat disarankan untuk merusaknya, dan tidak akan membatalkan perubahan, akan rusak.

Bagi siapa pun yang melakukan ini, ini disebabkan oleh layanan-api yang tidak lagi menjalankan backend ...

Dalam kasus saya itu adalah KEDA, tetapi ada sejumlah layanan berbeda yang memasang server API gabungan.

Untuk memperbaikinya:

kubectl get apiservice

Cari yang AVAILABLE adalah False

Jika Anda tidak membutuhkan API itu lagi, hapuslah:

kubectl delete apiservce <service-name>

Maka Helm akan bekerja dengan baik. Saya pikir memperbaiki pesan kesalahan Helm untuk kasus ini mungkin bermanfaat ...

Terima kasih atas penjelasannya - adakah cara Helm dapat mengkodekan hal ini juga?

Kami pikir begitu, meski kami masih menyelidikinya. Tampilan pertama saya menunjukkan bahwa ini hanya terkait dengan penggunaan Discovery API kami, yang digunakan untuk objek Capabilities dalam rendering template. Kami mungkin dapat menjebak kesalahan khusus ini dan memperingatkan pengguna alih-alih gagal.

Sama dengan 2.15.0 sekarang:

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

Ini sangat mengganggu. Peringatan daripada gagal akan jauh lebih baik.
Ada pembaruan sejauh ini?

EDIT: dapatkah s / o mengonfirmasi 2.15 juga terpengaruh? Kemudian saya akan menyarankan untuk menyesuaikan label tiket ini.

@sjentzsch Saya juga melihat hal yang sama menggunakan Helm 2.15.0 dan k8s 1.16.0 .

Jika ini juga mempengaruhi 2.x maka setiap orang yang menggunakan "cert-manager" (mungkin hanya pra-konfigurasi) akan mengalami kesulitan.

__ Di sini kami memiliki dua kasus berbeda dengan perilaku yang sama dari sisi kemudi.
Baik versi 2.15.1 dan 3 beta terpengaruh .__

Seperti yang disebutkan @technosophos, helm menggunakan fungsionalitas API penemuan dan gagal jika ada respons API yang gagal https://github.com/helm/helm/blob/f1dc84773f9a34fe59a504fdb32428ce1d56a2e8/pkg/action/action.go#L105 -L118

1. Cert-manager's admission.certmanager.k8s.io/v1beta1 adalah contoh yang bagus:

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

dan untuk kasus ini Anda dapat dengan mudah memperbaikinya dengan kubectl delete apiservice v1beta1.admission.certmanager.k8s.io
seperti yang dijelaskan oleh @brendandburns .

1. Kasus lain kegagalan ketika helm tidak dapat mengambil respon dari salah satu layanan api
   misalnya "metrics.k8s.io/v1beta1: server saat ini tidak dapat menangani permintaan" dan ini terjadi dari kasus ke kasus

Saat ini, itu hidup dan berjalan tetapi tidak sengaja mati selama permintaan kemudi.

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

Saya yakin bahwa kemudi harus lebih kuat untuk jenis masalah seperti itu,
1) mungkin ada baiknya untuk mengubah kesalahan menjadi peringatan (saya tidak tahu bagaimana info dari layanan api digunakan selama rendering template)
2) terapkan percobaan ulang untuk jenis permintaan seperti itu

Kami memiliki masalah serupa dengan 2.15.1 di Kubernetes 1.15.5, tetapi BUKAN dengan helm 2.14.3.

Masalahnya mengambang: beberapa bagan dipasang dengan baik, tetapi kemudian mulai gagal.
Pesan kami adalah:

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 daftar metrics.k8s.io/v1beta1 sebagai tersedia. Mungkin kami mengalami masalah sementara dengan layanan ini, tetapi helm 2.14.3 pada cluster yang sebagian besar identik berfungsi dengan andal.

Kami mengalami masalah ini saat mencoba meningkatkan ke Helm 2.15.2 pada bagan CI cluster. Jadi, ini bukan hanya masalah Helm 3. Menghapus layanan API yang hilang memperbaikinya. Saya ingin tahu apakah Helm bisa lebih anggun di sini, terutama karena ini mungkin bisa muncul lagi kapan saja.

Mengalami masalah serupa saat menginstal diagram stable / metrics-server pada cluster yang diinstal kubeadm.

Ketika Anda mencoba untuk mencopot bagan, pencopotan pemasangan gagal dengan kesalahan server api (karena server metrik adalah fubar), dan itu meninggalkan banyak sumber daya yang menggantung di sekitar yang harus Anda bersihkan dengan tangan - karena helm telah menghapus rilis dari database-nya.

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

Mulai melakukannya baru-baru ini di cluster GKE yang baru dibuat, menggunakan 2.15.1 (mungkin baru-baru ini diupgrade melalui Snap). Juga dilaporkan sebagai https://github.com/kubernetes/kubernetes/issues/72051#issuecomment -521157642. Tampaknya dapat mengatasi dengan mendahului setiap helm install perintah dengan:

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

@jglick Dalam kasus Anda, apakah ini hanya terjadi saat cluster pertama kali dibuat?

Masalahnya ada jauh di dalam klien penemuan Kubernetes Go. Saya bereksperimen hanya dengan mencetak peringatan. Namun, itu bisa berdampak negatif untuk bagan yang sangat bergantung pada objek Capabilities.

Dalam kasus Anda, apakah ini hanya terjadi saat cluster pertama kali dibuat?

Iya. Saya memiliki skrip yang membuat cluster, menginstal Tiller, dan membuat rilis Helm. Jadi sepertinya kondisi balapan dalam inisialisasi cluster.

@jglick penerapan yang saya lakukan kemarin kemungkinan besar akan menghindari masalah bagi Anda kecuali Anda menulis bagan yang secara langsung merujuk pada grup API yang menyinggung.

@technosophos terima kasih untuk penggabungan itu. Saya pikir itu akan meningkatkan ketahanan kemudi.

Apakah kami memiliki perbaikan untuk 2.15 / 2.16?

Melihat ini di 2.16 juga. GKE Master versi 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

tidak ada perbaikan yang tersedia untuk 2.16. Jika Anda ingin mengubah perbaikan dari Helm 3, itu akan menjadi perubahan yang disambut baik.

Untuk pengguna GKE, Google mengalami masalah dengan heapster dan metrik-server. Inilah yang menyebabkan kegagalan kemudi dan menjelaskan mengapa kadang-kadang berhasil dan tidak pada orang lain.

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

Saya hanya menggunakan helm 3.0.0 stable dan menjalankan masalah:

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

Layanan tampaknya sehat b / c Ketersediaan menunjukkan "benar" di kubectl get apiservices | grep certmanager .

Setelah "memulai kembali" dengan kubectl delete apiservice v1beta1.admission.certmanager.k8s.io masalah hilang.

perbaikan digabungkan ke dalam cabang master, tetapi tidak digabungkan menjadi 3.0.0. Tambalan akan ada di 3.1.

Carilah yang TERSEDIA Salah

Jika Anda tidak membutuhkan API itu lagi, hapuslah:

kubectl menghapus 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 untuk windows.

Saya menduga ada kesalahan ketik dalam instruksi. Mungkin seharusnya begitu
kubectl delete apiservice (saya tidak ada dalam layanan)

Kami juga terkena perilaku tidak konsisten saat menghapus. Sebagai contoh

1. Kami mengarahkan pemasangan server metrik yang sengaja salah dikonfigurasi
   1a. sumber daya dibuat tetapi pod metrik-server berakhir dengan crashloopbackoff (diharapkan)
2. Kami mengarahkan penghapusan metrik-server
   2a. Kami mendapatkan kembali "Kesalahan: penginstalan selesai dengan 1 kesalahan: tidak bisa mendapatkan apiVersions dari Kubernetes: tidak bisa mendapatkan apiVersions dari Kubernetes: tidak dapat mengambil daftar lengkap API server: metrics.k8s.io/v1beta1: server sedang saat ini tidak dapat menangani permintaan "
   2b. Rahasia pelepasan helm telah dihapus
   2c. Semua sumber daya di bagan masih ada di kluster
   2d. Pembersihan manual diperlukan

Satu-satunya bagian dari "pencopotan pemasangan" yang telah diselesaikan adalah menghapus rahasia rilis.

Humas yang memperbaikinya ada di sini: https://github.com/helm/helm/pull/6908 Lihat diskusi tambahan seputar apakah masih ada satu kasus tambahan.

@di sini kita dapat melakukan backport perbaikan ini ke v2?

Jika ada yang tersedia untuk menguji perbaikan Helm 2, itu di sini: # 7196

@bacongobbler sesuai komentar Anda di sini https://github.com/helm/helm/issues/6361#issuecomment -554480815 tahukah Anda kapan v3.1 akan tersedia? Saya baru saja menginstal 3.0.1 dan saya masih mengalami masalah - saya terkejut perbaikan ini tidak berhasil menjadi v3.0.1 karena tampaknya menjadi masalah yang cukup luas. Adakah peluang untuk membuatnya menjadi rilis v3.0.x jika itu sebelum v3.1?

Pertanyaan yang sama seperti @mcginne . Saya telah menggunakan cabang master sebentar sekarang menunggu perbaikan ini masuk ke rilis. Tapi saya ingin kembali menjadi rilis. Bug ini membuat otomatisasi penulisan dengan helm cukup sulit (kecuali jika Anda hanya ingin mencoba keberuntungan dan membuat tidur dan pelayan di mana-mana).

Bahkan seperti 3.1alpha atau sesuatu akan menyenangkan :)

Menutup masalah ini, karena telah diselesaikan pada master

Satu kasus lagi:

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

Itu terkait dengan https://github.com/linkerd/linkerd2/issues/3497 , ketika layanan Linkerd memiliki beberapa masalah internal dan tidak dapat menanggapi kembali permintaan layanan API. Diperbaiki dengan memulai ulang podnya.

@ kivagant-ba maukah Anda membuka edisi baru untuk yang satu itu? Ini kasus yang sedikit berbeda, dan kita harus memutuskan perilaku yang "benar" di pihak Helm. Saya pikir perbaikan saat ini masih akan menganggap kesalahan fatal di atas.

Bagi siapa pun yang melakukan ini, ini disebabkan oleh layanan-api yang tidak lagi menjalankan backend ...

Dalam kasus saya itu adalah KEDA, tetapi ada sejumlah layanan berbeda yang memasang server API gabungan.

Untuk memperbaikinya:

kubectl get apiservice

Cari yang AVAILABLE adalah False

Jika Anda tidak membutuhkan API itu lagi, hapuslah:

kubectl delete apiservice <service-name>

Maka Helm akan bekerja dengan baik. Saya pikir memperbaiki pesan kesalahan Helm untuk kasus ini mungkin bermanfaat ...

Hanya koreksi kecil dalam ejaan "layanan". memperbaikinya.

maukah Anda membuka edisi baru untuk yang satu itu?

Ini bukan masalah bagi orang-orang yang menggunakan Linkerd versi terbaru. Saya meninggalkan komentar saya di sini bagi mereka yang akan mencari frase kesalahan karena terlihat mirip tetapi akar penyebabnya berbeda.

Oh! Baik. Terima kasih!

@technosophos apa perbaikan untuk ini? Haruskah kita grep kubectl get apiservice dan kemudian memblokir sampai semua layanan dalam status Ready ? Apakah ada hal lain yang bisa kami lakukan?

Kami sedang mengerjakan alat OSS yang memasang sejumlah bagan helm untuk mem-bootstrap sistem dan masalah ini tampaknya menyebabkan seluruh proses gagal sebentar-sebentar.

Saya baru saja menghadapi masalah ini dengan melakukan helm delete . Itu menyebabkan efek yang sangat buruk. Rilis Helm telah dihapus, tetapi semua objek K8 tetap berjalan di cluster. Jadi kami harus menghapus semuanya dengan tangan. Dan karena ini adalah operator, tindakan ini membutuhkan upaya yang signifikan.

@andrewnazarov Berikan informasi lebih lanjut tentang apa yang Anda coba hapus dan apa yang terjadi. Pesan kesalahan akan membantu, seperti versi Helm, versi Kube, dll.

@alexellis Apa sebenarnya yang menyebabkan masalah? Apakah Anda memasang bagan Helm yang memasang Layanan API dan bertanya-tanya bagaimana cara menunggu hingga tersedia? Jawaban singkatnya adalah Anda pasti perlu menyusun strategi untuk menunggu, atau mungkin memecahnya menjadi dua grafik. Kubernetes tidak memberi kita banyak perkakas untuk dapat menangani kesalahan pada API penemuan, tetapi jika deskripsi layanan tidak didukung oleh sebuah layanan, panggilan penemuan pasti akan gagal _dan tidak mengembalikan layanan_ di peta yang dikembalikannya.

Berikan lebih banyak informasi tentang apa yang Anda coba hapus dan apa yang terjadi. Pesan kesalahan akan membantu, seperti versi Helm, versi Kube, dll.

Tentu.

Helm: 3.0.0.0
K8s: 1.14.8

helm delete prom -n monitoring diakhiri dengan kesalahan berikut

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

Setelah itu, pelepasan helm menghilang dari daftar pelepasan Helm dan semua objek yang berhubungan dengan operator Prometheus menjadi yatim piatu.

Oke, saya mengerti, itu mungkin masalah versi. Akan mengupgrade Helm ke versi terbaru 3.0.2 secepatnya.

Ya, ini jelas merupakan masalah ketidakcocokan versi. Tambalan ini tersedia di 3.0.2. Di masa mendatang, pastikan untuk menguji dengan rilis patch terbaru (atau, lebih baik lagi, di master). Terima kasih!

Jika Anda mengalami masalah lebih lanjut, buka tiket baru.

kubectl get apiservice

Jika salah satu layanan "AVAILABLE = false", Anda dapat mencoba menghapus pod terkait untuk memulai ulang.
Ini memecahkan masalah saya dengan layanan kube-system / metrics.

Hai @techosophos. Mungkin saya melewatkan sesuatu, tetapi saya tidak melihat PR https://github.com/helm/helm/pull/6908/files ini di -porting ke 2.16.3, meskipun itu juga terjadi dengan helm 2. Apakah Anda merencanakan solusi ini di helm 2 juga?

Itu telah digabungkan menjadi dev-v2 beberapa bulan yang lalu. Anda dapat membangun dari cabang itu dan mengujinya jika Anda mau.

Akan sangat menyenangkan melihat ini dimasukkan ke dalam Helm 2 dan penyedia Terraform . Saya dapat melaporkan kesalahan ini setiap kali cluster dibuat.

Sudahkah Anda menguji cabang dev-v2 ? Saat ini kami tidak memiliki konfirmasi apa pun (selain pengujian kami sendiri) bahwa solusi di sana berfungsi, meskipun pada dasarnya adalah solusi yang sama.

Saya belum, saya bisa mencobanya minggu ini. Karena saya menggunakan ini dengan Terraform, dapatkah saya membangun / menjalankan dev-v2 branch dan menyetel variabel repositori sumber daya helm_release ke "local" untuk disimulasikan?

@bacongobbler Kami menghadapi masalah yang sama dengan prometheus-adapter yang mengekspos perangkat lunak kustom dan jika saya gagal merilis dengan perangkat lunak kustom dan kubectl get apiservice daftar ini akan TERSEDIA = helm palsu tidak lagi dapat membuat yang baru rilis meskipun tidak terkait dengan layanan aplikasi kustom:
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 dengan penyedia Terraform rusak karena masalah ini saat ini dan. Saya harap Anda juga dapat memberikan perbaikan untuk itu, sepertinya ini adalah kasus penggunaan yang umum.

Dapat mengonfirmasi bahwa saya juga mengalami masalah ini. Berharap untuk diperbaiki.

Larutan:

Langkah-langkah yang saya ikuti adalah:

1. kubectl get apiservices : Jika layanan metrik-server mati dengan kesalahan CrashLoopBackOff coba ikuti langkah 2 jika tidak coba mulai ulang layanan metrik-server menggunakan kubectl delete apiservice/"service_name" . Bagi saya itu v1beta1.metrics.k8s.io.

2. kubectl get pods -n kube-system dan menemukan bahwa pod seperti metrics-server, kubernetes-dashboard down karena pod coreDNS utama down.

Bagi saya itu adalah:

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

1. Gunakan kubectl describe pod/"pod_name" untuk memeriksa kesalahan di pod coreDNS dan jika tidak aktif karena / etc / coredns / Corefile: 10 - Kesalahan selama parsing: Proksi direktif tidak dikenal, maka kita perlu menggunakan maju alih-alih proxy di yaml file di mana konfigurasi coreDNS ada. Karena CoreDNS versi 1.5x yang digunakan oleh gambar tidak lagi mendukung kata kunci proxy.

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