Database
 sql >> Base de données >  >> RDS >> Database

Comment installer Kubernetes avec Kubeadm

Kubernetes a été présenté dans un article précédent, « Premiers pas avec Kubernetes sur Amazon Web Services (AWS) ». Kubernetes a également été abordé dans un autre article, "Utilisation de Kubernetes (K8s) sur IBM Bluemix". Kubernetes peut être installé sur du métal nu sur presque tous les systèmes d'exploitation, y compris Fedora, CentOS, Ubuntu et CoreOS à des fins de développement.

Le problème

L'installation de Kubernetes sur du métal nu implique l'exécution de plusieurs commandes pour configurer un nœud maître, des nœuds de travail, un réseau de pods, etc.

La solution

Kubernetes 1.4 introduit un nouvel outil appelé kubeadm pour démarrer un cluster Kubernetes. Le kubeadm démarre un cluster Kubernetes avec deux commandes. Après avoir installé Docker, kubectl et kubelet, le nœud maître peut être démarré avec kubeadm init et nœuds de travail ajoutés avec kubeadm join .

Dans cet article, nous allons utiliser la procédure suivante pour installer et démarrer un cluster Kubernetes et ensuite tester le cluster :

  1. Démarrez trois nouvelles instances Ubuntu sur Amazon EC2.
  2. Sur toutes les instances Ubuntu, installez Docker, kubeadm, kubectl et kubelet.
  3. Depuis l'une des instances Ubuntu, initialisez le maître du cluster Kubernetes avec la commande suivante :
    kubeadm init
  4. Appliquer la politique réseau Calico Pod kubeadm/calico.yaml .
  5. Rejoignez les deux autres instances Ubuntu (nœuds) avec le maître avec kubeadm join --token= .
  6. Sur le maître, trois nœuds sont répertoriés avec "kubectl get nodes".
  7. Exécutez une application sur le maître :
    kubectl -s http://localhost:8080 run nginx
       --image=nginx
       --replicas=3 --port=80
    
  8. Listez les pods :
    kubectl get pods -o wide
  9. Désinstallez le cluster Kubernetes.
    kubeadm reset

Cet article comporte les sections suivantes :

  • Configuration de l'environnement
  • Installer Docker, kubeadm, kubectl et kubelet sur chaque hôte
  • Initialisation du maître
  • Installation du réseau Calico Pod
  • Joindre des nœuds au cluster
  • Installation d'un exemple d'application
  • Désinstaller le cluster
  • Limites
  • Autres développements dans kubeadm
  • Conclusion

Configuration de l'environnement

Le kubeadm L'outil nécessite les machines suivantes exécutant l'une des versions d'Ubuntu 16.04+, HypriotOS v1.0.1+ ou CentOS 7.

  • Une machine pour le nœud maître
  • Une ou plusieurs machines pour les noeuds worker

Au moins 1 Go de RAM est requis sur chacune des machines. Nous avons utilisé trois machines Ubuntu exécutées sur Amazon EC2 pour amorcer un cluster avec un seul nœud maître et deux nœuds de travail. Les trois machines Ubuntu sont illustrées à la figure 1.


Figure 1 : Machines Ubuntu

Installer Docker, kubeadm, kubectl et kubelet sur chaque hôte

Dans cette section, nous allons installer Docker, kubelet, kubectl et kubeadm sur chacune des trois machines. Les composants installés sont décrits dans le tableau 1.

Composant Description
Docker Le runtime du conteneur. La version 1.11.2 est recommandée et les v1.10.3 et v1.12.1 conviennent également. Requis sur toutes les machines du cluster.
kubelet Le composant central de Kubernetes qui s'exécute sur toutes les machines du cluster. Démarre les conteneurs et les pods. Requis sur toutes les machines du cluster.
kubectl L'outil en ligne de commande pour gérer un cluster. Requis uniquement sur le nœud maître, mais utile s'il est installé sur tous les nœuds.
kubeadm L'outil pour démarrer un cluster. Requis sur toutes les machines du cluster.

Tableau 1 : Composants à installer

Obtenez l'adresse IP publique de chacune des trois machines et connectez-vous en SSH à chacune des machines :

ssh -i "docker.pem" [email protected]
ssh -i "docker.pem" [email protected]
ssh -i "docker.pem" [email protected]

Les commandes pour installer les binaires doivent être exécutées en tant que root; par conséquent, définissez l'utilisateur sur root.

sudo su -

Exécutez les commandes suivantes sur chacune des machines :

curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg
   | apt-key add -
cat <<EOF > /etc/apt/sources.list.d/kubernetes.list
deb http://apt.kubernetes.io/ kubernetes-xenial main
EOF

La première commande télécharge les packages requis pour Kubernetes, comme illustré dans la sortie de la figure 2.


Figure 2 : Téléchargement de packages pour Kubernetes

La commande 2 télécharge les listes de packages à partir des référentiels et les met à jour avec les dernières versions des packages.

apt-get update

La sortie est illustrée à la figure 3.


Figure 3 : Mise à jour des packages de référentiel

Ensuite, installez Docker :

# Install docker if you don't have it already.
apt-get install -y docker.io

Docker est installé, comme indiqué dans la sortie de la commande de la figure 4.


Figure 4 : Installation de Docker

Et installez ensuite kubelet (composant principal de Kubernetes), kubeadm (outil d'amorçage), kubectl (outil de gestion de cluster) et kubernetes-cni (plugin réseau) :

apt-get install -y kubelet kubeadm kubectl kubernetes-cni

La sortie des commandes précédentes est illustrée à la figure 5.


Figure 5 : Installation de kubelet, kubeadm, kubectln et kubernetes-cni

Initialisation du maître

Ensuite, initialisez le maître sur lequel la base de données etcd et le serveur API s'exécutent. Le kubelet démarre les pods pour exécuter ces composants. Exécutez la commande suivante qui détecte automatiquement les adresses IP :

kubeadm init

Comme indiqué dans la sortie de la commande, certaines vérifications préalables au vol sont d'abord exécutées pour valider l'état du système. Par la suite, un jeton maître/jetons est généré et doit être utilisé comme clé d'authentification mutuelle pour les nœuds de travail qui souhaitent rejoindre le cluster. Ensuite, une clé et un certificat d'autorité de certification auto-signés sont générés pour fournir des identités à chacun des nœuds du cluster pour la communication avec les clients. Une clé et un certificat de serveur API sont créés pour le serveur API pour la communication avec les clients. Un util/kubeconfig le fichier est créé pour que le kubelet se connecte au serveur d'API et à un autre util/kubeconfig fichier est créé pour l'administration. Par la suite, la configuration du client API est créée. La sortie de kubeadm init La commande est illustrée à la figure 6.


Figure 6 : Lancer kubeadm init

Tous les composants du plan de contrôle sont prêts. Le premier nœud devient prêt et un déploiement de test est effectué. Les composants complémentaires essentiels kube-discovery, kube-proxy et kube-dns sont également créés, comme illustré dans la sortie de la commande de la figure 7. Le maître Kubernetes est initialisé avec succès. Une commande avec la syntaxe suivante est générée ; il doit être exécuté sur des machines (nœuds) qui doivent rejoindre le cluster.

kubeadm join -token=<token> <IP Address of the master node>

La commande précédente doit être copiée et conservée pour une utilisation ultérieure sur les noeuds worker.


Figure 7 : Maître Kubernetes initialisé

Par défaut, les nœuds maîtres ne sont pas planifiables et le sont en utilisant la teinte « dédiée ». Le nœud maître peut être rendu programmable avec la commande suivante :

kubectl taint nodes --all dedicated-

Le kubeadm La commande prend en charge d'autres options (voir Tableau 2) que nous n'avions pas à utiliser mais qui pourraient être utilisées pour remplacer la commande par défaut.

Paramètre de commande Description Par défaut
--skip-preflight-checks Ignore les vérifications préliminaires Les vérifications en amont sont effectuées
--use-kubernetes-version Définit la version de Kubernetes à utiliser v1.5.1
--api-advertise-addresses La commande kubeadm init détecte automatiquement et utilise l'adresse IP de l'interface réseau par défaut et l'utilise pour générer des certificats pour le serveur API. Ce paramètre de configuration peut être utilisé pour remplacer la valeur par défaut par une ou plusieurs adresses IP sur lesquelles le serveur API doit être validé. Détection automatique
--api-external-dns-names Ce paramètre de configuration peut être utilisé pour remplacer l'interface réseau par défaut par un ou plusieurs noms d'hôtes sur lesquels le serveur API doit être validé. Une seule adresse IP ou un seul nom DNS externe doit être utilisé.
--fournisseur-cloud Spécifie un fournisseur Cloud.

Le gestionnaire de cloud prend en charge "aws", "azure", "cloudstack", "gce", "mesos", "openstack", "ovirt", "rackspace" et "vsphere". La configuration du fournisseur de cloud peut être fournie dans le fichier /etc/kubernetes/cloud-config. L'utilisation d'un fournisseur Cloud présente également l'avantage d'utiliser des volumes persistants et un équilibrage de charge.

Pas de détection automatique d'un fournisseur Cloud
--pod-network-cidr Alloue des plages de réseau (CIDR) à chaque nœud et est utile pour certaines solutions de mise en réseau, y compris les fournisseurs Flannel et Cloud.
--service-cidr Remplace le sous-réseau que Kubernetes utilise pour attribuer des adresses IP aux pods. Le /etc/systemd/system/kubelet.service.d/10-kubeadm.conf doit également être modifié. 10.96.0.0/12
--service-dns-domain Remplace le suffixe du nom DNS pour attribuer des services avec des noms DNS ; il a le format ..svc.cluster.local . Le /etc/systemd/system/kubelet.service.d/10-kubeadm.conf doit également être modifié. cluster.local
--jeton Spécifie le jeton à utiliser pour l'authentification mutuelle entre le maître et les nœuds rejoignant le cluster. Généré automatiquement

Tableau 2 : Options de la commande Kubeadm

Installation du réseau Calico Pod

Pour que les pods puissent communiquer entre eux, un module complémentaire de réseau de pod doit être installé. Calico fournit une configuration d'installation hébergée par kubeadm sous la forme d'un ConfigMap sur http://docs.projectcalico.org/master/getting-started/kubernetes/installation/hosted/kubeadm/calico.yaml que nous utiliserons dans cette section pour installer un réseau Pod. Exécutez la commande suivante sur le nœud maître pour installer le réseau Pod :

kubectl apply -f
   http://docs.projectcalico.org/master/getting-started/
   kubernetes/installation/hosted/kubeadm/calico.yaml

Vous pouvez également télécharger le calico.yaml et copiez sur le nœud maître :

scp -i "docker.pem" calico.yaml [email protected]:~

Ensuite, exécutez la commande suivante :

kubectl apply -f calico.yaml

Calico et un cluster etcd à nœud unique sont installés, comme illustré à la figure 8.


Figure 8 : Installation de la politique Calico

Ensuite, répertoriez tous les pods dans tous les espaces de noms Kubernetes.

kubectl get pods --all-namespaces

Le kube-dns Le pod doit être en cours d'exécution, comme indiqué dans la figure 9.


Figure 9 : Répertorier les pods dans tous les espaces de noms

Joindre des nœuds au cluster

Dans cette section, nous allons joindre les noeuds worker au cluster en utilisant la kubeadm join commande, dont la syntaxe est la suivante :

kubeadm join --token=<token> <master-ip>

Facultativement, la jointure kubeadm la commande peut être exécutée avec la commande --skip-preflight-checks option pour ignorer la validation préliminaire.

La jointure kubeadm La commande utilise le jeton fourni pour communiquer avec le serveur d'API et obtenir le certificat de l'autorité de certification racine, puis crée une paire de clés locale. Par la suite, une demande de signature de certificat (CSR) est envoyée au serveur API pour signature et le kubelet local est configuré pour se connecter au serveur API.

Exécutez la jointure kubeadm commande copiée depuis la sortie de kubeadm init commande sur chacune des machines Ubuntu qui doivent rejoindre le cluster.

Tout d'abord, connectez-vous en SSH à la ou aux instances Ubuntu :

ssh -i "docker.pem" [email protected]

et

ssh -i "docker.pem" [email protected]

Ensuite, exécutez la kubeadm join commande. Tout d'abord, certaines vérifications pré-vol sont effectuées. Le jeton fourni est validé. Ensuite, la découverte de nœud est utilisée. Un client de découverte d'informations de cluster est créé et des informations sont demandées au serveur d'API. Un objet d'informations de cluster est reçu et une signature est vérifiée à l'aide du jeton donné. La signature et le contenu des informations de cluster sont jugés valides et la découverte du nœud est terminée. Par la suite, un amorçage de nœud est effectué, dans lequel les points de terminaison API https://10.0.0.129:6443 sont utilisés pour établir une connexion. Par la suite, une demande de signature de certificat (csr) est effectuée à l'aide d'un client API pour obtenir un certificat unique pour le nœud. Une fois qu'un certificat signé est reçu du serveur API, un fichier de configuration kubelet est généré. Le message « Node join complete » répertorié dans la figure 10 indique que le nœud a rejoint le cluster.


Figure 10 : Joindre un nœud au cluster

De même, exécutez la même commande sur l'autre machine Ubuntu. L'autre nœud rejoint également le cluster, comme indiqué par la sortie de la figure 11.


Figure 11 : Joindre le deuxième nœud au cluster

Sur le nœud maître, exécutez la commande suivante pour répertorier les nœuds :

kubectl get nodes

Le nœud maître et les deux nœuds de travail doivent être répertoriés, comme illustré à la figure 12.


Figure 12 : Liste des nœuds de cluster Kubernetes

Installation d'un exemple d'application

Ensuite, nous allons tester le cluster. Exécutez la commande suivante pour exécuter un nginx - cluster de pods composé de trois instances dupliquées :

kubectl -s http://localhost:8080 run nginx --image=nginx
   --replicas=3 --port=80

Lister les déploiements :

kubectl get deployments

Répertoriez les pods à l'échelle du cluster :

kubectl get pods -o wide

Exposez le déploiement en tant que service de type LoadBalancer :

kubectl expose deployment nginx --port=80 --type=LoadBalancer

Lister les services :

kubectl get services

La sortie des commandes précédentes indique le nginx déploiement a été créé et les trois pods s'exécutent sur les deux nœuds de travail du cluster. Un service appelé "nginx" est également créé, comme illustré à la figure 13.


Figure 13 : Exécuter un cluster de pods nginx

Copiez l'IP de cluster du service. Exécutez la commande curl pour appeler le service :

curl 10.0.0.99

Le balisage HTML du service obtient une sortie, comme illustré à la figure 14.


Figure 14 : Appel du service nginx

Désinstallation du cluster

Pour désinstaller le cluster installé par kubeadm, exécutez la commande suivante :

kubeadm reset

Le cluster est désinstallé, comme illustré à la figure 15.


Figure 15 : Désinstaller/réinitialiser le cluster Kubernetes

Limites

kubeadm a plusieurs limitations et n'est recommandé que pour une utilisation en développement. Les limitations de kubeadm sont les suivantes :

  • Seuls quelques systèmes d'exploitation sont pris en charge :Ubuntu 16.04+, CentOS 7, HypriotOS v1.0.1+.
  • Ne convient pas à une utilisation en production.
  • L'intégration des fournisseurs cloud est expérimentale.
  • Un cluster avec un seul maître avec une seule base de données etcd dessus est créé. La haute disponibilité n'est pas prise en charge, ce qui implique que le maître est un point de défaillance unique (SPOF).
  • Les fonctionnalités HostPort et HostIP ne sont pas prises en charge.
  • Quelques autres problèmes connus lorsque kubeadm est utilisé avec RHEL/CentOS 7 et VirtualBox.

Autres développements dans kubeadm

kubeadm est en alpha dans Kubernetes v 1.5 et en bêta depuis Kubernetes 1.6. Des corrections mineures et des améliorations continuent d'être apportées à kubeadm à chaque nouvelle version de Kubernetes :

  • Avec Kubernetes 1.7, les modifications apportées aux ressources internes du cluster installées avec kubeadm sont écrasées lors de la mise à niveau de la version 1.6 vers la version 1.7.
  • Dans Kubernetes 1.8, le jeton Bootstrap par défaut créé avec kubeadm init devient non valide et est supprimé après 24 heures de création pour limiter l'exposition de l'identifiant de valeur. La jointure kubeadm La commande délègue le démarrage TLS au kubelet iteslf au lieu de réimplémenter le processus. Le bootstrap KubeConfig le fichier est écrit dans /etc/kubernetes/bootstrap-kubelet-conf avec joindre kubeadm .

Conclusion

Dans cet article, nous avons utilisé la fonctionnalité de l'outil kubeadm disponible depuis Kubernetes v1.4 pour démarrer un cluster Kubernetes. Tout d'abord, les fichiers binaires requis pour Docker, kubectl, kubelet et kubeadm sont installés. Par la suite, le kubeadm init La commande est utilisée pour initialiser le nœud maître dans le cluster. Enfin, la jointure kubeadm La commande est utilisée pour joindre les noeuds worker au cluster. Un exemple de nginx l'application est exécutée pour tester le cluster.