Environnement de production

• 1: Installer Kubernetes avec les outils de déploiement
• 1.1: Déploiement d'un cluster avec kubeadm
• 1.1.1: Installer kubeadm
• 1.1.2: Création d'un Cluster a master unique avec kubeadm
• 1.1.3: Personnalisation de la configuration du control plane avec kubeadm
• 1.1.4: Options pour la topologie en haute disponibilité
• 1.1.5: Création de clusters hautement disponibles avec kubeadm
• 1.1.6: Configurer un cluster etcd en haute disponibilité avec kubeadm
• 1.1.7: Configuration des kubelet de votre cluster avec kubeadm
• 1.1.8: Dépanner kubeadm
• 2: Solutions Cloud clés en main
• 3: On-Premises VMs
• 4: Windows dans Kubernetes

1 - Installer Kubernetes avec les outils de déploiement

1.1 - Déploiement d'un cluster avec kubeadm

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.

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.

Vérifiez les ports requis

nœuds maîtres (masters)

nœuds workers

** 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).

Installation du runtime

Pour exécuter des conteneurs dans des pods, Kubernetes utilise un container runtime.

• Linux nodes
• autres systèmes d'exploitation

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.

For information about installing kubectl, see Installation et configuration kubectl.

Pour plus d'informations sur les compatibilités de version, voir:

• Kubernetes version et politique de compatibilité de version
• Kubeadm-specific politique de compatibilité de version

• Ubuntu, Debian or HypriotOS
• CentOS, RHEL or Fedora
• Fedora CoreOS ou Flatcar Container Linux

sudo apt-get update && sudo apt-get install -y apt-transport-https curl
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
cat <<EOF | sudo tee /etc/apt/sources.list.d/kubernetes.list
deb https://apt.kubernetes.io/ kubernetes-xenial main
EOF
sudo apt-get update
sudo apt-get install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl

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

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

DOWNLOAD_DIR=/usr/local/bin
sudo mkdir -p $DOWNLOAD_DIR

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

RELEASE="$(curl -sSL https://dl.k8s.io/release/stable.txt)"
ARCH="amd64"
cd $DOWNLOAD_DIR
sudo curl -L --remote-name-all https://storage.googleapis.com/kubernetes-release/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

sudo systemctl enable --now kubelet

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 :

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.

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.

Dépannage

Si vous rencontrez des difficultés avec kubeadm, veuillez consulter notre documentation de dépannage.

A suivre

• Utiliser kubeadm pour créer un cluster

1.1.2 - Création d'un Cluster a 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 Conformance 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

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.

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é.

Objectifs

• Installer un cluster Kubernetes à master unique ou un cluster à haute disponibilité
• Installez un réseau de pods sur le cluster afin que vos pods puissent se parler

Instructions

Installer kubeadm sur vos hôtes

Voir "Installation de kubeadm".

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).

1. 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.
2. (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
3. (Optional) Lancez kubeadm config images pull avant de faire kubeadm init pour vérifier la connectivité aux registres gcr.io.

Maintenant, lancez:

kubeadm init <args>

Plus d'information

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.

Installation d'un add-on réseau

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.

• Le support IPv6 a été ajouté dans CNI v0.6.0.
• 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.

• Choisissez-en un...
• Calico
• Canal
• Cilium
• Flannel
• Kube-router
• Romana
• Weave Net
• JuniperContrail/TungstenFabric

kubectl apply -f https://docs.projectcalico.org/v3.8/manifests/calico.yaml

kubectl apply -f https://docs.projectcalico.org/v3.8/manifests/canal.yaml

kubectl taint nodes <node-name> node-role.kubernetes.io/master:NoSchedule-

kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.4/examples/kubernetes/1.13/cilium.yaml

$ kubectl get pods -n kube-system --selector=k8s-app=cilium
NAME           READY   STATUS    RESTARTS   AGE
cilium-drxkl   1/1     Running   0          18m

kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/a70459be0084506e4ec919aa1c114638878db11b/Documentation/kube-flannel.yml

kubectl apply -f https://raw.githubusercontent.com/romana/romana/master/containerize/specs/romana-kubeadm.yml

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

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:

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.

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:

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

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

(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:

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

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:

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.

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
• En savoir plus sur l'utilisation avancée de kubeadm dans la documentation de référence de kubeadm
• En savoir plus sur Kubernetes concepts et kubectl.
• 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.

Feedback

• Pour les bugs, visitez kubeadm GitHub issue tracker
• Pour le support, rendez vous sur le Channel Slack kubeadm: #kubeadm
• Le Channel Slack: General SIG Cluster Lifecycle Development: #sig-cluster-lifecycle
• SIG Cluster Lifecycle SIG information
• SIG Cluster Lifecycle Mailing List: kubernetes-sig-cluster-lifecycle

Politique de compatibilité de versions

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:

• politique de compatibilité de versions de Kubernetes
• Guide d'installation spécifique à Kubeadm

kubeadm fonctionne sur plusieurs plates-formes

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.

1.1.3 - Personnalisation de la configuration du control plane avec kubeadm

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:

1. Ajoutez les champs appropriés à votre configuration.
2. 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.

Paramètres pour l'API Server

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

Paramètres pour le ControllerManager

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

Paramètres pour le Scheduler

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

1.1.4 - Options pour la topologie en haute disponibilité

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.

Schéma de la Topologie etcd empilée

Topologie etcd externe

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

A suivre

• Configurer un cluster hautement disponible avec kubeadm

1.1.5 - Création de clusters hautement disponibles avec kubeadm

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

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

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

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

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

Voir aussi La documentation de mise à niveau HA.

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

Premières étapes pour les deux méthodes

• 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

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

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

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

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

   • HAProxy peut être utilisé comme load balancer.

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

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

   nc -v LOAD_BALANCER_IP PORT
   

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

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

Configurer SSH

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

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

   eval $(ssh-agent)
   

2. Ajoutez votre clé SSH à la session:

   ssh-add ~/.ssh/path_to_private_key
   

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

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

     ssh -A 10.0.0.7
     

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

     sudo -E -s
     

Control plane empilé et nœuds etcd

Étapes pour le premier nœud du control plane

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

   apiVersion: kubeadm.k8s.io/v1beta1
   kind: ClusterConfiguration
   kubernetesVersion: stable
   apiServer:
     certSANs:
     - "LOAD_BALANCER_DNS"
   controlPlaneEndpoint: "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT"
   

   • kubernetesVersion doit représenter la version de Kubernetes à utiliser. Cet exemple utilise stable.
   • controlPlaneEndpoint doit correspondre à l'adresse ou au DNS et au port du load balancer.
   • Il est recommandé que les versions de kubeadm, kubelet, kubectl et kubernetes correspondent.

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

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

   Vous devriez voir quelque chose comme:

   ...
   

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

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

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

2. Activez l'extension CNI Weave:

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

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

   kubectl get pod -n kube-system -w
   

   • Il est recommandé de ne joindre les nouveaux nœuds du control plane qu'après l'initialisation du premier nœud.

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

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

   USER=ubuntu # customizable
   CONTROL_PLANE_IPS="10.0.0.7 10.0.0.8"
   for host in ${CONTROL_PLANE_IPS}; do
       scp /etc/kubernetes/pki/ca.crt "${USER}"@$host:
       scp /etc/kubernetes/pki/ca.key "${USER}"@$host:
       scp /etc/kubernetes/pki/sa.key "${USER}"@$host:
       scp /etc/kubernetes/pki/sa.pub "${USER}"@$host:
       scp /etc/kubernetes/pki/front-proxy-ca.crt "${USER}"@$host:
       scp /etc/kubernetes/pki/front-proxy-ca.key "${USER}"@$host:
       scp /etc/kubernetes/pki/etcd/ca.crt "${USER}"@$host:etcd-ca.crt
       scp /etc/kubernetes/pki/etcd/ca.key "${USER}"@$host:etcd-ca.key
       scp /etc/kubernetes/admin.conf "${USER}"@$host:
   done
   

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

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

   USER=ubuntu # customizable
   mkdir -p /etc/kubernetes/pki/etcd
   mv /home/${USER}/ca.crt /etc/kubernetes/pki/
   mv /home/${USER}/ca.key /etc/kubernetes/pki/
   mv /home/${USER}/sa.pub /etc/kubernetes/pki/
   mv /home/${USER}/sa.key /etc/kubernetes/pki/
   mv /home/${USER}/front-proxy-ca.crt /etc/kubernetes/pki/
   mv /home/${USER}/front-proxy-ca.key /etc/kubernetes/pki/
   mv /home/${USER}/etcd-ca.crt /etc/kubernetes/pki/etcd/ca.crt
   mv /home/${USER}/etcd-ca.key /etc/kubernetes/pki/etcd/ca.key
   mv /home/${USER}/admin.conf /etc/kubernetes/admin.conf
   

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

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

   sudo kubeadm join 192.168.0.200:6443 --token j04n3m.octy8zely83cy2ts --discovery-token-ca-cert-hash sha256:84938d2a22203a8e56a787ec0c6ddad7bc7dbd52ebabc62fd5f4dbea72b14d1f --experimental-control-plane
   

   • Remarquez l'ajout de l'option --experimental-control-plane. Ce paramètre automatise l'adhésion au control plane du cluster.

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

   kubectl get pod -n kube-system -w
   

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

Noeuds etcd externes

Configurer le cluster etcd

• Suivez ces instructions pour configurer le cluster etcd.

Configurer le premier nœud du control plane

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

   export CONTROL_PLANE="ubuntu@10.0.0.7"
   +scp /etc/kubernetes/pki/etcd/ca.crt "${CONTROL_PLANE}":
   +scp /etc/kubernetes/pki/apiserver-etcd-client.crt "${CONTROL_PLANE}":
   +scp /etc/kubernetes/pki/apiserver-etcd-client.key "${CONTROL_PLANE}":
   

   • Remplacez la valeur de CONTROL_PLANE par l'utilisateur@hostname de cette machine.

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

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

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

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

     • LOAD_BALANCER_DNS
     • LOAD_BALANCER_PORT
     • ETCD_0_IP
     • ETCD_1_IP
     • ETCD_2_IP

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

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

5. Appliquer le plugin CNI Weave:

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

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

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

Pour résumer:

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

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

Installer un réseau de pod

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

Installer les workers

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

1.1.6 - Configurer 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.
• Chaque hôte doit avoir docker, kubelet et kubeadm installés.
• 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.

1. 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
   

2. 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
   

3. 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

4. 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 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
   

5. 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/
   

6. 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
   

7. 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
   

8. 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
   

   • 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.

1.1.7 - Configuration des kubelet de votre cluster avec kubeadm

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:

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.

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.

Regardez aussi la référence API pour le composant ComponentConfig des kubelets pour plus d'informations sur les champs individuels.

Workflow lors de l'utilisation de kubeadm init

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:

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.

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:

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 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:

1.1.8 - Dépanner kubeadm

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:

  • Aller à github.com/kubernetes/kubeadm et rechercher les problèmes existants.
  • 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:

1. Installez à nouveau Docker en suivant les instructions ici.
2. Changez manuellement la configuration de la kubelet pour correspondre au driver Docker cgroup, vous pouvez vous référer à     Configurez le driver de cgroupe utilisé par la kubelet sur le Nœud Master pour des instruction détaillées.

• 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:

sudo systemctl restart docker.service
sudo 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ès 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.
• 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.

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.

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 ":

  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
  

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:

  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
  

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:

• Mise à niveau vers une nouvelle version de Docker.
• Désactiver SELinux.
• 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.

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:

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

• Installez l'une des versions les plus récentes recommandées, telles que la 18.06:

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

2 - Solutions Cloud clés en main

3 - On-Premises VMs

4 - Windows dans Kubernetes