Helm: サーバーAPIの完全なリストを取得できません

エラーメッセージは次のとおりですが、AKSでも同じ問題が発生します

エラー：KubernetesからapiVersionsを取得できませんでした：サーバーAPIの完全なリストを取得できません：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 "}

• ヘルムバージョン：アルパイン/ヘルム：3.0.0-beta.2 （ドッカー）

• kubectlapi-リソース
  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興味がないので、AWSでknativeを使用していますか？ テクトンオブジェクトが見えないので実際には見えません

私はこの問題を自分で見たばかりです。 私の場合、問題を引き起こしたのはcert-managerでした。 それを元の状態に戻す方法にまだ取り組んでいます。

@ planetf1 knativeを使用していません（または使用していないと思います）が、このテスト用にデプロイした新しいクラスターにのみ問題が存在します。
動作しているクラスターと動作していないクラスターの違いは次のとおりです。

| |機能している|機能していない|
| --- | --- | --- |
|久部版| 1.13.5 | 1.14.6 |
| AzureAD認証|無効|有効|
| RBAC |無効|有効|

だから私はいくつかの大きな変更があります。

私にとって問題は、デプロイしようとしているチャートに使用されていない一部のAPIにアクセスできないために、helm3がクラッシュすることです。

k8クラスターバージョン1.13.9で使用していますが、安定したチャートをデプロイするときに同じエラーが発生します。

ヘルムバージョン
version.BuildInfo {Version： "v3.0.0-beta.3"、GitCommit： "5cb923eecbe80d1ad76399aee234717c11931d9a"、GitTreeState： "clean"、GoVersion： "go1.12.9"}

helm.go：81：[デバッグ]サーバーAPIの完全なリストを取得できません：metrics.k8s.io/v1beta1：サーバーは現在リクエストを処理できません。

メトリックポッドから問題を解決した後（どのように解決したか思い出せません。hostNetworkまたは単に関連するポッドを再起動する必要があると思います）helm3は期待どおりに機能します。
したがって、クラスターを正常な状態に維持することを強制するため、これは「機能」である可能性がありますが、APIが中断するたびに、誰かが手動でクラスターに入る必要があります（したがって、helm3を使用してリスト可能なポッドをデプロイできなくなる可能性がありますこれについて）。

Kubernetesを使い始めた人にとって、それは本当に、本当に迷惑です。 acmeを使用して証明書のソリューションを手作業で作成しています。これは、証明書マネージャーを構成した後でも壊れないことを保証できないためです。

本当に厄介なのは、ヘルムを使用して証明書マネージャーをアンインストールし、元の場所に戻ることができないことです。 強く推奨されるサービスがそれを破ることを可能にし、変更を元に戻さないものはすべて破られます。

これにぶつかった人にとっては、バックエンドが実行されなくなったapiサービスが原因です...

私の場合はKEDAでしたが、集約されたAPIサーバーをインストールするさまざまなサービスがいくつかあります。

それを修正するには：

kubectl get apiservice

AVAILABLEがFalseであるものを探してください

これらのAPIが不要になった場合は、以下を削除してください。

kubectl delete apiservce <service-name>

その後、ヘルムは正しく動作するはずです。 この場合のヘルムエラーメッセージを改善することは価値があると思います...

説明をありがとう-Helmがこれを回避する方法もありますか？

まだ調査中ですが、そう思います。 私の最初の見た目は、これがテンプレートレンダリングのCapabilitiesオブジェクトに使用されるDiscoveryAPIの使用に関連していることを示唆しています。 この特定のエラーをトラップして、失敗する代わりにユーザーに警告できる場合があります。

今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も影響を受けていることをs / oで確認できますか？ 次に、このチケットのラベルを調整することをお勧めします。

@sjentzsch Helm 2.15.0とk8s 1.16.0を使用しても同じことがわかります。

これが2.xにも影響する場合は、「cert-manager」（おそらく事前構成のみ）を使用しているすべての人が悪い時間を過ごすことになります。

__ここでは、ヘルム側から同じ動作をする2つの異なるケースがあります。
2.15.1 3 betaバージョンと

@technosophosが述べたように、helmは検出API機能を使用し、API応答のいずれかが失敗すると失敗しますhttps://github.com/helm/helm/blob/f1dc84773f9a34fe59a504fdb32428ce1d56a2e8/pkg/action/action.go#L105 -L118

1. cert-managerの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. ヘルムがどのAPIサービスからも応答を取得できない場合の失敗の別のケース
   例：「metrics.k8s.io / v1beta1：サーバーは現在リクエストを処理できません」これはケースバイケースで発生します

現在、それは生きていて実行されていますが、舵の要求の間に偶然にダウンしました。

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

ヘルムはそのようなタイプの問題に対してより堅牢でなければならないと確信しています、
1）エラーを警告に変換することをお勧めします（テンプレートのレンダリング中にAPIサービスからの情報がどのように使用されるかわかりません）
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をリストします。 このサービスに一時的な問題がある可能性がありますが、ほとんど同じクラスター上のhelm2.14.3は確実に機能します。

チャートCIクラスターでHelm2.15.2にアップグレードしようとすると、この問題が発生します。 つまり、Helm3の問題だけではありません。 不足しているAPIサービスを削除すると修正されました。 ヘルムがここでもっと優雅になるのではないかと思います。特に、これはいつでも再び現れる可能性があるからです。

kubeadmがインストールされたクラスターにstable / metrics-serverチャートをインストールする場合にも同様の問題が発生します。

チャートをアンインストールしようとすると、アンインストールはapi-serverエラーで失敗し（メトリックサーバーはfubarであるため）、ヘルムがリリースを削除したため、手作業でクリーンアップする必要があるぶら下がっているリソースの負荷が残りますとにかくそのデータベースから。

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

2.15.1を使用して、新しく作成されたGKEクラスターでこれをヒットし始めました（最近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あなたの場合、クラスターが最初に作成されたときにのみ発生しますか？

問題は、KubernetesGo検出クライアントの奥深くにあります。 警告を出力するだけで実験しています。 ただし、これは、Capabilitiesオブジェクトに大きく依存するグラフに悪影響を与える可能性があります。

あなたの場合、それはクラスターが最初に作成されたときにのみ発生しますか？

はい。 クラスターを作成し、Tillerをインストールし、Helmリリースを作成するスクリプトがあります。 したがって、クラスター初期化の競合状態のようです。

@jglick昨日行った実装では、問題のAPIグループを直接参照するグラフを作成していない限り、問題を回避できる可能性が非常に高くなります。

@technosophosはそのマージに感謝します。 舵の弾力性が向上すると思います。

2.15 / 2.16の修正はありますか？

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の修正は提供されていません。 Helm 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

私はhelm3.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は、Availabiliyがkubectl get apiservices | grep certmanagerで「true」を示していたため、正常であるように見えました。

kubectl delete apiservice v1beta1.admission.certmanager.k8s.io 「再起動」した後、問題は解決しました。

修正はmasterブランチにマージされましたが、3.0.0にはマージされませんでした。 パッチは3.1になります。

AVAILABLEがFalseのものを探してください

これらのAPIが不要になった場合は、以下を削除してください。

kubectl delete 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、Windows用のdokcer。

説明書にタイプミスがあったと思います。 おそらく
kubectl delete apiservice （サービス中のiがありません）

また、削除時の一貫性のない動作にも見舞われます。 例えば

1. 意図的に誤って構成されたメトリックサーバーをインストールします
   1a。 リソースは作成されますが、メトリック-サーバーポッドはcrashloopbackoffになります（予想）
2. メトリックスサーバーを削除します
   2a。 「エラー：アンインストールが1つのエラーで完了しました：KubernetesからapiVersionsを取得できませんでした：KubernetesからapiVersionsを取得できませんでした：サーバーAPIの完全なリストを取得できません：metrics.k8s.io/v1beta1：サーバーは現在、リクエストを処理できません」
   2b。 ヘルムリリースシークレットが削除されました
   2c。 チャート内のすべてのリソースはまだクラスター内に存在します
   2d。 手動のクリーンアップが必要です

完了した「アンインストール」の唯一の部分は、リリースシークレットの削除でした。

これを修正したPRはここにありました： https ：

@ここで、この修正をv2にバックポートできますか？

Helm 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解決されたため、この問題を解決します

もう1つのケース：

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

Linkerdサービスに内部的な問題があり、APIサービス要求に応答できなかったとき、これはhttps://github.com/linkerd/linkerd2/issues/3497に関連していました。 ポッドを再起動することで修正されました。

@ kivagant-baその問題の新しい問題を開いていただけませんか？ これは少し異なるケースであり、Helm側の「正しい」動作を決定する必要があります。 現在の修正では、上記の致命的なエラーが引き続き考慮されると思います。

これにぶつかった人にとっては、バックエンドが実行されなくなったapiサービスが原因です...

私の場合はKEDAでしたが、集約されたAPIサーバーをインストールするさまざまなサービスがいくつかあります。

それを修正するには：

kubectl get apiservice

AVAILABLEがFalseであるものを探してください

これらのAPIが不要になった場合は、以下を削除してください。

kubectl delete apiservice <service-name>

その後、ヘルムは正しく動作するはずです。 この場合のヘルムエラーメッセージを改善することは価値があると思います...

「サービス」のスペルのほんの少しの修正。 修正しました。

その号の新しい号を開いていただけませんか。

Linkerdの新しいバージョンを使用している人にとっては問題ではありません。 エラーフレーズは似ているように見えますが、根本的な原因が異なるため、エラーフレーズを検索する人のためにここにコメントを残しました。

ああ！ はい。 ありがとうございました！

@technosophosこれの修正は何ですか？ kubectl get apiserviceをgrepしてから、すべてのサービスがReady状態になるまでブロックする必要がありますか？ 代わりに他にできることはありますか？

システムをブートストラップするために多数のヘルムチャートをインストールするOSSツールに取り組んでいますが、この問題が原因でプロセス全体が断続的に失敗しているようです。

helm delete実行しているときにこの問題に直面しました。 それは非常に悪い影響を引き起こしました。 Helmリリースは削除されましたが、すべてのK8sオブジェクトはクラスター内で実行され続けました。 そのため、すべてを手作業で削除する必要がありました。 そしてそれはオペレーターだったので、この行動はかなりの努力を必要としました。

@andrewnazarov削除しようとしたものと何が起こったのかについての詳細を提供してください。 Helmバージョン、Kubeバージョンなどと同様に、エラーメッセージが役立ちます。

@alexellis正確には、何が問題を引き起こしていますか？ APIサービスをインストールするHelmチャートをインストールしていて、それが利用可能になるまでどのように待つのか疑問に思っていますか？ 簡単に言えば、待つ戦略を考案する必要があるか、場合によっては2つのチャートに分割する必要があるということです。 Kubernetesは、検出APIのエラーを処理するためのツールをあまり提供していませんが、サービスの説明がサービスによってサポートされていない場合、検出呼び出しは間違いなく失敗し、返されるマップでサービスを返しません。

何を削除しようとしたのか、何が起こったのかについて詳しく教えてください。 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リリースはHelmリリースのリストから消え、そのPrometheusオペレーターに関連するすべてのオブジェクトが孤立しました。

はい、バージョンの問題である可能性があります。 Helmをできるだけ早く最新バージョン3.0.2にアップグレードします。

はい、これは間違いなくバージョンの不一致の問題です。 このパッチは3.0.2で利用可能になりました。 将来的には、必ず最新のパッチリリースでテストしてください（または、さらに良いことに、マスターでテストしてください）。 ありがとう！

さらに問題が発生した場合は、新しいチケットを開いてください。

kubectl get apiservice

サービスの1つが「AVAILABLE = false」の場合、関連するポッドを削除して再起動することができます。
kube-system / metricsサービスの問題は解決しました。

こんにちは@technosophos。 何かが足りないかもしれませんが、ヘルム2でも発生しますが、このPRhttps

数か月前にdev-v2マージされました。 そのブランチからビルドして、必要に応じてテストすることができます。

これがHelm2とです。 クラスターが作成されるたびに、このエラーを報告することができます。

dev-v2ブランチをテストしましたか？ 本質的には同じソリューションですが、現在、そこでのソリューションが機能することを確認することはできません（独自のテストを除く）。

今週は試してみることができます。 これをTerraformで使用しているので、 dev-v2ブランチをビルド/実行し、helm_releaseリソースのリポジトリ変数を"local"してシミュレートできますか？

@bacongobblerカスタムapiserviceを公開するprometheus-adapterで同じ問題に直面し、カスタムapiserviceとkubectl get apiserviceリリースに失敗した場合、このリストのいずれかがAVAILABLE = falsehelmで新しいものを作成できなくなりますカスタム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プロバイダーのHelm2が壊れています。 修正も提供できるといいのですが、これは一般的なユースケースのようです。

私もこの問題を抱えていることを確認できます。 修正を期待しています。

解決：

私が従った手順は次のとおりです。

1. kubectl get apiservices ：メトリックサーバーサービスがエラーCrashLoopBackOffでダウンしている場合は、手順2に従ってください。それ以外の場合は、 kubectl delete apiservice/"service_name"を使用してメトリックサーバーサービスを再起動してください。 私にとってはv1beta1.metrics.k8s.ioでした。

2. kubectl get pods -n kube-systemで、メインのcoreDNSポッドがダウンしたため、metrics-server、kubernetes-dashboardなどのポッドがダウンしていることがわかりました。

私にとってそれは：

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

1. kubectl describe pod/"pod_name"を使用してcoreDNSポッドのエラーを確認し、/ etc / coredns / Corefile：10が原因でダウンしている場合-解析中のエラー：不明なディレクティブプロキシ、yamlでプロキシの代わりにforwardを使用する必要がありますcoreDNS構成が存在するファイル。 イメージで使用されるCoreDNSバージョン1.5xは、proxyキーワードをサポートしなくなったためです。

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