Cette page explique deux approches différentes pour configurer un Kubernetes à haute disponibilité. cluster utilisant kubeadm:
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 fonctionne ni avec des objets de type load balancer, ni avec des volumes persistants dynamiques.
Pour les deux méthodes, vous avez besoin de cette infrastructure:
kubeadm
et une kubelet
installés sur toutes les machines. kubectl
est optionnel.Pour le cluster etcd externe uniquement, vous avez besoin également de:
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.
Note: Toutes les commandes d’un control plane ou d’un noeud etcd doivent être éxecutées en tant que root.
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
deClusterConfiguration
.Note: Il existe de nombreuses configurations pour les équilibreurs de charge (load balancer). L’exemple suivant n’est qu’un exemple. Vos exigences pour votre cluster peuvent nécessiter une configuration différente.
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.
Ajoutez les premiers nœuds du control plane au load balancer et testez la connexion:
nc -v LOAD_BALANCER_IP PORT
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.Ajouter les nœuds du control plane restants au groupe cible du load balancer.
SSH est requis si vous souhaitez contrôler tous les nœuds à partir d’une seule machine.
Activer ssh-agent sur votre machine ayant accès à tous les autres nœuds du cluster:
eval $(ssh-agent)
Ajoutez votre clé SSH à la session:
ssh-add ~/.ssh/path_to_private_key
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
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.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
Copiez ce jeton dans un fichier texte. Vous en aurez besoin plus tard pour joindre d’autres nœuds du control plane au cluster.
Activez l’extension CNI Weave:
kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
Tapez ce qui suit et observez les pods des composants démarrer:
kubectl get pod -n kube-system -w
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.
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
.
Lancez kubeadm join
sur ce nœud en utilisant la commande de join qui vous avait été précédemment
donnée parkubeadm 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
--experimental-control-plane
. Ce paramètre automatise l’adhésion au
control plane du cluster.Tapez ce qui suit et observez les pods des composants démarrer:
kubectl get pod -n kube-system -w
Répétez ces étapes pour le reste des nœuds du control plane.
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}":
CONTROL_PLANE
par l’utilisateur@hostname
de cette machine.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
Lancez kubeadm init --config kubeadm-config.yaml
sur ce nœud.
Ecrivez le résultat de la commande de join dans un fichier texte pour une utilisation ultérieure.
Appliquer le plugin CNI Weave:
kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
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:
--experimental-control-plane
.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.
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.
Cette page est elle utile ?
Thanks for the feedback. If you have a specific, answerable question about how to use Kubernetes, ask it on Stack Overflow. Open an issue in the GitHub repo if you want to report a problem or suggest an improvement.