概要

在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