GKE - Metrics-Server - 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

我尝试按照其他人answers 的建议更改设置，但它们都不起作用。还有其他建议吗？

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，您将能够看到它更改了serviceAccount、Roles 等的默认GKE 配置。

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:
$

结论

如果您从metrics-server-v.0.4.1 部署YAML 中删除Readiness 和Liveness 探针，它将被部署并且pod 将处于Running 状态，但是强烈不推荐 . 它可能会干扰您将来在集群上的工作或导致一些意外情况。

如果您想使用最新的metrics-server 版本，您应该使用Kubeadm 和Google Compute Engine。

作为附加信息，您可以在Public Issue Tracker 上发送Feature Request 以在GKE 上使用最新的metrics-server-v0.4.1。你可以做到here