Création de clusters hautement disponibles avec kubeadm

Cluster Kubernetes haute-disponibilité kubeadm

Cette page explique deux approches différentes pour configurer un Kubernetes à haute disponibilité. cluster utilisant kubeadm:

  • Avec des nœuds de control plane empilés. Cette approche nécessite moins d'infrastructure. Les membres etcd et les nœuds du control plane sont co-localisés.
  • Avec un cluster etcd externe cette approche nécessite plus d'infrastructure. Les nœuds du control plane et les membres etcd sont séparés.

Avant de poursuivre, vous devez déterminer avec soin quelle approche répond le mieux aux besoins de vos applications et de l'environnement. Cette comparaison décrit les avantages et les inconvénients de chacune.

Vos clusters doivent exécuter Kubernetes version 1.12 ou ultérieure. Vous devriez aussi savoir que la mise en place de clusters HA avec kubeadm est toujours expérimentale et sera simplifiée davantage dans les futures versions. Vous pouvez par exemple rencontrer des problèmes lors de la mise à niveau de vos clusters. Nous vous encourageons à essayer l’une ou l’autre approche et à nous faire part de vos commentaires dans Suivi des problèmes Kubeadm.

Notez que la fonctionnalité alpha HighAvailability est obsolète dans la version 1.12 et supprimée dans la version 1.13

Voir aussi La documentation de mise à niveau HA.

Avertissement: Cette page ne traite pas de l'exécution de votre cluster sur un fournisseur de cloud. Dans un environnement Cloud, les approches documentées ici ne fonctionnent ni avec des objets de type load balancer, ni avec des volumes persistants dynamiques.

Pré-requis

Pour les deux méthodes, vous avez besoin de cette infrastructure:

  • Trois machines qui répondent aux pré-requis des exigences de kubeadm pour les maîtres (masters)
  • Trois machines qui répondent aux pré-requis des exigences de kubeadm pour les workers
  • Connectivité réseau complète entre toutes les machines du cluster (public ou réseau privé)
  • Privilèges sudo sur toutes les machines
  • Accès SSH d'une machine à tous les nœuds du cluster
  • kubeadm et une kubelet installés sur toutes les machines. kubectl est optionnel.

Pour le cluster etcd externe uniquement, vous avez besoin également de:

  • Trois machines supplémentaires pour les membres etcd
Note: Les exemples suivants utilisent Calico en tant que fournisseur de réseau de Pod. Si vous utilisez un autre CNI, pensez à remplacer les valeurs par défaut si nécessaire.

Premières étapes pour les deux méthodes

Note: Toutes les commandes d'un control plane ou d'un noeud etcd doivent être éxecutées en tant que root.
  • Certains plugins réseau CNI tels que Calico nécessitent un CIDR tel que 192.168.0.0 / 16 et  certains comme Weave n'en ont pas besoin. Voir la Documentation du CNI réseau. Pour ajouter un CIDR de pod, définissez le champ podSubnet: 192.168.0.0 / 16 sous   l'objet networking de ClusterConfiguration.

Créez un load balancer pour kube-apiserver

Note: Il existe de nombreuses configurations pour les équilibreurs de charge (load balancers). L'exemple suivant n'est qu'un exemple. Vos exigences pour votre cluster peuvent nécessiter une configuration différente.

  1. Créez un load balancer kube-apiserver avec un nom résolu en DNS.

    • Dans un environnement cloud, placez vos nœuds du control plane derrière un load balancer TCP. Ce load balancer distribue le trafic à tous les nœuds du control plane sains dans sa liste. La vérification de la bonne santé d'un apiserver est une vérification TCP sur le port que kube-apiserver écoute (valeur par défaut: 6443).

    • Il n'est pas recommandé d'utiliser une adresse IP directement dans un environnement cloud.

    • Le load balancer doit pouvoir communiquer avec tous les nœuds du control plane sur le port apiserver. Il doit également autoriser le trafic entrant sur son réseau de port d'écoute.

    • HAProxy peut être utilisé comme load balancer.

    • Assurez-vous que l'adresse du load balancer correspond toujours à       l'adresse de ControlPlaneEndpoint de kubeadm.

  2. Ajoutez les premiers nœuds du control plane au load balancer et testez la connexion:

    nc -v LOAD_BALANCER_IP PORT
    • Une erreur connection refused est attendue car l'apiserver n'est pas encore en fonctionnement. Cependant, un timeout signifie que le load balancer ne peut pas communiquer avec le nœud du control plane. Si un timeout survient, reconfigurez le load balancer pour communiquer avec le nœud du control plane.

  3. Ajouter les nœuds du control plane restants au groupe cible du load balancer.

Configurer SSH

SSH est requis si vous souhaitez contrôler tous les nœuds à partir d'une seule machine.

  1. Activer ssh-agent sur votre machine ayant accès à tous les autres nœuds du cluster:

    eval $(ssh-agent)

  2. Ajoutez votre clé SSH à la session:

    ssh-add ~/.ssh/path_to_private_key

  3. SSH entre les nœuds pour vérifier que la connexion fonctionne correctement.

    • Lorsque vous faites un SSH sur un noeud, assurez-vous d’ajouter l’option -A:

      ssh -A 10.0.0.7

    • Lorsque vous utilisez sudo sur n’importe quel nœud, veillez à préserver l’environnement afin que le SSH forwarding fonctionne:

      sudo -E -s

Control plane empilé et nœuds etcd

Étapes pour le premier nœud du control plane

  1. Sur le premier nœud du control plane, créez un fichier de configuration appelé kubeadm-config.yaml:

    apiVersion: kubeadm.k8s.io/v1beta1
kind: ClusterConfiguration
kubernetesVersion: stable
apiServer:
  certSANs:
  - "LOAD_BALANCER_DNS"
controlPlaneEndpoint: "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT"
    • kubernetesVersion doit représenter la version de Kubernetes à utiliser. Cet exemple utilise stable.
    • controlPlaneEndpoint doit correspondre à l'adresse ou au DNS et au port du load balancer.
    • Il est recommandé que les versions de kubeadm, kubelet, kubectl et kubernetes correspondent.

  2. Assurez-vous que le nœud est dans un état sain:

    sudo kubeadm init --config=kubeadm-config.yaml

    Vous devriez voir quelque chose comme:

    ...

Vous pouvez à présent joindre n'importe quelle machine au cluster en lancant la commande suivante sur chaque nœeud en tant que root:

kubeadm join 192.168.0.200:6443 --token j04n3m.octy8zely83cy2ts --discovery-token-ca-cert-hash    sha256:84938d2a22203a8e56a787ec0c6ddad7bc7dbd52ebabc62fd5f4dbea72b14d1f
```

  1. Copiez ce jeton dans un fichier texte. Vous en aurez besoin plus tard pour joindre d’autres nœuds du control plane au cluster.

  2. Activez l'extension CNI Weave:

    kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"

  3. Tapez ce qui suit et observez les pods des composants démarrer:

    kubectl get pod -n kube-system -w
    • Il est recommandé de ne joindre les nouveaux nœuds du control plane qu'après l'initialisation du premier nœud.

  4. Copiez les fichiers de certificat du premier nœud du control plane dans les autres:

    Dans l'exemple suivant, remplacez CONTROL_PLANE_IPS par les adresses IP des autres nœuds du control plane.

    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
    scp /etc/kubernetes/pki/etcd/ca.key "${USER}"@$host:etcd-ca.key
    scp /etc/kubernetes/admin.conf "${USER}"@$host:
done
Avertissement: N'utilisez que les certificats de la liste ci-dessus. kubeadm se chargera de générer le reste des certificats avec les SANs requis pour les instances du control plane qui se joignent. Si vous copiez tous les certificats par erreur, la création de noeuds supplémentaires pourrait échouer en raison d'un manque de SANs requis.

Étapes pour le reste des nœuds du control plane

  1. Déplacer les fichiers créés à l'étape précédente où scp était utilisé:

    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
mv /home/${USER}/etcd-ca.key /etc/kubernetes/pki/etcd/ca.key
mv /home/${USER}/admin.conf /etc/kubernetes/admin.conf

    Ce processus écrit tous les fichiers demandés dans le dossier /etc/kubernetes.

  2. Lancez kubeadm join sur ce nœud en utilisant la commande de join qui vous avait été précédemment donnée par kubeadm init sur le premier noeud. Ça devrait ressembler a quelque chose comme ça:

    sudo kubeadm join 192.168.0.200:6443 --token j04n3m.octy8zely83cy2ts --discovery-token-ca-cert-hash sha256:84938d2a22203a8e56a787ec0c6ddad7bc7dbd52ebabc62fd5f4dbea72b14d1f --experimental-control-plane
    • Remarquez l'ajout de l'option --experimental-control-plane. Ce paramètre automatise l'adhésion au control plane du cluster.

  3. Tapez ce qui suit et observez les pods des composants démarrer:

    kubectl get pod -n kube-system -w

  4. Répétez ces étapes pour le reste des nœuds du control plane.

Noeuds etcd externes

Configurer le cluster etcd

Configurer le premier nœud du control plane

  1. Copiez les fichiers suivants de n’importe quel nœud du cluster etcd vers ce nœud.:

    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}":
    • Remplacez la valeur de CONTROL_PLANE par l'utilisateur@hostname de cette machine.

  2. Créez un fichier YAML appelé kubeadm-config.yaml avec le contenu suivant:

    apiVersion: kubeadm.k8s.io/v1beta1
kind: ClusterConfiguration
kubernetesVersion: stable
apiServer:
  certSANs:
  - "LOAD_BALANCER_DNS"
controlPlaneEndpoint: "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT"
etcd:
    external:
        endpoints:
        - https://ETCD_0_IP:2379
        - https://ETCD_1_IP:2379
        - https://ETCD_2_IP:2379
        caFile: /etc/kubernetes/pki/etcd/ca.crt
        certFile: /etc/kubernetes/pki/apiserver-etcd-client.crt
        keyFile: /etc/kubernetes/pki/apiserver-etcd-client.key

    • La différence entre etcd empilé et externe, c’est que nous utilisons le champ external pour etcd dans la configuration de kubeadm. Dans le cas de la topologie etcd empilée, c'est géré automatiquement.

    • Remplacez les variables suivantes dans le modèle (template) par les valeurs appropriées pour votre cluster:

      • LOAD_BALANCER_DNS
      • LOAD_BALANCER_PORT
      • ETCD_0_IP
      • ETCD_1_IP
      • ETCD_2_IP

  3. Lancez kubeadm init --config kubeadm-config.yaml sur ce nœud.

  4. Ecrivez le résultat de la commande de join dans un fichier texte pour une utilisation ultérieure.

  5. Appliquer le plugin CNI Weave:

    kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"

Étapes pour le reste des nœuds du control plane

Pour ajouter le reste des nœuds du control plane, suivez ces instructions. Les étapes sont les mêmes que pour la configuration etcd empilée, à l’exception du fait qu'un membre etcd local n'est pas créé.

Pour résumer:

  • Assurez-vous que le premier nœud du control plane soit complètement initialisé.
  • Copier les certificats entre le premier nœud du control plane et les autres nœuds du control plane.
  • Joignez chaque nœud du control plane à l'aide de la commande de join que vous avez enregistrée dans un fichier texte, puis ajoutez l'option --experimental-control-plane.

Tâches courantes après l'amorçage du control plane

Installer un réseau de pod

Suivez ces instructions afin d'installer le réseau de pod. Assurez-vous que cela correspond au pod CIDR que vous avez fourni dans le fichier de configuration principal.

Installer les workers

Chaque nœud worker peut maintenant être joint au cluster avec la commande renvoyée à partir du resultat de n’importe quelle commande kubeadm init. L'option --experimental-control-plane ne doit pas être ajouté aux nœuds workers.

Dernière modification September 17, 2020 at 6:18 PM PST : fixing language issues on HA-related FR content (8729c6d36)