更多奇技淫巧欢迎订阅博客:https://fuckcloudnative.io
前言
系统环境:
部署方式:二进制
Docker 版本:19.03.8
kubernetes 版本:1.20.1
操作系统版本:CentOS 7.8
metrics server 版本:0.4.1
参考地址:
带你玩转 kubernetes-k8s 第 54 篇[1]
二进制方式搭建 Kubernetes 1.19.3 高可用集群(五)部署 dashboard[2]
通过二进制方式部署完成 kubernetes
后,部署 Metrics Server
后,查看日志出现下面错误信息:
E1231 10:33:31.978715 1 configmap_cafile_content.go:243] key failed with:
missing content for CA bundle "client-ca::kube-system::extension-apiserver-authentication::requestheader-client-ca-file"
E1231 10:34:22.710836 1 configmap_cafile_content.go:243] kube-system/extension-apiserver-authentication failed with:
missing content for CA bundle "client-ca::kube-system::extension-apiserver-authentication::requestheader-client-ca-file"
E1231 10:34:31.978769 1 configmap_cafile_content.go:243] key failed with:
missing content for CA bundle "client-ca::kube-system::extension-apiserver-authentication::requestheader-client-ca-file"
根据错误日志信息,可以知道是缺少认证的证书文件,导致不能访问 kube-apiserver
而出现的问题。
经过网上查找搜寻,从一篇博客中 https://www.lingjie.tech/article/2020-11-07/20 找到答案。之所以出现这个错误是因为 kube-apiserver 没有开启 API
聚合功能。所以需要配置 kube-apiserver
参数,开启聚合功能即可。
这里的 API 聚合机制
是 Kubernetes 1.7 版本引入的特性,能够将用户扩展的 API
注册到 kube-apiserver
上,仍然通过 API Server
的 HTTP URL
对新的 API
进行访问和操作。为了实现这个机制,Kubernetes 在 kube-apiserver
服务中引入了一个 API 聚合层(API Aggregation Layer)
,用于将 扩展 API
的访问请求转发到用户服务的功能。
为了能够将用户自定义的 API 注册到 Master
的 API Server
中,首先需要在 Master 节点所在服务器,配置 kube-apiserver
应用的启动参数来启用 API 聚合
功能,参数如下:
--runtime-config=api/all=true
--requestheader-allowed-names=aggregator
--requestheader-group-headers=X-Remote-Group
--requestheader-username-headers=X-Remote-User
--requestheader-extra-headers-prefix=X-Remote-Extra-
--requestheader-client-ca-file=/etc/kubernetes/pki/ca.pem
--proxy-client-cert-file=/etc/kubernetes/pki/proxy-client.pem
--proxy-client-key-file=/etc/kubernetes/pki/proxy-client-key.pem
如果 kube-apiserver
所在的主机上没有运行 kube-proxy
,即无法通过服务的 ClusterIP
进行访问,那么还需要设置以下启动参数:
--enable-aggregator-routing=true
在设置完成重启 kube-apiserver
服务,就启用 API 聚合
功能了。
$ systemctl daemon-reload && systemctl restart kube-apiserver
按照上面的解决问题思路,我们可以开启 API 聚合功能,然后重启 Metrics Server 服务,步骤如下:
## 下载三个组件
$ wget https://pkg.cfssl.org/R1.2/cfssl_linux-amd64 -O cfssl
$ wget https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64 -O cfssljson
$ wget https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64 -O cfssl-certinfo
## 复制到 bin 目录下
$ chmod +x ./cfssl*
$ mv ./cfssl* /usr/local/bin/
创建 proxy-client-csr.json 文件:
{
"CN": "aggregator",
"hosts": [],
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "CN",
"ST": "BeiJing",
"L": "BeiJing",
"O": "system:masters",
"OU": "System"
}
]
}
生成证书和秘钥:
## Master1 执行下面命令生成证书
$ cfssl gencert \
-profile=kubernetes \
-ca=/etc/kubernetes/pki/ca.pem \
-ca-key=/etc/kubernetes/pki/ca-key.pem \
proxy-client-csr.json
查看生产的证书:
$ ls -l
-rw-r--r-- 1 root root 1017 12月 31 11:20 proxy-client.csr
-rw-r--r-- 1 root root 236 12月 31 11:07 proxy-client-csr.json
-rw------- 1 root root 1675 12月 31 11:20 proxy-client-key.pem
-rw-r--r-- 1 root root 1411 12月 31 11:20 proxy-client.pem
将证书访问指定的目录下,这里我将其放到 /etc/kubernetes/pki 下:
$ cp * /etc/kubernetes/pki/
复制到其它 Master 节点服务器中:
## 复制到 Master2
$ scp * 192.168.2.11:/etc/kubernetes/pki/
## 复制到 Master3
$ scp * 192.168.2.12:/etc/kubernetes/pki/
修改三个 Master 节点中全部 kube-apiserver 配置参数:
vi /etc/kubernetes/manifests/kube-apiserver.yaml
...
--runtime-config=api/all=true \
--requestheader-allowed-names=aggregator \
--requestheader-group-headers=X-Remote-Group \
--requestheader-username-headers=X-Remote-User \
--requestheader-extra-headers-prefix=X-Remote-Extra- \
--requestheader-client-ca-file=/etc/kubernetes/pki/ca.pem \
--proxy-client-cert-file=/etc/kubernetes/pki/proxy-client.pem \
--proxy-client-key-file=/etc/kubernetes/pki/proxy-client-key.pem \
...
参数说明:
–requestheader-client-ca-file: 客户端 CA 证书。
–requestheader-allowed-names: 允许访问的客户端 common names 列表,通过 header 中 –requestheader-username-headers 参数指定的字段获取。客户端 common names 的名称需要在 client-ca-file 中进行设置,将其设置为空值时,表示任意客户端都可访问。
–requestheader-username-headers: 参数指定的字段获取。
–requestheader-extra-headers-prefix: 请求头中需要检查的前缀名。
–requestheader-group-headers 请求头中需要检查的组名。
–requestheader-username-headers 请求头中需要检查的用户名。
–proxy-client-cert-file: 在请求期间验证 Aggregator 的客户端 CA 证书。
–proxy-client-key-file: 在请求期间验证 Aggregator 的客户端私钥。
–requestheader-allowed-names: 允许访问的客户端 common names 列表,通过 header 中 –requestheader-username-headers 参数指定的字段获取。客户端 common names 的名称需要在 client-ca-file 中进行设置,将其设置为空值时,表示任意客户端都可访问。
重启三个 Master 服务器中全部 kube-apiserver 组件:
$ systemctl daemon-reload && systemctl restart kube-apiserver
查看已有的 metrics server 的 pod:
$ kubectl get pods -n kube-system | grep metrics-server
metrics-server-7455879dcc-w9dw7 1/1 Running 0 1d
删掉已有的 metrics server 的 pod,使其重新生成新的 pod 资源:
$ kubectl delete pods metrics-server-7455879dcc-w9dw7 -n kube-system
等一段时间,然后输入下面命令进行测试:
[root@k8s-cluster-master-0040 ~]# kubectl top node
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
k8s-master-10 300m 3% 4788Mi 30%
k8s-master-11 800m 5% 5218Mi 31%
k8s-master-12 500m 4% 4900Mi 31%
k8s-woker-021 81m 1% 2930Mi 9%
k8s-woker-022 61m 0% 1658Mi 5%
k8s-woker-023 62m 0% 6061Mi 22%
可以观察到命令已经可以正常使用。
[1]
带你玩转 kubernetes-k8s 第 54 篇: https://blog.csdn.net/qq_31136839/article/details/100183026
[2]二进制方式搭建 Kubernetes 1.19.3 高可用集群(五)部署 dashboard: https://www.lingjie.tech/article/2020-11-07/20
原文链接:http://www.mydlq.club/article/102/
你可能还喜欢
点击下方图片即可阅读
云原生是一种信仰 ????
扫码关注公众号
后台回复◉k8s◉获取史上最方便快捷的 Kubernetes 高可用部署工具,只需一条命令,连 ssh 都不需要!
点击 "阅读原文" 获取更好的阅读体验!
❤️给个「在看」,是对我最大的支持❤️