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

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

CrashLoopBackOff

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

未经授权的
错误。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

由于OP没有提供进一步的信息，我已经运行了多个场景，并且我能够重现这种行为

背景
OP希望使用最新的
metrics server
版本
0.4.1
-

请记住，这是一种特殊的
谷歌云平台
产品，它与其他
GCP
功能集成在一起。这意味着，除了是开源的Kubernetes实现之外，它还具有一些特定的配置和依赖项（在开源k8s中不可用），这使得使用这些功能更加容易（例如，
Stackdriver
）

与建立在
googlecomputeengine
之上的kubernetes集群不同，
GKE
完全由
Google
管理

根本原因
所有
GKE
版本（稳定、快速通道、静态版本）都在使用
metrics-server-v0.3.6
，因为它与其他
GCP
功能集成在一起

如果您将部署最新的
metrics服务器v.0.4.1
，您将能够看到它更改了
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

在重新配置这些资源时，可能会出现一些
未经授权的
错误

另一个问题是新版本设置了
准备就绪
和
活力
探头

$ 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
deployment
YAML
中删除
Readiness
和
Liveness
探测器，它将被部署，pod将处于
运行
状态，但是强烈建议不要这样做。
它可能会干扰将来在集群上的工作，或导致一些意外情况

如果您想使用最新的
metrics服务器
版本，则应使用
Kubeadm
with

作为附加信息，您可以在
公共问题跟踪器
上提出
功能请求
，以使用
GKE
上最新的
metrics-server-v0.4.1
。你可以这样做
你的GKE版本是什么？你最近在集群上做了什么改变吗？您是否更改了默认度量服务器参数？您使用的是什么GKE版本？您是否进行过任何升级？您可以提供metrics pod的日志吗？只是为了说明您正在使用
谷歌Kubernetes引擎
，或者您已经使用
谷歌云虚拟机
创建了Kubeadm集群？