Utilisez cette page pour trouver le type de solution qui correspond le mieux à vos besoins.
Le choix de distribution Kubernetes dépend des ressources dont vous disposez et de la flexibilité dont vous avez besoin.
Vous pouvez exécuter Kubernetes presque partout, de votre ordinateur portable aux machines virtuelles d'un fournisseur de cloud jusqu'à un rack de serveurs en bare metal.
Vous pouvez également mettre en place un cluster entièrement géré en exécutant une seule commande ou bien créer votre propre cluster personnalisé sur vos serveurs bare-metal.
Solutions locales
La solution locale, installée sur votre machine, est un moyen facile de démarrer avec Kubernetes. Vous
pouvez créer et tester des clusters Kubernetes sans vous soucier de la consommation
des ressources et des quotas d'un cloud.
Vous devriez choisir une solution locale si vous souhaitez :
Essayer ou commencer à apprendre Kubernetes
Développer et réaliser des tests sur des clusters locaux
Les solutions hébergées sont un moyen pratique de créer et de maintenir des clusters Kubernetes. Elles
permettent de gérer et d'exploiter vos clusters pour que vous n'ayez pas à le faire.
Vous devriez choisir une solution hébergée si vous :
Voulez une solution entièrement gérée
Voulez vous concentrer sur le développement de vos applications ou services
N'avez pas d'équipe de Site Reliability Engineering (SRE) dédiée, mais que vous souhaitez une haute disponibilité.
Vous n'avez pas les ressources pour héberger et surveiller vos clusters
Ces solutions vous permettent de créer des clusters Kubernetes avec seulement quelques commandes et
sont activement développées et bénéficient du soutien actif de la communauté. Elles peuvent également être hébergés sur
un ensemble de fournisseurs de Cloud de type IaaS, mais elles offrent plus de liberté et de flexibilité en contrepartie
d'un effort à fournir plus important.
Vous devriez choisir une solution cloud clés en main si vous :
Voulez plus de contrôle sur vos clusters que ne le permettent les solutions hébergées
Voulez réaliser vous même un plus grand nombre d'operations
Les solutions personnalisées vous offrent le maximum de liberté sur vos clusters, mais elles nécessitent plus
d'expertise. Ces solutions vont du bare-metal aux fournisseurs de cloud sur
différents systèmes d'exploitation.
Minikube est un outil facilitant l’exécution locale de Kubernetes.
Minikube exécute un cluster Kubernetes à nœud unique dans une machine virtuelle (VM) de votre ordinateur portable pour les utilisateurs qui souhaitent essayer Kubernetes ou le développer au quotidien.
Fonctionnalités de Minikube
Minikube prend en charge les fonctionnalités Kubernetes suivantes:
Cette brève démonstration vous explique comment démarrer, utiliser et supprimer les minikube localement.
Suivez les étapes ci-dessous pour commencer et explorer Minikube.
Lancez Minikube et créez un cluster:
minikube start
Le résultat est similaire à ceci:
Starting local Kubernetes cluster...
Running pre-create checks...
Creating machine...
Starting local Kubernetes cluster...
Pour plus d'informations sur le démarrage de votre cluster avec une version spécifique de Kubernetes, une machine virtuelle ou un environnement de conteneur, voir Démarrage d'un cluster.
Vous pouvez maintenant interagir avec votre cluster à l'aide de kubectl.
Pour plus d'informations, voir Interagir avec votre cluster.
Créons un déploiement Kubernetes en utilisant une image existante nommée echoserver, qui est un serveur HTTP, et exposez-la sur le port 8080 à l’aide de --port.
La commande minikube start peut être utilisée pour démarrer votre cluster.
Cette commande crée et configure une machine virtuelle qui exécute un cluster Kubernetes à un seul nœud.
Cette commande configure également kubectl pour communiquer avec ce cluster.
Note:
Si vous êtes derrière un proxy Web, vous devez transmettre ces informations à la commande minikube start:
Malheureusement, définir les seules variables d'environnement ne fonctionne pas.
Minikube crée également un contexte "minikube" et le définit par défaut dans kubectl.
Pour revenir à ce contexte, exécutez la commande suivante: kubectl config use-context minikube.
Spécifier la version de Kubernetes
Vous pouvez spécifier la version de Kubernetes pour Minikube à utiliser en ajoutant la chaîne --kubernetes-version à la commande minikube start.
Par exemple, pour exécuter la version 1.32.0, procédez comme suit:
minikube start --kubernetes-version v1.32.0
Spécification du pilote de machine virtuelle
Vous pouvez changer le pilote de machine virtuelle en ajoutant l'indicateur --vm-driver=<nom_du_pilote> à minikube start.
Par exemple, la commande serait:
minikube start --vm-driver=<nom_du_pilote>
Minikube prend en charge les pilotes suivants:
Note:
Voir DRIVERS pour plus de détails sur les pilotes pris en charge et comment installer les plugins.
none (Exécute les composants Kubernetes sur l’hôte et non sur une machine virtuelle. Il n'est pas recommandé d'exécuter le pilote none sur des postes de travail personnels. L'utilisation de ce pilote nécessite Docker (docker installer) et un environnement Linux)
Démarrage d'un cluster sur des exécutions de conteneur alternatives
Vous pouvez démarrer Minikube aux exécutions de conteneurs suivantes.
Utiliser des images locales en réutilisant le démon Docker
Lorsque vous utilisez une seule machine virtuelle pour Kubernetes, il est utile de réutiliser le démon Docker intégré de Minikube.
La réutilisation du démon intégré signifie que vous n’avez pas besoin de créer un registre Docker sur votre ordinateur hôte et d’y insérer l’image.
Au lieu de cela, vous pouvez créer le même démon Docker que Minikube, ce qui accélère les expériences locales.
Note:
Assurez-vous de marquer votre image Docker avec autre chose que la plus récente et utilisez cette balise pour extraire l'image.
Parce que :latest est la valeur par défaut, avec une stratégie d'extraction d'image par défaut correspondante de Always, une erreur d'extraction d'image (ErrImagePull) est éventuellement générée si vous n'avez pas l'image Docker dans le registre par défaut de Docker (généralement DockerHub). .
Pour travailler avec le démon Docker sur votre hôte Mac/Linux, utilisez la commande docker-env dans votre shell:
eval$(minikube docker-env)
Vous pouvez maintenant utiliser Docker sur la ligne de commande de votre ordinateur hôte Mac/Linux pour communiquer avec le démon Docker dans la VM Minikube:
docker ps
Note:
Sur Centos 7, Docker peut signaler l’erreur suivante:
Could not read CA certificate "/etc/docker/ca.pem": open /etc/docker/ca.pem: no such file or directory
Vous pouvez résoudre ce problème en mettant à jour /etc/sysconfig/docker pour vous assurer que les modifications de l'environnement de Minikube sont respectées:
Minikube a une fonction de "configurateur" qui permet aux utilisateurs de configurer les composants Kubernetes avec des valeurs arbitraires.
Pour utiliser cette fonctionnalité, vous pouvez utiliser l'indicateur --extra-config de la commande minikube start.
Cet indicateur est répété, vous pouvez donc le transmettre plusieurs fois avec plusieurs valeurs différentes pour définir plusieurs options.
Cet indicateur prend une chaîne de la forme composant.key=valeur, où composant est l'une des chaînes de la liste ci-dessous, key est une valeur de la structure de configuration et valeur est la valeur à définir.
Des clés valides peuvent être trouvées en examinant la documentation de Kubernetes composantconfigs pour chaque composant.
Voici la documentation pour chaque configuration prise en charge:
Pour changer le paramètre MaxPods en 5 sur le Kubelet, passez cet indicateur: --extra-config=kubelet.MaxPods=5.
Cette fonctionnalité prend également en charge les structures imbriquées.
Pour modifier le paramètre LeaderElection.LeaderElect sur true sur le planificateur, transmettez cet indicateur: --extra-config=scheduler.LeaderElection.LeaderElect=true.
Pour définir le AuthorizationMode du apiserver sur RBAC, vous pouvez utiliser: --extra-config=apiserver.authorization-mode=RBAC.
Arrêter un cluster
La commande minikube stop peut être utilisée pour arrêter votre cluster.
Cette commande arrête la machine virtuelle Minikube, mais conserve tout l'état et les données du cluster.
Le redémarrage du cluster le restaurera à son état précédent.
Suppression d'un cluster
La commande minikube delete peut être utilisée pour supprimer votre cluster.
Cette commande ferme et supprime la machine virtuelle Minikube.
Aucune donnée ou état n'est conservé.
La commande minikube start crée un contexte kubectl appelé "minikube".
Ce contexte contient la configuration pour communiquer avec votre cluster Minikube.
Minikube définit automatiquement ce contexte par défaut, mais si vous devez y revenir ultérieurement, exécutez:
kubectl config use-context minikube,
Ou passez le contexte sur chaque commande comme ceci: kubectl get pods --context=minikube.
Dashboard
Pour accéder au Kubernetes Dashboard, lancez cette commande dans un shell après avoir lancé Minikube pour obtenir l'adresse:
minikube dashboard
Services
Pour accéder à un service exposé via un port de nœud, exécutez cette commande dans un shell après le démarrage de Minikube pour obtenir l'adresse:
minikube service [-n NAMESPACE][--url] NAME
La mise en réseau
La machine virtuelle Minikube est exposée au système hôte via une adresse IP routable uniquement depuis le hôte, qui peut être obtenue à l'aide de la commande minikube ip.
Tous les services de type NodePort sont accessibles via cette adresse IP, sur le NodePort.
Pour déterminer le NodePort pour votre service, vous pouvez utiliser une commande kubectl comme celle-ci:
kubectl get service $SERVICE --output='jsonpath="{.spec.ports[0].nodePort}"'
Volumes persistants
Minikube supporte les PersistentVolumes de type hostPath.
Ces volumes persistants sont mappés vers un répertoire à l'intérieur de la VM Minikube.
La machine virtuelle Minikube démarre dans un fichier tmpfs, de sorte que la plupart des répertoires ne seront pas conservés lors des redémarrages avec (minikube stop).
Toutefois, Minikube est configuré pour conserver les fichiers stockés dans les répertoires d’hôte suivants:
/data
/var/lib/minikube
/var/lib/docker
Voici un exemple de configuration PersistentVolume permettant de conserver des données dans le répertoire /data:
Certains pilotes vont monter un dossier hôte dans la VM afin de pouvoir facilement partager des fichiers entre la VM et l'hôte.
Celles-ci ne sont pas configurables pour le moment et diffèrent selon le pilote et le système d'exploitation que vous utilisez.
Note:
Le partage de dossier hôte n'est pas encore implémenté dans le pilote KVM.
Pilote
OS
HostFolder
VM
VirtualBox
Linux
/home
/hosthome
VirtualBox
macOS
/Users
/Users
VirtualBox
Windows
C:/Users
/c/Users
VMware Fusion
macOS
/Users
/Users
Xhyve
macOS
/Users
/Users
Registres de conteneurs privés
Pour accéder à un registre de conteneurs privé, suivez les étapes de cette page.
Nous vous recommandons d'utiliser ImagePullSecrets, mais si vous souhaitez configurer l'accès sur la VM Minikube, vous pouvez placer le .dockercfg dans le repertoire /home/docker ou le config.json dans le repertoire /home/docker/.docker.
Add-ons
Pour que Minikube puisse démarrer ou redémarrer correctement des addons personnalisés, placez les addons que vous souhaitez lancer avec Minikube dans le répertoire ~/.minikube/addons.
Les extensions de ce dossier seront déplacées vers la VM Minikube et lancées à chaque démarrage ou redémarrage de Minikube.
Utilisation de Minikube avec un proxy HTTP
Minikube crée une machine virtuelle qui inclut Kubernetes et un démon Docker.
Lorsque Kubernetes tente de planifier des conteneurs à l'aide de Docker, le démon Docker peut nécessiter un accès réseau externe pour extraire les conteneurs.
Si vous êtes derrière un proxy HTTP, vous devrez peut-être fournir à Docker les paramètres de proxy.
Pour ce faire, transmettez les variables d’environnement requises en tant qu’indicateurs lors de la création de minikube start.
Si l'adresse de votre machine virtuelle est 192.168.99.100, il est probable que vos paramètres de proxy empêcheront kubectl de l'atteindre directement.
Pour contourner la configuration du proxy pour cette adresse IP, vous devez modifier vos paramètres no_proxy.
Vous pouvez le faire avec:
exportno_proxy=$no_proxy,$(minikube ip)
Problèmes connus
Les fonctionnalités nécessitant plusieurs nœuds ne fonctionneront pas dans Minikube.
Conception
Minikube utilise libmachine pour le provisionnement de machines virtuelles, et kubeadm mettre en service un cluster Kubernetes.
Pour plus d'informations sur Minikube, voir la proposition.
Liens supplémentaires
Objectifs et non-objectifs: Pour les objectifs et non-objectifs du projet Minikube, veuillez consulter notre roadmap.
Guide de développement: Voir CONTRIBUTING.md pour avoir un aperçu de comment envoyer des pull requests.
Construire Minikube: Pour obtenir des instructions sur la création / test de Minikube à partir des sources, voir le guide de build.
Ajout d'une nouvelle dépendance: Pour savoir comment ajouter une nouvelle dépendance à Minikube, voir la section guide d'ajout de dépendances.
Ajout d'un nouvel addon: Pour savoir comment ajouter un nouvel addon pour Minikube, reportez-vous au Ajout d’un addon.
MicroK8s: Les utilisateurs de Linux qui souhaitent éviter d’exécuter une machine virtuelle peuvent envisager MicroK8s.
Communauté
Les contributions, questions et commentaires sont les bienvenus et sont encouragés !
Les développeurs de minikube sont dans le canal #minikube du Slack de Kubernetes (recevoir une invitation ici).
Nous avons également la liste de diffusion dev@kubernetes Google Groupes.
Si vous publiez sur la liste, veuillez préfixer votre sujet avec "minikube:".
2 - Télécharger Kubernetes
Téléchargement Kubernetes release
2.1 - Construire une release
Construire une release de la documentation Kubernetes
Vous pouvez soit compiler une version à partir des sources, soit télécharger une version pré-compilée. Si vous ne
prévoyez pas de développer Kubernetes nous vous suggérons d'utiliser une version pré-compilée de la version actuelle,
que l'on peut trouver dans le répertoire Release Notes.
Le code source de Kubernetes peut être téléchargé sur le repo kubernetes/kubernetes.
Installer à partir des sources
Si vous installez simplement une version à partir des sources, il n'est pas nécessaire de mettre en place un environnement golang complet car tous les builds se font dans un conteneur Docker.
Construire une release est simple.
git clone https://github.com/kubernetes/kubernetes.git
cd kubernetes
make release
Pour plus de détails sur le processus de release, voir le repertoire build dans kubernetes/kubernetes.
3 - Environnement de production
3.1 - Installer Kubernetes avec les outils de déploiement
3.1.1 - Déploiement d'un cluster avec kubeadm
3.1.1.1 - Installer kubeadm
Cette page vous apprend comment installer la boîte à outils kubeadm.
Pour plus d'informations sur la création d'un cluster avec kubeadm, une fois que vous avez effectué ce processus d'installation, voir la page: Utiliser kubeadm pour créer un cluster.
Pré-requis
Une ou plusieurs machines exécutant:
Ubuntu 16.04+
Debian 9+
CentOS 7
Red Hat Enterprise Linux (RHEL) 7
Fedora 25+
HypriotOS v1.0.1+
Flatcar Container Linux (testé avec 2512.3.0)
2 Go ou plus de RAM par machine (toute quantité inférieure laissera peu de place à vos applications)
2 processeurs ou plus
Connectivité réseau complète entre toutes les machines du cluster (réseau public ou privé)
Nom d'hôte, adresse MAC et product_uuid uniques pour chaque nœud. Voir ici pour plus de détails.
Certains ports doivent êtres ouverts sur vos machines. Voir ici pour plus de détails.
Swap désactivé. Vous devez impérativement désactiver le swap pour que la kubelet fonctionne correctement.
Vérifiez que les adresses MAC et product_uuid sont uniques pour chaque nœud
Vous pouvez obtenir l'adresse MAC des interfaces réseau en utilisant la commande ip link ou ifconfig -a
Le product_uuid peut être vérifié en utilisant la commande sudo cat /sys/class/dmi/id/product_uuid
Il est très probable que les périphériques matériels aient des adresses uniques, bien que
certaines machines virtuelles puissent avoir des valeurs identiques. Kubernetes utilise ces valeurs pour identifier de manière unique les nœuds du cluster.
Si ces valeurs ne sont pas uniques à chaque nœud, le processus d'installation
peut échouer.
Vérifiez les cartes réseaux
Si vous avez plusieurs cartes réseaux et que vos composants Kubernetes ne sont pas accessibles par la route par défaut,
nous vous recommandons d’ajouter une ou plusieurs routes IP afin que les adresses de cluster Kubernetes soient acheminées via la carte approprié.
Permettre à iptables de voir le trafic ponté
Assurez-vous que le module br_netfilter est chargé. Cela peut être fait en exécutant lsmod | grep br_netfilter. Pour le charger explicitement, appelez sudo modprobe br_netfilter.
Pour que les iptables de votre nœud Linux voient correctement le trafic ponté, vous devez vous assurer que net.bridge.bridge-nf-call-iptables est défini sur 1 dans votre configuration sysctl, par ex.
Tous les numéros de port marqués d'un * sont écrasables. Vous devrez donc vous assurer que
les ports personnalisés que vous utilisez sont également ouverts.
Bien que les ports etcd soient inclus dans les nœuds masters, vous pouvez également héberger
votre propre cluster etcd en externe ou sur des ports personnalisés.
Le plug-in de réseau de pod que vous utilisez (voir ci-dessous) peut également nécessiter certains ports à ouvrir.
Étant donné que cela diffère d’un plugin à l’autre, veuillez vous reporter à la
documentation des plugins sur le(s) port(s) requis(s).
Installation du runtime
Pour exécuter des conteneurs dans des pods, Kubernetes utilise un
container runtime.
Par défaut, Kubernetes utilise le
Container Runtime Interface (CRI)
pour s'interfacer avec votre environnement d'exécution de conteneur choisi.
Si vous ne spécifiez pas de runtime, kubeadm essaie automatiquement de détecter un
Runtime de conteneur en parcourant une liste de sockets de domaine Unix bien connus.
Le tableau suivant répertorie les environnements d'exécution des conteneurs et leurs chemins de socket associés:
Les environnements d'exécution des conteneurs et leurs chemins de socket
Runtime
Chemin vers le socket de domaine Unix
Docker
/var/run/docker.sock
containerd
/run/containerd/containerd.sock
CRI-O
/var/run/crio/crio.sock
Si Docker et containerd sont détectés, Docker est prioritaire. C'est
nécessaire car Docker 18.09 est livré avec containerd et les deux sont détectables même si vous
installez Docker.
Si deux autres environnements d'exécution ou plus sont détectés, kubeadm se ferme avec une erreur.
Le kubelet s'intègre à Docker via l'implémentation CRI intégrée de dockershim.
Par défaut, kubeadm utilise Docker comme environnement d'exécution du conteneur.
Le kubelet s'intègre à Docker via l'implémentation CRI intégrée de dockershim.
Installation de kubeadm, des kubelets et de kubectl
Vous installerez ces paquets sur toutes vos machines:
kubeadm: la commande pour initialiser le cluster.
la kubelet: le composant qui s'exécute sur toutes les machines de votre cluster et fait des actions
comme le démarrage des pods et des conteneurs.
kubectl: la ligne de commande utilisée pour parler à votre cluster.
kubeadm n'installera pas ni ne gèrera les kubelet ou kubectl pour vous.
Vous devez vous assurer qu'ils correspondent à la version du control plane de Kubernetes que vous souhaitez que kubeadm installe pour vous. Si vous ne le faites pas, vous risquez qu'une
erreur de version se produise, qui pourrait conduire à un comportement inattendu.
Cependant, une version mineure entre les kubelets et le control plane est pris en charge,
mais la version de la kubelet ne doit jamais dépasser la version de l'API server.
Par exemple, les kubelets exécutant la version 1.7.0 devraient être entièrement compatibles avec un API server en 1.8.0,
mais pas l'inverse.
Ces instructions excluent tous les packages Kubernetes de toutes les mises à niveau du système d'exploitation.
C’est parce que kubeadm et Kubernetes ont besoin d'une
attention particulière lors de la mise à niveau.
Pour plus d'informations sur les compatibilités de version, voir:
Mettre SELinux en mode permissif en lançant setenforce 0 et sed ... le désactive efficacement.
C'est nécessaire pour permettre aux conteneurs d'accéder au système de fichiers hôte, qui est nécessaire par exemple pour les réseaux de pod.
Vous devez le faire jusqu'à ce que le support de SELinux soit amélioré dans Kubelet.
Vous pouvez laisser SELinux activé si vous savez comment le configurer, mais il peut nécessiter des paramètres qui ne sont pas pris en charge par kubeadm.
Installez les plugins CNI (requis pour la plupart des réseaux de pods) :
Définissez le répertoire pour télécharger les fichiers de commande
Note:
La variable DOWNLOAD_DIR doit être définie sur un répertoire accessible en écriture.
Si vous exécutez Flatcar Container Linux, définissez DOWNLOAD_DIR=/opt/bin
CRICTL_VERSION="v1.22.0"ARCH="amd64"curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-${ARCH}.tar.gz" | sudo tar -C $DOWNLOAD_DIR -xz
Installez kubeadm, kubelet, kubectl et ajoutez un service systemd kubelet:
RELEASE_VERSION="v0.6.0"
RELEASE="$(curl -sSL https://dl.k8s.io/release/stable.txt)"ARCH="amd64"cd$DOWNLOAD_DIRsudo curl -L --remote-name-all https://dl.k8s.io/release/${RELEASE}/bin/linux/${ARCH}/{kubeadm,kubelet,kubectl}sudo chmod +x {kubeadm,kubelet,kubectl}curl -sSL "https://raw.githubusercontent.com/kubernetes/release/${RELEASE_VERSION}/cmd/kubepkg/templates/latest/deb/kubelet/lib/systemd/system/kubelet.service" | sed "s:/usr/bin:${DOWNLOAD_DIR}:g" | sudo tee /etc/systemd/system/kubelet.service
sudo mkdir -p /etc/systemd/system/kubelet.service.d
curl -sSL "https://raw.githubusercontent.com/kubernetes/release/${RELEASE_VERSION}/cmd/kubepkg/templates/latest/deb/kubeadm/10-kubeadm.conf" | sed "s:/usr/bin:${DOWNLOAD_DIR}:g" | sudo tee /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
Activez et démarrez kubelet :
sudo systemctl enable --now kubelet
Note:
La distribution Linux Flatcar Container monte le répertoire /usr comme un système de fichiers en lecture seule.
Avant de démarrer votre cluster, vous devez effectuer des étapes supplémentaires pour configurer un répertoire accessible en écriture.
Consultez le Guide de dépannage de Kubeadm pour savoir comment configurer un répertoire accessible en écriture.
Kubelet redémarre maintenant toutes les quelques secondes,
car il attend les instructions de kubeadm dans une boucle de crash.
Configurer le driver de cgroup utilisé par la kubelet sur un nœud master
Lorsque vous utilisez Docker, kubeadm détecte automatiquement le pilote ( driver ) de cgroup pour kubelet
et le configure dans le fichier /var/lib/kubelet/config.yaml lors de son éxecution.
Si vous utilisez un autre CRI, vous devez passer votre valeur cgroupDriver avec kubeadm init, comme ceci :
Veuillez noter que vous devez seulement le faire si le driver de cgroupe de votre CRI
n'est pas cgroupfs, car c'est déjà la valeur par défaut dans la kubelet.
Note:
Depuis que le paramètre --cgroup-driver est obsolète par kubelet, si vous l'avez dans/var/lib/kubelet/kubeadm-flags.env
ou /etc/default/kubelet(/etc/sysconfig/kubelet pour les RPM), veuillez le supprimer et utiliser à la place KubeletConfiguration
(stocké dans/var/lib/kubelet/config.yaml par défaut).
3.1.1.2 - Création d'un Cluster à master unique avec kubeadm
Création d'un Cluster à master unique avec kubeadm
kubeadm vous aide à démarrer un cluster Kubernetes minimum,
viable et conforme aux meilleures pratiques. Avec kubeadm, votre cluster
doit passer les tests de Conformité Kubernetes.
Kubeadm prend également en charge d'autres fonctions du cycle de vie, telles que les mises
à niveau, la rétrogradation et la gestion des
bootstrap tokens.
Comme vous pouvez installer kubeadm sur différents types de machines (par exemple, un ordinateur
portable, un serveur,
Raspberry Pi, etc.), il est parfaitement adapté à l'intégration avec des systèmes d'approvisionnement
comme Terraform ou Ansible.
La simplicité de kubeadm lui permet d'être utilisé dans une large gamme de cas d'utilisation:
Les nouveaux utilisateurs peuvent commencer par kubeadm pour essayer Kubernetes pour la première
fois.
Les utilisateurs familiarisés avec Kubernetes peuvent créer des clusters avec kubeadm et tester
leurs applications.
Les projets plus importants peuvent inclure kubeadm en tant que brique de base dans un système
plus complexe pouvant également inclure d'autres outils d'installation.
Kubeadm est conçu pour être un moyen simple pour les nouveaux utilisateurs de commencer à essayer
Kubernetes, pour la première fois éventuellement. C'est un moyen pour les utilisateurs avancés de
tester leur application en même temps qu'un cluster facilement, et aussi être
une brique de base dans un autre écosystème et/ou un outil d’installation avec une plus grand
portée.
Vous pouvez installer très facilement kubeadm sur des systèmes d'exploitation prenant en charge
l'installation des paquets deb ou rpm. Le SIG responsable de kubeadm,
SIG Cluster Lifecycle,
fournit ces paquets pré-construits pour vous,
mais vous pouvez également les construire à partir des sources pour d'autres systèmes d'exploitation.
Maturité de kubeadm
Elément
Niveau de maturité
Command line UX
GA
Implementation
GA
Config file API
beta
CoreDNS
GA
kubeadm alpha subcommands
alpha
High availability
alpha
DynamicKubeletConfig
alpha
Self-hosting
alpha
Les fonctionnalités globales de kubeadm sont GA. Quelques sous-fonctionnalités, comme
la configuration, les API de fichiers sont toujours en cours de développement. L'implémentation de la création du cluster
peut changer légèrement au fur et à mesure que l'outil évolue, mais la mise en œuvre globale devrait être assez stable.
Toutes les commandes sous kubeadm alpha sont par définition prises en charge au niveau alpha.
Calendrier de support
Les versions de Kubernetes sont généralement prises en charge pendant neuf mois et pendant cette
période, une version de correctif peut être publiée à partir de la branche de publication si un bug grave ou un
problème de sécurité est trouvé. Voici les dernières versions de Kubernetes et le calendrier de support
qui s'applique également à kubeadm.
Version de Kubernetes
Date de sortie de la version
Fin de vie
v1.6.x
Mars 2017
Décembre 2017
v1.7.x
Juin 2017
Mars 2018
v1.8.x
Septembre 2017
Juin 2018
v1.9.x
Décembre 2017
Septembre 2018
v1.10.x
Mars 2018
Décembre 2018
v1.11.x
Juin 2018
Mars 2019
v1.12.x
Septembre 2018
Juin 2019
v1.13.x
Décembre 2018
Septembre 2019
Pré-requis
Une ou plusieurs machines exécutant un système d'exploitation compatible deb/rpm, par exemple Ubuntu ou CentOS
2 Go ou plus de RAM par machine. Si vous essayez moins cela laissera trop peu de place pour vos applications.
2 processeurs ou plus sur le master
Connectivité réseau entre toutes les machines du cluster, qu'il soit public ou privé.
Si vous avez déjà installé kubeadm, lancez apt-get update && apt-get upgrade ou yum update pour obtenir la dernière version de kubeadm.
Lorsque vous effectuez une mise à niveau, la kubelet redémarre plusieurs fois au bout de quelques
secondes car elle attend dans une boucle de blocage
kubeadm pour lui dire quoi faire. Ce fonctionnement est normal.
Une fois que vous avez initialisé votre master, la kubelet s'exécute normalement.
Initialiser votre master
Le master est la machine sur laquelle s'exécutent les composants du control plane, y compris
etcd (la base de données du cluster) et l'API serveur (avec lequel la CLI kubectl communique).
Choisissez un add-on réseau pour les pods et vérifiez s’il nécessite des arguments à
passer à l'initialisation de kubeadm. Selon le
fournisseur tiers que vous choisissez, vous devrez peut-être définir le --pod-network-cidr sur
une valeur spécifique au fournisseur. Voir Installation d'un add-on réseau de pod.
(Facultatif) Sauf indication contraire, kubeadm utilise l'interface réseau associée
avec la passerelle par défaut pour annoncer l’IP du master. Pour utiliser une autre
interface réseau, spécifiez l'option --apiserver-advertise-address=<ip-address>
à kubeadm init. Pour déployer un cluster Kubernetes en utilisant l’adressage IPv6, vous devez
spécifier une adresse IPv6, par exemple --apiserver-advertise-address=fd00::101
(Optional) Lancez kubeadm config images pull avant de faire kubeadm init pour vérifier la
connectivité aux registres gcr.io.
Pour personnaliser les composants du control plane, y compris l'affectation facultative d'IPv6
à la sonde liveness, pour les composants du control plane et du serveur etcd, fournissez des arguments
supplémentaires à chaque composant, comme indiqué dans les arguments personnalisés.
Pour lancer encore une fois kubeadm init, vous devez d'abord détruire le cluster.
Si vous joignez un nœud avec une architecture différente par rapport à votre cluster, créez un
Déploiement ou DaemonSet pour kube-proxy et kube-dns sur le nœud. C’est nécéssaire car les images Docker pour ces
composants ne prennent actuellement pas en charge la multi-architecture.
kubeadm init exécute d’abord une série de vérifications préalables pour s’assurer que la machine
est prête à exécuter Kubernetes. Ces vérifications préalables exposent des avertissements et se terminent
en cas d'erreur. Ensuite kubeadm init télécharge et installe les composants du control plane du cluster.
Cela peut prendre plusieurs minutes. l'output devrait ressembler à:
[init] Using Kubernetes version: vX.Y.Z
[preflight] Running pre-flight checks
[preflight] Pulling images required for setting up a Kubernetes cluster
[preflight] This might take a minute or two, depending on the speed of your internet connection
[preflight] You can also perform this action in beforehand using 'kubeadm config images pull'
[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet-start] Activating the kubelet service
[certs] Using certificateDir folder "/etc/kubernetes/pki"
[certs] Generating "etcd/ca" certificate and key
[certs] Generating "etcd/server" certificate and key
[certs] etcd/server serving cert is signed for DNS names [kubeadm-master localhost] and IPs [10.138.0.4 127.0.0.1 ::1]
[certs] Generating "etcd/healthcheck-client" certificate and key
[certs] Generating "etcd/peer" certificate and key
[certs] etcd/peer serving cert is signed for DNS names [kubeadm-master localhost] and IPs [10.138.0.4 127.0.0.1 ::1]
[certs] Generating "apiserver-etcd-client" certificate and key
[certs] Generating "ca" certificate and key
[certs] Generating "apiserver" certificate and key
[certs] apiserver serving cert is signed for DNS names [kubeadm-master kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 10.138.0.4]
[certs] Generating "apiserver-kubelet-client" certificate and key
[certs] Generating "front-proxy-ca" certificate and key
[certs] Generating "front-proxy-client" certificate and key
[certs] Generating "sa" key and public key
[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
[kubeconfig] Writing "admin.conf" kubeconfig file
[kubeconfig] Writing "kubelet.conf" kubeconfig file
[kubeconfig] Writing "controller-manager.conf" kubeconfig file
[kubeconfig] Writing "scheduler.conf" kubeconfig file
[control-plane] Using manifest folder "/etc/kubernetes/manifests"
[control-plane] Creating static Pod manifest for "kube-apiserver"
[control-plane] Creating static Pod manifest for "kube-controller-manager"
[control-plane] Creating static Pod manifest for "kube-scheduler"
[etcd] Creating static Pod manifest for local etcd in "/etc/kubernetes/manifests"
[wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests". This can take up to 4m0s
[apiclient] All control plane components are healthy after 31.501735 seconds
[uploadconfig] storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[kubelet] Creating a ConfigMap "kubelet-config-X.Y" in namespace kube-system with the configuration for the kubelets in the cluster
[patchnode] Uploading the CRI Socket information "/var/run/dockershim.sock" to the Node API object "kubeadm-master" as an annotation
[mark-control-plane] Marking the node kubeadm-master as control-plane by adding the label "node-role.kubernetes.io/master=''"
[mark-control-plane] Marking the node kubeadm-master as control-plane by adding the taints [node-role.kubernetes.io/master:NoSchedule]
[bootstrap-token] Using token: <token>
[bootstrap-token] Configuring bootstrap tokens, cluster-info ConfigMap, RBAC Roles
[bootstraptoken] configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
[bootstraptoken] configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
[bootstraptoken] configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
[bootstraptoken] creating the "cluster-info" ConfigMap in the "kube-public" namespace
[addons] Applied essential addon: CoreDNS
[addons] Applied essential addon: kube-proxy
Your Kubernetes master has initialized successfully!
To start using your cluster, you need to run the following as a regular user:
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
https://kubernetes.io/fr/docs/concepts/cluster-administration/addons/
You can now join any number of machines by running the following on each node
as root:
kubeadm join <master-ip>:<master-port> --token <token> --discovery-token-ca-cert-hash sha256:<hash>
Pour que kubectl fonctionne pour votre utilisateur non root, exécutez ces commandes, qui font
également partie du resultat de la commande kubeadm init:
Alternativement, si vous êtes root, vous pouvez exécuter:
exportKUBECONFIG=/etc/kubernetes/admin.conf
Faites un enregistrement du retour de la commande kubeadm join que kubeadm init génère. Vous avez
besoin de cette commande pour joindre des noeuds à votre cluster.
Le jeton est utilisé pour l'authentification mutuelle entre le master et les nœuds qui veulent le rejoindre.
Le jeton est secret. Gardez-le en sécurité, parce que n'importe qui avec ce
jeton peut ajouter des nœuds authentifiés à votre cluster. Ces jetons peuvent être listés,
créés et supprimés avec la commande kubeadm token. Voir le
Guide de référence kubeadm.
Installation d'un add-on réseau
Avertissement:
Cette section contient des informations importantes sur l’ordre d’installation et de déploiement. Lisez-la attentivement avant de continuer.
Vous devez installer un add-on réseau pour pod afin que vos pods puissent communiquer les uns
avec les autres.
Le réseau doit être déployé avant toute application. De plus, CoreDNS ne démarrera pas avant
l’installation d’un réseau.
kubeadm ne prend en charge que les réseaux basés sur un CNI (et ne prend pas
en charge kubenet).
Plusieurs projets fournissent des réseaux de pod Kubernetes utilisant CNI, dont certains
supportent les network policies.
Allez voir la page des add-ons pour une liste complète
des add-ons réseau disponibles.
CNI bridge et
local-ipam
sont les seuls plug-ins de réseau IPv6 pris en charge dans Kubernetes version 1.9.
Notez que kubeadm configure un cluster sécurisé par défaut et impose l’utilisation de
RBAC.
Assurez-vous que votre manifeste de réseau prend en charge RBAC.
Veuillez également à ce que votre réseau Pod ne se superpose à aucun des réseaux hôtes,
car cela pourrait entraîner des problèmes.
Si vous constatez une collision entre le réseau de pod de votre plug-in de réseau et certains
de vos réseaux hôtes,
vous devriez penser à un remplacement de CIDR approprié et l'utiliser lors de kubeadm init avec
--pod-network-cidr et en remplacement du YAML de votre plugin réseau.
Vous pouvez installer un add-on réseau de pod avec la commande suivante:
kubectl apply -f <add-on.yaml>
Vous ne pouvez installer qu'un seul réseau de pod par cluster.
Pour que Calico fonctionne correctement, vous devez passer --pod-network-cidr = 192.168.0.0 / 16
à kubeadm init ou mettre à jour le fichier calico.yml pour qu'il corresponde à votre réseau de Pod.
Notez que Calico fonctionne uniquement sur amd64, arm64, ppc64le et s390x.
Canal utilise Calico pour les netpols et Flannel pour la mise en réseau. Reportez-vous à la
documentation Calico pour obtenir le guide de démarrage officiel.
Pour que Canal fonctionne correctement, --pod-network-cidr = 10.244.0.0 / 16 doit être passé à
kubeadm init. Notez que Canal ne fonctionne que sur amd64.
Ces commandes déploieront Cilium avec son propre etcd géré par l'opérateur etcd.
Note: Si vous utilisez kubeadm dans un seul noeud, veuillez enlever sa marque (taint) pour que
les pods etcd-operator puissent être déployés dans le nœud du control plane.
Une fois que tous les pods Cilium sont marqués «READY», vous commencez à utiliser votre cluster.
$ kubectl get pods -n kube-system --selector=k8s-app=cilium
NAME READY STATUS RESTARTS AGE
cilium-drxkl 1/1 Running 0 18m
Pour que flannel fonctionne correctement, vous devez passer --pod-network-cidr = 10.244.0.0 / 16 à kubeadm init.
Paramétrez /proc/sys/net/bridge/bridge-nf-call-iptables à «1» en exécutant
sysctl net.bridge.bridge-nf-call-iptables = 1
passez le trafic IPv4 bridged à iptables. Ceci est nécessaire pour que certains plugins CNI
fonctionnent, pour plus d'informations
allez voir ici.
Notez que flannel fonctionne sur amd64, arm, arm64, ppc64le et s390x sous Linux.
Windows (amd64) est annoncé comme supporté dans la v0.11.0 mais son utilisation n’est pas
documentée.
Paramétrez /proc/sys/net/bridge/bridge-nf-call-iptables à «1» en exécutant
sysctl net.bridge.bridge-nf-call-iptables = 1
Cette commande indiquera de passer le trafic IPv4 bridgé à iptables.
Ceci est nécessaire pour que certains plugins CNI fonctionnent, pour plus d'informations
s'il vous plaît allez voir ici.
Kube-router s'appuie sur kube-controller-manager pour allouer le pod CIDR aux nœuds. Par conséquent,
utilisez kubeadm init avec l'option --pod-network-cidr.
Kube-router fournit un réseau de pod, une stratégie réseau et un proxy de service basé sur un
IP Virtual Server (IPVS) / Linux Virtual Server (LVS) hautement performant.
Pour plus d'informations sur la configuration du cluster Kubernetes avec Kube-router à l'aide de kubeadm,
veuillez consulter le guide d'installation.
Paramétrez /proc/sys/net/bridge/bridge-nf-call-iptables à 1 en exécutant
sysctl net.bridge.bridge-nf-call-iptables = 1
Cette commande indiquera de passer le trafic IPv4 bridged à iptables. Ceci est nécessaire pour que certains plugins CNI fonctionnent,
pour plus d'informations
veuillez consulter la documentation ici.
Le guide d'installation officiel de Romana est ici.
Paramétrez /proc/sys/net/bridge/bridge-nf-call-iptables à «1» en exécutant sysctl net.bridge.bridge-nf-call-iptables = 1
Cette commande indiquera de passer le trafic IPv4 bridged à iptables. Ceci est nécessaire pour que certains plugins CNI fonctionnent, pour plus d'informations
s'il vous plaît allez voir ici.
Le guide de configuration officiel de Weave Net est ici.
Weave Net fonctionne sur amd64, arm, arm64 et ppc64le sans aucune action supplémentaire requise.
Weave Net paramètre le mode hairpin par défaut. Cela permet aux pods de se connecter via leur adresse IP de service
s'ils ne connaissent pas leur Pod IP.
Fournit une solution SDN superposée, offrant un réseau multicouches, un réseau de cloud hybride,
prise en charge simultanée des couches superposées, application de la stratégie réseau, isolation du réseau,
chaînage de service et équilibrage de charge flexible.
Il existe de nombreuses manières flexibles d’installer JuniperContrail / TungstenFabric CNI.
Veuillez vous référer à ce guide de démarrage rapide: TungstenFabric
Une fois qu'un réseau de pod a été installé, vous pouvez vérifier qu'il fonctionne en
vérifiant que le pod CoreDNS est en cours d’exécution dans l'output de kubectl get pods --all-namespaces.
Et une fois que le pod CoreDNS est opérationnel, vous pouvez continuer en joignant vos nœuds.
Si votre réseau ne fonctionne pas ou si CoreDNS n'est pas en cours d'exécution, vérifiez
notre documentation de dépannage.
Isolation des nœuds du control plane
Par défaut, votre cluster ne déploie pas de pods sur le master pour des raisons de sécurité.
Si vous souhaitez pouvoir déployer des pods sur le master, par exemple, pour un
cluster Kubernetes mono-machine pour le développement, exécutez:
Avec un resultat ressemblant à quelque chose comme:
node "test-01" untainted
taint "node-role.kubernetes.io/master:" not found
taint "node-role.kubernetes.io/master:" not found
Cela supprimera la marque node-role.kubernetes.io/master de tous les nœuds qui
l'ont, y compris du nœud master, ce qui signifie que le scheduler sera alors capable
de déployer des pods partout.
Faire rejoindre vos nœuds
Les nœuds sont ceux sur lesquels vos workloads (conteneurs, pods, etc.) sont exécutées.
Pour ajouter de nouveaux nœuds à votre cluster, procédez comme suit pour chaque machine:
SSH vers la machine
Devenir root (par exemple, sudo su-)
Exécutez la commande qui a été récupérée sur l'output de kubeadm init. Par exemple:
Si vous n'avez pas le jeton, vous pouvez l'obtenir en exécutant la commande suivante sur le nœud master:
kubeadm token list
L'output est similaire à ceci:
TOKEN TTL EXPIRES USAGES DESCRIPTION EXTRA GROUPS
8ewj1p.9r9hcjoqgajrj4gi 23h 2018-06-12T02:51:28Z authentication, The default bootstrap system:
signing token generated by bootstrappers:
'kubeadm init'. kubeadm:
default-node-token
Par défaut, les jetons expirent après 24 heures. Si vous joignez un nœud au cluster après
l’expiration du jeton actuel,
vous pouvez créer un nouveau jeton en exécutant la commande suivante sur le nœud maître:
kubeadm token create
L'output est similaire à ceci:
5didvk.d09sbcov8ph2amjw
Si vous n'avez pas la valeur --discovery-token-ca-cert-hash, vous pouvez l'obtenir en
exécutant la suite de commande suivante sur le nœud master:
Pour spécifier un tuple IPv6 pour <maître-ip>: <maître-port>, l'adresse IPv6 doit être placée
entre crochets, par exemple: [fd00 :: 101]: 2073.
Le resultat devrait ressembler à quelque chose comme:
[preflight] Running pre-flight checks
... (log output of join workflow) ...
Node join complete:
* Certificate signing request sent to master and response
received.
* Kubelet informed of new secure connection details.
Run 'kubectl get nodes' on the master to see this machine join.
Quelques secondes plus tard, vous remarquerez ce nœud dans l'output de kubectl get node.
(Optionnel) Contrôler votre cluster à partir de machines autres que le master
Afin d'utiliser kubectl sur une autre machine (par exemple, un ordinateur portable) pour communiquer avec votre
cluster, vous devez copier le fichier administrateur kubeconfig de votre master
sur votre poste de travail comme ceci:
scp root@<master ip>:/etc/kubernetes/admin.conf .
kubectl --kubeconfig ./admin.conf get nodes
Note:
L'exemple ci-dessus suppose que l'accès SSH est activé pour root. Si ce n'est pas le cas,
vous pouvez copier le fichier admin.conf pour qu'il soit accessible à un autre utilisateur.
et scp en utilisant cet autre utilisateur à la place.
Le fichier admin.conf donne à l'utilisateur superuser des privilèges sur le cluster.
Ce fichier doit être utilisé avec parcimonie. Pour les utilisateurs normaux, il est recommandé de
générer une information d'identification unique pour laquelle vous ajoutez des privilèges à la liste blanche
(whitelist).
Vous pouvez faire ceci avec kubeadm alpha kubeconfig utilisateur --nom-client <CN>.
Le resultat de cette commande génèrera un fichier KubeConfig qui sera envoyé sur STDOUT, que vous
devrez enregistrer dans un fichier et donner à votre utilisateur. Après cela, créez la whitelist des
privilèges en utilisant kubectl create (cluster) rolebinding.
(Facultatif) Proxifier l'API Server vers localhost
Si vous souhaitez vous connecter à l'API server à partir de l'éxterieur du cluster, vous pouvez utiliser
kubectl proxy:
Vous pouvez maintenant accéder à l'API server localement à http://localhost:8001/api/v1
Destruction
Pour annuler ce que kubeadm a fait, vous devez d’abord
drainer le nœud
et assurez-vous que le nœud est vide avant de l'arrêter.
En communiquant avec le master en utilisant les informations d'identification appropriées, exécutez:
Ensuite, sur le nœud en cours de suppression, réinitialisez l'état de tout ce qui concerne kubeadm:
kubeadm reset
Le processus de réinitialisation ne réinitialise pas et ne nettoie pas les règles iptables ni les
tables IPVS. Si vous souhaitez réinitialiser iptables, vous devez le faire manuellement:
Si vous souhaitez réinitialiser les tables IPVS, vous devez exécuter la commande suivante:
ipvsadm -C
Si vous souhaitez recommencer Il suffit de lancer kubeadm init ou kubeadm join avec les
arguments appropriés.
Plus d'options et d'informations sur la
commande de réinitialisation de kubeadm.
Maintenir un cluster
Vous trouverez des instructions pour la maintenance des clusters kubeadm (mises à niveau,
rétrogradation, etc.) ici
Explorer les autres add-ons
Parcourez la liste des add-ons,
y compris des outils pour la journalisation, la surveillance, la stratégie réseau, la visualisation
et le contrôle de votre cluster Kubernetes.
Et après ?
Vérifiez que votre cluster fonctionne correctement avec Sonobuoy
Configurez la rotation des logs. Vous pouvez utiliser logrotate pour cela. Lorsque vous utilisez Docker,
vous pouvez spécifier des options de rotation des logs pour le démon Docker, par exemple
--log-driver = fichier_json --log-opt = taille_max = 10m --log-opt = fichier_max = 5.
Consultez Configurer et dépanner le démon Docker pour plus de détails.
L'outil CLI kubeadm de la version vX.Y peut déployer des clusters avec un control
plane de la version vX.Y ou vX. (Y-1).
kubeadm CLI vX.Y peut également mettre à niveau un cluster existant créé par kubeadm
de la version vX. (Y-1).
Pour cette raison, nous ne pouvons pas voir plus loin, kubeadm CLI vX.Y peut ou pas être
en mesure de déployer des clusters vX. (Y + 1).
Exemple: kubeadm v1.8 peut déployer des clusters v1.7 et v1.8 et mettre à niveau des
clusters v1.7 créés par kubeadm vers
v1.8.
Ces ressources fournissent plus d'informations sur le saut de version pris en
charge entre les kubelets et le control plane, ainsi que sur d'autres composants Kubernetes:
Les packages et fichiers binaires de kubeadm deb/rpm sont conçus pour amd64, arm (32 bits), arm64, ppc64le et s390x
suite à la multiplateforme proposal.
Les images de conteneur multiplatform pour le control plane et les addons sont également pris en charge depuis la v1.12.
Seuls certains fournisseurs de réseau proposent des solutions pour toutes les plateformes. Veuillez consulter la liste des
fournisseurs de réseau ci-dessus ou la documentation de chaque fournisseur pour déterminer si le fournisseur
prend en charge votre plate-forme.
Limitations
Remarque: kubeadm évolue continuellement et ces limitations seront résolues en temps voulu.
Le cluster créé ici a un seul master, avec une seule base de données etcd. Cela signifie que
si le master est irrécupérable, votre cluster peut perdre ses données et peut avoir besoin d'être recréé à
partir de zéro. L'ajout du support HA (plusieurs serveurs etcd, plusieurs API servers, etc.)
à kubeadm est encore en cours de developpement.
Contournement: régulièrement sauvegarder etcd.
le répertoire des données etcd configuré par kubeadm se trouve dans /var/lib/etcd sur le master.
Diagnostic
Si vous rencontrez des difficultés avec kubeadm, veuillez consulter nos
troubleshooting docs.
3.1.1.3 - Personnalisation de la configuration du control plane avec kubeadm
Personnalisation de la configuration du control plane avec kubeadm
FEATURE STATE:Kubernetes 1.12 [stable]
L'objet ClusterConfiguration de kubeadm expose le champ extraArgs qui peut
remplacer les indicateurs par défaut transmis au control plane à des composants
tels que l'APIServer, le ControllerManager et le Scheduler. Les composants sont
définis à l'aide des champs suivants:
apiServer
controllerManager
scheduler
Le champ extraArgs se compose de paires clé: valeur. Pour remplacer un indicateur
pour un composant du control plane:
Ajoutez les champs appropriés à votre configuration.
Ajoutez les indicateurs à remplacer dans le champ.
Pour plus de détails sur chaque champ de la configuration, vous pouvez accéder aux
pages de référence de l'API.
3.1.1.4 - Options pour la topologie en haute disponibilité
Topologie haute-disponibilité Kubernetes
Cette page explique les deux options de configuration de topologie de vos clusters Kubernetes
pour la haute disponibilité.
Vous pouvez configurer un cluster en haute disponibilité:
Avec des nœuds du control plane empilés, les nœuds etcd étant co-localisés avec des nœuds du control plane
Avec des nœuds etcd externes, où etcd s'exécute sur des nœuds distincts du control plane
Vous devez examiner attentivement les avantages et les inconvénients de chaque topologie avant
de configurer un cluster en haute disponibilité.
Topologie etcd empilée
Un cluster HA empilé est une topologie réseau
où le cluster de stockage de données distribuées est fourni par etcd et est superposé au
cluster formé par les noeuds gérés par kubeadm qui exécute les composants du control plane.
Chaque nœud du control plane exécute une instance de kube-apiserver, kube-scheduler et
kube-controller-manager.
Le kube-apiserver est exposé aux nœuds à l'aide d'un loadbalancer.
Chaque nœud du control plane crée un membre etcd local et ce membre etcd communique uniquement avec
le kube-apiserver de ce noeud. Il en va de même pour le kube-controller-manager local
et les instances de kube-scheduler.
Cette topologie couple les control planes et les membres etcd sur les mêmes nœuds. C'est
plus simple à mettre en place qu'un cluster avec des nœuds etcd externes et plus simple à
gérer pour la réplication.
Cependant, un cluster empilé présente un risque d'échec du couplage. Si un noeud tombe en panne,
un membre etcd et une instance du control plane sont perdus et la redondance est compromise. Vous
pouvez atténuer ce risque en ajoutant plus de nœuds au control plane.
Par conséquent, vous devez exécuter au moins trois nœuds de control plane empilés pour un cluster
en haute disponibilité.
C'est la topologie par défaut dans kubeadm. Un membre etcd local est créé automatiquement
sur les noeuds du control plane en utilisant kubeadm init et kubeadm join --experimental-control-plane.
Un cluster haute disponibilité avec un etcd externe est une
topologie réseau où le cluster de stockage de données
distribuées fourni par etcd est externe au cluster formé par les nœuds qui exécutent les composants
du control plane.
Comme la topologie etcd empilée, chaque nœud du control plane d'une topologie etcd externe exécute
une instance de kube-apiserver, kube-scheduler et kube-controller-manager. Et le kube-apiserver
est exposé aux nœuds workers à l’aide d’un load-balancer. Cependant, les membres etcd s'exécutent sur
des hôtes distincts et chaque hôte etcd communique avec le kube-apiserver de chaque nœud du control plane.
Cette topologie dissocie le control plane et le membre etcd. Elle fournit donc une configuration HA où
perdre une instance de control plane ou un membre etcd a moins d'impact et n'affecte pas la redondance du
cluster autant que la topologie HA empilée.
Cependant, cette topologie requiert le double du nombre d'hôtes de la topologie HA integrée.
Un minimum de trois machines pour les nœuds du control plane et de trois machines
pour les nœuds etcd est requis pour un cluster HA avec cette topologie.
3.1.1.5 - 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
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.
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.
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
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.
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.
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
Control plane empilé et nœuds etcd
Étapes pour le premier nœud du control plane
Sur le premier nœud du control plane, créez un fichier de configuration appelé kubeadm-config.yaml:
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
Déplacer les fichiers créés à l'étape précédente où scp était utilisé:
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 par kubeadm init sur le premier noeud. Ça devrait ressembler a quelque chose
comme ça:
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.
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.
3.1.1.6 - Configurer un cluster etcd en haute disponibilité avec kubeadm
Configuration d'un cluster etcd en haute disponibilité avec kubeadm
Par défaut, Kubeadm exécute un cluster etcd mono nœud dans un pod statique géré
par la kubelet sur le nœud du plan de contrôle (control plane). Ce n'est pas une configuration haute disponibilité puisque le cluster etcd ne contient qu'un seul membre et ne peut donc supporter
qu'aucun membre ne devienne indisponible. Cette page vous accompagne dans le processus de création
d'un cluster etcd à trois membres en haute disponibilité, pouvant être utilisé en tant que cluster externe lors de l’utilisation de kubeadm pour configurer un cluster kubernetes.
Pré-requis
Trois machines pouvant communiquer entre elles via les ports 2379 et 2380. Cette
methode utilise ces ports par défaut. Cependant, ils sont configurables via
le fichier de configuration kubeadm.
Certains paquets pour copier des fichiers entre les hôtes. Par exemple, ssh et scp.
Mise en place du cluster
L’approche générale consiste à générer tous les certificats sur un nœud et à ne distribuer que
les fichiers nécessaires aux autres nœuds.
Note:
kubeadm contient tout ce qui est nécessaire pour générer les certificats décrits ci-dessous;
aucun autre outil de chiffrement n'est requis pour cet exemple.
Configurez la kubelet pour qu'elle soit un gestionnaire de service pour etcd.
Etant donné qu'etcd a été créé en premier, vous devez remplacer la priorité de service en
créant un nouveau fichier unit qui a une priorité plus élevée que le fichier unit de la kubelet fourni
par kubeadm.
Générez un fichier de configuration kubeadm pour chaque machine qui éxécutera un membre etcd
en utilisant le script suivant.
# Update HOST0, HOST1, and HOST2 with the IPs or resolvable names of your hostsexportHOST0=10.0.0.6
exportHOST1=10.0.0.7
exportHOST2=10.0.0.8
# Create temp directories to store files that will end up on other hosts.mkdir -p /tmp/${HOST0}/ /tmp/${HOST1}/ /tmp/${HOST2}/
ETCDHOSTS=(${HOST0}${HOST1}${HOST2})NAMES=("infra0""infra1""infra2")for i in "${!ETCDHOSTS[@]}"; doHOST=${ETCDHOSTS[$i]}NAME=${NAMES[$i]}cat << EOF > /tmp/${HOST}/kubeadmcfg.yaml
apiVersion: "kubeadm.k8s.io/v1beta1"
kind: ClusterConfiguration
etcd:
local:
serverCertSANs:
- "${HOST}"
peerCertSANs:
- "${HOST}"
extraArgs:
initial-cluster: ${NAMES[0]}=https://${ETCDHOSTS[0]}:2380,${NAMES[1]}=https://${ETCDHOSTS[1]}:2380,${NAMES[2]}=https://${ETCDHOSTS[2]}:2380
initial-cluster-state: new
name: ${NAME}
listen-peer-urls: https://${HOST}:2380
listen-client-urls: https://${HOST}:2379
advertise-client-urls: https://${HOST}:2379
initial-advertise-peer-urls: https://${HOST}:2380
EOFdone
Générer l'autorité de certification
Si vous avez déjà une autorité de certification, alors la seule action qui est faite copie
les fichiers crt et key de la CA dans /etc/kubernetes/pki/etcd/ca.crt et
/etc/kubernetes/pki/etcd/ca.key. Une fois ces fichiers copiés,
passez à l'étape suivante, "Créer des certificats pour chaque membre".
Si vous ne possédez pas déjà de CA, exécutez cette commande sur $HOST0 (où vous
avez généré les fichiers de configuration pour kubeadm).
kubeadm init phase certs etcd-ca
Cela crée deux fichiers
/etc/kubernetes/pki/etcd/ca.crt
/etc/kubernetes/pki/etcd/ca.key
Créer des certificats pour chaque membre
kubeadm init phase certs etcd-server --config=/tmp/${HOST2}/kubeadmcfg.yaml
kubeadm init phase certs etcd-peer --config=/tmp/${HOST2}/kubeadmcfg.yaml
kubeadm init phase certs etcd-healthcheck-client --config=/tmp/${HOST2}/kubeadmcfg.yaml
kubeadm init phase certs apiserver-etcd-client --config=/tmp/${HOST2}/kubeadmcfg.yaml
cp -R /etc/kubernetes/pki /tmp/${HOST2}/
# cleanup non-reusable certificatesfind /etc/kubernetes/pki -not -name ca.crt -not -name ca.key -type f -delete
kubeadm init phase certs etcd-server --config=/tmp/${HOST1}/kubeadmcfg.yaml
kubeadm init phase certs etcd-peer --config=/tmp/${HOST1}/kubeadmcfg.yaml
kubeadm init phase certs etcd-healthcheck-client --config=/tmp/${HOST1}/kubeadmcfg.yaml
kubeadm init phase certs apiserver-etcd-client --config=/tmp/${HOST1}/kubeadmcfg.yaml
cp -R /etc/kubernetes/pki /tmp/${HOST1}/
find /etc/kubernetes/pki -not -name ca.crt -not -name ca.key -type f -delete
kubeadm init phase certs etcd-server --config=/tmp/${HOST0}/kubeadmcfg.yaml
kubeadm init phase certs etcd-peer --config=/tmp/${HOST0}/kubeadmcfg.yaml
kubeadm init phase certs etcd-healthcheck-client --config=/tmp/${HOST0}/kubeadmcfg.yaml
kubeadm init phase certs apiserver-etcd-client --config=/tmp/${HOST0}/kubeadmcfg.yaml
# No need to move the certs because they are for HOST0# clean up certs that should not be copied off this hostfind /tmp/${HOST2} -name ca.key -type f -delete
find /tmp/${HOST1} -name ca.key -type f -delete
Copier les certificats et les configurations kubeadm
Les certificats ont été générés et doivent maintenant être déplacés vers leur
hôtes respectifs.
Maintenant que les certificats et les configurations sont en place, il est temps de créer les
manifestes. Sur chaque hôte, exécutez la commande kubeadm pour générer un manifeste statique
pour etcd.
root@HOST0 $ kubeadm init phase etcd local --config=/tmp/${HOST0}/kubeadmcfg.yaml
root@HOST1 $ kubeadm init phase etcd local --config=$HOME/kubeadmcfg.yaml
root@HOST2 $ kubeadm init phase etcd local --config=$HOME/kubeadmcfg.yaml
Configurez ${ETCD_TAG} avec la version de votre image etcd. Par exemple v3.2.24.
Configurez ${HOST0} avec l'adresse IP de l'hôte que vous testez.
A suivre
Une fois que vous avez un cluster de 3 membres etcd qui fonctionne, vous pouvez continuer à
configurer un control plane hautement disponible utilisant la
méthode etcd externe avec kubeadm.
3.1.1.7 - Configuration des kubelet de votre cluster avec kubeadm
Configuration kubelet Kubernetes cluster kubeadm
FEATURE STATE:Kubernetes 1.11 [stable]
Le cycle de vie de l’outil CLI kubeadm est découplé de celui de la
kubelet, qui est un démon qui s'éxécute
sur chaque noeud du cluster Kubernetes. L'outil CLI de kubeadm est exécuté par l'utilisateur lorsque
Kubernetes est initialisé ou mis à niveau, alors que la kubelet est toujours exécutée en arrière-plan.
Comme la kubelet est un démon, elle doit être maintenue par une sorte d'init système ou un gestionnaire
de service. Lorsque la kubelet est installée à l'aide de DEB ou de RPM,
systemd est configuré pour gérer la kubelet. Vous pouvez utiliser un gestionnaire différent à la place,
mais vous devez le configurer manuellement.
Certains détails de configuration de la kubelet doivent être identiques pour
toutes les kubelets du cluster, tandis que d’autres aspects de la configuration
doivent être définis par nœud, pour tenir compte des différentes caractéristiques
d’une machine donnée, telles que le système d’exploitation, le stockage et la
mise en réseau. Vous pouvez gérer la configuration manuellement de vos kubelets,
mais kubeadm fournit maintenant un type d’API KubeletConfiguration pour la gestion centralisée de vos configurations de kubelets.
Patterns de configuration des Kubelets
Les sections suivantes décrivent les modèles de configuration de kubelet simplifiés en
utilisant kubeadm, plutôt que de gérer manuellement la configuration des kubelets pour chaque nœud.
Propagation de la configuration niveau cluster à chaque kubelet
Vous pouvez fournir à la kubelet les valeurs par défaut à utiliser par les commandes kubeadm init et
kubeadm join. Des exemples intéressants incluent l’utilisation d’un runtime CRI différent ou la
définition du sous-réseau par défaut utilisé par les services.
Si vous souhaitez que vos services utilisent le sous-réseau 10.96.0.0 / 12 par défaut pour les
services, vous pouvez passer le paramètre --service-cidr à kubeadm:
kubeadm init --service-cidr 10.96.0.0/12
Les adresses IP virtuelles pour les services sont maintenant attribuées à partir de ce sous-réseau.
Vous devez également définir l'adresse DNS utilisée par la kubelet, en utilisant l'option
--cluster-dns. Ce paramètre doit être le même pour chaque kubelet sur chaque master et worker
du cluster. La kubelet fournit un objet API structuré versionné qui peut configurer la plupart des
paramètres dans la kubelet et pousser cette configuration à chaque exécution de la kubelet dans
le cluster. Cet objet s'appelle la ComponentConfig de la kubelet.
La ComponentConfig permet à l’utilisateur de spécifier des options tels que les adresses IP DNS du
cluster exprimées en une liste de valeurs pour une clé formatée en CamelCased, illustrée par l'exemple suivant:
Pour plus de détails sur ComponentConfig, jetez un œil à cette section.
Fournir des détails de configuration spécifiques à l'instance
Certaines machines nécessitent des configurations de kubelet spécifiques, en raison de la différences de
matériel, de système d’exploitation, réseau ou d’autres paramètres spécifiques à l’hôte. La liste suivante
fournit quelques exemples.
Le chemin d'accès au fichier de résolution DNS, tel que spécifié par l'option de configuration
de la kubelet --resolv-conf, peut différer selon les systèmes d'exploitation ou selon que vous utilisez
ou non systemd-resolved. Si ce chemin est incorrect, la résolution DNS échouera sur le nœud
dont la kubelet est configuré de manière incorrecte.
L'objet API de nœud .metadata.name est défini par défaut sur le hostname de la machine,
sauf si vous utilisez un fournisseur de cloud. Vous pouvez utiliser l’indicateur --hostname-override
pour remplacer le comportement par défaut si vous devez spécifier un nom de nœud différent du hostname
de la machine.
Actuellement, la kubelet ne peut pas détecter automatiquement le driver cgroup utilisé par le
runtime CRI, mais la valeur de --cgroup-driver doit correspondre au driver cgroup
utilisé par le runtime CRI pour garantir la santé de la kubelet.
En fonction du runtime du CRI utilisé par votre cluster, vous devrez peut-être spécifier des
options différentes pour la kubelet. Par exemple, lorsque vous utilisez Docker,
vous devez spécifier des options telles que
--network-plugin = cni, mais si vous utilisez un environnement d’exécution externe, vous devez spécifier
--container-runtime = remote et spécifier le CRI endpoint en utilisant l'option
--container-runtime-path-endpoint = <chemin>.
Vous pouvez spécifier ces options en modifiant la configuration d’une kubelet individuelle dans
votre gestionnaire de service, tel que systemd.
Configurer les kubelets en utilisant kubeadm
Il est possible de configurer la kubelet que kubeadm va démarrer si un objet API personnalisé
KubeletConfiguration est passé en paramètre via un fichier de configuration comme
kubeadm ... --config some-config-file.yaml.
En appelant kubeadm config print-default --api-objects KubeletConfiguration vous
pouvez voir toutes les valeurs par défaut pour cette structure.
Lorsque vous appelez kubeadm init, la configuration de la kubelet est organisée sur le disque
sur /var/lib/kubelet/config.yaml, et également chargé sur une ConfigMap du cluster. La ConfigMap
est nommé kubelet-config-1.X, où .X est la version mineure de la version de Kubernetes
que vous êtes en train d'initialiser. Un fichier de configuration de kubelet est également écrit dans
/etc/kubernetes/kubelet.conf avec la configuration de base à l'échelle du cluster pour tous les
kubelets du cluster. Ce fichier de configuration pointe vers les certificats clients permettant aux
kubelets de communiquer avec l'API server. Ceci répond au besoin de
propager la configuration niveau cluster à chaque kubelet.
Pour répondre au besoin de
fournir des détails de configuration spécifiques à l'instance de kubelet,
kubeadm écrit un fichier d'environnement dans /var/lib/kubelet/kubeadm-flags.env, qui contient une liste
d'options à passer à la kubelet quand elle démarre. Les options sont représentées dans le fichier comme ceci:
Outre les indicateurs utilisés lors du démarrage de la kubelet, le fichier contient également des
informations dynamiques comme des paramètres tels que le driver cgroup et s'il faut utiliser un autre
socket de runtime CRI (--cri-socket).
Après avoir rassemblé ces deux fichiers sur le disque, kubeadm tente d’exécuter ces deux commandes,
si vous utilisez systemd:
Si le rechargement et le redémarrage réussissent, le workflow normal de kubeadm init continue.
Workflow en utilisant kubeadm join
Lorsque vous exécutez kubeadm join, kubeadm utilise les informations d'identification du bootstrap
token pour faire un bootstrap TLS, qui récupère les informations d’identité nécessaires pour télécharger le
kubelet-config-1.X ConfigMap puis l'écrit dans /var/lib/kubelet/config.yaml. Le fichier d’environnement
dynamique est généré exactement de la même manière que kubeadm init.
Ensuite, kubeadm exécute les deux commandes suivantes pour charger la nouvelle configuration dans la kubelet:
Après le chargement de la nouvelle configuration par la kubelet, kubeadm écrit le fichier KubeConfig
/etc/kubernetes/bootstrap-kubelet.conf, qui contient un certificat de CA et un jeton Bootstrap.
Ceux-ci sont utilisés par la kubelet pour effectuer le TLS Bootstrap et obtenir une information
d'identification unique, qui est stocké dans /etc/kubernetes/kubelet.conf. Quand ce fichier est
écrit, la kubelet a terminé l'exécution du bootstrap TLS.
Le fichier kubelet généré pour systemd
Le fichier de configuration installé par le package DEB ou RPM de kubeadm est écrit dans
/etc/systemd/system/kubelet.service.d/10-kubeadm.conf et est utilisé par systemd.
[Service]
Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf
--kubeconfig=/etc/kubernetes/kubelet.conf"
Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml"
# This is a file that "kubeadm init" and "kubeadm join" generates at runtime, populating
the KUBELET_KUBEADM_ARGS variable dynamically
EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env
# This is a file that the user can use for overrides of the kubelet args as a last resort. Preferably,
# the user should use the .NodeRegistration.KubeletExtraArgs object in the configuration files instead.
# KUBELET_EXTRA_ARGS should be sourced from this file.
EnvironmentFile=-/etc/default/kubelet
ExecStart=
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS
Ce fichier spécifie les emplacements par défaut pour tous les fichiers gérés par kubeadm pour la kubelet.
Le fichier KubeConfig à utiliser pour le TLS Bootstrap est /etc/kubernetes/bootstrap-kubelet.conf,
mais il n'est utilisé que si /etc/kubernetes/kubelet.conf n'existe pas.
Le fichier KubeConfig avec l’identité unique de la kubelet est /etc/kubernetes/kubelet.conf.
Le fichier contenant le ComponentConfig de la kubelet est /var/lib/kubelet/config.yaml.
Le fichier d'environnement dynamique qui contient KUBELET_KUBEADM_ARGS est sourcé à partir de
/var/lib/kubelet/kubeadm-flags.env.
Le fichier qui peut contenir les paramètres surchargés par l'utilisateur avec KUBELET_EXTRA_ARGS
provient de /etc/default/kubelet (pour les DEBs), ou /etc/sysconfig/kubelet (pour les RPMs)
KUBELET_EXTRA_ARGS est le dernier de la chaîne d'options et a la priorité la plus élevée en cas
de conflit de paramètres.
Fichiers binaires de Kubernetes et contenu du package
Les packages DEB et RPM fournis avec les versions de Kubernetes sont les suivants:
Comme avec n'importe quel programme, vous pourriez rencontrer une erreur lors de l'installation ou de
l'exécution de kubeadm.
Cette page répertorie certains scénarios d’échec courants et propose des étapes pouvant vous aider à
comprendre et résoudre le problème.
Si votre problème ne figure pas dans la liste ci-dessous, procédez comme suit:
Si vous pensez que votre problème est un bug avec kubeadm:
Si aucune issue n'existe, veuillez en ouvrir une et
suivez le modèle ( template ) d'issue
Si vous ne savez pas comment fonctionne kubeadm, vous pouvez demander sur Slack
dans le canal #kubeadm, ou posez une questions sur
StackOverflow. Merci d'ajouter les tags pertinents
comme #kubernetes et #kubeadm, ainsi on pourra vous aider.
ebtables ou un exécutable similaire introuvable lors de l'installation
Si vous voyez les warnings suivants lors de l'exécution kubeadm init
[preflight] WARNING: ebtables not found in system path
[preflight] WARNING: ethtool not found in system path
Ensuite, il peut vous manquer ebtables, ethtool ou un exécutable similaire sur votre nœud. Vous
pouvez l'installer avec les commandes suivantes:
For Ubuntu/Debian users, run apt install ebtables ethtool.
For CentOS/Fedora users, run yum install ebtables ethtool.
kubeadm reste bloqué en attente du control plane pendant l'installation
Si vous remarquez que kubeadm init se bloque après la ligne suivante:
[apiclient] Created API client, waiting for the control plane to become ready
Cela peut être causé par un certain nombre de problèmes. Les plus communs sont:
problèmes de connexion réseau. Vérifiez que votre machine dispose d'une connectivité réseau
complète avant de continuer.
la configuration du driver cgroup par défaut pour la kubelet diffère de celle utilisée par Docker.
Vérifiez le fichier journal du système (par exemple, /var/log/message) ou examinez le résultat
de journalctl -u kubelet. Si vous voyez quelque chose comme ce qui suit:
error: failed to run Kubelet: failed to create kubelet:
misconfiguration: kubelet cgroup driver: "systemd" is different from docker cgroup driver: "cgroupfs"
Il existe deux méthodes courantes pour résoudre le problème du driver cgroup:
Installez à nouveau Docker en suivant les instructions
ici.
Les conteneurs Docker du control plane sont en crashloop ou suspendus. Vous pouvez le vérifier en lançant docker ps et étudier chaque conteneur en exécutant docker logs.
kubeadm bloque lors de la suppression de conteneurs gérés
Les événements suivants peuvent se produire si Docker s'arrête et ne supprime pas les conteneurs gérés
par Kubernetes:
sudo kubeadm reset
[preflight] Running pre-flight checks
[reset] Stopping the kubelet service
[reset] Unmounting mounted directories in "/var/lib/kubelet"[reset] Removing kubernetes-managed containers
(block)
Une solution possible consiste à redémarrer le service Docker, puis à réexécuter kubeadm reset:
L'inspection des journaux de Docker peut également être utile:
journalctl -ul docker
Pods dans l'état RunContainerError, CrashLoopBackOff ou Error
Juste après kubeadm init, il ne devrait pas y avoir de pods dans ces états.
S'il existe des pods dans l'un de ces états juste aprèskubeadm init, veuillez ouvrir un
issue dans le dépôt de Kubeadm. coredns (ou kube-dns) devrait être dans l'état Pending
jusqu'à ce que vous ayez déployé la solution réseau.
Si vous voyez des pods dans les états RunContainerError, CrashLoopBackOff ou Error
après le déploiement de la solution réseau et que rien ne se passe pour coredns (ou kube-dns),
il est très probable que la solution Pod Network que vous avez installée est en quelque sorte
endommagée. Vous devrez peut-être lui accorder plus de privilèges RBAC ou utiliser une version
plus récente. S'il vous plaît créez une issue dans le dépôt du fournisseur de réseau de Pod.
Si vous installez une version de Docker antérieure à 1.12.1, supprimez l'option MountFlags = slave
lors du démarrage de dockerd avec systemd et redémarrez docker. Vous pouvez voir les options
de montage dans /usr/lib/systemd/system/docker.service.
Les options de montage peuvent interférer avec les volumes montés par Kubernetes et mettre les
pods dans l'état CrashLoopBackOff. L'erreur se produit lorsque Kubernetes ne trouve pas les fichiers
var/run/secrets/kubernetes.io/serviceaccount.
coredns (ou kube-dns) est bloqué dans l'état Pending
Ceci est prévu et fait partie du design. kubeadm est agnostique vis-à-vis du fournisseur
de réseau, ainsi l'administrateur devrait installer la solution réseau pod
de choix. Vous devez installer un réseau de pods avant que CoreDNS ne soit complètement déployé.
D'où l' état Pending avant la mise en place du réseau.
Les services HostPort ne fonctionnent pas
Les fonctionnalités HostPort et HostIP sont disponibles en fonction de votre fournisseur
de réseau de pod. Veuillez contacter l’auteur de la solution de réseau de Pod pour savoir si
Les fonctionnalités HostPort et HostIP sont disponibles.
Les fournisseurs de CNI Calico, Canal, et Flannel supportent HostPort.
Si votre fournisseur de réseau ne prend pas en charge le plug-in portmap CNI, vous devrez peut-être utiliser le
NodePort feature of services ou utiliser HostNetwork=true.
Les pods ne sont pas accessibles via leur IP de service
De nombreux add-ons réseau ne permettent pas encore
hairpin mode
qui permet aux pods d’accéder à eux-mêmes via leur IP de service. Ceci est un problème lié
au CNI. S'il vous plaît contacter
le fournisseur d'add-on réseau afin d'obtenir des informations en matière de prise en charge du mode hairpin.
Si vous utilisez VirtualBox (directement ou via Vagrant), vous devrez vous assurez que
hostname -i renvoie une adresse IP routable. Par défaut la première interface est connectée
à un réseau d’ hôte uniquement non routable. En contournement vous pouvez modifier /etc/hosts,
jetez un œil à ce Vagrantfile par exemple.
Erreurs de certificats TLS
L'erreur suivante indique une possible incompatibilité de certificat.
# kubectl get pods
Unable to connect to the server: x509: certificate signed by unknown authority (possibly because of
"crypto/rsa: verification error" while trying to verify candidate authority certificate "kubernetes")
Vérifiez que le fichier $HOME/.kube/config contient un certificat valide, et
re-générer un certificat si nécessaire. Les certificats dans un fichier kubeconfig
sont encodés en base64. La commande base64 -d peut être utilisée pour décoder le certificat
et openssl x509 -text -noout peut être utilisé pour afficher les informations du certificat.
Une autre solution consiste à écraser le kubeconfig existant pour l'utilisateur" admin ":
Carte réseau par défaut lors de l'utilisation de flannel comme réseau de pod dans Vagrant
L'erreur suivante peut indiquer que quelque chose n'allait pas dans le réseau de pod:
Error from server (NotFound): the server could not find the requested resource
Si vous utilisez flannel comme réseau de pod dans Vagrant, vous devrez spécifier le
nom d'interface par défaut pour flannel.
Vagrant attribue généralement deux interfaces à tous les ordinateurs virtuels. La
première, pour laquel tous les hôtes se voient attribuer l’adresse IP 10.0.2.15,
est pour le trafic externe qui est NATé.
Cela peut entraîner des problèmes avec Flannel, qui utilise par défaut la première
interface sur un hôte. Ceci conduit au fait que tous les hôtes pensent qu'ils ont la
même adresse IP publique. Pour éviter cela, passez l'option --iface eth1 sur Flannel
pour que la deuxième interface soit choisie.
IP non publique utilisée pour les conteneurs
Dans certaines situations, les commandes kubectl logs et kubectl run peuvent
renvoyer les erreurs suivantes dans un cluster par ailleurs fonctionnel:
Error from server: Get https://10.19.0.41:10250/containerLogs/default/mysql-ddc65b868-glc5m/mysql:
dial tcp 10.19.0.41:10250: getsockopt: no route to host
Cela peut être dû au fait que Kubernetes utilise une adresse IP qui ne peut pas communiquer
avec d’autres adresses IP même sous-réseau, éventuellement à cause d'une politique mise en place
par le fournisseur de la machine.
Digital Ocean attribue une adresse IP publique à eth0 ainsi qu’une adresse privée à
utiliser en interne comme IP d'ancrage pour leur fonction IP flottante, mais kubelet choisira cette
dernière comme InternalIP du noeud au lieu du public.
Utilisez ip addr show pour verifier ce scénario au lieu de ifconfig car ifconfig n'affichera pas
l'alias de l'adresse IP incriminée. Sinon, une API spécifique à Digital Ocean
permet de rechercher l'adresse IP d'ancrage à partir du droplet:
La solution consiste à indiquer à la kubelet l'adresse IP à utiliser avec --node-ip. Lors de
l'utilisation de Digital Ocean, il peut être public (assigné à eth0) ou privé (assigné à eth1)
si vous voulez utiliser le réseau privé optionnel. la
la section KubeletExtraArgs de kubeadm NodeRegistrationOptions structure peut être utilisé pour cela.
Puis redémarrer la kubelet:
systemctl daemon-reload
systemctl restart kubelet
Les pods coredns sont en état CrashLoopBackOff ou Error
Si vous avez des nœuds qui exécutent SELinux avec une version plus ancienne de Docker, vous risquez
de rencontrer un problème ou les pods de coredns ne démarrent pas. Pour résoudre ce problème, vous pouvez essayer l'une des options suivantes:
Modifiez le déploiement de coredns pour définir allowPrivilegeEscalation à true:
kubectl -n kube-system get deployment coredns -o yaml | \
sed 's/allowPrivilegeEscalation: false/allowPrivilegeEscalation: true/g' | \
kubectl apply -f -
une autre raison pour laquelle CoreDNS peut se retrouver dans l'état CrashLoopBackOff est lorsqu'un
Pod de CoreDNS déployé dans Kubernetes détecte une boucle. Un certain nombre de solutions de contournement
sont disponibles pour éviter que Kubernetes ne tente de redémarrer le pod CoreDNS chaque fois que CoreDNS détecte une boucle et s'arrête.
Attention:
Désactiver SELinux ou paramètrer allowPrivilegeEscalation sur true peut compromettre
la sécurité de votre cluster.
Les pods etcd redémarrent continuellement
Si vous rencontrez l'erreur suivante:
rpc error: code = 2 desc = oci runtime error: exec failed: container_linux.go:247: starting container
process caused "process_linux.go:110: decoding init error from pipe caused \"read parent: connection
reset by peer\""
ce problème apparaît si vous exécutez CentOS 7 avec Docker 1.13.1.84.
Cette version de Docker peut empêcher la kubelet de s'exécuter dans le conteneur etcd.
Pour contourner le problème, choisissez l'une de ces options.:
Revenir à une version antérieure de Docker, telle que la 1.13.1-75:
Il existe plusieurs guides permettant d'utiliser Kubernetes avec CoreOS.
Guides officiels CoreOS
Ces guides sont maintenus par CoreOS et déploient Kubernetes à la "façon CoreOS" avec du TLS, le composant complémentaire pour le DNS interne, etc. Ces guides passent les tests de conformité Kubernetes et nous vous recommendons de [les tester vous-même] (https://coreos.com/kubernetes/docs/latest/conformance-tests.html).
Guide et outil en ligne de commande pour créer un cluster multi-noeuds sur AWS.
CloudFormation est utilisé pour créer un noeud maitre ("master") et plusieurs noeuds de type "worker".
Guide et service HTTP / API pour l'initialisation et l'installation d’un cluster à plusieurs nœuds bare metal à partir d'un PXE.
Ignition est utilisé pour provisionner un cluster composé d'un master et de plusieurs workers lors du démarrage initial des serveurs.
Guide pour l'installation d'un cluster multi-noeuds sur Vagrant.
L'outil de déploiement permet de configurer indépendemment le nombre de noeuds etcd, masters et workers afin d'obtenir un control plane en haute disponibilité.
C'est la façon la plus rapide d'installer un environnement de développement local Kubernetes.
Il suffit simplement de git clone, vagrant up puis configurer kubectl.
Un guide générique qui permet de déployer un cluster en haute disponibilité (avec du TLS) sur n'importe cloud ou sur du bare metal.
Répéter les étapes pour obtenir plus de noeuds master ou worker
Guide de la communauté
Ces guides sont maintenus par des membres de la communauté et couvrent des besoins et cas d'usages spécifiques. Ils proposent différentes manières de configurer Kubernetes sur CoreOS.
Guide permettant d'obtenir un cluster d'un seul noeud faisant office de master et worker et contrôlé par une application macOS menubar.
(basé sur xhyve et CoreOS)
Pour le niveau de support de toutes les solutions se référer au Tableau des solutions.
4.2 - Installer Kubernetes avec Kubespray (on-premises et fournisseurs de cloud)
Installation de Kubernetes avec Kubespray
Cette documentation permet d'installer rapidement un cluster Kubernetes hébergé sur GCE, Azure, Openstack, AWS, vSphere, Oracle Cloud Infrastructure (expérimental) ou sur des serveurs physiques (bare metal) grâce à Kubespray.
Kubespray se base sur des outils de provisioning, des paramètres et playbooks Ansible ainsi que sur des connaissances spécifiques à Kubernetes et l'installation de systèmes d'exploitation afin de fournir:
Les serveurs doivent être installés en s'assurant des éléments suivants:
Ansible v2.11 (ou version plus récente) et python-netaddr installés sur la machine qui exécutera les commandes Ansible
Jinja 2.11 (ou version plus récente) est nécessaire pour exécuter les playbooks Ansible
Les serveurs cibles doivent avoir accès à Internet afin de télécharger les images Docker. Autrement, une configuration supplémentaire est nécessaire, (se référer à Offline Environment)
Les serveurs cibles doivent être configurés afin d'autoriser le transfert IPv4 (IPv4 forwarding)
Votre clé ssh doit être copiée sur tous les serveurs faisant partie de votre inventaire Ansible.
La configuration du pare-feu n'est pas gérée. Vous devrez vous en charger en utilisant votre méthode habituelle. Afin d'éviter tout problème pendant l'installation nous vous conseillons de le désactiver.
Si Kubespray est exécuté avec un utilisateur autre que "root", une méthode d'autorisation appropriée devra être configurée sur les serveurs cibles (exemple: sudo). Il faudra aussi utiliser le paramètre ansible_become ou ajouter --become ou b à la ligne de commande.
Afin de vous aider à préparer votre de votre environnement, Kubespray fournit les outils suivants:
Scripts Terraform pour les fournisseurs de cloud suivants:
Lorsque vos serveurs sont disponibles, créez un fichier d'inventaire Ansible (inventory).
Vous pouvez le créer manuellement ou en utilisant un script d'inventaire dynamique. Pour plus d'informations se référer à Building your own inventory.
(3/5) Préparation au déploiement de votre cluster
Kubespray permet de personnaliser de nombreux éléments:
Choix du mode: kubeadm ou non-kubeadm
Plugins CNI (réseau)
Configuration du DNS
Choix du control plane: natif/binaire ou dans un conteneur docker/rkt
Version de chaque composant
"route reflectors" Calico
Moteur de conteneur
docker
rkt
cri-o
Méthode de génération des certificats (Vault n'étant plus maintenu)
Ces paramètres Kubespray peuvent être définis dans un fichier de variables.
Si vous venez juste de commencer à utiliser Kubespray nous vous recommandons d'utiliser les paramètres par défaut pour déployer votre cluster et découvrir Kubernetes
(4/5) Déployer un Cluster
Vous pouvez ensuite lancer le déploiement de votre cluster:
Déploiement du cluster en utilisant l'outil en ligne de commande ansible-playbook.
Pour des déploiements plus importants (>100 noeuds) quelques ajustements peuvent être nécessaires afin d'obtenir de meilleurs résultats.
(5/5) Vérifier le déploiement
Kubespray fournit le moyen de vérifier la connectivité inter-pods ainsi que la résolution DNS grâce à Netchecker.
Les pods netchecker-agents s'assurent que la résolution DNS (services Kubernetes) ainsi que le ping entre les pods fonctionnent correctement.
Ces pods reproduisent un comportement similaire à celui des autres applications et offrent un indicateur de santé du cluster.
Opérations sur le cluster
Kubespray fournit des playbooks supplémentaires qui permettent de gérer votre cluster: scale et upgrade.
Mise à l'échelle du cluster
Vous pouvez ajouter des noeuds à votre cluster en exécutant le playbook scale. Pour plus d'informations se référer à Adding nodes.
vous pouvez retirer des noeuds de votre cluster en exécutant le playbook remove-node. Se référer à Remove nodes.
Mise à jour du cluster
Vous pouvez mettre à jour votre cluster en exécutant le playbook upgrade-cluster. Pour plus d'informations se référer à Upgrades.
Nettoyage
Vous pouvez réinitialiser vos noeuds et supprimer tous les composants installés par Kubespray en utilisant le playbook reset.
Avertissement:
Quand vous utilisez le playbook reset, assurez-vous de ne pas cibler accidentellement un cluster de production !
kops utilise le DNS pour la découverte, que ce soit à l'intérieur du cluster ou pour pouvoir communiquer avec l'API de kubernetes à partir des clients.
Pour kops le nom du cluster doit impérativement être un nom de domaine valide.
De cette façon vous ne confondrez pas vos cluster et vous pourrez les partager avec vos collègues sans ambiguïté. Par ailleurs vous pourrez vous y connecter sans avoir à vous rappeler une adresse IP.
Vous pouvez, et vous devriez certainement, utiliser des sous-domaines afin de séparer vos clusters.
Dans notre exemple nous utiliserons useast1.dev.example.com. Le point d'accès au serveur API sera donc api.useast1.dev.example.com.
Une zone hébergée Route53 peut servir les sous-domaines. Votre zone hébergée pourrait être useast1.dev.example.com,
mais aussi dev.example.com ou même example.com. kops fonctionne avec n'importe lequel d'entre eux, le choix dépend de vos contraintes d'organisation (ex: Vous êtes autorisés à créer des enregistrements dns dans dev.example.com mais pas dans example.com)
Supposons que vous utilisiez dev.example.com comme zone hébergée. Vous créeriez cette zone hébergée en utilisant la méthode normal, ou avec une ligne de commande telle que aws route53 create-hosted-zone --name dev.example.com --caller-reference 1.
Vous devrez ensuite configurer vos enregistrements NS dans le domaine parent afin que vous puissiez résoudre dans ce domaine.
Vous créeriez donc des enregistrements NS dans le domaine example.com pour dev.
S'il s'agit d'un nom de domaine racine, vous devrez configurer les enregistrements NS chez votre hébergeur de nom de domaine (là où vous avez acheté votre nom de domaine example.com).
Cette étape est délicate, soyez vigilants (c’est la première cause de problèmes !). Vous pouvez vérifier que
votre cluster est configuré correctement avec l'outil dig, en exécutant:
dig NS dev.example.com
Vous devriez voir les 4 enregistrements NS attribués à votre zone hébergée sur Route53.
(3/5) Créez un conteneur (bucket) S3 pour stocker l'état de vos clusters.
kops vous permet de gérer vos clusters même lorsque ceux-ci sont déjà installés. Pour ce faire, il est nécessaire de conserver une trace des clusters que vous avez créé, avec leur configuration, les clés qu’ils utilisent, etc. Ces informations sont stockées dans un bucket S3. Les autorisations S3 sont utilisées pour contrôler l'accès au bucket.
Plusieurs clusters peuvent utiliser le même bucket S3 et vous pouvez aussi le partager avec vos collègues qui
administrer les mêmes clusters - c'est beaucoup plus facile que de faire circuler des fichiers kubecfg.
Cependant quiconque ayant accès au bucket S3 aura un accès complet (permissions élevées) à tous vos clusters. Vous souhaiterez donc limiter l'accès à l'équipe opérationnelle.
Plus généralement, vous auriez un bucket S3 pour chaque équipe ops (et le nom correspondrait souvent
au nom de la zone hébergée ci-dessus!)
Dans notre exemple, nous avons choisi dev.example.com comme zone hébergée. Nous allons donc choisir clusters.dev.example.com comm le nom du bucket S3.
Exportez AWS_PROFILE (si vous devez sélectionner un profil pour que l'outil en ligne de commande d'AWS fonctionne).
Créez le compartiment S3 en utilisant aws s3 mb s3://clusters.dev.example.com
Vous pouvez export KOPS_STATE_STORE=s3://clusters.dev.example.com afin que kops utilise cet emplacement par défaut.
Nous vous suggérons de le mettre dans votre profil bash ou similaire.
(4/5) Construisez votre configuration de cluster
Exécutez "kops create cluster" pour créer votre configuration de cluster:
kops créera la configuration pour votre cluster. Notez que cela génère uniquement la configuration, la création des ressources cloud se fait à l'étape suivante avec kops update cluster. Cela vous permettra d'analyser la configuration ou de la modifier avant de l'appliquer.
Voici quelques commandes qui vous permettent de visualiser ou éditer:
Listez vos clusters avec: kops get cluster
Éditez ce cluster avec: kops edit cluster useast1.dev.example.com
Modifiez votre groupe d'instances de nœuds: kops edit ig --name=useast1.dev.example.com nodes
Si vous utilisez kops pour la première fois, prenez quelques minutes pour les essayer! Un groupe d'instances est un
ensemble d'instances, qui seront enregistrées en tant que noeuds kubernetes. Sur AWS, cela est implémenté via des groupes de mise à l'échelle automatique (auto-scaling).
Vous pouvez avoir plusieurs groupes d'instances, par exemple si vous voulez des nœuds combinant des instances ponctuelles (spot instances) et à la demande, ou éventuellement des instances GPU et non-GPU.
(5/5) Créer le cluster dans AWS
Exécutez "kops update cluster" pour créer votre cluster dans AWS :
kops update cluster useast1.dev.example.com --yes
Cela prend quelques secondes à s'exécuter, et ensuite votre cluster prendra probablement quelques minutes pour être réellement opérationnel.
kops update cluster sera l'outil que vous utiliserez à chaque fois que vous modifierez la configuration de votre cluster.
Il applique les modifications que vous avez apportées à la configuration sur votre cluster (reconfiguration d'AWS ou de kubernetes au besoin).
Par exemple, après un kops edit ig nodes, puis un kops update cluster --yes pour appliquer votre configuration, parfois, vous devrez également exécuter un kops rolling-update cluster pour déployer la configuration immédiatement.
Sans l'argument --yes, kops update cluster vous montrera un aperçu de ce qu’il va faire. C'est pratique
pour les clusters de production !
Explorer d'autres composants additionnels (add-ons)
Reportez-vous à la [liste des add-ons] (/docs/concepts/cluster-administration/addons/) pour explorer d'autres add-ons, y compris des outils de journalisation, de surveillance, de stratégie réseau, de visualisation ou de contrôle de votre cluster Kubernetes.
Nettoyer
Pour supprimer votre cluster: kops delete cluster useast1.dev.example.com --yes