在这种比较极端的情况下,要小心翼翼的规划和操作,才不会让集群彻底死翘翘。首先,几个ca根证书是10年期,应该还没有过期。我们可以基于这几个根证书,来重新生成一套可用的各组件认证证书。
前期,先制定以下方案步骤,能否实现,待验证。
一,制作证书的基本文件。
Ca-csr.json(因为根证书是OK的,所以这个文件,可是列在这里,不会用上)
{ "CN": "kubernetes", "key": { "algo": "rsa", "size": 2048 }, "ca": { "expiry": "438000h" } }
Ca-config.json(它用来从自签名根ca.crt和ca.key生成新的证书,可以共用)
{ "signing": { "default": { "expiry": "43800h" }, "profiles": { "server": { "expiry": "43800h", "usages": [ "signing", "key encipherment", "server auth" ] }, "client": { "expiry": "43800h", "usages": [ "signing", "key encipherment", "client auth" ] }, "peer": { "expiry": "43800h", "usages": [ "signing", "key encipherment", "server auth", "client auth" ] } } } }
二,重新生成etcd系列证书((注意,这是依据/etc/kubernetes/pki/etcd/目录下的ca证书)
Etcd-server.json
{ "CN": "etcdServer", "hosts": [ "127.0.0.1", "localhost", "小写主机名", "本机ip" ], "key": { "algo": "rsa", "size": 2048 }, "names": [ { "O": "etcd", "OU": "etcd Security", "C": "CN", "L": "ShangHai", "ST": "ShangHai" } ] }
cfssl gencert -ca=ca.crt -ca-key=ca.key -config=ca-config.json -profile=server etcd-server.json|cfssljson -bare server
etcd-peer.json
{ "CN": "etcdPeer", "hosts": [ "127.0.0.1", "localhost", "小写主机名", "本机ip " ], "key": { "algo": "rsa", "size": 2048 }, "names": [ { "O": "etcd", "OU": "etcd Security", "C": "CN", "L": "ShangHai", "ST": "ShangHai" } ] }
cfssl gencert -ca=ca.crt -ca-key=ca.key -config=ca-config.json -profile=peer etcd-peer.json|cfssljson -bare peer
etcd-client.json
{ "CN": "etcdClient", "key": { "algo": "rsa", "size": 2048 }, "names": [ { "O": "etcd", "OU": "etcd Security", "C": "CN", "L": "ShangHai", "ST": "ShangHai" } ] }
cfssl gencert -ca=ca.crt -ca-key=ca.key -config=ca-config.json -profile=client etcd-client.json|cfssljson -bare client
三,重新制作apiserver证书(注意,这是依据/etc/kubernetes/pki目录下的ca证书)
Apiserver.json
{ "CN": "kube-apiserver", "hosts": [ "kubernetes", "kubernetes.default", "kubernetes.default.svc", "kubernetes.default.svc.cluster.local", "10.96.0.1", "小写主机名", "本机ip " ], "key": { "algo": "rsa", "size": 2048 } }
cfssl gencert -ca=ca.crt -ca-key=ca.key -config=ca-config.json -profile=server apiserver.json|cfssljson -bare apiserver
apiserver-kubelet-client.json
{ "CN": "kube-apiserver-kubelet-client", "key": { "algo": "rsa", "size": 2048 }, "names": [ { "O": "system:masters" } ] }
cfssl gencert -ca=ca.crt -ca-key=ca.key -config=ca-config.json -profile=client apiserver-kubelet-client.json|cfssljson -bare apiserver-kubelet-client
三,重新制作front-proxy证书(注意,这是依据/etc/kubernetes/pki目录下的front-proxy-ca证书,它必须和apiserver的ca不一样,牵扯到apiserver的认证顺序,切记)
Front-proxy-client.json
{ "CN": "front-proxy-client", "key": { "algo": "rsa", "size": 2048 } }
cfssl gencert -ca=front-proxy-ca.crt -ca-key=front-proxy-ca.key -config=ca-config.json -profile=client front-proxy-client.json|cfssljson -bare front-proxy-client
四,如果/etc/kubernetes/pki目录下的sa.key,sa.pub存在,则无须更新,因为它没有过期概念。
五,以上文件作好之后,需要根据现在的k8s命令规则改名,还要根据不同的文件,存放于不同的目录。
六,这时,k8s master应该可以启动了。接下来,制作kubeconfig文件,参考url
https://www.cnblogs.com/netsa/p/8134000.html(配置bootstrap及kubelet认证)
https://www.cnblogs.com/charlieroro/p/8489515.html(配置.kube/config文件)
# 设置集群参数 kubectl config set-cluster # 设置客户端认证参数 kubectl config set-credentials # 设置上下文参数 kubectl config set-context # 设置默认上下文 kubectl config use-context
七,当制作好这些文件之后,按k8s安装的位置,分发文件,重启kubelet,应该就可以重新启动好集群了。