L'expiration du certificat de Kubernetes entraîne l'arrêt de la communication à l'échelle du cluster

Introduction

Ce document décrit un problème éventuel de panne auquel les clients peuvent être confrontés lorsqu'ils disposent d'un système basé sur Kubernetes installé depuis plus de 365 jours. En outre, il passe en revue les étapes nécessaires pour remédier à la situation et faire fonctionner le système basé sur Kubernetes.

Problème

Après un an de cluster Kubernetes installé par défaut, les certificats client expirent. Vous ne pourrez pas accéder à Cisco CloudCentre Suite (CCS). Bien qu'il apparaisse toujours, vous ne pourrez pas vous connecter. Si vous naviguez jusqu'à l'interface de ligne de commande de kubectl, cette erreur s'affiche : « Impossible de se connecter au serveur : x509 : le certificat a expiré ou n'est pas encore valide. »

Vous pouvez exécuter ce script bash pour voir la date d'expiration de leurs certificats :

for crt in /etc/kubernetes/pki/*.crt; do
     printf '%s: %s\n' \
     "$(date --date="$(openssl x509 -enddate -noout -in "$crt"|cut -d= -f 2)" --iso-8601)" \
     "$crt"
done | sort

Vous pouvez également trouver un workflow opensource pour Action Orchestrator qui surveillera ce processus quotidiennement et les avertira des problèmes.

https://github.com/cisco-cx-workflows/cx-ao-shared-workflows/tree/master/CCSCheckKubernetesExpiration__definition_workflow_01E01VIRWZDE24mWlsHrqCGB9xUix0f9ZxG

Solution

De nouveaux certificats doivent être réémis via Kubeadm à travers le cluster, puis vous devez rejoindre les noeuds de travail aux maîtres.

1. Connectez-vous à un noeud maître.
   
   
2. Obtenez son adresse IP via ip address show.
   
   

   [root@cx-ccs-prod-master-d7f34f25-f524-4f90-9037-7286202ed13a3 kubernetes]# ip address show
   1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
   inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
   2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8920 qdisc pfifo_fast state UP group default qlen 1000
   link/ether fa:16:3e:19:63:a2 brd ff:ff:ff:ff:ff:ff
   inet 192.168.1.20/24 brd 192.168.1.255 scope global dynamic eth0
   valid_lft 37806sec preferred_lft 37806sec
   3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
   link/ether 02:42:d0:29:ce:5e brd ff:ff:ff:ff:ff:ff
   inet 172.17.0.1/16 scope global docker0
   valid_lft forever preferred_lft forever
   13: tunl0@NONE: <NOARP,UP,LOWER_UP> mtu 1430 qdisc noqueue state UNKNOWN group default qlen 1000
   link/ipip 0.0.0.0 brd 0.0.0.0
   inet 172.16.176.128/32 brd 172.16.176.128 scope global tunl0
   valid_lft forever preferred_lft forever
   14: cali65453a0219d@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1430 qdisc noqueue state UP group default
   link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff link-netnsid 4

3. Accédez au répertoire Kubernetes via cd /etc/kubernetes.
   
   
4. Créez un fichier appelé kubeadmCERT.yaml via vi kubeadmCERT.yaml.
   
   
5. Le fichier doit ressembler à ceci :
   
   

   apiVersion: kubeadm.k8s.io/v1alpha1
   kind: MasterConfiguration
   api:
     advertiseAddress: <IP ADDRESS FROM STEP 2>
   kubernetesVersion: v1.11.6
   #NOTE: If the customer is running a load balancer VM then you must add these lines after...
   #apiServerCertSANs:
   #- <load balancer IP>

6. Sauvegardez vos anciens certificats et clés. Cette opération n'est pas requise mais recommandée. Créez un répertoire de sauvegarde et copiez-y ces fichiers.
   
   

   #Files
   #apiserver.crt
   #apiserver.key
   #apiserver-kubelet-client.crt
   #apiserver-kubelet-client.key
   #front-proxy-client.crt
   #front-proxy-client.key
   
   #ie
   cd /etc/kubernetes/pki
   mkdir backup
   mv apiserver.key backup/apiserver.key.bak

7. Si vous avez ignoré l'étape 6., vous pouvez simplement supprimer les fichiers mentionnés précédemment via la commande rm comme rm apiserver.crt.
   
   
8. Revenez à l'emplacement de votre fichier kubeadmCERT.yaml. Générez un nouveau certificat apiserver via kubeadm —config kubeadmCERT.yaml alpha phase certs apiserver.
   
   

   [root@cx-ccs-prod-master-d7f34f25-f524-4f90-9037-7286202ed13a3 kubernetes]# kubeadm --config kubeadmCERT.yaml alpha phase certs apiserver
   [certificates] Generated apiserver certificate and key.
   [certificates] apiserver serving cert is signed for DNS names [cx-ccs-prod-master-d7f34f25-f524-4f90-9037-7286202ed13a3 kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 192.168.1.20]

9. Générez un nouveau cert de kubelet apiserver via kubeadm —config kubeadmCERT.yaml alpha phase certs apiserver-kubelet-client.
   
   
10. Générez un nouveau certificat client-proxy avant via kubeadm —config kubeadmCERT.yaml alpha phase certs client-proxy avant.
    
    
11. Dans le dossier /etc/kubernetes, sauvegardez les fichiers .conf. Non obligatoire mais recommandé. Vous devez avoir kubelet.conf, controller-manager.conf, Scheduler.conf et éventuellement admin.conf. Vous pouvez les supprimer si vous ne voulez pas les sauvegarder.
    
    
12. Générez de nouveaux fichiers de configuration via kubeadm —config kubeadmCERT.yaml alpha phase kubeconfig all.
    
    

    [root@cx-ccs-prod-master-d7f34f25-f524-4f90-9037-7286202ed13a3 kubernetes]# kubeadm --config kubeadmCERT.yaml alpha phase kubeconfig all
    [kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/admin.conf"
    [kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/kubelet.conf"
    [kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/controller-manager.conf"
    [kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/scheduler.conf"

13. Exportez votre nouveau fichier admin.conf vers votre hôte.
    
    

    cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
    chown $(id -u):$(id -g) $HOME/.kube/config
    chmod 777 $HOME/.kube/config
    export KUBECONFIG=.kube/config

14. Redémarrez le noeud maître via shutdown -r maintenant.
    
    
15. Une fois le maître sauvegardé, vérifiez si kubelet fonctionne via system ctl status kubelet.
    
    
16. Vérifier les Kubernetes via les noeuds d'obtention de kubectl.
    
    

    [root@cx-ccs-prod-master-d7f34f25-f524-4f90-9037-7286202ed13a3 ~]# kubectl get nodes
    NAME                                                       STATUS     ROLES     AGE       VERSION
    cx-ccs-prod-master-d7f34f25-f524-4f90-9037-7286202ed13a1   Ready      master    1y        v1.11.6
    cx-ccs-prod-master-d7f34f25-f524-4f90-9037-7286202ed13a2   Ready      master    1y        v1.11.6
    cx-ccs-prod-master-d7f34f25-f524-4f90-9037-7286202ed13a3   Ready      master    1y        v1.11.6
    cx-ccs-prod-worker-d7f34f25-f524-4f90-9037-7286202ed13a1   NotReady   <none>    1y        v1.11.6
    cx-ccs-prod-worker-d7f34f25-f524-4f90-9037-7286202ed13a2   NotReady   <none>    1y        v1.11.6
    cx-ccs-prod-worker-d7f34f25-f524-4f90-9037-7286202ed13a3   NotReady   <none>    1y        v1.11.6
    cx-ccs-prod-worker-d7f34f25-f524-4f90-9037-7286202ed13a4   NotReady   <none>    1y        v1.11.6
    cx-ccs-prod-worker-d7f34f25-f524-4f90-9037-7286202ed13a5   NotReady   <none>    1y        v1.11.6
    cx-ccs-prod-worker-d7f34f25-f524-4f90-9037-7286202ed13a6   NotReady   <none>    1y        v1.11.6
    

    
    
17. Répétez les étapes 1. à 16. pour chaque noeud maître.
    
    
18. Sur un maître, générez un nouveau jeton de jointure via kubeadm token create —print-join-command. Copiez cette commande pour une utilisation ultérieure.
    
    

    [root@cx-ccs-prod-master-d7f34f25-f524-4f90-9037-7286202ed13a1 k8s-mgmt]# kubeadm token create 
     --print-join-command
    kubeadm join 192.168.1.14:6443 --token m1ynvj.f4n3et3poki88ry4
     --discovery-token-ca-cert-hash 
    sha256:4d0c569985c1d460ef74dc01c85740285e4af2c2369ff833eed1ba86e1167575

19. Obtenez les adresses IP de vos employés via kubectl get noeuds -o large.
    
    
20. Connectez-vous à un travailleur comme ssh -i /home/cloud-user/keys/gen3-ao-prod.key cloud-user@192.168.1.17 et accédez à l'accès racine.
    
    
21. Arrêtez le service de kubelet via systemctl stop kubelet.
    
    
22. Supprimez les anciens fichiers de configuration, notamment ca.crt, kubelet.conf et bootstrap-kubelet.conf.
    
    

    rm /etc/kubernetes/pki/ca.crt
    rm /etc/kubernetes/kubelet.conf
    rm /etc/kubernetes/bootstrap-kubelet.conf

23. Saisissez le nom du noeud à partir de l'étape 19.
    
    
24. Émettez la commande pour le collaborateur afin de rejoindre à nouveau le cluster. Utilisez la commande 18., mais ajoutez —node-name <nom du noeud> à la fin.
    
    

    [root@cx-ccs-prod-worker-d7f34f25-f524-4f90-9037-7286202ed13a1 kubernetes]# kubeadm join 192.168.1.14:6443 --token m1ynvj.f4n3et3poki88ry4 --discovery-token-ca-cert-hash sha256:4d0c569985c1d460ef74dc01c85740285e4af2c2369ff833eed1ba86e1167575 --node-name cx-ccs-prod-worker-d7f34f25-f524-4f90-9037-7286202ed13a1
    [preflight] running pre-flight checks
            [WARNING RequiredIPVSKernelModulesAvailable]: the IPVS proxier will not be used, because the following required kernel modules are not loaded: [ip_vs_rr ip_vs_wrr ip_vs_sh] or no builtin kernel ipvs support: map[ip_vs:{} ip_vs_rr:{} ip_vs_wrr:{} ip_vs_sh:{} nf_conntrack_ipv4:{}]
    you can solve this problem with following methods:
     1. Run 'modprobe -- ' to load missing kernel modules;
    2. Provide the missing builtin kernel ipvs support
    
    I0226 17:59:52.644282   19170 kernel_validator.go:81] Validating kernel version
    I0226 17:59:52.644421   19170 kernel_validator.go:96] Validating kernel config
    [discovery] Trying to connect to API Server "192.168.1.14:6443"
    [discovery] Created cluster-info discovery client, requesting info from "https://192.168.1.14:6443"
    [discovery] Requesting info from "https://192.168.1.14:6443" again to validate TLS against the pinned public key
    [discovery] Cluster info signature and contents are valid and TLS certificate validates against pinned roots, will use API Server "192.168.1.14:6443"
    [discovery] Successfully established connection with API Server "192.168.1.14:6443"
    [kubelet] Downloading configuration for the kubelet from the "kubelet-config-1.11" ConfigMap in the kube-system namespace
    [kubelet] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
    [kubelet] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
    [preflight] Activating the kubelet service
    [tlsbootstrap] Waiting for the kubelet to perform the TLS Bootstrap...
    [patchnode] Uploading the CRI Socket information "/var/run/dockershim.sock" to the Node API object "cx-ccs-prod-worker-d7f34f25-f524-4f90-9037-7286202ed13a1" as an annotation
    
    This node has joined the cluster:
    * Certificate signing request was sent to master and a response
      was received.
    * The Kubelet was informed of the new secure connection details.
    
    Run 'kubectl get nodes' on the master to see this node join the cluster.
    

25. Quittez le collaborateur et vérifiez l'état d'un maître via les noeuds d'obtention de kubectl. Il doit être à l'état Prêt.
    
    
26. Répétez les étapes 20. à 25. pour chaque travailleur.
    
    
27. Les derniers noeuds de Kubectl devraient montrer que tous les noeuds sont en état « Prêt », de nouveau en ligne et joints au cluster.
    
    

    [root@cx-ccs-prod-master-d7f34f25-f524-4f90-9037-7286202ed13a1 ~]# kubectl get nodes
    NAME                                                       STATUS    ROLES     AGE       VERSION
    cx-ccs-prod-master-d7f34f25-f524-4f90-9037-7286202ed13a1   Ready     master    1y        v1.11.6
    cx-ccs-prod-master-d7f34f25-f524-4f90-9037-7286202ed13a2   Ready     master    1y        v1.11.6
    cx-ccs-prod-master-d7f34f25-f524-4f90-9037-7286202ed13a3   Ready     master    1y        v1.11.6
    cx-ccs-prod-worker-d7f34f25-f524-4f90-9037-7286202ed13a1   Ready     <none>    1y        v1.11.6
    cx-ccs-prod-worker-d7f34f25-f524-4f90-9037-7286202ed13a2   Ready     <none>    1y        v1.11.6
    cx-ccs-prod-worker-d7f34f25-f524-4f90-9037-7286202ed13a3   Ready     <none>    1y        v1.11.6
    cx-ccs-prod-worker-d7f34f25-f524-4f90-9037-7286202ed13a4   Ready     <none>    1y        v1.11.6
    cx-ccs-prod-worker-d7f34f25-f524-4f90-9037-7286202ed13a5   Ready     <none>    1y        v1.11.6
    cx-ccs-prod-worker-d7f34f25-f524-4f90-9037-7286202ed13a6   Ready     <none>    1y        v1.11.6