Cette page explique deux approches pour configurer un cluster Kubernetes hautement disponible (HA) à l’aide de kubeadm :
Avant de continuer, vous devez soigneusement choisir l’approche qui correspond le mieux aux besoins de vos applications et de votre environnement. La page Options de topologie hautement disponible décrit les avantages et inconvénients de chaque approche.
Si vous rencontrez des problèmes lors de la configuration du cluster HA, veuillez les signaler dans le système de tickets kubeadm.
Voir également la documentation de mise à niveau.
Les prérequis dépendent de la topologie choisie pour le plan de contrôle :
Vous avez besoin de :
sudosudo dans les exemples.kubeadm et kubelet déjà installés sur toutes les machines.Voir la topologie etcd empilée pour le contexte.
Vous avez besoin de :
sudosudo dans les exemples.kubeadm et kubelet déjà installés sur toutes les machines.Et vous avez également besoin de :
kubeadm et kubelet installés.Voir la topologie etcd externe pour le contexte.
Chaque hôte doit avoir accès en lecture et pouvoir récupérer les images depuis le registre d’images de conteneurs Kubernetes, registry.k8s.io. Si vous souhaitez déployer un cluster hautement disponible dont les hôtes n’ont pas accès pour télécharger les images, c’est possible. Vous devez alors vous assurer par d’autres moyens que les bonnes images de conteneurs sont déjà disponibles sur les hôtes concernés.
Pour gérer Kubernetes une fois votre cluster configuré, vous devez
installer kubectl sur votre ordinateur. Il est également utile
d’installer l’outil kubectl sur chaque nœud du plan de contrôle, car cela peut être
utile pour le dépannage.
Créer un load balancer pour le kube-apiserver avec un nom qui résout via DNS.
Dans un environnement cloud, vous devez placer vos nœuds du plan de contrôle derrière un load balancer TCP. Ce load balancer distribue le trafic vers tous les nœuds du plan de contrôle en bonne santé présents dans sa liste de cibles. Le contrôle de santé (health check) pour l’API server est une vérification TCP sur le port utilisé par le kube-apiserver (valeur par défaut :6443).
Il n’est pas recommandé d’utiliser directement une adresse IP dans un environnement cloud.
Le load balancer doit pouvoir communiquer avec tous les nœuds du plan de contrôle sur le port de l’API server. Il doit également autoriser le trafic entrant sur son port d’écoute.
Assurez-vous que l’adresse du load balancer correspond toujours à l’adresse définie dans le ControlPlaneEndpoint de kubeadm.
Consultez le guide Options for Software Load Balancing pour plus de détails.
Ajouter le premier nœud du plan de contrôle au load balancer, et tester la connexion :
nc -zv -w 2 <LOAD_BALANCER_IP> <PORT>
Une erreur de type connection refused est attendue car le serveur API n’est pas encore en cours d’exécution. En revanche, un timeout signifie que le load balancer ne peut pas communiquer avec le nœud du plan de contrôle. Si un timeout se produit, reconfigurez le load balancer afin qu’il puisse communiquer avec le nœud du plan de contrôle.
Ajouter les autres nœuds du plan de contrôle au groupe de cibles du load balancer.
Initialiser le plan de contrôle :
sudo kubeadm init --control-plane-endpoint "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" --upload-certs
Vous pouvez utiliser l’option --kubernetes-version pour définir la version de Kubernetes à utiliser.
Il est recommandé que les versions de kubeadm, kubelet, kubectl et Kubernetes soient identiques.
L’option --control-plane-endpoint doit être définie avec l’adresse (ou le DNS) et le port du load balancer.
L’option --upload-certs est utilisée pour téléverser les certificats qui doivent être partagés
entre toutes les instances du plan de contrôle dans le cluster. Si vous préférez copier les certificats
manuellement entre les nœuds du plan de contrôle ou utiliser des outils d’automatisation, supprimez cette option et référez-vous à la section Distribution manuelle des certificats ci-dessous.
--config et --certificate-key de kubeadm init ne peuvent pas être utilisés ensemble.
Par conséquent, si vous souhaitez utiliser la configuration kubeadm,
vous devez ajouter le champ certificateKey aux emplacements appropriés
(dans InitConfiguration et JoinConfiguration: controlPlane).--pod-network-cidr, ou si vous utilisez un fichier de configuration kubeadm, définissez le champ podSubnet dans l’objet networking de ClusterConfiguration.La sortie ressemble à :
...
Vous pouvez maintenant joindre autant de nœuds du plan de contrôle que vous le souhaitez en exécutant la commande suivante sur chacun en tant que root :
kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 --control-plane --certificate-key f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07
Veuillez noter que la certificate-key donne accès à des données sensibles du cluster, gardez-la secrète !
Par mesure de sécurité, les certificats téléversés seront supprimés au bout de deux heures. Si nécessaire, vous pouvez utiliser `kubeadm init phase upload-certs` pour recharger les certificats par la suite.
Ensuite, vous pouvez joindre autant de nœuds workers que vous le souhaitez en exécutant la commande suivante sur chacun en tant que root :
kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866
Copiez cette sortie dans un fichier texte. Vous en aurez besoin plus tard pour ajouter des nœuds du plan de contrôle et des nœuds workers au cluster.
Lorsque l’option --upload-certs est utilisée avec kubeadm init, les certificats du plan de contrôle principal sont chiffrés et envoyés dans le Secret kubeadm-certs.
Pour ré-envoyer les certificats et générer une nouvelle clé de déchiffrement, utilisez la commande suivante sur un nœud du plan de contrôle déjà joint au cluster :
sudo kubeadm init phase upload-certs --upload-certs
Vous pouvez également spécifier une clé personnalisée --certificate-key lors de l’exécution de init, qui pourra ensuite être utilisée par join.
Pour générer une telle clé, vous pouvez utiliser la commande suivante :
kubeadm certs certificate-key
La clé de certificat est une chaîne encodée en hexadécimal correspondant à une clé AES de 32 octets.
kubeadm-certs ainsi que la clé de déchiffrement expirent après deux heures.Appliquez le plugin CNI de votre choix : Suivez ces instructions pour installer un fournisseur CNI. Assurez-vous que la configuration correspond au CIDR des Pods défini dans le fichier de configuration kubeadm (le cas échéant).
Tapez la commande suivante et observez le démarrage des Pods des composants du plan de contrôle :
kubectl get pod -n kube-system -w
Pour chaque nœud de plan de contrôle supplémentaire, vous devez :
Exécutez la commande de jointure qui vous a été fournie précédemment par la sortie de kubeadm init sur le premier nœud.
Elle devrait ressembler à ceci :
sudo kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 --control-plane --certificate-key f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07
--control-plane indique à kubeadm join de créer un nouveau plan de contrôle.--certificate-key ... permet de télécharger les certificats du plan de contrôle depuis le Secret kubeadm-certs du cluster, puis de les déchiffrer à l’aide de la clé fournie.kubectl -n kube-system rollout restart deployment coredns après qu’au moins un nouveau nœud a été rejoint.La configuration d’un cluster avec des nœuds etcd externes est similaire à celle du mode stacked etcd, à l’exception du fait que vous devez d’abord configurer etcd, puis fournir les informations etcd dans le fichier de configuration kubeadm.
Suivez ces instructions pour configurer le cluster etcd.
Configurez SSH comme décrit ici.
Copiez les fichiers suivants depuis n’importe quel nœud etcd du cluster vers le premier nœud du plan de contrôle :
export CONTROL_PLANE="ubuntu@10.0.0.7"
scp /etc/kubernetes/pki/etcd/ca.crt "${CONTROL_PLANE}":
scp /etc/kubernetes/pki/apiserver-etcd-client.crt "${CONTROL_PLANE}":
scp /etc/kubernetes/pki/apiserver-etcd-client.key "${CONTROL_PLANE}":
CONTROL_PLANE with the user@host of the first control-plane node.Créez un fichier nommé kubeadm-config.yaml avec le contenu suivant :
---
apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
kubernetesVersion: stable
controlPlaneEndpoint: "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" # change this (see below)
etcd:
external:
endpoints:
- https://ETCD_0_IP:2379 # change ETCD_0_IP appropriately
- https://ETCD_1_IP:2379 # change ETCD_1_IP appropriately
- https://ETCD_2_IP:2379 # change ETCD_2_IP appropriately
caFile: /etc/kubernetes/pki/etcd/ca.crt
certFile: /etc/kubernetes/pki/apiserver-etcd-client.crt
keyFile: /etc/kubernetes/pki/apiserver-etcd-client.key
external de etcd.
Dans le cas de la topologie etcd empilée, cela est géré automatiquement.Remplacez les variables suivantes dans le modèle de configuration avec les valeurs appropriées de votre cluster :
LOAD_BALANCER_DNSLOAD_BALANCER_PORTETCD_0_IPETCD_1_IPETCD_2_IPLes étapes suivantes sont similaires à la configuration etcd empilée :
Exécutez sudo kubeadm init --config kubeadm-config.yaml --upload-certs sur ce nœud.
Enregistrez les commandes de jointure affichées dans un fichier texte pour une utilisation ultérieure.
Appliquez le plugin réseau CNI de votre choix.
Les étapes sont les mêmes que pour la configuration etcd empilée :
--certificate-key expire par défaut après deux heures.Les nœuds worker peuvent être ajoutés au cluster avec la commande que vous avez précédemment enregistrée lors de la sortie de kubeadm init :
sudo kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866
Si vous choisissez de ne pas utiliser kubeadm init avec le flag --upload-certs, cela signifie que
vous devrez copier manuellement les certificats depuis le nœud principal du plan de contrôle vers les
nœuds du plan de contrôle qui rejoignent le cluster.
Il existe plusieurs façons de faire cela. L’exemple suivant utilise ssh et scp :
SSH est requis si vous souhaitez contrôler tous les nœuds depuis une seule machine.
Activez ssh-agent sur votre machine principale qui a accès à tous les autres nœuds du système :
eval $(ssh-agent)
Ajoutez votre identité SSH à la session :
ssh-add ~/.ssh/path_to_private_key
Effectuez une connexion SSH entre les nœuds pour vérifier que la connexion fonctionne correctement.
Lorsque vous vous connectez en SSH à un nœud, ajoutez l’option -A. Cette option permet au nœud sur lequel vous êtes connecté via SSH d’accéder à l’agent SSH de votre PC. Envisagez des méthodes alternatives si vous ne faites pas entièrement confiance à la sécurité de votre session utilisateur sur le nœud.
ssh -A 10.0.0.7
Lorsque vous utilisez sudo sur un nœud, assurez-vous de préserver l’environnement afin que la redirection SSH (SSH forwarding) fonctionne :
sudo -E -s
Après avoir configuré SSH sur tous les nœuds, vous devez exécuter le script suivant sur le premier
nœud du plan de contrôle après avoir exécuté kubeadm init. Ce script va copier les certificats depuis
le premier nœud du plan de contrôle vers les autres nœuds du plan de contrôle :
Dans l’exemple suivant, remplacez CONTROL_PLANE_IPS par les adresses IP des
autres nœuds du plan de contrôle.
USER=ubuntu # customizable
CONTROL_PLANE_IPS="10.0.0.7 10.0.0.8"
for host in ${CONTROL_PLANE_IPS}; do
scp /etc/kubernetes/pki/ca.crt "${USER}"@$host:
scp /etc/kubernetes/pki/ca.key "${USER}"@$host:
scp /etc/kubernetes/pki/sa.key "${USER}"@$host:
scp /etc/kubernetes/pki/sa.pub "${USER}"@$host:
scp /etc/kubernetes/pki/front-proxy-ca.crt "${USER}"@$host:
scp /etc/kubernetes/pki/front-proxy-ca.key "${USER}"@$host:
scp /etc/kubernetes/pki/etcd/ca.crt "${USER}"@$host:etcd-ca.crt
# Skip the next line if you are using external etcd
scp /etc/kubernetes/pki/etcd/ca.key "${USER}"@$host:etcd-ca.key
done
Ensuite, sur chaque nœud du plan de contrôle qui rejoint le cluster, vous devez exécuter le script suivant avant d’exécuter kubeadm join.
Ce script déplacera les certificats précédemment copiés depuis le répertoire home vers /etc/kubernetes/pki :
USER=ubuntu # customizable
mkdir -p /etc/kubernetes/pki/etcd
mv /home/${USER}/ca.crt /etc/kubernetes/pki/
mv /home/${USER}/ca.key /etc/kubernetes/pki/
mv /home/${USER}/sa.pub /etc/kubernetes/pki/
mv /home/${USER}/sa.key /etc/kubernetes/pki/
mv /home/${USER}/front-proxy-ca.crt /etc/kubernetes/pki/
mv /home/${USER}/front-proxy-ca.key /etc/kubernetes/pki/
mv /home/${USER}/etcd-ca.crt /etc/kubernetes/pki/etcd/ca.crt
# Skip the next line if you are using external etcd
mv /home/${USER}/etcd-ca.key /etc/kubernetes/pki/etcd/ca.key