Kubeadm deploys Kubernetes update certificate

A look at the certificate

1.1 Viewing the Expiration Time – Method 1

  1 [root@master01 ~]# tree /etc/kubernetes/pki/
  2 [root@master01 ~]# for tls in `find /etc/kubernetes/pki -maxdepth 2 -name "*.crt"`; \
  3 do echo ===============$tls===============; \
  4 openssl x509 -in $tls -text| grep Not; \
  5 done
Copy the code

 

1.1 Viewing the Expiration Time – Method 2

  1 [root@master01 ~]# tree /etc/kubernetes/pki/
Copy the code

  1 [root@master01 ~]# kubeadm alpha certs check-expiration
Copy the code

Note: The root certificate is valid for 10 years, and all other certificates are valid for 1 year.

Ii Types of Certificates

2.1 Cluster Root Certificate

1 / root @ master01 ~ # ll/etc/kubernetes/pki/ca * 2 - rw - r - r - 1 root root 1.1 K Jun 15 21:08 / etc/kubernetes/pki/ca. CRT 3 Rw -- -- -- -- -- -- -- 1 root root 1.7 K Jun 15 21:08 / etc/kubernetes/pki/ca. KeyCopy the code

 

The following certificates are issued by the cluster root certificate:

1. Server certificate held by the kube-Apiserver component

1 / root @ master01 ~ # ll/etc/kubernetes/pki/apiserver. * 2 - rw - r - r - 1 Jun 15 21:08 root root 1.3 K / etc/kubernetes/pki/apiserver. CRT 3 rw -- -- -- -- -- -- -- 1 root root 1.7 K Jun 15 21:08 / etc/kubernetes/pki/apiserver. KeyCopy the code

 

2. Client certificates held by kubelet components

1 / root @ master01 ~ # ll/etc/kubernetes/pki/apiserver - kubelet - client. * 2 - rw - r - r - 1 Jun 15 21:08 root root 1.1 K The/etc/kubernetes/pki/apiserver - kubelet - client. CRT 3 rw -- -- -- -- -- -- -- 1 Jun 15 21:08 root root 1.7 K /etc/kubernetes/pki/apiserver-kubelet-client.keyCopy the code

 

Hint: kubelet/var/lib/kubelet/config yaml configuration file doesn’t explicitly specify the server certificate, but only specified ca root, let kubelet automatically generated according to the local host information server certificate and saved to the configuration of the cert – dir folder.

2.2 Aggregation Layer Certificate

1 / root @ master01 ~ # ll/etc/kubernetes/pki/front - proxy - ca. * 2 - rw - r - r - 1 Jun 15 21:08 root root 1.1 K The/etc/kubernetes/pki/front - proxy - ca. CRT 3 rw -- -- -- -- -- -- -- 1 root root 1.7 K Jun 15 21:08 / etc/kubernetes/pki/front - proxy - ca. KeyCopy the code

 

The following certificates are issued by the root certificate of the aggregation layer:

1 / root @ master01 ~ # ll/etc/kubernetes/pki/front - proxy - client. * 2 - rw - r - r - 1 Jun 15 21:08 root root 1.1 K The/etc/kubernetes/pki/front - proxy - client. CRT 3 rw -- -- -- -- -- -- -- 1 Jun 15 21:08 root root 1.7 K /etc/kubernetes/pki/front-proxy-client.keyCopy the code

 

2.3 ETCD Cluster root certificate

1 [root@master01 ~]# ll /etc/kubernetes/pki/etcd/ca.* 2 -rw-r--r-- 1 root root 1017 Jun 15 21:08 / etc/kubernetes/pki/etcd/ca. CRT 3 rw -- -- -- -- -- -- -- 1 root root 1.7 K Jun 15 21:08 / etc/kubernetes/pki/etcd/ca. KeyCopy the code

 

The certificates issued by this ETCD root certificate are:

1. Etcd server Server certificate

1 / root @ master01 ~ # ll/etc/kubernetes/pki/etcd/server. * 2 - rw - r - r - 1 Jun 15 21:08 root root 1.2 K / etc/kubernetes/pki/etcd/server. The CRT 3 rw -- -- -- -- -- -- -- 1 root root 1.7 K Jun 15 21:08 / etc/kubernetes/pki/etcd/server. The keyCopy the code

 

2. Etcd Client certificate used by peer nodes in an ETCD cluster to communicate with each other

1 / root @ master01 ~ # ll/etc/kubernetes/pki/etcd/peer. * 2 - rw - r - r - 1 Jun 15 21:08 root root 1.2 K / etc/kubernetes/pki/etcd/peer. The CRT 3 rw -- -- -- -- -- -- -- 1 root root 1.7 K Jun 15 21:08 / etc/kubernetes/pki/etcd/peer. The keyCopy the code

 

3. The client certificate used by the Liveness probe is defined in the POD

1 / root @ master01 ~ # ll/etc/kubernetes/pki/etcd/healthcheck - client. * 2 - rw - r - r - 1 Jun 15 21:08 root root 1.1 K The/etc/kubernetes/pki/etcd/healthcheck - client. CRT 3 rw -- -- -- -- -- -- -- 1 Jun 15 21:08 root root 1.7 K /etc/kubernetes/pki/etcd/healthcheck-client.keyCopy the code

 

4. Configure the client certificate used in Kube-Apiserver for two-way authentication with etCD Server

1 / root @ master01 ~ # ll/etc/kubernetes/pki/apiserver - etcd - client. * 2 - rw - r - r - 1 Jun 15 21:08 root root 1.1 K The/etc/kubernetes/pki/apiserver - etcd - client. CRT 3 rw -- -- -- -- -- -- -- 1 Jun 15 21:08 root root 1.7 K /etc/kubernetes/pki/apiserver-etcd-client.keyCopy the code

 

2.4 Serveice Account Key

1 / root @ master01 ~ # ll/etc/kubernetes/pki/sa. * 2 rw -- -- -- -- -- -- -- 1 root root 1.7 K Jun 15 21:08 / etc/kubernetes/pki/sa. Key 3  -rw------- 1 root root 451 Jun 15 21:08 /etc/kubernetes/pki/sa.pubCopy the code

 

 

Serveice Account key pair is provided for kube-controller-Manager only. Kube-controller-manager signs tokens through sa.key. Pub is used to verify the signature of the master node.

Extension: API Server authentication process:

The AUTHENTICating part of the API Server supports multiple authentication modes: Client cert, bearer token, static password Auth, etc. If one of these methods passes authenticating (Kubernetes API Server tries it one by one), the authentication will pass.

When THE API Server discovers that a client initiated a request using a Service Account token, the API Server automatically performs identity verification with a signed bearer token. Request uses the service Account token carried by request to authenticate. The token is generated when the API Server creates a service account with the value of the API Server startup parameter: – service-account-key-file. If – service-account-key-file does not pass any value, the value of – TLS-private-key-file is used by default, that is, the API Server’s private key (server.key).

After authenticating, the API Server will perform the following operations based on the Pod Username group: System: ServiceAccounts and System: ServiceAccounts :(NAMESPACE) Permission The admission control and authority procedures are performed for the system: ServiceAccounts :(NAMESPACE) permission. In the two steps, the Cluster administrator can specify the service account permission.

 

In the cluster created by Kubeadm, Kube-proxy, Flannel and coreDNS run in pod form. In POD, service Account is directly used to authenticate with Kube-Apiserver. At this point, there is no need to create a separate certificate for Kube-Proxy.

Method 1 for updating certificates

Note: This method adopts the kubeadm default extension policy of one year. To customize a longer period, such as 100 years, refer to Step 4.

3.1 Backup Cluster Configuration

  1 [root@master01 ~]# kubeadm config view > kubeadm-cluster.yaml
Copy the code

3.2 Updating a Certificate

1 [root@master01 ~]# kubeadm alpha certs renew --help #Copy the code

Note: The certificate can be updated for a single certificate.

1 [root@master01 ~]# kubeadm alpha certs renew all --config=kubeadm-cluster.yaml #Copy the code

1 [root@master01 ~]# kubeadm alpha certs check-expiration #Copy the code

1 [root@master01 ~]# scp -rp kubeadm-cluster.yaml root@master02:/root/ 2 [root@master01 ~]# scp -rp kubeadm-cluster.yaml  root@master03:/root/ 3 [root@master02 ~]# kubeadm alpha certs renew all --config=kubeadm-cluster.yaml 4 [root@master03 ~]# kubeadm alpha certs renew all --config=kubeadm-cluster.yamlCopy the code

 

Tip: Update operations need to be performed on all master nodes.

3.3 Enabling a Certificate

Kube-apiserver, Kube-Controller, kuBE-Scheduler, etCD are restarted on the three masters for the certificate to take effect.

 

  1 [root@master01 ~]# docker ps |grep -E 'k8s_kube-apiserver|k8s_kube-controller-manager|k8s_kube-scheduler|k8s_etcd_etcd' | awk -F ' ' '{print $1}' |xargs docker restart
  2 [root@master02 ~]# docker ps |grep -E 'k8s_kube-apiserver|k8s_kube-controller-manager|k8s_kube-scheduler|k8s_etcd_etcd' | awk -F ' ' '{print $1}' |xargs docker restart
  3 [root@master03 ~]# docker ps |grep -E 'k8s_kube-apiserver|k8s_kube-controller-manager|k8s_kube-scheduler|k8s_etcd_etcd' | awk -F ' ' '{print $1}' |xargs docker restart
Copy the code

Tip: Enable operations need to be performed on all master nodes.

4 Update certificates method 2

Tip: this method uses the compilation of Kubeadm source code, source custom certificate time, such as 100 years.

4.1 Backup Cluster Configuration

  1 [root@master01 ~]# kubeadm config view > kubeadm-cluster.yaml
Copy the code

4.2 Viewing the Current Version

  1 [root@master01 ~]# kubectl version
Copy the code

4.3 Obtaining Source Code

1 / root @ master01 ~ # wget HTTP: / / https://github.com/kubernetes/kubernetes/archive/v1.18.3.tar.gz/root @ master01 ~ # 2 tar ZXVF. - V1.18.3. Tar. Gz 3Copy the code

 

4.4 Changing the CA Certificate Time

1 / root @ master01 ~ # vi kubernetes - 1.18.3 / staging/SRC/k8s. IO/client - go/util/cert/cert. Go 2... 5 57 func NewSelfSignedCACert(CFG Config, key crypto.signer) (*x509.Certificate, error) {4...... UTC(), 6 66 NotAfter: now.add (duration365d * 100).UTC(), 7...Copy the code

 

Note: The maximum time limit of ca certificate is 100 years. To extend the maximum time limit, you can modify the following maxAge value in cert.go:

maxAge := time.Hour * 24 * 365 * 10

4.5 Changing other Certificate Time

1 / root @ master01 ~ # vi kubernetes - 1.18.3 / CMD/kubeadm/app/constants/the go 2... 3 39 const ( 4 48 // CertificateValidity defines the validity for all the signed certificates generated by kubeadm 5 49 CertificateValidity = time.Hour * 24 * 365 * 100 6...... 7 [root@master01 kubernetes-1.18.3]# cat build/build-image/cross/VERSION 8 v1.13.9-5Copy the code

 

4.6 Compiling Kubeadm Method 1

1 [root@master01 kubernetes-1.18.3]# docker pull US.gcr. IO /k8s-artifacts-prod/build-image/kube-cross: v1.13.9-52 / root @ master01 ~ # docker run - rm - v/root/kubernetes 1.18.3 / : / go/SRC/k8s. IO/kubernetes - it Us. GCR. IO/k8s - artifacts - prod/build - image/kube - cross: v1.13.9 - bash root @ 51 e96585ea73:3 / go# CD/go/SRC/k8s. IO/kubernetes  4 root@51e96585ea73:/go/src/k8s.io/kubernetes# make all WHAT=cmd/kubeadm GOFLAGS=-vCopy the code

 

Tip: To compile other commands, see the following:

Kubectl # make all WHAT= CMD /kubectl GOFLAGS=-v

 

Kubeadm _output/bin/kubeadm

Bin is a soft connection

# true path is _output/local/bin/Linux/amd64 / kubeadm

1 root @ 51 e96585ea73: / go/SRC/k8s. IO/kubernetes# exit # exit containers/root @ master01 ~ # 2 mv/usr/bin/kubeadm The/usr/bin/kubeadm_backup # backup original kubeadm 3 / root @ master01 ~ # cp kubernetes 1.18.3 / _output/local/bin/Linux/amd64 / kubeadm /usr/bin/kubeadm 4 [root@master01 ~]# kubeadm versionCopy the code

 

4.7 Compiling Kubeadm Mode 2

1 [root@master01 ~]# yum -y install gcc make rsync jq 2 [root@master01 ~]# wget https://dl.google.com/go/go1.13.9.linux-amd64.tar.gz/root @ master01 ~ # 3 tar ZXVF go1.13.9. Linux - amd64. Tar. Gz - C /usr/local/ 4 [root@master01 ~]# vi /etc/profile.d/goenv.sh 5 #go setting 6 export GOROOT=/usr/local/go 7 export GOPATH=/usr/local/gopath 8 export PATH=$PATH:$GOROOT/bin 9 [root@master01 ~]# source /etc/profile 10 [root@master01 ~]# Go1.13.9 Linux/AMD64 12 [root@master01 ~]# CD kubernetes-1.18.3/13 [root@master01 Kubernetes-1.18.3]# make all WHAT= CMD /kubeadm GOFLAGS=-v 14 [root@master01 kubernetes-1.18.3]# mv /usr/bin/kubeadm The/usr/bin/kubeadm_backup # backup original kubeadm 15 [root @ master01 kubernetes - 1.18.3] # cp _output/local/bin/Linux/amd64 / kubeadm /usr/bin/kubeadmCopy the code

 

4.8 Configuring a Backup Cluster

  1 [root@master01 ~]# kubeadm config view > kubeadm-cluster.yaml
Copy the code

4.8 Updating a Certificate

1 [root@master01 ~]# ssh root@master02 "mv /usr/bin/kubeadm /usr/bin/kubeadm_backup" 2 [root@master01 ~]# ssh root@master03 "mv /usr/bin/kubeadm /usr/bin/kubeadm_backup" 3 [root@master01 ~]# scp -rp kubeadm-cluster.yaml root@master02:/root/ 4 [root@master01 ~]# scp -rp kubeadm-cluster.yaml root@master03:/root/ 5 [root@master01 ~]# kubeadm  alpha certs renew all --config=kubeadm-cluster.yaml 6 [root@master02 ~]# kubeadm alpha certs renew all --config=kubeadm-cluster.yaml 7 [root@master03 ~]# kubeadm alpha certs renew all --config=kubeadm-cluster.yaml 8 [root@master01 ~]# kubeadm alpha certs check-expiration #Copy the code

 

Tip: Update operations need to be performed on all master nodes.

All root certificates: CA, etcd-CA, front-proxy-ca are updated only when init is initialized, so it is recommended that for kubeadm deployment Kubernetes, the certificate can be set to a longer time using compilation before initialization, such as 100 years.

4.9 Enabling a Certificate

Kube-apiserver, Kube-Controller, kuBE-Scheduler, etCD are restarted on the three masters for the certificate to take effect.

Refer to 3.3.