Mise en place d’un cluster Kubernetes

1. Composants de base

Kubernetes est composé d’un plan de contrôle (control plane), et de nœuds (nodes, compute nodes ou workers). Les serveurs du control plane sont appelés masters et ce sont eux qui contrôlent les processus de décision, qui gèrent l’ensemble des événements. Ce sont donc eux qui contrôlent l’ensemble du cluster. Les masters et les nodes communiquent ensemble, et les applications sous forme de pods sont exécutées sur les nodes.

Un master est composé de plusieurs services :

Un nœud dispose aussi de services spécialisés :

1. Rappels

Les trois masters et les nœuds disposent des capacités suivantes suffisantes pour notre application :

La configuration DNS est la suivante, incluant la VIP d’accès à l’API Kube :

Les serveurs sont tous installés sous Ubuntu 20.04. Toute trace précédente de Kubernetes doit être supprimée. L’utilisateur Ansible et les droits sudo associés doivent être présents, et Ansible depuis infra01 doit pouvoir se connecter. Le résolveur DNS doit être configuré pour utiliser nos serveurs DNS primaires et secondaires.

2. HAProxy

Chaque master disposant du composant kube-apiserver, il peut répondre aux requêtes des clients et des nœuds, par défaut sur le port 6443. Nous devons configurer une VIP et placer les trois masters derrière un répartiteur de charge ou un reverse proxy. Nous allons utiliser les répartiteurs créés dans le chapitre Infrastructure et services de base.

La VIP est celle provisionnée dès le chapitre Infrastructure et services de base : 192.168.56.15. Nous écoutons sur le port 8443. Le backend est en mode TCP et le contrôle de santé est sur /healtz.

Une configuration peut être la suivante :

frontend apikube 
    bind 192.168.56.15:8443 
    mode tcp 
    option tcplog 
    default_backend kubemasters 
 
backend kubemasters 
    option httpchk GET /healthz 
    http-check expect status 200 
    mode tcp 
    option ssl-hello-chk 
    balance     roundrobin 
    server k8s-master01 192.168.56.20:6443 check 
    server k8s-master02 192.168.56.21:6443 check 
    server...

1. Images de Kubernetes

Si ce n’est pas encore fait, il faut s’assurer que le service kubelet est activé sur tous les serveurs.

$ ansible k8s -m shell --become -a "systemctl enable kubelet" 

La commande centrale de configuration initiale du cluster est kubeadm. Kubernetes lui-même fonctionne sous forme de pods, donc de containers. À la différence des applications que nous déploierons, c’est le service kubelet qui va les démarrer lors de son activation, de manière statique. Dans un premier temps, nous allons récupérer ces images. Ce n’est pas obligatoire (la création des masters le fait), mais nous allons ainsi nous assurer qu’elles sont bien présentes. 

Sur chaque master, récupérez les images :

$ sudo kubeadm config images pull 

Vous pouvez utiliser une commande Ansible :

$ ansible k8s_masters -m shell --become -a "kubeadm config images pull" 

Le résultat est le suivant :

[config/images] Pulled k8s.gcr.io/kube-apiserver:v1.20.2 
[config/images] Pulled k8s.gcr.io/kube-controller-manager:v1.20.2 
[config/images] Pulled k8s.gcr.io/kube-scheduler:v1.20.2 
[config/images] Pulled k8s.gcr.io/kube-proxy:v1.20.2 
[config/images] Pulled k8s.gcr.io/pause:3.2 
[config/images] Pulled k8s.gcr.io/etcd:3.4.13-0 
[config/images] Pulled k8s.gcr.io/coredns:1.7.0 

2. Premier master

# kubeadm init \ 
   --control-plane-endpoint"api.kube.diehard.net:8443" \ 
   --pod-network-cidr=10.244.0.0/16 \ 
   --upload-certs 

1. Crash ou arrêt sale d’un node

Si on stoppe violemment un node, il peut se passer des choses étranges. Lorsque cela se produit, l’origine du problème n’est pas notifiée aux masters : ils ne savent pas pourquoi le node n’est plus visible. Doivent-ils redémarrer les pods manquants ? Après tout, le problème peut être transitoire : le node peut redémarrer rapidement et les pods associés peuvent donc être à nouveau accessibles… 

Aussi, un mécanisme de timeout est en place. Le node est détecté comme étant NotReady, et avec les réglages que nous avons appliqués lors de la création des masters, un mécanisme d’éviction des pods démarre après un délai variable, d’environ 30 secondes à 1 minute. Les pods qui tournaient sur le node planté passent en statut Terminating. Un délai de grâce s’applique alors, qui a été fixé à 30 secondes, à la fin duquel Kubernetes remplace le pod absent par un nouveau. À ce délai s’ajoutent le délai de détection du node en panne, le délai de redémarrage du nouveau pod (récupération de l’image et lancement), etc.

Ces délais mettent en évidence...