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.
ip link ou ifconfig -asudo cat /sys/class/dmi/id/product_uuidIl 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.
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é.
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.
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
EOF
sudo sysctl --system
Pour plus de détails, veuillez consulter la page Configuration requise pour le plug-in réseau.
| Protocole | Direction | Plage de Port | Utilisé pour | Utilisé par |
|---|---|---|---|---|
| TCP | Entrant | 6443* | Kubernetes API server | Tous |
| TCP | Entrant | 2379-2380 | Etcd server client API | kube-apiserver, etcd |
| TCP | Entrant | 10250 | Kubelet API | Lui-même, Control plane |
| TCP | Entrant | 10251 | kube-scheduler | Lui-même |
| TCP | Entrant | 10252 | kube-controller-manager | Lui-même |
| Protocole | Direction | Plage de Port | Utilisé pour | Utilisé par |
|---|---|---|---|---|
| TCP | Entrant | 10250 | Kubelet API | Lui-même, Control plane |
| TCP | Entrant | 30000-32767 | NodePort Services** | Eux-mêmes |
** Plage de ports par défaut pour les Services NodePort.
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).
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:
| 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 |
Le kubelet s'intègre à Docker via l'implémentation CRI intégrée de dockershim.
Voir runtimes de conteneur pour plus d'informations.
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.
Voir runtimes de conteneur pour plus d'informations.
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.
For information about installing kubectl, see Installation et configuration kubectl.
Pour plus d'informations sur les compatibilités de version, voir:
Les instructions suivantes sont pour Kubernetes v1.35.
Mettez à jour l'index de package apt et installez les dépendances suivantes nécessaires au dépôt apt Kubernetes:
sudo apt-get update
# apt-transport-https n'est plus utile; vous pouvez l'ignorez
sudo apt-get install -y apt-transport-https ca-certificates curl gpg
Téléchargez la clé publique pour les dépôts de paquets Kubernetes. La même clé de signature est utilisée pour tous les dépôts, vous pouvez donc ne pas tenir compte de la version dans l’URL.
# Si le répertoire `/etc/apt/keyrings` n'existe pas, vous devez le créer avant la curl, avec la commande ci-dessous par exemple.
# sudo mkdir -p -m 755 /etc/apt/keyrings
curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.35/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
Ajoutez le dépôt apt approprié pour Kubernetes.
Veuillez noter que ce dépôt contient uniquement les paquets pour Kubernetes 1.35; pour d'autres versions mineures de Kubernetes, vous devez modifier la version mineure dans l'URL afin qu'elle corresponde à la version souhaitée.
# Cette commande écrase toute configuration préexistante du fichier `/etc/apt/sources.list.d/kubernetes.list`
echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.35/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list
Mettez à jour l'index de package apt puis installez kubelet, kubeadm et kubectl. Puis verrouillez leurs version:
sudo apt-get update
sudo apt-get install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl
(Optionnel) Démarrez le service kubelet avant de démarrer kubeadm:
sudo systemctl enable --now kubelet
cat <<EOF | sudo tee /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-\$basearch
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
exclude=kubelet kubeadm kubectl
EOF
# Mettre SELinux en mode permissif (le désactiver efficacement)
sudo setenforce 0
sudo sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config
sudo yum install -y kubelet kubeadm kubectl --disableexcludes=kubernetes
sudo systemctl enable --now kubelet
Note:
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) :
CNI_VERSION="v0.8.2"
ARCH="amd64"
sudo mkdir -p /opt/cni/bin
curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/cni-plugins-linux-${ARCH}-${CNI_VERSION}.tgz" | sudo tar -C /opt/cni/bin -xz
Définissez le répertoire pour télécharger les fichiers de commande
DOWNLOAD_DIR=/usr/local/bin
sudo mkdir -p $DOWNLOAD_DIR
Installez crictl (requis pour Kubeadm / Kubelet Container Runtime Interface (CRI))
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_DIR
sudo 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
/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.
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 :
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
cgroupDriver: <value>
Pour plus de détails, veuillez lire Utilisation de kubeadm init avec un fichier de configuration.
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.
--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).Il est nécessaire de redémarrer la kubelet:
sudo systemctl daemon-reload
sudo systemctl restart kubelet
La détection automatique du pilote cgroup pour d'autres runtimes de conteneur comme CRI-O et containerd est un travail en cours.
Si vous rencontrez des difficultés avec kubeadm, veuillez consulter notre documentation de dépannage.
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:
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.
| 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.
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 |
Voir "Installation de kubeadm".
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.
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).
--pod-network-cidr sur
une valeur spécifique au fournisseur. Voir Installation d'un add-on réseau de pod.--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::101kubeadm config images pull avant de faire kubeadm init pour vérifier la
connectivité aux registres gcr.io.Maintenant, lancez:
kubeadm init <args>
Pour plus d'informations sur les arguments de kubeadm init, voir le
guide de référence kubeadm.
Pour une liste complète des options de configuration, voir la documentation du fichier de configuration.
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:
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
Alternativement, si vous êtes root, vous pouvez exécuter:
export KUBECONFIG=/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.
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.
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.
Sélectionnez l'un des onglets pour consulter les instructions d'installation du fournisseur de réseau de pods.
Pour plus d'informations sur l'utilisation de Calico, voir Guide de démarrage rapide de Calico sur Kubernetes, Installation de Calico pour les netpols ( network policies ) et le réseau, ainsi que d'autres resources liées à ce sujet.
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.
kubectl apply -f https://docs.projectcalico.org/v3.8/manifests/calico.yaml
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.
kubectl apply -f https://docs.projectcalico.org/v3.8/manifests/canal.yaml
Pour plus d'informations sur l'utilisation de Cilium avec Kubernetes, voir Guide d'installation de Kubernetes pour Cilium.
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.
kubectl taint nodes <node-name> node-role.kubernetes.io/master:NoSchedule-
Pour déployer Cilium, il vous suffit de lancer:
kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.4/examples/kubernetes/1.13/cilium.yaml
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.
kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/a70459be0084506e4ec919aa1c114638878db11b/Documentation/kube-flannel.yml
Pour plus d’informations sur flannel, voir le dépôt CoreOS sur GitHub.
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.
Romana ne fonctionne que sur amd64.
kubectl apply -f https://raw.githubusercontent.com/romana/romana/master/containerize/specs/romana-kubeadm.yml
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.
kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
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.
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:
kubectl taint nodes --all node-role.kubernetes.io/master-
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.
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:
sudo su-)kubeadm init. Par exemple:kubeadm join --token <token> <master-ip>:<master-port> --discovery-token-ca-cert-hash sha256:<hash>
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:
openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | \
openssl dgst -sha256 -hex | sed 's/^.* //'
L'output est similaire à ceci:
8cb2de97839780a412b93877f8507ad6c94f73add17d5d7058e91741c9d5ec78
<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.
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
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.
Si vous souhaitez vous connecter à l'API server à partir de l'éxterieur du cluster, vous pouvez utiliser
kubectl proxy:
scp root@<master ip>:/etc/kubernetes/admin.conf .
kubectl --kubeconfig ./admin.conf proxy
Vous pouvez maintenant accéder à l'API server localement à http://localhost:8001/api/v1
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:
kubectl drain <node name> --delete-local-data --force --ignore-daemonsets
kubectl delete node <node name>
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:
iptables -F && iptables -t nat -F && iptables -t mangle -F && iptables -X
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.
Vous trouverez des instructions pour la maintenance des clusters kubeadm (mises à niveau, rétrogradation, etc.) ici
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.
kubectl.--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.
Remarque: kubeadm évolue continuellement et ces limitations seront résolues en temps voulu.
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.
Si vous rencontrez des difficultés avec kubeadm, veuillez consulter nos troubleshooting docs.
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:
apiServercontrollerManagerschedulerLe champ extraArgs se compose de paires clé: valeur. Pour remplacer un indicateur
pour un composant du control plane:
Pour plus de détails sur chaque champ de la configuration, vous pouvez accéder aux pages de référence de l'API.
Pour plus de détails, voir la documentation de référence pour kube-apiserver.
Exemple d'utilisation:
apiVersion: kubeadm.k8s.io/v1beta1
kind: ClusterConfiguration
kubernetesVersion: v1.13.0
metadata:
name: 1.13-sample
apiServer:
extraArgs:
advertise-address: 192.168.0.103
anonymous-auth: false
enable-admission-plugins: AlwaysPullImages,DefaultStorageClass
audit-log-path: /home/johndoe/audit.log
Pour plus de détails, voir la documentation de référence pour kube-controller-manager.
Exemple d'utilisation:
apiVersion: kubeadm.k8s.io/v1beta1
kind: ClusterConfiguration
kubernetesVersion: v1.13.0
metadata:
name: 1.13-sample
controllerManager:
extraArgs:
cluster-signing-key-file: /home/johndoe/keys/ca.key
bind-address: 0.0.0.0
deployment-controller-sync-period: 50
Pour plus de détails, voir la documentation de référence pour kube-scheduler.
Example usage:
apiVersion: kubeadm.k8s.io/v1beta1
kind: ClusterConfiguration
kubernetesVersion: v1.13.0
metadata:
name: 1.13-sample
scheduler:
extraArgs:
bind-address: 0.0.0.0
config: /home/johndoe/schedconfig.yaml
kubeconfig: /home/johndoe/kubeconfig.yaml
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é:
Vous devez examiner attentivement les avantages et les inconvénients de chaque topologie avant de configurer un cluster en haute disponibilité.
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.
Schéma de la Topologie etcd empilée
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.
Schéma de la Topologie externe etcd
Cette page explique deux approches différentes pour configurer un Kubernetes à haute disponibilité. cluster utilisant kubeadm:
Avant de poursuivre, vous devez déterminer avec soin quelle approche répond le mieux aux besoins de vos applications et de l'environnement. Cette comparaison décrit les avantages et les inconvénients de chacune.
Vos clusters doivent exécuter Kubernetes version 1.12 ou ultérieure. Vous devriez aussi savoir que la mise en place de clusters HA avec kubeadm est toujours expérimentale et sera simplifiée davantage dans les futures versions. Vous pouvez par exemple rencontrer des problèmes lors de la mise à niveau de vos clusters. Nous vous encourageons à essayer l’une ou l’autre approche et à nous faire part de vos commentaires dans Suivi des problèmes Kubeadm.
Notez que la fonctionnalité alpha HighAvailability est obsolète dans la version 1.12 et supprimée dans la version 1.13
Voir aussi La documentation de mise à niveau HA.
Pour les deux méthodes, vous avez besoin de cette infrastructure:
kubeadm et une kubelet installés sur toutes les machines. kubectl est optionnel.Pour le cluster etcd externe uniquement, vous avez besoin également de:
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 kube-apiserver avec un nom résolu en DNS.
Dans un environnement cloud, placez vos nœuds du control plane derrière un load balancer TCP.
Ce load balancer distribue le trafic à tous les nœuds du control plane sains dans sa liste.
La vérification de la bonne santé d'un apiserver est une vérification TCP sur le port que
kube-apiserver écoute (valeur par défaut: 6443).
Il n'est pas recommandé d'utiliser une adresse IP directement dans un environnement cloud.
Le load balancer doit pouvoir communiquer avec tous les nœuds du control plane sur le port apiserver. Il doit également autoriser le trafic entrant sur son réseau de port d'écoute.
HAProxy peut être utilisé comme load balancer.
Assurez-vous que l'adresse du load balancer correspond toujours à
l'adresse de ControlPlaneEndpoint de kubeadm.
Ajoutez les premiers nœuds du control plane au load balancer et testez la connexion:
nc -v LOAD_BALANCER_IP PORT
connection refused est attendue car l'apiserver n'est pas encore en fonctionnement.
Cependant, un timeout signifie que le load balancer ne peut pas communiquer avec le nœud du
control plane. Si un timeout survient, reconfigurez le load balancer pour communiquer avec le nœud du control plane.Ajouter les nœuds du control plane restants au groupe cible du load balancer.
SSH est requis si vous souhaitez contrôler tous les nœuds à partir d'une seule machine.
Activer ssh-agent sur votre machine ayant accès à tous les autres nœuds du cluster:
eval $(ssh-agent)
Ajoutez votre clé SSH à la session:
ssh-add ~/.ssh/path_to_private_key
SSH entre les nœuds pour vérifier que la connexion fonctionne correctement.
Lorsque vous faites un SSH sur un noeud, assurez-vous d’ajouter l’option -A:
ssh -A 10.0.0.7
Lorsque vous utilisez sudo sur n’importe quel nœud, veillez à préserver l’environnement afin que le SSH forwarding fonctionne:
sudo -E -s
Sur le premier nœud du control plane, créez un fichier de configuration appelé kubeadm-config.yaml:
apiVersion: kubeadm.k8s.io/v1beta1
kind: ClusterConfiguration
kubernetesVersion: stable
apiServer:
certSANs:
- "LOAD_BALANCER_DNS"
controlPlaneEndpoint: "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT"
kubernetesVersion doit représenter la version de Kubernetes à utiliser. Cet exemple utilise stable.controlPlaneEndpoint doit correspondre à l'adresse ou au DNS et au port du load balancer.Assurez-vous que le nœud est dans un état sain:
sudo kubeadm init --config=kubeadm-config.yaml
Vous devriez voir quelque chose comme:
...
Vous pouvez à présent joindre n'importe quelle machine au cluster en lancant la commande suivante sur chaque nœeud en tant que root:
kubeadm join 192.168.0.200:6443 --token j04n3m.octy8zely83cy2ts --discovery-token-ca-cert-hash sha256:84938d2a22203a8e56a787ec0c6ddad7bc7dbd52ebabc62fd5f4dbea72b14d1f
```
Copiez ce jeton dans un fichier texte. Vous en aurez besoin plus tard pour joindre d’autres nœuds du control plane au cluster.
Activez l'extension CNI Weave:
kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
Tapez ce qui suit et observez les pods des composants démarrer:
kubectl get pod -n kube-system -w
Copiez les fichiers de certificat du premier nœud du control plane dans les autres:
Dans l'exemple suivant, remplacez CONTROL_PLANE_IPS par les adresses IP des autres nœuds du control plane.
USER=ubuntu # customizable
CONTROL_PLANE_IPS="10.0.0.7 10.0.0.8"
for host in ${CONTROL_PLANE_IPS}; do
scp /etc/kubernetes/pki/ca.crt "${USER}"@$host:
scp /etc/kubernetes/pki/ca.key "${USER}"@$host:
scp /etc/kubernetes/pki/sa.key "${USER}"@$host:
scp /etc/kubernetes/pki/sa.pub "${USER}"@$host:
scp /etc/kubernetes/pki/front-proxy-ca.crt "${USER}"@$host:
scp /etc/kubernetes/pki/front-proxy-ca.key "${USER}"@$host:
scp /etc/kubernetes/pki/etcd/ca.crt "${USER}"@$host:etcd-ca.crt
scp /etc/kubernetes/pki/etcd/ca.key "${USER}"@$host:etcd-ca.key
scp /etc/kubernetes/admin.conf "${USER}"@$host:
done
Déplacer les fichiers créés à l'étape précédente où scp était utilisé:
USER=ubuntu # customizable
mkdir -p /etc/kubernetes/pki/etcd
mv /home/${USER}/ca.crt /etc/kubernetes/pki/
mv /home/${USER}/ca.key /etc/kubernetes/pki/
mv /home/${USER}/sa.pub /etc/kubernetes/pki/
mv /home/${USER}/sa.key /etc/kubernetes/pki/
mv /home/${USER}/front-proxy-ca.crt /etc/kubernetes/pki/
mv /home/${USER}/front-proxy-ca.key /etc/kubernetes/pki/
mv /home/${USER}/etcd-ca.crt /etc/kubernetes/pki/etcd/ca.crt
mv /home/${USER}/etcd-ca.key /etc/kubernetes/pki/etcd/ca.key
mv /home/${USER}/admin.conf /etc/kubernetes/admin.conf
Ce processus écrit tous les fichiers demandés dans le dossier /etc/kubernetes.
Lancez kubeadm join sur ce nœud en utilisant la commande de join qui vous avait été précédemment
donnée par kubeadm init sur le premier noeud. Ça devrait ressembler a quelque chose
comme ça:
sudo kubeadm join 192.168.0.200:6443 --token j04n3m.octy8zely83cy2ts --discovery-token-ca-cert-hash sha256:84938d2a22203a8e56a787ec0c6ddad7bc7dbd52ebabc62fd5f4dbea72b14d1f --experimental-control-plane
--experimental-control-plane. Ce paramètre automatise l'adhésion au
control plane du cluster.Tapez ce qui suit et observez les pods des composants démarrer:
kubectl get pod -n kube-system -w
Répétez ces étapes pour le reste des nœuds du control plane.
Copiez les fichiers suivants de n’importe quel nœud du cluster etcd vers ce nœud.:
export CONTROL_PLANE="ubuntu@10.0.0.7"
+scp /etc/kubernetes/pki/etcd/ca.crt "${CONTROL_PLANE}":
+scp /etc/kubernetes/pki/apiserver-etcd-client.crt "${CONTROL_PLANE}":
+scp /etc/kubernetes/pki/apiserver-etcd-client.key "${CONTROL_PLANE}":
CONTROL_PLANE par l'utilisateur@hostname de cette machine.Créez un fichier YAML appelé kubeadm-config.yaml avec le contenu suivant:
apiVersion: kubeadm.k8s.io/v1beta1
kind: ClusterConfiguration
kubernetesVersion: stable
apiServer:
certSANs:
- "LOAD_BALANCER_DNS"
controlPlaneEndpoint: "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT"
etcd:
external:
endpoints:
- https://ETCD_0_IP:2379
- https://ETCD_1_IP:2379
- https://ETCD_2_IP:2379
caFile: /etc/kubernetes/pki/etcd/ca.crt
certFile: /etc/kubernetes/pki/apiserver-etcd-client.crt
keyFile: /etc/kubernetes/pki/apiserver-etcd-client.key
La différence entre etcd empilé et externe, c’est que nous utilisons le champ external
pour etcd dans la configuration de kubeadm. Dans le cas de la topologie etcd empilée,
c'est géré automatiquement.
Remplacez les variables suivantes dans le modèle (template) par les valeurs appropriées pour votre cluster:
LOAD_BALANCER_DNSLOAD_BALANCER_PORTETCD_0_IPETCD_1_IPETCD_2_IPLancez kubeadm init --config kubeadm-config.yaml sur ce nœud.
Ecrivez le résultat de la commande de join dans un fichier texte pour une utilisation ultérieure.
Appliquer le plugin CNI Weave:
kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
Pour ajouter le reste des nœuds du control plane, suivez ces instructions. Les étapes sont les mêmes que pour la configuration etcd empilée, à l’exception du fait qu'un membre etcd local n'est pas créé.
Pour résumer:
--experimental-control-plane.Suivez ces instructions afin d'installer le réseau de pod. Assurez-vous que cela correspond au pod CIDR que vous avez fourni dans le fichier de configuration principal.
Chaque nœud worker peut maintenant être joint au cluster avec la commande renvoyée à partir du resultat
de n’importe quelle commande kubeadm init. L'option --experimental-control-plane ne doit pas
être ajouté aux nœuds workers.
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.
ssh et scp.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.
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.
cat << EOF > /etc/systemd/system/kubelet.service.d/20-etcd-service-manager.conf
[Service]
ExecStart=
ExecStart=/usr/bin/kubelet --address=127.0.0.1 --pod-manifest-path=/etc/kubernetes/manifests
Restart=always
EOF
systemctl daemon-reload
systemctl restart kubelet
Créez des fichiers de configuration pour 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 hosts
export HOST0=10.0.0.6
export HOST1=10.0.0.7
export HOST2=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[@]}"; do
HOST=${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
EOF
done
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.keyCré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 certificates
find /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 host
find /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.
USER=ubuntu
HOST=${HOST1}
scp -r /tmp/${HOST}/* ${USER}@${HOST}:
ssh ${USER}@${HOST}
USER@HOST $ sudo -Es
root@HOST $ chown -R root:root pki
root@HOST $ mv pki /etc/kubernetes/
S'assurer que tous les fichiers attendus existent
La liste complète des fichiers requis sur $HOST0 est la suivante:
/tmp/${HOST0}
└── kubeadmcfg.yaml
---
/etc/kubernetes/pki
├── apiserver-etcd-client.crt
├── apiserver-etcd-client.key
└── etcd
├── ca.crt
├── ca.key
├── healthcheck-client.crt
├── healthcheck-client.key
├── peer.crt
├── peer.key
├── server.crt
└── server.key
Sur $HOST1:
$HOME
└── kubeadmcfg.yaml
---
/etc/kubernetes/pki
├── apiserver-etcd-client.crt
├── apiserver-etcd-client.key
└── etcd
├── ca.crt
├── healthcheck-client.crt
├── healthcheck-client.key
├── peer.crt
├── peer.key
├── server.crt
└── server.key
Sur $HOST2:
$HOME
└── kubeadmcfg.yaml
---
/etc/kubernetes/pki
├── apiserver-etcd-client.crt
├── apiserver-etcd-client.key
└── etcd
├── ca.crt
├── healthcheck-client.crt
├── healthcheck-client.key
├── peer.crt
├── peer.key
├── server.crt
└── server.key
Créer les manifestes de pod statiques
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
Facultatif: Vérifiez la santé du cluster
docker run --rm -it \
--net host \
-v /etc/kubernetes:/etc/kubernetes quay.io/coreos/etcd:${ETCD_TAG} etcdctl \
--cert-file /etc/kubernetes/pki/etcd/peer.crt \
--key-file /etc/kubernetes/pki/etcd/peer.key \
--ca-file /etc/kubernetes/pki/etcd/ca.crt \
--endpoints https://${HOST0}:2379 cluster-health
...
cluster is healthy
${ETCD_TAG} avec la version de votre image etcd. Par exemple v3.2.24.${HOST0} avec l'adresse IP de l'hôte que vous testez.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.
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.
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.
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:
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
clusterDNS:
- 10.96.0.10
Pour plus de détails sur ComponentConfig, jetez un œil à cette section.
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.
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.
Regardez aussi la référence API pour le composant ComponentConfig des kubelets pour plus d'informations sur les champs individuels.
kubeadm initLorsque 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:
KUBELET_KUBEADM_ARGS="--flag1=value1 --flag2=value2 ..."
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:
systemctl daemon-reload && systemctl restart kubelet
Si le rechargement et le redémarrage réussissent, le workflow normal de kubeadm init continue.
kubeadm joinLorsque 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:
systemctl daemon-reload && systemctl restart 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 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.
/etc/kubernetes/bootstrap-kubelet.conf,
mais il n'est utilisé que si /etc/kubernetes/kubelet.conf n'existe pas./etc/kubernetes/kubelet.conf./var/lib/kubelet/config.yaml.KUBELET_KUBEADM_ARGS est sourcé à partir de
/var/lib/kubelet/kubeadm-flags.env.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.Les packages DEB et RPM fournis avec les versions de Kubernetes sont les suivants:
| Nom du paquet | Description |
|---|---|
kubeadm |
Installe l'outil CLI /usr/bin/kubeadm et le fichier instantané de kubelet pour la kubelet. |
kubelet |
Installe /usr/bin/kubelet. |
kubectl |
Installe /usr/bin/kubectl. |
kubernetes-cni |
Installe les binaires officiels du CNI dans le repertoire /opt/cni/bin. |
cri-tools |
Installe /usr/bin/crictl à partir de https://github.com/kubernetes-incubator/cri-tools. |
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 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'installationSi 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:
apt install ebtables ethtool.yum install ebtables ethtool.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:
docker ps et étudier chaque conteneur en exécutant docker logs.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:
sudo systemctl restart docker.service
sudo kubeadm reset
L'inspection des journaux de Docker peut également être utile:
journalctl -ul docker
RunContainerError, CrashLoopBackOff ou ErrorJuste après kubeadm init, il ne devrait pas y avoir de pods dans ces états.
kubeadm 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.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.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 PendingCeci 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.
HostPort ne fonctionnent pasLes 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.
Pour plus d'informations, voir la CNI portmap documentation.
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.
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.
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 ":
mv $HOME/.kube $HOME/.kube.bak
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
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
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.
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:
curl http://169.254.169.254/metadata/v1/interfaces/public/0/anchor_ipv4/address
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
coredns sont en état CrashLoopBackOff ou ErrorSi 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:
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.
allowPrivilegeEscalation sur true peut compromettre
la sécurité de votre cluster.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.:
yum downgrade docker-1.13.1-75.git8633870.el7.centos.x86_64 docker-client-1.13.1-75.git8633870.el7.centos.x86_64 docker-common-1.13.1-75.git8633870.el7.centos.x86_64
sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
yum install docker-ce-18.06.1.ce-3.el7.x86_64