成功最有效的方法就是向有经验的人学习!

在k8s集群中启用metrics server监控

概要

在apiserver中开启聚合层,这里我们使用一套独立的证书,在以往我使用的是apiserver证书,官方明确说了不要这样操作
kubernetes 集群资源监控之前可以通过 heapster 来获取数据,在 1.11 开始开始逐渐废弃 heapster 了,采用 metrics-server 来代替,metrics-server 是集群的核心监控数据的聚合器,它从 kubelet 公开的 Summary API 中采集指标信息,metrics-server 是扩展的 APIServer,依赖于kube-aggregator,因为我们需要在 APIServer 中开启相关参数。

引用官网的冲突说明

CA-重用和冲突
Kubernetes apiserver 有两个客户端 CA 选项:
–client-ca-file
–requestheader-client-ca-file
这些功能中的每个功能都是独立的;如果使用不正确,可能彼此冲突。
–client-ca-file:当请求到达 Kubernetes apiserver 时,如果启用了此选项,则 Kubernetes apiserver 会检查请求的证书。如果它是由 –client-ca-file 引用的文件中的 CA 证书之一签名的,并且用户是公用名CN=的值,而组是组织O= 的取值,则该请求被视为合法请求。请参阅 关于 TLS 身份验证的文档。
–requestheader-client-ca-file:当请求到达 Kubernetes apiserver 时,如果启用此选项,则 Kubernetes apiserver 会检查请求的证书。如果它是由文件引用中的 –requestheader-client-ca-file 所签署的 CA 证书之一签名的,则该请求将被视为潜在的合法请求。然后,Kubernetes apiserver 检查通用名称CN=是否是 –requestheader-allowed-names 提供的列表中的名称之一。如果名称允许,则请求被批准;如果不是,则请求被拒绝。
如果同时提供了 –client-ca-file 和–requestheader-client-ca-file,则首先检查 –requestheader-client-ca-file CA,然后再检查–client-ca-file。通常,这些选项中的每一个都使用不同的 CA(根 CA 或中间 CA)。常规客户端请求与 –client-ca-file 相匹配,而聚合请求与 –requestheader-client-ca-file 相匹配。但是,如果两者都使用同一个 CA,则通常会通过 –client-ca-file 传递的客户端请求将失败,因为 CA 将与 –requestheader-client-ca-file 中的 CA 匹配,但是通用名称 CN= 将不匹配 –requestheader-allowed-names 中可接受的通用名称之一。这可能导致您的 kubelet 和其他控制平面组件以及最终用户无法向 Kubernetes apiserver 认证。
因此,请对用于控制平面组件和最终用户鉴权的 –client-ca-file 选项和用于聚合 apiserver 鉴权的 –requestheader-client-ca-file 选项使用不同的 CA 证书。
警告: 除非您了解风险和保护 CA 用法的机制,否则 不要 重用在不同上下文中使用的 CA。
如果您未在运行 API 服务器的主机上运行 kube-proxy,则必须确保使用以下 kube-apiserver 标志启用系统:
–enable-aggregator-routing=true

OK,我们既然了解了为什么不要这样去操作,那我们在这里重新定义一套专用的证书

创建证书

创建 CA 配置文件

cat > aggregator-ca-config.json <<EOF
{
  "signing": {
    "default": {
      "expiry": "87600h"
    },
    "profiles": {
      "aggregator": {
        "usages": [
            "signing",
            "key encipherment",
            "server auth",
            "client auth"
        ],
        "expiry": "87600h"
      }
    }
  }
}
EOF

字段说明:

profiles : 可以定义多个 profiles,分别指定不同的过期时间、使用场景等参数;后续在签名证书时使用某个 profile。
signing :表示该证书可用于签名其它证书;生成的 aggregator-ca.pem 证书中 CA=TRUE。
server auth :表示 Client 可以用该 CA 对 Server 提供的证书进行验证。
client auth :表示 Server 可以用该 CA 对 Client 提供的证书进行验证。

创建 CA 证书签名请求

cat > aggregator-ca-csr.json <<EOF
{
  "CN": "aggregator",
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "CN",
      "ST": "Shanghai",
      "L": "Shanghai",
      "O": "k8s",
      "OU": "System"
    }
  ],
    "ca": {
       "expiry": "87600h"
    }
}
EOF

字段说明:

“CN” :Common Name,kube-apiserver 从证书中提取该字段作为请求的用户名 (User Name);浏览器使用该字段验证网站是否合法。
“O” :Organization,kube-apiserver 从证书中提取该字段作为请求用户所属的组 (Group);

生成 CA 证书和私钥

cfssl gencert -initca aggregator-ca-csr.json | cfssljson -bare aggregator-ca
ls aggregator-ca*
aggregator-ca-config.json  aggregator-ca.csr  aggregator-ca-csr.json  aggregator-ca-key.pem

创建 kubernetes 证书

创建 aggregator 证书签名请求文件

cat > aggregator-csr.json <<EOF
{
    "CN": "aggregator",
    "hosts": [
      "10.0.0.1",
      "172.0.0.1",
      "127.0.0.1",
      "10.0.0.101",
      "10.0.0.102",
      "10.0.0.103",
      "10.0.0.99",
      "10.0.0.98",
      "10.0.0.97",
      "10.0.0.90",
      "kubernetes",
      "kubernetes.default",
      "kubernetes.default.svc",
      "kubernetes.default.svc.cluster",
      "kubernetes.default.svc.cluster.local"
    ],
    "key": {
        "algo": "rsa",
        "size": 2048
    },
    "names": [
        {
            "C": "CN",
            "ST": "Shanghai",
            "L": "Shanghai",
            "O": "k8s",
            "OU": "System"
        }
    ]
}
EOF

如果 hosts 字段不为空则需要指定授权使用该证书的 IP 或域名列表,由于该证书后续被 etcd 集群和 kubernetes master 集群使用,所以上面分别指定了 etcd 集群、kubernetes master 集群的主机 IP 和 kubernetes 服务的服务 IP(一般是 kube-apiserver 指定的 service-cluster-ip-range 网段的第一个 IP,如 10.254.0.1)。
以上物理节点的 IP 也可以更换为主机名。

生成 aggregator 证书和私钥

cfssl gencert -ca=aggregator-ca.pem -ca-key=aggregator-ca-key.pem -config=aggregator-ca-config.json -profile=aggregator aggregator-csr.json | cfssljson -bare aggregator
ls aggregator*
aggregator.csr  aggregator-csr.json  aggregator-key.pem  aggregator.pem

分发证书

将生成的证书和秘钥文件(后缀名为.pem)拷贝到 Master 节点的 /opt/kubernetes/ssl 目录下。

cp *.pem /etc/kubernetes/ssl

开启聚合层 API

kube-apiserver 增加以下配置:

# 聚合层配置
您暂时无权查看此隐藏内容!

免单独生成证书的配置

您暂时无权查看此隐藏内容!

注意:

–requestheader-XXX、–proxy-client-XXX 是 kube-apiserver 的 aggregator layer 相关的配置参数,metrics-server & HPA 需要使用;
–requestheader-client-ca-file:用于签名 –proxy-client-cert-file 和 –proxy-client-key-file 指定的证书;在启用了 metric aggregator 时使用;
如果 —requestheader-allowed-names 不为空,则—proxy-client-cert-file 证书的 CN 必须位于 allowed-names 中,默认为 aggregator;

如果 kube-apiserver 机器没有运行 kube-proxy,则还需要添加 --enable-aggregator-routing=true 参数;
requestheader-client-ca-file 指定的 CA 证书,必须具有 client auth and server auth

有很多的文档都说在要做以下操作:
这里特别说明一下,现在新版本中不需要了,请要去多此一举,这个配置已经弃用。

kube-controller-manager

添加如下配置参数:

--horizontal-pod-autoscaler-use-rest-clients=true
用于配置 HPA 控制器使用 REST 客户端获取 metrics 数据

重启 kube-apiserver:

systemctl restart kube-apiserver

布署metrics server

下载yaml文件

kubectl apply -f metrics-server.yaml

注意:这里我修改了metrics-server的启动命令,增加了–kubelet-preferred-address-types=InternalIP和–kubelet-insecure-tls参数,否则metrics server可能会从kubelet拿不到监控数据。具体报错可以通过kubectl logs metrics-server-7875f8bf59-xzttf -n kube-system命令查看

如果部署集群的时候,CA 证书并没有把各个节点的 IP 签上去,所以这里 metrics-server 通过 IP 去请求时,提示签的证书没有对应的 IP(错误:x509: cannot validate certificate for 192.168.33.11 because it doesn’t contain any IP SANs),我们可以添加一个–kubelet-insecure-tls参数跳过证书校验

注意官方也提了生产环境中不建议开始证书跳过
那有的人可能就说我就不开启证书跳过,行不行呢?当然可以。而且也是官方推荐的生产环境的做法。
我们可以配置证书自动颁发,有兴趣的朋友可以咨询我。

验证metrics server

kubectl get --raw /apis/metrics.k8s.io/v1beta1/nodes
kubectl top node
NAME          CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%   
k8s-master    282m         14%    1159Mi          61%       
k8s-master2   244m         12%    745Mi           57%       
k8s-node1     161m         8%     398Mi           56%       
k8s-node2     156m         7%     430Mi           61%       
kubectl top pod -n kube-system
NAME                              CPU(cores)   MEMORY(bytes)   
coredns-5ffbfd976d-wrsrj          7m           20Mi            
kube-flannel-ds-6zjmg             4m           18Mi            
kube-flannel-ds-dzz9g             5m           16Mi            
kube-flannel-ds-r9hm6             5m           22Mi            
kube-flannel-ds-ss6f7             4m           22Mi            
kuboard-7986796cf8-m82bz          0m           6Mi             
metrics-server-7875f8bf59-xzttf   2m           30Mi
内容查看本文隐藏内容查看需要消耗6土豆币,请先
土豆币按需购买,不退换,请考虑清楚后购买。
赞(7) 打赏
未经允许不得转载:陈桂林博客 » 在k8s集群中启用metrics server监控
分享到

大佬们的评论 4

  1. #4

    写的好

    jeff3年前 (2022-01-16)回复
  2. #3

    写的不错

    一代伟人4年前 (2021-03-18)回复
  3. #2

    写的不错

    it码4年前 (2020-12-30)回复
  4. #1

    写的不错

    4年前 (2020-12-27)回复

全新“一站式”建站,高质量、高售后的一条龙服务

微信 抖音 支付宝 百度 头条 快手全平台打通信息流

橙子建站.极速智能建站8折购买虚拟主机

觉得文章有用就打赏一下文章作者

非常感谢你的打赏,我们将继续给力更多优质内容,让我们一起创建更加美好的网络世界!

支付宝扫一扫打赏

微信扫一扫打赏

登录

找回密码

注册