我们其实可以使用多个不同的 CA 来颁发这些证书。只要在通信的组件中正确配置用于验证对方证书的 CA 根证书,就可以使用不同的 CA 来颁发不同用途的证书。但我们一般建议采用统一的 CA 来颁发 kubernetes 集群中的所有证书,这是因为采用一个集群根 CA 的方式比采用多个 CA 的方式更容易管理,可以避免多个CA 导致的复杂的证书配置、更新等问题,减少由于证书配置错误导致的集群故障。
ls /etc/kubernetes/pki
apiserver.crt
apiserver.key
ca.crt
ca.key
front-proxy-ca.crt
front-proxy-ca.key
front-proxy-client.crt
front-proxy-client.key
apiserver-etcd-client.crt
apiserver-etcd-client.key
apiserver-kubelet-client.crt
apiserver-kubelet-client.key
sa.key
sa.pub
etcd
ls /etc/kubernetes/pki/etcd
ca.crt
ca.key
healthcheck-client.crt
healthcheck-client.key
peer.crt
peer.key
server.crt
server.key
1、sa.key与sa.pub:
service Account密钥对 。提供给 kube-controller-manager 使用,
kube-controller-manager 通过 sa.key 对 token 进行签名,
master 节点通过公钥 sa.pub 进行签名的验证
如:kube-proxy 是以 pod 形式运行的, 在 pod 中, 直接使用 service account与
kube-apiserver进行认证,此时就不需要再单独为 kube-proxy 创建证书了, 直接使用token校验
2、ca.crt与ca.key
根证书与私钥
3、apiserver.crt与apiserver.key
apiserver的证书与私钥
4、apiserver-kubelet-client.crt与apiserver-kubelet-client.key
kubelet的证书与私钥。kubelet要主动访问kube-apiserver,kube-apiserver也需要主动向
kubelet发起请求。所以双方都需要有自己的根证书以及使用该根证书签发的服务端证书
和客户端证书。在kube-apiserver中, 一般明确指定用于https访问的服务端证书和
带有CN用户名信息的客户端证书。
而在kubelet的启动配置中, 一般只指定了ca根证书,而没有明确指定用于https访问的
服务端证书,在生成服务端证书时, 一般会指定服务端地址或主机名,kube-apiserver
相对变化不是很频繁,所以在创建集群之初就可以预先分配好用作 kube-apiserver的
IP 或主机名/域名。但是由于部署在node节点上的kubelet会因为集群规模的变化而
频繁变化,而无法预知node的所有IP信息,所以kubelet上一般不会明确指定服务端证书,
而是只指定ca根证书,让kubelet根据本地主机信息自动生成服务端证书并保存到cert-dir文件夹中
5、front-proxy-ca.crt与front-proxy-ca.key
代理根证书与私钥。
6、front-proxy-client.crt与front-proxy-client.key
由代理根证书签发的客户端证书与私钥。比如使用kubectl proxy代理访问时,
kube-apiserver使用这个证书来验证客户端证书是否是自己签发的证书
7、pki/etcd/ca.crt与pki/etcd/ca.key
etcd根证书与私钥
8、pki/etcd/peer.crt与pki/etcd/peer.key
etcd节点间相互通信 peer证书
9、pki/etcd/healthcheck-client.crt与pki/etcd/healthcheck-client.key
pod中Liveness探针客户端证书与私钥
10、apiserver-etcd-client.crt与apiserver-etcd-client.key
apiserver访问etcd的证书
apiserver证书配置
- command:
- kube-apiserver
# client-ca-file用于验证客户端证书,集群里用的ca是同一个,才不用为不同组件配置不同ca
- --client-ca-file=/etc/kubernetes/pki/ca.crt
- --etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt
- --etcd-certfile=/etc/kubernetes/pki/apiserver-etcd-client.crt
- --etcd-keyfile=/etc/kubernetes/pki/apiserver-etcd-client.key
- --kubelet-client-certificate=/etc/kubernetes/pki/apiserver-kubelet-client.crt
- --kubelet-client-key=/etc/kubernetes/pki/apiserver-kubelet-client.key
- --proxy-client-cert-file=/etc/kubernetes/pki/front-proxy-client.crt
- --proxy-client-key-file=/etc/kubernetes/pki/front-proxy-client.key
- --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt
- --service-account-key-file=/etc/kubernetes/pki/sa.pub
- --service-account-signing-key-file=/etc/kubernetes/pki/sa.key
- --tls-cert-file=/etc/kubernetes/pki/apiserver.crt
- --tls-private-key-file=/etc/kubernetes/pki/apiserver.key
kube-scheduler证书配置:直接使用了预生成的kubeconfig,用token代替证书进行通信
- command:
- kube-scheduler
- --authentication-kubeconfig=/etc/kubernetes/scheduler.conf
- --authorization-kubeconfig=/etc/kubernetes/scheduler.conf
- --kubeconfig=/etc/kubernetes/scheduler.conf
kube-controller-manager证书配置:
- command:
- kube-controller-manager
- --authentication-kubeconfig=/etc/kubernetes/controller-manager.conf
- --authorization-kubeconfig=/etc/kubernetes/controller-manager.conf
- --client-ca-file=/etc/kubernetes/pki/ca.crt
- --cluster-signing-cert-file=/etc/kubernetes/pki/ca.crt
- --cluster-signing-key-file=/etc/kubernetes/pki/ca.key
- --kubeconfig=/etc/kubernetes/controller-manager.conf
- --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt
- --root-ca-file=/etc/kubernetes/pki/ca.crt
- --service-account-private-key-file=/etc/kubernetes/pki/sa.key
etcd证书配置:
- command:
- etcd
- --cert-file=/etc/kubernetes/pki/etcd/server.crt
- --key-file=/etc/kubernetes/pki/etcd/server.key
- --peer-cert-file=/etc/kubernetes/pki/etcd/peer.crt
- --peer-client-cert-auth=true
- --peer-key-file=/etc/kubernetes/pki/etcd/peer.key
- --peer-trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt
- --trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt
kubelet证书配置:
x509:
clientCAFile: /etc/kubernetes/pki/ca.crt