GKE - 指标服务器 - HTTP 探测失败，状态代码：500

Question

它工作了一段时间，然后就崩溃了

CrashLoopBackOff

。当它偶尔工作时，我会收到

Unauthorized

错误。 5到10分钟后，它崩溃了。

Error from server (InternalError): an error on the server ("Internal Server Error: \"/apis/metrics.k8s.io/v1beta1/nodes\": Unauthorized") has prevented the request from succeeding (get nodes.metrics.k8s.io)

我正在使用最新版本的 metric-server。

Events:
  Type     Reason     Age                   From               Message
  ----     ------     ----                  ----               -------
  Normal   Scheduled  27m                   default-scheduler  Successfully assigned kube-system/metrics-server-59ff97d56-xjbh4 to gke-test-test-node-pool-05539c92-26z1
  Normal   Created    20m (x3 over 27m)     kubelet            Created container metrics-server
  Normal   Started    20m (x3 over 27m)     kubelet            Started container metrics-server
  Warning  Unhealthy  20m (x7 over 21m)     kubelet            Liveness probe failed: HTTP probe failed with statuscode: 500
  Warning  Unhealthy  20m (x8 over 21m)     kubelet            Readiness probe failed: HTTP probe failed with statuscode: 500
  Normal   Killing    12m (x8 over 20m)     kubelet            Container metrics-server failed liveness probe, will be restarted
  Normal   Pulled     7m19s (x9 over 27m)   kubelet            Container image "k8s.gcr.io/metrics-server/metrics-server:v0.4.1" already present on machine
  Warning  BackOff    2m15s (x71 over 18m)  kubelet            Back-off restarting failed container

我尝试按照其他人答案的建议更改设置，但没有一个起作用。还有其他建议吗？

135a136,137
>         - --kubelet-insecure-tls
>         - --kubelet-preferred-address-types=InternalIP
151a154
>           initialDelaySeconds: 300

Answer 1

由于 OP 没有提供更多信息，我运行了多个场景，并且能够重现此行为。

背景

OP 希望使用最新的

metrics-server

版本

0.4.1

- k8s.gcr.io/metrics-server/metrics-server:v0.4.1.

请记住，Google Kubernetes Engine是特殊的

Google Cloud Platform

产品，它与其他

GCP

功能集成。这意味着除了开源

Kubernetes

实现之外，它还具有一些特定的配置和依赖项（在开源 k8s 中不可用），这使得使用这些功能更容易（例如。

Stackdriver

）。

与构建在

Google Compute Engine

之上的 Kubernetes 集群不同，

GKE

完全由

Google

管理。

根本原因

所有

GKE

版本（稳定、快速通道、静态版本）都使用

metrics-server-v0.3.6

，因为它与其他

GCP

功能集成。

如果您要部署最新的

metrics-server v.0.4.1

，您将能够看到它更改了

GKE

、

serviceAccount

等的默认

Roles

配置。

clusterrole.rbac.authorization.k8s.io/system:aggregated-metrics-reader created
clusterrole.rbac.authorization.k8s.io/system:metrics-server configured
rolebinding.rbac.authorization.k8s.io/metrics-server-auth-reader configured
clusterrolebinding.rbac.authorization.k8s.io/metrics-server:system:auth-delegator configured
clusterrolebinding.rbac.authorization.k8s.io/system:metrics-server configured
service/metrics-server configured
deployment.apps/metrics-server created
apiservice.apiregistration.k8s.io/v1beta1.metrics.k8s.io configured

重新配置这些资源后，您可能会遇到一些

Unauthorized

错误。

另一个问题是新版本设置了

Readiness

和

Liviness

探针。

$ kubectl describe po metrics-server-59ff97d56-mp2v2 -n kube-system | grep Liveness:
    Liveness:       http-get https://:https/livez delay=0s timeout=1s period=10s #success=1 #failure=3
$ kubectl describe po metrics-server-59ff97d56-mp2v2 -n kube-system | grep Readiness:
    Readiness:      http-get https://:https/readyz delay=0s timeout=1s period=10s #success=1 #failure=3
$ kubectl describe po metrics-server-v0.3.6-64655c969-jd5gj -n kube-system | grep Liveness:
$ kubectl describe po metrics-server-v0.3.6-64655c969-jd5gj -n kube-system | grep Readiness:
$

结论

如果您从

Readiness

部署中删除

Liveness

和

metrics-server-v.0.4.1

探针，

YAML

它将被部署并且pod将处于

Running

状态，但是强烈不建议。 它可能会干扰您集群将来的工作或导致一些意外情况。

如果您想使用最新的

metrics-server

版本，您应该将

Kubeadm

与 Google Compute Engine 一起使用。

作为附加信息，您可以在

Feature Request

上升起

Public Issue Tracker

以使用

metrics-server-v0.4.1

上的最新

GKE

。你可以做到这里