Installation

• 1: Environnement d'apprentissage
• 1.1: Installer Kubernetes avec Minikube
• 2: Télécharger Kubernetes
• 2.1: Construire une release
• 3: Environnement de production
• 3.1: Installer Kubernetes avec les outils de déploiement
• 3.1.1: Déploiement d'un cluster avec kubeadm
• 3.1.1.1: Installer kubeadm
• 3.1.1.2: Création d'un Cluster a master unique avec kubeadm
• 3.1.1.3: Personnalisation de la configuration du control plane avec kubeadm
• 3.1.1.4: Options pour la topologie en haute disponibilité
• 3.1.1.5: Création de clusters hautement disponibles avec kubeadm
• 3.1.1.6: Configurer un cluster etcd en haute disponibilité avec kubeadm
• 3.1.1.7: Configuration des kubelet de votre cluster avec kubeadm
• 3.1.1.8: Dépanner kubeadm
• 3.2: Solutions Cloud clés en main
• 3.3: On-Premises VMs
• 3.4: Windows dans Kubernetes
• 4: Solutions Cloud personnalisées
• 4.1: CoreOS sur AWS ou GCE
• 4.2: Installer Kubernetes avec Kubespray (on-premises et fournisseurs de cloud)
• 4.3: Installer Kubernetes sur AWS avec kops

1 - Environnement d'apprentissage

1.1 - Installer Kubernetes avec Minikube

Minikube est un outil facilitant l’exécution locale de Kubernetes. Minikube exécute un cluster Kubernetes à nœud unique dans une machine virtuelle (VM) de votre ordinateur portable pour les utilisateurs qui souhaitent essayer Kubernetes ou le développer au quotidien.

Fonctionnalités de Minikube

Minikube prend en charge les fonctionnalités Kubernetes suivantes:

• DNS
• NodePorts
• ConfigMaps et Secrets
• Dashboards
• Container Runtime: Docker, CRI-O, et containerd
• Activation de la CNI (Container Network Interface)
• Ingress

Installation

Consultez Installation de Minikube.

Démarrage rapide

Cette brève démonstration vous explique comment démarrer, utiliser et supprimer les minikube localement. Suivez les étapes ci-dessous pour commencer et explorer Minikube.

1. Lancez Minikube et créez un cluster:

   minikube start
   

   Le résultat est similaire à ceci:

   Starting local Kubernetes cluster...
   Running pre-create checks...
   Creating machine...
   Starting local Kubernetes cluster...
   

   Pour plus d'informations sur le démarrage de votre cluster avec une version spécifique de Kubernetes, une machine virtuelle ou un environnement de conteneur, voir Démarrage d'un cluster.

2. Vous pouvez maintenant interagir avec votre cluster à l'aide de kubectl. Pour plus d'informations, voir Interagir avec votre cluster.

   Créons un déploiement Kubernetes en utilisant une image existante nommée echoserver, qui est un serveur HTTP, et exposez-la sur le port 8080 à l’aide de --port.

   kubectl create deployment hello-minikube --image=k8s.gcr.io/echoserver:1.10
   

   Le résultat est similaire à ceci:

   deployment.apps/hello-minikube created
   

3. Pour accéder au Deployment hello-minikube, exposez-le comme un Service:

   kubectl expose deployment hello-minikube --type=NodePort --port=8080
   

   L'option --type=NodePort spécifie le type du Service.

   Le résultat est similaire à ceci:

   service/hello-minikube exposed
   

4. Le Pod hello-minikube est maintenant lancé, mais vous devez attendre que le Pod soit opérationnel avant d'y accéder via le Service.

   Vérifiez si le Pod est opérationnel:

   kubectl get pod
   

   Si la sortie affiche le STATUS comme ContainerCreating, le Pod est toujours en cours de création:

   NAME                              READY     STATUS              RESTARTS   AGE
   hello-minikube-3383150820-vctvh   0/1       ContainerCreating   0          3s
   

   Si la sortie indique le statut STATUS comme Running, le Pod est maintenant opérationnel:

   NAME                              READY     STATUS    RESTARTS   AGE
   hello-minikube-3383150820-vctvh   1/1       Running   0          13s
   

5. Obtenez l'URL du Service exposé pour afficher les détails du service:

   minikube service hello-minikube --url
   

6. Pour afficher les détails de votre cluster local, copiez et collez l’URL que vous avez obtenue en tant que sortie dans votre navigateur.

   Le résultat est similaire à ceci:

   Hostname: hello-minikube-7c77b68cff-8wdzq
   
   Pod Information:
       -no pod information available-
   
   Server values:
       server_version=nginx: 1.13.3 - lua: 10008
   
   Request Information:
       client_address=172.17.0.1
       method=GET
       real path=/
       query=
       request_version=1.1
       request_scheme=http
       request_uri=http://192.168.99.100:8080/
   
   Request Headers:
       accept=*/*
       host=192.168.99.100:30674
       user-agent=curl/7.47.0
   
   Request Body:
       -no body in request-
   

   Si vous ne souhaitez plus que le service et le cluster s'exécutent, vous pouvez les supprimer.

7. Supprimez le Service hello-minikube:

    kubectl delete services hello-minikube
   

   Le résultat est similaire à ceci:

   service "hello-minikube" deleted
   

8. Supprimez le Deployment hello-minikube:

   kubectl delete deployment hello-minikube
   

   Le résultat est similaire à ceci:

   deployment.extensions "hello-minikube" deleted
   

9. Arrêtez le cluster de minikube local:

   minikube stop
   

   Le résultat est similaire à ceci:

   Stopping "minikube"...
   "minikube" stopped.
   

   Pour plus d'informations, voir Arrêt d'un cluster.

10. Supprimez le cluster de minikube local:

    minikube delete
    

    Le résultat est similaire à ceci:

    Deleting "minikube" ...
    The "minikube" cluster has been deleted.
    

    Pour plus d'informations, voir Suppression d'un cluster.

Gérer votre cluster

Démarrer un cluster

La commande minikube start peut être utilisée pour démarrer votre cluster. Cette commande crée et configure une machine virtuelle qui exécute un cluster Kubernetes à un seul nœud. Cette commande configure également kubectl pour communiquer avec ce cluster.

Note:

Si vous êtes derrière un proxy Web, vous devez transmettre ces informations à la commande minikube start:

https_proxy=<my proxy> minikube start --docker-env http_proxy=<my proxy> --docker-env https_proxy=<my proxy> --docker-env no_proxy=192.168.99.0/24

Malheureusement, définir les seules variables d'environnement ne fonctionne pas.

Minikube crée également un contexte "minikube" et le définit par défaut dans kubectl. Pour revenir à ce contexte, exécutez la commande suivante: kubectl config use-context minikube.

Spécifier la version de Kubernetes

Vous pouvez spécifier la version de Kubernetes pour Minikube à utiliser en ajoutant la chaîne --kubernetes-version à la commande minikube start. Par exemple, pour exécuter la version v1.21.14, procédez comme suit:

minikube start --kubernetes-version v1.21.14

Spécification du pilote de machine virtuelle

Vous pouvez changer le pilote de machine virtuelle en ajoutant l'indicateur --vm-driver=<nom_du_pilote> à minikube start. Par exemple, la commande serait:

minikube start --vm-driver=<nom_du_pilote>

Minikube prend en charge les pilotes suivants:

Note: Voir DRIVERS pour plus de détails sur les pilotes pris en charge et comment installer les plugins.

• virtualbox
• vmwarefusion
• kvm2 (installation du pilote)
• hyperkit (installation du pilote)
• hyperv (installation du pilote) Notez que l'adresse IP ci-dessous est dynamique et peut changer. Il peut être récupéré avec minikube ip.
• vmware (installation du pilote) (VMware unified driver)
• none (Exécute les composants Kubernetes sur l’hôte et non sur une machine virtuelle. Il n'est pas recommandé d'exécuter le pilote none sur des postes de travail personnels. L'utilisation de ce pilote nécessite Docker (docker installer) et un environnement Linux)

Démarrage d'un cluster sur des exécutions de conteneur alternatives

Vous pouvez démarrer Minikube aux exécutions de conteneurs suivantes.

• containerd
• CRI-O

minikube start \
    --network-plugin=cni \
    --enable-default-cni \
    --container-runtime=containerd \
    --bootstrapper=kubeadm

minikube start \
    --network-plugin=cni \
    --enable-default-cni \
    --extra-config=kubelet.container-runtime=remote \
    --extra-config=kubelet.container-runtime-endpoint=unix:///run/containerd/containerd.sock \
    --extra-config=kubelet.image-service-endpoint=unix:///run/containerd/containerd.sock \
    --bootstrapper=kubeadm

minikube start \
    --network-plugin=cni \
    --enable-default-cni \
    --container-runtime=cri-o \
    --bootstrapper=kubeadm

minikube start \
    --network-plugin=cni \
    --enable-default-cni \
    --extra-config=kubelet.container-runtime=remote \
    --extra-config=kubelet.container-runtime-endpoint=/var/run/crio.sock \
    --extra-config=kubelet.image-service-endpoint=/var/run/crio.sock \
    --bootstrapper=kubeadm

Utiliser des images locales en réutilisant le démon Docker

Lorsque vous utilisez une seule machine virtuelle pour Kubernetes, il est utile de réutiliser le démon Docker intégré de Minikube. La réutilisation du démon intégré signifie que vous n’avez pas besoin de créer un registre Docker sur votre ordinateur hôte et d’y insérer l’image. Au lieu de cela, vous pouvez créer le même démon Docker que Minikube, ce qui accélère les expériences locales.

Note: Assurez-vous de marquer votre image Docker avec autre chose que la plus récente et utilisez cette balise pour extraire l'image. Parce que :latest est la valeur par défaut, avec une stratégie d'extraction d'image par défaut correspondante de Always, une erreur d'extraction d'image (ErrImagePull) est éventuellement générée si vous n'avez pas l'image Docker dans le registre par défaut de Docker (généralement DockerHub). .

Pour travailler avec le démon Docker sur votre hôte Mac/Linux, utilisez la commande docker-env dans votre shell:

eval $(minikube docker-env)

Vous pouvez maintenant utiliser Docker sur la ligne de commande de votre ordinateur hôte Mac/Linux pour communiquer avec le démon Docker dans la VM Minikube:

docker ps

Note:

Sur Centos 7, Docker peut signaler l’erreur suivante:

Could not read CA certificate "/etc/docker/ca.pem": open /etc/docker/ca.pem: no such file or directory

Vous pouvez résoudre ce problème en mettant à jour /etc/sysconfig/docker pour vous assurer que les modifications de l'environnement de Minikube sont respectées:

< DOCKER_CERT_PATH=/etc/docker
---
> if [ -z "${DOCKER_CERT_PATH}" ]; then
>   DOCKER_CERT_PATH=/etc/docker
> fi

Configuration de Kubernetes

Minikube a une fonction de "configurateur" qui permet aux utilisateurs de configurer les composants Kubernetes avec des valeurs arbitraires. Pour utiliser cette fonctionnalité, vous pouvez utiliser l'indicateur --extra-config de la commande minikube start.

Cet indicateur est répété, vous pouvez donc le transmettre plusieurs fois avec plusieurs valeurs différentes pour définir plusieurs options.

Cet indicateur prend une chaîne de la forme composant.key=valeur, où composant est l'une des chaînes de la liste ci-dessous, key est une valeur de la structure de configuration et valeur est la valeur à définir.

Des clés valides peuvent être trouvées en examinant la documentation de Kubernetes composantconfigs pour chaque composant. Voici la documentation pour chaque configuration prise en charge:

• kubelet
• apiserver
• proxy
• controller-manager
• etcd
• scheduler

Exemples

Pour changer le paramètre MaxPods en 5 sur le Kubelet, passez cet indicateur: --extra-config=kubelet.MaxPods=5.

Cette fonctionnalité prend également en charge les structures imbriquées. Pour modifier le paramètre LeaderElection.LeaderElect sur true sur le planificateur, transmettez cet indicateur: --extra-config=scheduler.LeaderElection.LeaderElect=true.

Pour définir le AuthorizationMode du apiserver sur RBAC, vous pouvez utiliser: --extra-config=apiserver.authorization-mode=RBAC.

Arrêter un cluster

La commande minikube stop peut être utilisée pour arrêter votre cluster. Cette commande arrête la machine virtuelle Minikube, mais conserve tout l'état et les données du cluster. Le redémarrage du cluster le restaurera à son état précédent.

Suppression d'un cluster

La commande minikube delete peut être utilisée pour supprimer votre cluster. Cette commande ferme et supprime la machine virtuelle Minikube. Aucune donnée ou état n'est conservé.

Mise à niveau de minikube

Voir upgrade minikube

Interagir avec votre cluster

Kubectl

La commande minikube start crée un contexte kubectl appelé "minikube". Ce contexte contient la configuration pour communiquer avec votre cluster Minikube.

Minikube définit automatiquement ce contexte par défaut, mais si vous devez y revenir ultérieurement, exécutez:

kubectl config use-context minikube,

Ou passez le contexte sur chaque commande comme ceci: kubectl get pods --context=minikube.

Dashboard

Pour accéder au Kubernetes Dashboard, lancez cette commande dans un shell après avoir lancé Minikube pour obtenir l'adresse:

minikube dashboard

Services

Pour accéder à un service exposé via un port de nœud, exécutez cette commande dans un shell après le démarrage de Minikube pour obtenir l'adresse:

minikube service [-n NAMESPACE] [--url] NAME

La mise en réseau

La machine virtuelle Minikube est exposée au système hôte via une adresse IP routable uniquement depuis le hôte, qui peut être obtenue à l'aide de la commande minikube ip. Tous les services de type NodePort sont accessibles via cette adresse IP, sur le NodePort.

Pour déterminer le NodePort pour votre service, vous pouvez utiliser une commande kubectl comme celle-ci:

kubectl get service $SERVICE --output='jsonpath="{.spec.ports[0].nodePort}"'

Volumes persistants

Minikube supporte les PersistentVolumes de type hostPath. Ces volumes persistants sont mappés vers un répertoire à l'intérieur de la VM Minikube.

La machine virtuelle Minikube démarre dans un fichier tmpfs, de sorte que la plupart des répertoires ne seront pas conservés lors des redémarrages avec (minikube stop). Toutefois, Minikube est configuré pour conserver les fichiers stockés dans les répertoires d’hôte suivants:

• /data
• /var/lib/minikube
• /var/lib/docker

Voici un exemple de configuration PersistentVolume permettant de conserver des données dans le répertoire /data:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv0001
spec:
  accessModes:
    - ReadWriteOnce
  capacity:
    storage: 5Gi
  hostPath:
    path: /data/pv0001/

Dossiers hôtes montés

Certains pilotes vont monter un dossier hôte dans la VM afin de pouvoir facilement partager des fichiers entre la VM et l'hôte. Celles-ci ne sont pas configurables pour le moment et diffèrent selon le pilote et le système d'exploitation que vous utilisez.

Note: Le partage de dossier hôte n'est pas encore implémenté dans le pilote KVM.

Registres de conteneurs privés

Pour accéder à un registre de conteneurs privé, suivez les étapes de cette page.

Nous vous recommandons d'utiliser ImagePullSecrets, mais si vous souhaitez configurer l'accès sur la VM Minikube, vous pouvez placer le .dockercfg dans le repertoire /home/docker ou le config.json dans le repertoire /home/docker/.docker.

Add-ons

Pour que Minikube puisse démarrer ou redémarrer correctement des addons personnalisés, placez les addons que vous souhaitez lancer avec Minikube dans le répertoire ~/.minikube/addons. Les extensions de ce dossier seront déplacées vers la VM Minikube et lancées à chaque démarrage ou redémarrage de Minikube.

Utilisation de Minikube avec un proxy HTTP

Minikube crée une machine virtuelle qui inclut Kubernetes et un démon Docker. Lorsque Kubernetes tente de planifier des conteneurs à l'aide de Docker, le démon Docker peut nécessiter un accès réseau externe pour extraire les conteneurs.

Si vous êtes derrière un proxy HTTP, vous devrez peut-être fournir à Docker les paramètres de proxy. Pour ce faire, transmettez les variables d’environnement requises en tant qu’indicateurs lors de la création de minikube start.

Par exemple:

minikube start --docker-env http_proxy=http://$YOURPROXY:PORT \
                 --docker-env https_proxy=https://$YOURPROXY:PORT

Si l'adresse de votre machine virtuelle est 192.168.99.100, il est probable que vos paramètres de proxy empêcheront kubectl de l'atteindre directement. Pour contourner la configuration du proxy pour cette adresse IP, vous devez modifier vos paramètres no_proxy. Vous pouvez le faire avec:

export no_proxy=$no_proxy,$(minikube ip)

Problèmes connus

Les fonctionnalités nécessitant plusieurs nœuds ne fonctionneront pas dans Minikube.

Conception

Minikube utilise libmachine pour le provisionnement de machines virtuelles, et kubeadm mettre en service un cluster Kubernetes.

Pour plus d'informations sur Minikube, voir la proposition.

Liens supplémentaires

• Objectifs et non-objectifs: Pour les objectifs et non-objectifs du projet Minikube, veuillez consulter notre roadmap.
• Guide de développement: Voir CONTRIBUTING.md pour avoir un aperçu de comment envoyer des pull requests.
• Construire Minikube: Pour obtenir des instructions sur la création / test de Minikube à partir des sources, voir le guide de build.
• Ajout d'une nouvelle dépendance: Pour savoir comment ajouter une nouvelle dépendance à Minikube, voir la section guide d'ajout de dépendances.
• Ajout d'un nouvel addon: Pour savoir comment ajouter un nouvel addon pour Minikube, reportez-vous au Ajout d’un addon.
• MicroK8s: Les utilisateurs de Linux qui souhaitent éviter d’exécuter une machine virtuelle peuvent envisager MicroK8s.

Communauté

Les contributions, questions et commentaires sont les bienvenus et sont encouragés ! Les développeurs de minikube sont dans le canal #minikube du Slack de Kubernetes (recevoir une invitation ici). Nous avons également la liste de diffusion kubernetes-dev Google Groupes. Si vous publiez sur la liste, veuillez préfixer votre sujet avec "minikube:".

2 - Télécharger Kubernetes

2.1 - Construire une release

Vous pouvez soit compiler une version à partir des sources, soit télécharger une version pré-compilée. Si vous ne prévoyez pas de développer Kubernetes nous vous suggérons d'utiliser une version pré-compilée de la version actuelle, que l'on peut trouver dans le répertoire Release Notes.

Le code source de Kubernetes peut être téléchargé sur le repo kubernetes/kubernetes.

Installer à partir des sources

Si vous installez simplement une version à partir des sources, il n'est pas nécessaire de mettre en place un environnement golang complet car tous les builds se font dans un conteneur Docker.

Construire une release est simple.

git clone https://github.com/kubernetes/kubernetes.git
cd kubernetes
make release

Pour plus de détails sur le processus de release, voir le repertoire build dans kubernetes/kubernetes.

3 - Environnement de production

3.1 - Installer Kubernetes avec les outils de déploiement

3.1.1 - Déploiement d'un cluster avec kubeadm

3.1.1.1 - Installer kubeadm

Cette page vous apprend comment installer la boîte à outils kubeadm. Pour plus d'informations sur la création d'un cluster avec kubeadm, une fois que vous avez effectué ce processus d'installation, voir la page: Utiliser kubeadm pour créer un cluster.

Pré-requis

• Une ou plusieurs machines exécutant:
  • Ubuntu 16.04+
  • Debian 9+
  • CentOS 7
  • Red Hat Enterprise Linux (RHEL) 7
  • Fedora 25+
  • HypriotOS v1.0.1+
  • Flatcar Container Linux (testé avec 2512.3.0)
• 2 Go ou plus de RAM par machine (toute quantité inférieure laissera peu de place à vos applications)
• 2 processeurs ou plus
• Connectivité réseau complète entre toutes les machines du cluster (réseau public ou privé)
• Nom d'hôte, adresse MAC et product_uuid uniques pour chaque nœud. Voir ici pour plus de détails.
• Certains ports doivent êtres ouverts sur vos machines. Voir ici pour plus de détails.
• Swap désactivé. Vous devez impérativement désactiver le swap pour que la kubelet fonctionne correctement.

Vérifiez que les adresses MAC et product_uuid sont uniques pour chaque nœud

• Vous pouvez obtenir l'adresse MAC des interfaces réseau en utilisant la commande ip link ou ifconfig -a
• Le product_uuid peut être vérifié en utilisant la commande sudo cat /sys/class/dmi/id/product_uuid

Il est très probable que les périphériques matériels aient des adresses uniques, bien que certaines machines virtuelles puissent avoir des valeurs identiques. Kubernetes utilise ces valeurs pour identifier de manière unique les nœuds du cluster. Si ces valeurs ne sont pas uniques à chaque nœud, le processus d'installation peut échouer.

Vérifiez les cartes réseaux

Si vous avez plusieurs cartes réseaux et que vos composants Kubernetes ne sont pas accessibles par la route par défaut, nous vous recommandons d’ajouter une ou plusieurs routes IP afin que les adresses de cluster Kubernetes soient acheminées via la carte approprié.

Permettre à iptables de voir le trafic ponté

Assurez-vous que le module br_netfilter est chargé. Cela peut être fait en exécutant lsmod | grep br_netfilter. Pour le charger explicitement, appelez sudo modprobe br_netfilter.

Pour que les iptables de votre nœud Linux voient correctement le trafic ponté, vous devez vous assurer que net.bridge.bridge-nf-call-iptables est défini sur 1 dans votre configuration sysctl, par ex.

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.

Attention: Ces instructions excluent tous les packages Kubernetes de toutes les mises à niveau du système d'exploitation. C’est parce que kubeadm et Kubernetes ont besoin d'une attention particulière lors de la mise à niveau.

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

• 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/yum-key.gpg 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"
sudo mkdir -p /opt/cni/bin
curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/cni-plugins-linux-amd64-${CNI_VERSION}.tgz" | sudo tar -C /opt/cni/bin -xz

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

CRICTL_VERSION="v1.17.0"
curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-amd64.tar.gz" | sudo tar -C $DOWNLOAD_DIR -xz

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

Note: Depuis que le paramètre --cgroup-driver est obsolète par kubelet, si vous l'avez dans/var/lib/kubelet/kubeadm-flags.env ou /etc/default/kubelet(/etc/sysconfig/kubelet pour les RPM), veuillez le supprimer et utiliser à la place KubeletConfiguration (stocké dans/var/lib/kubelet/config.yaml par défaut).

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

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

Note:

Si vous avez déjà installé kubeadm, lancez apt-get update && apt-get upgrade ou yum update pour obtenir la dernière version de kubeadm.

Lorsque vous effectuez une mise à niveau, la kubelet redémarre plusieurs fois au bout de quelques secondes car elle attend dans une boucle de blocage kubeadm pour lui dire quoi faire. Ce fonctionnement est normal. Une fois que vous avez initialisé votre master, la kubelet s'exécute normalement.

Initialiser votre master

Le master est la machine sur laquelle s'exécutent les composants du control plane, y compris etcd (la base de données du cluster) et l'API serveur (avec lequel la CLI kubectl communique).

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

Avertissement: Cette section contient des informations importantes sur l’ordre d’installation et de déploiement. Lisez-la attentivement avant de continuer.

Vous devez installer un add-on réseau pour pod afin que vos pods puissent communiquer les uns avec les autres.

Le réseau doit être déployé avant toute application. De plus, CoreDNS ne démarrera pas avant l’installation d’un réseau. kubeadm ne prend en charge que les réseaux basés sur un CNI (et ne prend pas en charge kubenet).

Plusieurs projets fournissent des réseaux de pod Kubernetes utilisant CNI, dont certains supportent les network policies. Allez voir la page des add-ons pour une liste complète des add-ons réseau disponibles.

• 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

Note: Pour spécifier un tuple IPv6 pour <maître-ip>: <maître-port>, l'adresse IPv6 doit être placée entre crochets, par exemple: [fd00 :: 101]: 2073.

Le resultat devrait ressembler à quelque chose comme:

[preflight] Running pre-flight checks

... (log output of join workflow) ...

Node join complete:
* Certificate signing request sent to master and response
  received.
* Kubelet informed of new secure connection details.

Run 'kubectl get nodes' on the master to see this machine join.

Quelques secondes plus tard, vous remarquerez ce nœud dans l'output de kubectl get node.

(Optionnel) Contrôler votre cluster à partir de machines autres que le master

Afin d'utiliser kubectl sur une autre machine (par exemple, un ordinateur portable) pour communiquer avec votre cluster, vous devez copier le fichier administrateur kubeconfig de votre master sur votre poste de travail comme ceci:

scp root@<master ip>:/etc/kubernetes/admin.conf .
kubectl --kubeconfig ./admin.conf get nodes

Note:

L'exemple ci-dessus suppose que l'accès SSH est activé pour root. Si ce n'est pas le cas, vous pouvez copier le fichier admin.conf pour qu'il soit accessible à un autre utilisateur. et scp en utilisant cet autre utilisateur à la place.

Le fichier admin.conf donne à l'utilisateur superuser des privilèges sur le cluster. Ce fichier doit être utilisé avec parcimonie. Pour les utilisateurs normaux, il est recommandé de générer une information d'identification unique pour laquelle vous ajoutez des privilèges à la liste blanche (whitelist). Vous pouvez faire ceci avec kubeadm alpha kubeconfig utilisateur --nom-client <CN>. Le resultat de cette commande génèrera un fichier KubeConfig qui sera envoyé sur STDOUT, que vous devrez enregistrer dans un fichier et donner à votre utilisateur. Après cela, créez la whitelist des privilèges en utilisant kubectl create (cluster) rolebinding.

(Facultatif) Proxifier l'API Server vers localhost

Si vous souhaitez vous connecter à l'API server à partir de l'éxterieur du cluster, vous pouvez utiliser kubectl proxy:

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.

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

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

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

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

Pré-requis

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

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

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

• Trois machines supplémentaires pour les membres etcd

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

Premières étapes pour les deux méthodes

Note: Toutes les commandes d'un control plane ou d'un noeud etcd doivent être éxecutées en tant que root.

• Certains plugins réseau CNI tels que Calico nécessitent un CIDR tel que 192.168.0.0 / 16 et  certains comme Weave n'en ont pas besoin. Voir la Documentation du CNI réseau. Pour ajouter un CIDR de pod, définissez le champ podSubnet: 192.168.0.0 / 16 sous   l'objet networking de ClusterConfiguration.

Créez un load balancer pour kube-apiserver

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

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

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

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

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

   • HAProxy peut être utilisé comme load balancer.

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

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

   nc -v LOAD_BALANCER_IP PORT
   

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

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

Configurer SSH

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

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

   eval $(ssh-agent)
   

2. Ajoutez votre clé SSH à la session:

   ssh-add ~/.ssh/path_to_private_key
   

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

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

     ssh -A 10.0.0.7
     

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

     sudo -E -s
     

Control plane empilé et nœuds etcd

Étapes pour le premier nœud du control plane

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

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

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

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

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

   Vous devriez voir quelque chose comme:

   ...
   

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

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

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

2. Activez l'extension CNI Weave:

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

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

   kubectl get pod -n kube-system -w
   

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

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

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

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

Avertissement: N'utilisez que les certificats de la liste ci-dessus. kubeadm se chargera de générer le reste des certificats avec les SANs requis pour les instances du control plane qui se joignent. Si vous copiez tous les certificats par erreur, la création de noeuds supplémentaires pourrait échouer en raison d'un manque de SANs requis.

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

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

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

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

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

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

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

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

   kubectl get pod -n kube-system -w
   

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

Noeuds etcd externes

Configurer le cluster etcd

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

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

Note: kubeadm contient tout ce qui est nécessaire pour générer les certificats décrits ci-dessous; aucun autre outil de chiffrement n'est requis pour cet exemple.

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=/tmp/${HOST1}/kubeadmcfg.yaml
   root@HOST2 $ kubeadm init phase etcd local --config=/tmp/${HOST2}/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.

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

3.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'étatCrashLoopBackOff. 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.

Attention: Désactiver SELinux ou paramètrer allowPrivilegeEscalation sur true peut compromettre la sécurité de votre cluster.

Les pods etcd redémarrent continuellement

Si vous rencontrez l'erreur suivante:

rpc error: code = 2 desc = oci runtime error: exec failed: container_linux.go:247: starting container
process caused "process_linux.go:110: decoding init error from pipe caused \"read parent: connection
reset by peer\""

ce problème apparaît si vous exécutez CentOS 7 avec Docker 1.13.1.84. Cette version de Docker peut empêcher la kubelet de s'exécuter dans le conteneur etcd.

Pour contourner le problème, choisissez l'une de ces options.:

• Revenir à une version antérieure de Docker, telle que la 1.13.1-75:

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

3.2 - Solutions Cloud clés en main

3.3 - On-Premises VMs

3.4 - Windows dans Kubernetes

4 - Solutions Cloud personnalisées

4.1 - CoreOS sur AWS ou GCE

Il existe plusieurs guides permettant d'utiliser Kubernetes avec CoreOS.

Guides officiels CoreOS

Ces guides sont maintenus par CoreOS et déploient Kubernetes à la "façon CoreOS" avec du TLS, le composant complémentaire pour le DNS interne, etc. Ces guides passent les tests de conformité Kubernetes et nous vous recommendons de [les tester vous-même] (https://coreos.com/kubernetes/docs/latest/conformance-tests.html).

• Multi-noeuds sur AWS

  Guide et outil en ligne de commande pour créer un cluster multi-noeuds sur AWS. CloudFormation est utilisé pour créer un noeud maitre ("master") et plusieurs noeuds de type "worker".

• Multi-noeuds sur serveurs physiques (Bare Metal)

  Guide et service HTTP / API pour l'initialisation et l'installation d’un cluster à plusieurs nœuds bare metal à partir d'un PXE. Ignition est utilisé pour provisionner un cluster composé d'un master et de plusieurs workers lors du démarrage initial des serveurs.

• Multi-noeuds sur Vagrant

  Guide pour l'installation d'un cluster multi-noeuds sur Vagrant. L'outil de déploiement permet de configurer indépendemment le nombre de noeuds etcd, masters et workers afin d'obtenir un control plane en haute disponibilité.

• Noeud unique sur Vagrant

  C'est la façon la plus rapide d'installer un environnement de développement local Kubernetes. Il suffit simplement de git clone, vagrant up puis configurer kubectl.

• Guide complet pas à pas

  Un guide générique qui permet de déployer un cluster en haute disponibilité (avec du TLS) sur n'importe cloud ou sur du bare metal. Répéter les étapes pour obtenir plus de noeuds master ou worker

Guide de la communauté

Ces guides sont maintenus par des membres de la communauté et couvrent des besoins et cas d'usages spécifiques. Ils proposent différentes manières de configurer Kubernetes sur CoreOS.

• Cluster multi-noeuds facile sur Google Compute Engine

  Installation scriptée d'un master unique et de plusieurs workers sur GCE. Les composants Kubernetes sont gérés par fleet

• Cluster multi-noeuds en utilisant cloud-config et Weave sur Vagrant

  Configure un cluster de 3 machines sur Vagrant, le réseau du cluster étant fourni par Weave.

• Cluster multi-noeuds en utilisant cloud-config et Vagrant

  Configure un cluster local composé d'un master et de plusieurs workers sur l'hyperviseur de votre choix: VirtualBox, Parallels, ou VMware

• Cluster d'un seul noeud en utilisant une application macOS

  Guide permettant d'obtenir un cluster d'un seul noeud faisant office de master et worker et contrôlé par une application macOS menubar. (basé sur xhyve et CoreOS)

• Cluster multi-noeuds avec Vagrant et fleet en utilisant une petite application macOS

  Guide permettant d'obtenir un cluster composé d'un master, de plusieurs workers contrôlés par une application macOS menubar.

• Multi-node cluster using cloud-config, CoreOS and VMware ESXi

  Configure un cluster composé d'un master et de plusieurs workers sur VMWare ESXi

• Cluster Unique/Multi noeuds en utilisant cloud-config, CoreOS et Foreman

  Configure un cluster composé d'un ou de plusieurs noeuds avec Foreman.

Niveau de support

Pour le niveau de support de toutes les solutions se référer au Tableau des solutions.

4.2 - Installer Kubernetes avec Kubespray (on-premises et fournisseurs de cloud)

Cette documentation permet d'installer rapidement un cluster Kubernetes hébergé sur GCE, Azure, Openstack, AWS, vSphere, Oracle Cloud Infrastructure (expérimental) ou sur des serveurs physiques (bare metal) grâce à Kubespray.

Kubespray se base sur des outils de provisioning, des paramètres et playbooks Ansible ainsi que sur des connaissances spécifiques à Kubernetes et l'installation de systèmes d'exploitation afin de fournir:

• Un cluster en haute disponibilité
• des composants modulables
• Le support des principales distributions Linux:
  • Container Linux de CoreOS
  • Debian Jessie, Stretch, Wheezy
  • Ubuntu 16.04, 18.04
  • CentOS/RHEL 7
  • Fedora/CentOS Atomic
  • openSUSE Leap 42.3/Tumbleweed
• des tests d'intégration continue

Afin de choisir l'outil le mieux adapté à votre besoin, veuillez lire cette comparaison avec kubeadm et kops.

Créer un cluster

(1/5) Prérequis

Les serveurs doivent être installés en s'assurant des éléments suivants:

• Ansible v2.6 (ou version plus récente) et python-netaddr installés sur la machine qui exécutera les commandes Ansible
• Jinja 2.9 (ou version plus récente) est nécessaire pour exécuter les playbooks Ansible
• Les serveurs cibles doivent avoir accès à Internet afin de télécharger les images Docker. Autrement, une configuration supplémentaire est nécessaire, (se référer à Offline Environment)
• Les serveurs cibles doivent être configurés afin d'autoriser le transfert IPv4 (IPv4 forwarding)
• Votre clé ssh doit être copiée sur tous les serveurs faisant partie de votre inventaire Ansible.
• La configuration du pare-feu n'est pas gérée. Vous devrez vous en charger en utilisant votre méthode habituelle. Afin d'éviter tout problème pendant l'installation nous vous conseillons de le désacttiver.
• Si Kubespray est exécuté avec un utilisateur autre que "root", une méthode d'autorisation appropriée devra être configurée sur les serveurs cibles (exemple: sudo). Il faudra aussi utiliser le paramètre ansible_become ou ajouter --become ou b à la ligne de commande.

Afin de vous aider à préparer votre de votre environnement, Kubespray fournit les outils suivants:

• Scripts Terraform pour les fournisseurs de cloud suivants:
  • AWS
  • OpenStack

(2/5) Construire un fichier d'inventaire Ansible

Lorsque vos serveurs sont disponibles, créez un fichier d'inventaire Ansible (inventory). Vous pouvez le créer manuellement ou en utilisant un script d'inventaire dynamique. Pour plus d'informations se référer à Building your own inventory.

(3/5) Préparation au déploiement de votre cluster

Kubespray permet de personnaliser de nombreux éléments:

• Choix du mode: kubeadm ou non-kubeadm
• Plugins CNI (réseau)
• Configuration du DNS
• Choix du control plane: natif/binaire ou dans un conteneur docker/rkt
• Version de chaque composant
• "route reflectors" Calico
• Moteur de conteneur
  • docker
  • rkt
  • cri-o
• Méthode de génération des certificats (Vault n'étant plus maintenu)

Ces paramètres Kubespray peuvent être définis dans un fichier de variables. Si vous venez juste de commencer à utiliser Kubespray nous vous recommandons d'utiliser les paramètres par défaut pour déployer votre cluster et découvrir Kubernetes

(4/5) Déployer un Cluster

Vous pouvez ensuite lancer le déploiement de votre cluster:

Déploiement du cluster en utilisant l'outil en ligne de commande ansible-playbook.

ansible-playbook -i your/inventory/hosts.ini cluster.yml -b -v \
  --private-key=~/.ssh/private_key

Pour des déploiements plus importants (>100 noeuds) quelques ajustements peuvent être nécessaires afin d'obtenir de meilleurs résultats.

(5/5) Vérifier le déploiement

Kubespray fournit le moyen de vérifier la connectivité inter-pods ainsi que la résolution DNS grâce à Netchecker. Les pods netchecker-agents s'assurent que la résolution DNS (services Kubernetes) ainsi que le ping entre les pods fonctionnent correctement. Ces pods reproduisent un comportement similaire à celui des autres applications et offrent un indicateur de santé du cluster.

Opérations sur le cluster

Kubespray fournit des playbooks supplémentaires qui permettent de gérer votre cluster: scale et upgrade.

Mise à l'échelle du cluster

Vous pouvez ajouter des noeuds à votre cluster en exécutant le playbook scale. Pour plus d'informations se référer à Adding nodes. vous pouvez retirer des noeuds de votre cluster en exécutant le playbook remove-node. Se référer à Remove nodes.

Mise à jour du cluster

Vous pouvez mettre à jour votre cluster en exécutant le playbook upgrade-cluster. Pour plus d'informations se référer à Upgrades.

Nettoyage

Vous pouvez réinitialiser vos noeuds et supprimer tous les composants installés par Kubespray en utilisant le playbook reset.

Avertissement: Quand vous utilisez le playbook reset, assurez-vous de ne pas cibler accidentellement un cluster de production !

Retours

• Channel Slack: #kubespray
• Issues GitHub

A suivre

Jetez un oeil aux travaux prévus sur Kubespray: roadmap.

4.3 - Installer Kubernetes sur AWS avec kops

Cette documentation pour un démarrage rapide montre comment facilement installer un cluster Kubernetes sur AWS. L'outil utilisé est kops.

kops est un système de provisionnement dont les principes sont:

• Une installation totalement automatisée
• Utilisation du DNS pour identifier les clusters
• Auto-guérison: tous les composants tournent dans des groupe de mise à l'échelle automatique (auto-scaling)
• Support de plusieurs systèmes d'exploitation (Debian, Ubuntu 16.04 supportés, Centos & RHEL, Amazon Linux et CoreOS) - se référer à images.md
• Haute disponibilité - se référer à high_availability.md
• Peut provisionner directement, ou générer des manifests terraform - se référer à terraform.md

Si ces principes ne vous conviennent pas, vous préférerez probablement construire votre propre cluster selon votre convenance grâce à kubeadm.

Créer un cluster

(1/5) Installer kops

Pré-requis

Il est nécessaire d'avoir kubectl d'installé pour que kops puisse fonctionner.

Installation

Télécharger kops à partir de la page de releases (Il est aussi facile à construire à partir des sources):

Sur macOS:

Téléchargez la dernière version avec la commande:

curl -LO https://github.com/kubernetes/kops/releases/download/$(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4)/kops-darwin-amd64

Pour télécharger une version spécifique, remplacez le

$(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4)

partie de la commande avec la version spécifique.

Par exemple, pour télécharger la version 1.15.0 de kops, tapez:

curl -LO  https://github.com/kubernetes/kops/releases/download/1.15.0/kops-darwin-amd64

Rendre le binaire exécutable kops.

chmod +x kops-darwin-amd64

Déplacez le fichier binaire kops dans votre chemin.

sudo mv kops-darwin-amd64 /usr/local/bin/kops

Vous pouvez également installer kops en utilisant [Homebrew] (https://brew.sh/).

brew update && brew install kops

Sur Linux:

Téléchargez la dernière version avec la commande:

curl -LO https://github.com/kubernetes/kops/releases/download/$(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4)/kops-linux-amd64

Pour télécharger une version spécifique, remplacez le

$(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4)

partie de la commande avec la version spécifique.

Par exemple, pour télécharger la version 1.15.0 de kops, tapez:

curl -LO  https://github.com/kubernetes/kops/releases/download/1.15.0/kops-linux-amd64

Rendre le binaire exécutable kops

chmod +x kops-linux-amd64

Déplacez le fichier binaire kops dans votre chemin.

sudo mv kops-linux-amd64 /usr/local/bin/kops

Vous pouvez également installer kops en utilisant [Homebrew] (https://docs.brew.sh/Homebrew-on-Linux).

brew update && brew install kops

(2/5) Créer un domaine route53 pour votre cluster

kops utilise le DNS pour la découverte, que ce soit à l'intérieur du cluster ou pour pouvoir communiquer avec l'API de kubernetes à partir des clients.

Pour kops le nom du cluster doit impérativement être un nom de domaine valide. De cette façon vous ne confondrez pas vos cluster et vous pourrez les partager avec vos collègues sans ambiguïté. Par ailleurs vous pourrez vous y connecter sans avoir à vous rappeler une adresse IP.

Vous pouvez, et vous devriez certainement, utiliser des sous-domaines afin de séparer vos clusters. Dans notre exemple nous utiliserons useast1.dev.example.com. Le point d'accès au serveur API sera donc api.useast1.dev.example.com.

Une zone hébergée Route53 peut servir les sous-domaines. Votre zone hébergée pourrait être useast1.dev.example.com, mais aussi dev.example.com ou même example.com. kops fonctionne avec n'importe lequel d'entre eux, le choix dépend de vos contraintes d'organisation (ex: Vous êtes autorisés à créer des enregistrements dns dans dev.example.com mais pas dans example.com)

Supposons que vous utilisiez dev.example.com comme zone hébergée. Vous créeriez cette zone hébergée en utilisant la méthode normal, ou avec une ligne de commande telle que aws route53 create-hosted-zone --name dev.example.com --caller-reference 1.

Vous devrez ensuite configurer vos enregistrements NS dans le domaine parent afin que vous puissiez résoudre dans ce domaine. Vous créeriez donc des enregistrements NS dans le domaine example.com pour dev. S'il s'agit d'un nom de domaine racine, vous devrez configurer les enregistrements NS chez votre hébergeur de nom de domaine (là où vous avez acheté votre nom de domaine example.com).

Cette étape est délicate, soyez vigilants (c’est la première cause de problèmes !). Vous pouvez vérifier que votre cluster est configuré correctement avec l'outil dig, en exécutant:

dig NS dev.example.com

Vous devriez voir les 4 enregistrements NS attribués à votre zone hébergée sur Route53.

(3/5) Créez un conteneur (bucket) S3 pour stocker l'état de vos clusters.

kops vous permet de gérer vos clusters même lorsque ceux-ci sont déjà installés. Pour ce faire, il est nécessaire de conserver une trace des clusters que vous avez créé, avec leur configuration, les clés qu’ils utilisent, etc. Ces informations sont stockées dans un bucket S3. Les autorisations S3 sont utilisées pour contrôler l'accès au bucket.

Plusieurs clusters peuvent utiliser le même bucket S3 et vous pouvez aussi le partager avec vos collègues qui administrer les mêmes clusters - c'est beaucoup plus facile que de faire circuler des fichiers kubecfg. Cependant quiconque ayant accès au bucket S3 aura un accès complet (permissions élevées) à tous vos clusters. Vous souhaiterez donc limiter l'accès à l'équipe opérationnelle.

Plus généralement, vous auriez un bucket S3 pour chaque équipe ops (et le nom correspondrait souvent au nom de la zone hébergée ci-dessus!)

Dans notre exemple, nous avons choisi dev.example.com comme zone hébergée. Nous allons donc choisir clusters.dev.example.com comm le nom du bucket S3.

• Exportez AWS_PROFILE (si vous devez sélectionner un profil pour que l'outil en ligne de commande d'AWS fonctionne).

• Créez le compartiment S3 en utilisant aws s3 mb s3://clusters.dev.example.com

• Vous pouvez export KOPS_STATE_STORE=s3://clusters.dev.example.com afin que kops utilise cet emplacement par défaut.   Nous vous suggérons de le mettre dans votre profil bash ou similaire.

(4/5) Construisez votre configuration de cluster

Exécutez "kops create cluster" pour créer votre configuration de cluster:

kops create cluster --zones=us-east-1c useast1.dev.example.com

kops créera la configuration pour votre cluster. Notez que cela génère uniquement la configuration, la création des ressources cloud se fait à l'étape suivante avec kops update cluster. Cela vous permettra d'analyser la configuration ou de la modifier avant de l'appliquer.

Voici quelques commandes qui vous permettent de visualiser ou éditer:

• Listez vos clusters avec: kops get cluster
• Éditez ce cluster avec: kops edit cluster useast1.dev.example.com
• Modifiez votre groupe d'instances de nœuds: kops edit ig --name=useast1.dev.example.com nodes
• Éditez votre groupe d'instances maître (master): kops edit ig --name=useast1.dev.example.com master-us-east-1c

Si vous utilisez kops pour la première fois, prenez quelques minutes pour les essayer! Un groupe d'instances est un ensemble d'instances, qui seront enregistrées en tant que noeuds kubernetes. Sur AWS, cela est implémenté via des groupes de mise à l'échelle automatique (auto-scaling). Vous pouvez avoir plusieurs groupes d'instances, par exemple si vous voulez des nœuds combinant des instances ponctuelles (spot instances) et à la demande, ou éventuellement des instances GPU et non-GPU.

(5/5) Créer le cluster dans AWS

Exécutez "kops update cluster" pour créer votre cluster dans AWS :

kops update cluster useast1.dev.example.com --yes

Cela prend quelques secondes à s'exécuter, et ensuite votre cluster prendra probablement quelques minutes pour être réellement opérationnel. kops update cluster sera l'outil que vous utiliserez à chaque fois que vous modifierez la configuration de votre cluster. Il applique les modifications que vous avez apportées à la configuration sur votre cluster (reconfiguration d'AWS ou de kubernetes au besoin).

Par exemple, après un kops edit ig nodes, puis un kops update cluster --yes pour appliquer votre configuration, parfois, vous devrez également exécuter un kops rolling-update cluster pour déployer la configuration immédiatement.

Sans l'argument --yes, kops update cluster vous montrera un aperçu de ce qu’il va faire. C'est pratique pour les clusters de production !

Explorer d'autres composants additionnels (add-ons)

Reportez-vous à la [liste des add-ons] (/docs/concepts/cluster-administration/addons/) pour explorer d'autres add-ons, y compris des outils de journalisation, de surveillance, de stratégie réseau, de visualisation ou de contrôle de votre cluster Kubernetes.

Nettoyer

• Pour supprimer votre cluster: kops delete cluster useast1.dev.example.com --yes

Retour d'information

• Channel Slack: [#kops-users] (https://kubernetes.slack.com/messages/kops-users/)
• [Problèmes GitHub] (https://github.com/kubernetes/kops/issues)

A suivre

• En apprendre davantages sur les concepts Kubernetes et kubectl.
• En savoir plus sur les utilisations avancées de kops.
• Pour les bonnes pratiques et les options de configuration avancées de kops se référer à la documentation