kubernetes GKE - Metrics-Server - HTTP探测失败,状态代码为:500

kdfy810k  于 2022-11-02  发布在  Kubernetes
关注(0)|答案(1)|浏览(212)

它工作了一段时间,然后崩溃了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服务器。

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
js81xvg6

js81xvg61#

由于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,您将能够看到它更改了serviceAccountRoles等的默认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错误。
另一个问题是,新版本设置了ReadinessLiviness探测器。

$ 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中删除ReadinessLiveness探测器,则会部署YAML,并且单元将处于Running状态,但是强烈建议不要这样做。这可能会干扰将来在群集上的工作,或导致某些意外情况。
如果您想使用最新的metrics-server版本,您应该使用KubeadmGoogle Compute Engine
作为附加信息,您可以在Public Issue Tracker上提升Feature Request,以便在GKE上使用最新的metrics-server-v0.4.1。您可以在here上执行此操作

相关问题