Helm: 无法检索服务器API的完整列表

我在AKS上遇到了同样的问题，尽管错误消息是

错误：无法从Kubernetes获取apiVersions：无法检索服务器API的完整列表：metrics.k8s.io/v1beta1：服务器当前无法处理该请求

我的配置：

• kubectl版本：

客户端版本：version.Info {主要：“ 1”，次要：“ 15”，GitVersion：“ v1.15.2”，GitCommit：“ f6278300bebbb750328ac16ee6dd3aa7d3549568”，GitTreeState：“ clean”，BuildDate：“ 2019-08-05T09：23： 26Z“，GoVersion：” go1.12.5“，编译器：” gc“，平台：” windows / amd64“}
服务器版本：version.Info {主要：“ 1”，次要：“ 14”，GitVersion：“ v1.14.6”，GitCommit：“ 96fac5cd13a5dc064f7d9f4f23030a6aeface6cc”，GitTreeState：“ clean”，BuildDate：“ 2019-08-19T11：05： 16Z“，GoVersion：” go1.12.9“，编译器：” gc“，平台：” linux / amd64“}

• 头盔版本：alpine / helm：3.0.0-beta.2 （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出于兴趣，您是否在AWS上使用knative？ 因为我看不到tekton对象，所以它看起来实际上不是

我本人刚刚看过这个问题。 以我为例，是由证书管理器触发的问题。 仍在研究如何使其恢复原状。

@ planetf1我没有使用knative（或者我认为我没有使用），但是问题仅存在于我为此测试部署的新群集上。
工作群集和不工作群集之间的区别是：

| |工作|不工作|
| --- | --- | --- ||
| kube版本| 1.13.5 | 1.14.6 |
| azure AD身份验证|已禁用|已启用|
| RBAC |禁用|启用|

所以我有一些重大变化。

对我来说，问题是helm3崩溃是由于缺少对某些API的访问权限，而这些API并未用于我要部署的图表。

我在k8群集版本1.13.9上使用它，部署任何稳定的图表时都会出现相同的错误。

头盔版本
version.BuildInfo {版本：“ v3.0.0-beta.3”，GitCommit：“ 5cb923eecbe80d1ad76399aee234717c11931d9a”，GitTreeState：“ clean”，GoVersion：“ go1.12.9”}

helm.go：81：[调试]无法检索服务器API的完整列表：metrics.k8s.io/v1beta1：服务器当前无法处理该请求。

从指标pod解决问题之后（不记得我是如何解决的，我认为这可能与hostNetwork有关，或者只是重新启动关联的pod）helm3功能符合预期。
因此，这可能是一个“功能”，因为它迫使群集保持良好的健康状态，但是每次api中断时，都需要有人手动进入群集（因此可能会阻止使用helm3部署能够列出的Pod在此）。

当初使用Kubernetes的人真的很烦。 我正在尝试使用acme推出证书的解决方案，因为我无法保证即使配置了证书管理器也不会损坏它。

真正令人烦恼的部分是，我不能只使用掌舵来卸载证书管理器并回到原来的状态！ 任何强烈推荐的服务都可以破坏它，并且不会撤消更改的东西都将被破坏。

对于任何遇到这种情况的人来说，这都是由不再运行后端的api服务引起的。

在我的情况下是KEDA，但是有许多不同的服务可安装聚合的API服务器。

要解决这个问题：

kubectl get apiservice

寻找那些AVAILABLE是False

如果您不再需要这些API，请删除它们：

kubectl delete apiservce <service-name>

然后，头盔应该可以正常工作。 我认为针对这种情况改善Helm错误消息可能是值得的...

感谢您的解释-Helm是否也可以采用这种方式进行编码？

我们是这样认为的，尽管我们仍在调查中。 我的第一眼建议是，这与我们使用Discovery API有关，该API用于模板渲染中的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功能并且如果任何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可用。 可能是我们对该服务存在暂时性问题，但是在几乎相同的群集上运行头盔2.14.3确实可以可靠地工作。

尝试在统计图CI群集上升级到Helm 2.15.2时遇到此问题。 因此，这不仅是Helm 3的问题。 删除缺少的API服务即可对其进行修复。 我想知道Helm是否在这里会更优雅一些，尤其是因为这可能随时会弹出。

在安装kubeadm的集群上安装稳定/度量服务器图表时遇到类似的问题。

当您尝试卸载图表时，由于api服务器错误而导致卸载失败（因为metrics服务器是fubar），并且留下了大量的悬挂资源，您必须手工清理它们-因为helm已经删除了发行版反正从它的数据库。

$ 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在您的情况下，是否仅在首次创建集群时才发生？

该问题在Kubernetes Go发现客户端中很深。 我正在尝试仅打印警告。 但是，这可能会对严重依赖Capabilities对象的图表产生负面影响。

您的情况是否仅在首次创建集群时才发生？

是的。 我有一个脚本，可以创建集群，安装Tiller并创建Helm版本。 因此，这似乎是集群初始化中的竞争条件。

我昨天进行的@jglick实现很可能会为您避免该问题，除非您编写的图表直接引用了有问题的API组。

@technosophos感谢您的合并。 我确实认为这将提高头盔的弹性。

我们是否有针对2.15 / 2.16的修复程序？

在2.16中也可以看到这一点。 GKE Master版本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遇到了heapster和metric-server的问题。 这就是导致头盔​​故障的原因，并解释了为何有时无法正常工作。

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

api服务似乎很健康，因为Availabiliy在kubectl get apiservices | grep certmanager显示“ true”。

用kubectl delete apiservice v1beta1.admission.certmanager.k8s.io “重新启动”后，问题消失了。

该修复程序已合并到master分支中，但未合并到3.0.0中。 该补丁将在3.1中发布。

寻找那些可用的是假的

如果您不再需要这些API，请删除它们：

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，适用于Windows的dokcer。

我猜想说明中有错别字。 大概应该是
kubectl delete apiservice （在服务中缺少i）

删除操作中的不一致行为也会给我们带来打击。 例如

1. 我们掌舵故意安装错误配置的指标服务器
   1a。 资源已创建，但metrics-server pod最终以crashloopbackoff（预期）
2. 我们掌控删除指标服务器
   2a。 我们返回“错误：卸载完成，出现1个错误：无法从Kubernetes获得apiVersions：无法从Kubernetes获得apiVersions：无法检索服务器API的完整列表：metrics.k8s.io/v1beta1：服务器为当前无法处理该请求”
   2b。 头盔释放秘密已被移除
   2c。 图表中的所有资源仍然存在于群集中
   2d。 手动清理是必要的

完成的“卸载”的唯一部分是删除发行密钥。

修复此问题的PR在这里： https :

@在这里我们可以将该修补程序

如果有人可以测试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相同的问题。 我一直在使用master分支，等待此修复程序发布。 但我想回到发布状态。 此错误使使用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服务请求。 通过重新启动其pod进行修复。

@ kivagant-ba您介意为此开一个新书吗？ 情况稍有不同，我们必须决定在Helm方面应该采取的“正确”行为。 我认为当前的修补程序仍将上述错误视为致命错误。

对于任何遇到这种情况的人来说，这都是由不再运行后端的api服务引起的。

在我的情况下是KEDA，但是有许多不同的服务可安装聚合的API服务器。

要解决这个问题：

kubectl get apiservice

寻找那些AVAILABLE是False

如果您不再需要这些API，请删除它们：

kubectl delete apiservice <service-name>

然后，头盔应该可以正常工作。 我认为针对这种情况改善Helm错误消息可能是值得的...

只是对“服务”的拼写进行了小的更正。 更正它。

您介意为此开一个新书吗？

对于使用较新版本的Linkerd的人来说，这不是问题。 我在这里给那些会搜索错误短语的人留下了我的评论，因为它看起来很相似，但根本原因却不同。

哦！ 好的。 谢谢！

@technosophos的解决方法是什么？ 我们是否应该grep kubectl get apiservice然后阻塞直到所有服务都处于Ready状态？ 还有其他我们可以做的事情吗？

我们正在使用OSS工具，该工具安装了多个Helm图表以引导系统，此问题似乎正在导致整个过程间歇性地失败。

我刚刚在执行helm delete遇到了这个问题。 这造成了非常不好的影响。 Helm版本已删除，但所有K8s对象仍在群集中运行。 因此，我们必须手动删除所有内容。 由于是操作员，因此需要付出很大的努力。

@andrewnazarov请提供有关您尝试删除的内容以及发生的情况的更多信息。 错误消息会有所帮助，Helm版本，Kube版本等也会有所帮助。

@alexellis到底是什么引起了问题？ 您是否正在安装可安装API服务的Helm图表，并且想知道如何等待它可用？ 简短的答案是，您肯定需要设计一种策略来等待，或者可能将其分成两个图表。 Kubernetes并没有提供很多工具来处理发现API上的错误，但是如果服务描述没有得到服务的支持，发现调用肯定会失败_并且不会在返回的映射中返回service_。

请提供有关您尝试删除的内容和发生的情况的更多信息。 错误消息会有所帮助，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

如果服务之一“ AVAILABLE = false”，则可以尝试删除相关的Pod以重新启动它们。
它使用kube-system / metrics服务解决了我的问题。

嗨@technosophos。 可能是我错过了一些东西，但是我看不到将此PR https://github.com/helm/helm/pull/6908/files移植到2.16.3，尽管它也发生在头盔2中。 您是否也在计划将这种变通方法移植到头盔2中？

它在几个月前合并到dev-v2 。 您可以从该分支进行构建，并根据需要对其进行测试。

很高兴看到这被合并到Helm 2和

您是否测试了dev-v2分支？ 尽管实际上是相同的解决方案，但我们目前没有任何确认（除了我们自己的测试以外）该解决方案有效。

我还没有，我可以在这个星期尝试一下。 由于我将其与Terraform一起使用，可以构建/运行dev-v2分支并将helm_release资源的存储库变量设置为"local"进行模拟吗？

@bacongobbler我们遇到了与prometheus-adapter相同的问题，该问题公开了自定义apiservice，如果我使用自定义apiservice和kubectl get apiservice发布失败，则此列表中的任何一个都将变为AVAILABLE = false helm，不再能够进行任何新的更改即使与自定义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并发现诸如metrics-server，kubernetes-dashboard之类的pod已关闭，因为主要的coreDNS pod已关闭。

对我来说是：

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而导致错误Yaml中使用forward而不是proxy coreDNS配置所在的文件。 因为映像使用的CoreDNS版本1.5x不再支持proxy关键字。

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