L’auteur a sélectionné le Free and Open Source pour recevoir un don dans le cadre du Write for DOnations programme.
introduction
https://kubernetes.io [Kubernetes] est un système d’orchestration de conteneurs qui gère les conteneurs à grande échelle. Initialement développé par Google sur la base de son expérience dans la production de conteneurs, Kubernetes est une source ouverte et activement développée par une communauté du monde entier.
https://kubernetes.io/docs/reference/setup-tools/kubeadm/ kubeadm/[Kubeadm] automatise l’installation et la configuration de composants Kubernetes tels que le serveur API, le gestionnaire de contrôleurs et le DNS Kube. Cependant, il ne crée pas d’utilisateurs ni ne gère l’installation des dépendances au niveau du système d’exploitation et leur configuration. Pour ces tâches préliminaires, il est possible d’utiliser un outil de gestion de la configuration tel que Ansible ou SaltStack. L’utilisation de ces outils permet de créer des clusters supplémentaires ou de recréer des clusters existants beaucoup plus simplement et moins sujet aux erreurs.
Dans ce guide, vous allez configurer un cluster Kubernetes à partir de zéro en utilisant Ansible et Kubeadm, puis y déployer une application Nginx conteneurisée.
Buts
Votre cluster comprendra les ressources physiques suivantes:
-
* Un nœud maître *
Le nœud maître (un nœud dans Kubernetes fait référence à un serveur) est responsable de la gestion de l’état du cluster. Il exécute Etcd, qui stocke les données de cluster entre des composants qui planifient des charges de travail sur des nœuds de travail.
-
* Deux nœuds de travail *
Les nœuds de travail sont les serveurs sur lesquels votre workloads (c’est-à-dire applications et services conteneurisés) s’exécutera. Un travailleur continuera à exécuter votre charge de travail une fois qu’il lui est attribué, même si le maître tombe en panne une fois la planification terminée. La capacité d’un cluster peut être augmentée en ajoutant des travailleurs.
Une fois ce guide terminé, vous disposerez d’un cluster prêt à exécuter des applications conteneurisées, à condition que les serveurs du cluster disposent de suffisamment de ressources de processeur et de RAM pour être utilisées par vos applications. Presque toutes les applications Unix traditionnelles, y compris les applications Web, les bases de données, les démons et les outils de ligne de commande peuvent être conteneurisées et exécutées sur le cluster. Le cluster lui-même consommera environ 300 à 500 Mo de mémoire et 10% de CPU sur chaque nœud.
Une fois le cluster configuré, vous déploierez le serveur Web Nginx afin de vous assurer qu’il exécute correctement les workloads.
Conditions préalables
-
Une paire de clés SSH sur votre ordinateur Linux / Mac OS / BSD local. Si vous n’avez jamais utilisé de clés SSH, vous pouvez apprendre à les configurer en suivant https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and- keys # générer-et-travailler-avec-ssh-keys [cette explication sur la façon de configurer des clés SSH sur votre machine locale].
-
Trois serveurs exécutant Ubuntu 16.04 avec au moins 2 Go de RAM et 2 vCPU chacun. Vous devriez être capable de SSH sur chaque serveur en tant qu’utilisateur root avec votre paire de clés SSH.
-
Ansible installé sur votre machine locale. Si vous utilisez Ubuntu 16.04 comme système d’exploitation, suivez la section intitulée «Étape 1 - Installation de Ansible» dans https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-ansible-on- ubuntu-16-04 [Comment installer et configurer Ansible sur Ubuntu 16.04] pour installer Ansible. Pour obtenir des instructions d’installation sur d’autres plates-formes, telles que Mac OS X ou CentOS, suivez la page official installation d’installation.
-
Familiarité avec les playbooks Ansible. Pour un examen, consultez Configuration Management 101: Écrire des livres de lecture.
-
Savoir comment lancer un conteneur à partir d’une image Docker. Consultez «Étape 5 - Exécution d’un conteneur Docker» dans https://www.digitalocean.com/community/tutorials/how-to-install-and-use-docker-on-ubuntu-16-04#step-5- % E2% 80% 94-running-a-docker-container [Comment installer et utiliser Docker sur Ubuntu 16.04] si vous avez besoin d’un rappel.
Étape 1 - Configuration du répertoire de l’espace de travail et du fichier d’inventaire variable
Dans cette section, vous allez créer un répertoire sur votre ordinateur local qui servira d’espace de travail. Vous allez également configurer Ansible localement pour qu’il puisse communiquer avec et exécuter des commandes sur vos serveurs distants. Pour ce faire, vous allez créer un fichier + hosts +
contenant des informations d’inventaire telles que les adresses IP de vos serveurs et les groupes auxquels chaque serveur appartient.
Sur vos trois serveurs, l’un sera le maître avec une adresse IP affichée sous la forme «». Les deux autres serveurs seront des travailleurs et auront les adresses IP `` et ++
.
Créez un répertoire nommé + ~ / kube-cluster
dans le répertoire personnel de votre machine locale et` + cd` dans celui-ci:
mkdir ~/kube-cluster
cd ~/kube-cluster
Ce répertoire sera votre espace de travail pour le reste du didacticiel et contiendra tous vos playbooks Ansible. Ce sera également le répertoire dans lequel vous exécuterez toutes les commandes locales.
Créez un fichier nommé + ~ / kube-cluster / hosts +
en utilisant + nano +
ou votre éditeur de texte préféré:
nano ~/kube-cluster/hosts
Ajoutez le texte suivant au fichier, qui spécifiera des informations sur la structure logique de votre cluster:
~ / kube-cluster / hosts
[masters]
master ansible_host= ansible_user=root
[workers]
worker1 ansible_host= ansible_user=root
worker2 ansible_host= ansible_user=root
[all:vars]
ansible_python_interpreter=/usr/bin/python3
Vous pouvez vous rappeler que inventory files dans Ansible sont utilisés pour spécifier des informations sur le serveur, telles que des adresses IP, des utilisateurs distants et des groupes de serveurs à cibler. une seule unité pour exécuter des commandes. + ~ / kube-cluster / hosts +
sera votre fichier d’inventaire et vous y aurez ajouté deux groupes Ansible (* maîtres * et * travailleurs *) en spécifiant la structure logique de votre cluster.
Dans le groupe * maîtres *, il existe une entrée de serveur nommée «maître» qui répertorie l’adresse IP du nœud maître (++
) et spécifie que Ansible doit exécuter des commandes distantes en tant qu’utilisateur root.
De même, dans le groupe * workers *, il existe deux entrées pour les serveurs de travail (` et `
) qui spécifient également le + ansible_user +
en tant que root.
La dernière ligne du fichier indique à Ansible d’utiliser les interpréteurs Python 3 des serveurs distants pour ses opérations de gestion.
Enregistrez et fermez le fichier après avoir ajouté le texte.
Après avoir configuré l’inventaire du serveur avec des groupes, passons à l’installation de dépendances au niveau du système d’exploitation et à la création de paramètres de configuration.
Étape 2 - Création d’un utilisateur non racine sur tous les serveurs distants
Dans cette section, vous allez créer un utilisateur non root doté de privilèges sudo sur tous les serveurs, de manière à ce que vous puissiez y entrer manuellement en SSH en tant qu’utilisateur sans privilège. Cela peut être utile si, par exemple, vous souhaitez voir des informations système avec des commandes telles que + top / htop +
, afficher une liste des conteneurs en cours d’exécution ou modifier les fichiers de configuration appartenant à root. Ces opérations sont effectuées systématiquement lors de la maintenance d’un cluster. L’utilisation d’un utilisateur non root pour de telles tâches minimise le risque de modification ou de suppression de fichiers importants ou d’exécution involontaire d’autres opérations dangereuses.
Créez un fichier nommé + ~ / kube-cluster / initial.yml +
dans l’espace de travail:
nano ~/kube-cluster/initial.yml
Ensuite, ajoutez le fichier suivant play au fichier pour créer un utilisateur non root doté de privilèges sudo sur tous les serveurs. Un jeu dans Ansible est un ensemble d’étapes à effectuer qui ciblent des serveurs et des groupes spécifiques. Le jeu suivant créera un utilisateur sudo non-root:
~ / kube-cluster / initial.yml
- hosts: all
become: yes
tasks:
- name: create the 'ubuntu' user
user: name=ubuntu append=yes state=present createhome=yes shell=/bin/bash
- name: allow 'ubuntu' to have passwordless sudo
lineinfile:
dest: /etc/sudoers
line: 'ubuntu ALL=(ALL) NOPASSWD: ALL'
validate: 'visudo -cf %s'
- name: set up authorized keys for the ubuntu user
authorized_key: user=ubuntu key="{{item}}"
with_file:
- ~/.ssh/id_rsa.pub
Voici un aperçu de ce que ce livre de jeu fait:
-
Crée l’utilisateur non root
+ ubuntu
. -
Configure le fichier
+ sudoers
pour permettre à l’utilisateur` + ubuntu` d’exécuter des commandes+ sudo +
sans invite de mot de passe. -
Ajoute la clé publique de votre ordinateur local (généralement
+ ~ / .ssh / id_rsa.pub +
) à la liste de clés autorisées de l’utilisateur+ ubuntu +
distant. Cela vous permettra d’utiliser SSH sur chaque serveur en tant qu’utilisateur+ ubuntu +
.
Enregistrez et fermez le fichier après avoir ajouté le texte.
Ensuite, exécutez le playbook en lançant localement:
ansible-playbook -i hosts ~/kube-cluster/initial.yml
La commande sera terminée dans un délai de deux à cinq minutes. Une fois terminé, vous verrez une sortie semblable à celle-ci:
OutputPLAY [all] ****
TASK [Gathering Facts] ****
ok: [master]
ok: [worker1]
ok: [worker2]
TASK [create the 'ubuntu' user] ****
changed: [master]
changed: [worker1]
changed: [worker2]
TASK [allow 'ubuntu' user to have passwordless sudo] ****
changed: [master]
changed: [worker1]
changed: [worker2]
TASK [set up authorized keys for the ubuntu user] ****
changed: [worker1] => (item=ssh-rsa AAAAB3...
changed: [worker2] => (item=ssh-rsa AAAAB3...
changed: [master] => (item=ssh-rsa AAAAB3...
PLAY RECAP ****
master : ok=5 changed=4 unreachable=0 failed=0
worker1 : ok=5 changed=4 unreachable=0 failed=0
worker2 : ok=5 changed=4 unreachable=0 failed=0
Maintenant que la configuration préliminaire est terminée, vous pouvez installer les dépendances spécifiques à Kubernetes.
Étape 3 - Installation des dépendances de Kubernetes
Dans cette section, vous allez installer les paquetages au niveau du système d’exploitation requis par Kubernetes avec le gestionnaire de paquets d’Ubuntu. Ces forfaits sont:
-
Docker - une exécution de conteneur. C’est le composant qui exécute vos conteneurs. La prise en charge d’autres environnements d’exécution tels que rkt est en cours de développement actif dans Kubernetes.
-
+ kubeadm +
- un outil CLI qui installera et configurera les différents composants d’un cluster de manière standard. -
+ kubelet +
- un service / programme système qui s’exécute sur tous les nœuds et gère les opérations au niveau du nœud. -
+ kubectl +
- un outil CLI utilisé pour émettre des commandes au cluster via son serveur API.
Créez un fichier nommé '+ ~ / kube-cluster / kube-dependencies.yml + `dans l’espace de travail:
nano ~/kube-cluster/kube-dependencies.yml
Ajoutez les pièces suivantes au fichier pour installer ces packages sur vos serveurs:
~ / kube-cluster / kube-dependencies.yml
- hosts: all
become: yes
tasks:
- name: install Docker
apt:
name: docker.io
state: present
update_cache: true
- name: install APT Transport HTTPS
apt:
name: apt-transport-https
state: present
- name: add Kubernetes apt-key
apt_key:
url: https://packages.cloud.google.com/apt/doc/apt-key.gpg
state: present
- name: add Kubernetes' APT repository
apt_repository:
repo: deb http://apt.kubernetes.io/ kubernetes-xenial main
state: present
filename: 'kubernetes'
- name: install kubelet
apt:
name: kubelet=1.14.0-00
state: present
update_cache: true
- name: install kubeadm
apt:
name: kubeadm=1.14.0-00
state: present
- hosts: master
become: yes
tasks:
- name: install kubectl
apt:
name: kubectl=1.14.0-00
state: present
force: yes
La première pièce du livre de jeu a les effets suivants:
-
Installe Docker, l’environnement d’exécution du conteneur.
-
Installez
+ apt-transport-https
, vous permettant d’ajouter des sources HTTPS externes à votre liste de sources APT. -
Ajoute la clé apt du référentiel Kubernetes APT pour la vérification des clés.
-
Ajoute le référentiel Kubernetes APT à la liste des sources APT de vos serveurs distants.
-
Installez
+ kubelet
et` + kubeadm`.
La deuxième partie consiste en une tâche unique qui installe + kubectl
sur votre nœud maître.
Enregistrez et fermez le fichier lorsque vous avez terminé.
Ensuite, exécutez le playbook en lançant localement:
ansible-playbook -i hosts ~/kube-cluster/kube-dependencies.yml
Une fois terminé, vous verrez une sortie semblable à celle-ci:
OutputPLAY [all] ****
TASK [Gathering Facts] ****
ok: [worker1]
ok: [worker2]
ok: [master]
TASK [install Docker] ****
changed: [master]
changed: [worker1]
changed: [worker2]
TASK [install APT Transport HTTPS] *****
ok: [master]
ok: [worker1]
changed: [worker2]
TASK [add Kubernetes apt-key] *****
changed: [master]
changed: [worker1]
changed: [worker2]
TASK [add Kubernetes' APT repository] *****
changed: [master]
changed: [worker1]
changed: [worker2]
TASK [install kubelet] *****
changed: [master]
changed: [worker1]
changed: [worker2]
TASK [install kubeadm] *****
changed: [master]
changed: [worker1]
changed: [worker2]
PLAY [master] *****
TASK [Gathering Facts] *****
ok: [master]
TASK [install kubectl] ******
ok: [master]
PLAY RECAP ****
master : ok=9 changed=5 unreachable=0 failed=0
worker1 : ok=7 changed=5 unreachable=0 failed=0
worker2 : ok=7 changed=5 unreachable=0 failed=0
Après exécution, Docker, + kubeadm +
, et + kubelet +
seront installés sur tous les serveurs distants. + kubectl +
n’est pas un composant requis, il n’est nécessaire que pour exécuter des commandes de cluster. L’installer uniquement sur le nœud maître est logique dans ce contexte, car vous n’exécuterez les commandes + kubectl +
que depuis le maître. Notez cependant que les commandes + kubectl +
peuvent être exécutées à partir de n’importe quel nœud de travail ou de n’importe quel ordinateur sur lequel il peut être installé et configuré pour pointer vers un cluster.
Toutes les dépendances du système sont maintenant installées. Configurons le noeud maître et initialisons le cluster.
Étape 4 - Configuration du nœud principal
Dans cette section, vous allez configurer le nœud maître. Avant de créer des playbooks, cependant, il convient de couvrir quelques concepts tels que Pods et Pod Network Plugins, car votre cluster inclura les deux.
Un pod est une unité atomique qui exécute un ou plusieurs conteneurs. Ces conteneurs partagent des ressources telles que des volumes de fichiers et des interfaces réseau communes. Les pods sont l’unité de base de la planification dans Kubernetes: tous les conteneurs d’un pod sont assurés de s’exécuter sur le même nœud que celui-ci.
Chaque pod a sa propre adresse IP et un pod sur un nœud devrait pouvoir accéder à un pod sur un autre nœud en utilisant l’adresse IP du pod. Les conteneurs sur un seul nœud peuvent facilement communiquer via une interface locale. Cependant, la communication entre les pods est plus compliquée et nécessite un composant réseau séparé pouvant acheminer de manière transparente le trafic d’un pod d’un noeud à un autre.
Cette fonctionnalité est fournie par les plug-ins de réseau pod. Pour ce cluster, vous utiliserez Flannel, une option stable et performante.
Créez un livre de lecture Ansible nommé + master.yml +
sur votre ordinateur local:
nano ~/kube-cluster/master.yml
Ajoutez la lecture suivante au fichier pour initialiser le cluster et installer Flannel:
~ / kube-cluster / master.yml
- hosts: master
become: yes
tasks:
- name: initialize the cluster
shell: kubeadm init --pod-network-cidr=10.244.0.0/16 >> cluster_initialized.txt
args:
chdir: $HOME
creates: cluster_initialized.txt
- name: create .kube directory
become: yes
become_user: ubuntu
file:
path: $HOME/.kube
state: directory
mode: 0755
- name: copy admin.conf to user's kube config
copy:
src: /etc/kubernetes/admin.conf
dest: /home/ubuntu/.kube/config
remote_src: yes
owner: ubuntu
- name: install Pod network
become: yes
become_user: ubuntu
shell: kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/a70459be0084506e4ec919aa1c114638878db11b/Documentation/kube-flannel.yml >> pod_network_setup.txt
args:
chdir: $HOME
creates: pod_network_setup.txt
Voici le détail de cette pièce:
-
La première tâche initialise le cluster en exécutant
+ kubeadm init +
. Passer l’argument+ - pod-network-cidr = 10.244.0.0 / 16 +
spécifie le sous-réseau privé à partir duquel les IP du pod seront attribuées. Flannel utilise le sous-réseau ci-dessus par défaut. nous disons+ kubeadm +
d’utiliser le même sous-réseau. -
La deuxième tâche crée un répertoire
+ .kube
sur` + / home / ubuntu`. Ce répertoire contiendra des informations de configuration, telles que les fichiers de clé d’administrateur, nécessaires pour se connecter au cluster, ainsi que l’adresse de l’API du cluster. -
La troisième tâche copie le fichier
+ / etc / kubernetes / admin.conf +
généré à partir de+ kubeadm init +
dans le répertoire de base de votre utilisateur non root. Cela vous permettra d’utiliser+ kubectl +
pour accéder au cluster nouvellement créé. -
La dernière tâche exécute
+ kubectl apply +
pour installer+ Flannel +
.+ kubectl applique le descripteur -f. [yml | json] +
est la syntaxe pour indiquer à + kubectl +de créer les objets décrits dans le fichier descripteur
. [yml | json] + `. Le fichier ` kube-flannel.yml ` contient les descriptions des objets nécessaires à la configuration de ` Flannel +` dans le cluster.
Enregistrez et fermez le fichier lorsque vous avez terminé.
Exécutez le playbook localement en lançant:
ansible-playbook -i hosts ~/kube-cluster/master.yml
Une fois terminé, vous verrez une sortie semblable à celle-ci:
Output
PLAY [master] ****
TASK [Gathering Facts] ****
ok: [master]
TASK [initialize the cluster] ****
changed: [master]
TASK [create .kube directory] ****
changed: [master]
TASK [copy admin.conf to user's kube config] *****
changed: [master]
TASK [install Pod network] *****
changed: [master]
PLAY RECAP ****
master : ok=5 changed=4 unreachable=0 failed=0
Pour vérifier l’état du nœud maître, introduisez-le dans SSH à l’aide de la commande suivante:
ssh ubuntu@
Une fois à l’intérieur du nœud maître, exécutez:
kubectl get nodes
Vous verrez maintenant la sortie suivante:
OutputNAME STATUS ROLES AGE VERSION
master Ready master 1d v1.14.0
La sortie indique que le nœud + maître +
a terminé toutes les tâches d’initialisation et se trouve dans un état + Prêt +
à partir duquel il peut commencer à accepter les nœuds de travail et à exécuter les tâches envoyées au serveur API. Vous pouvez maintenant ajouter les travailleurs de votre machine locale.
Étape 5 - Configuration des nœuds de travail
L’ajout de travailleurs au cluster implique l’exécution d’une seule commande sur chacun d’eux. Cette commande inclut les informations de cluster nécessaires, telles que l’adresse IP et le port du serveur d’API du maître, ainsi qu’un jeton sécurisé. Seuls les nœuds qui passent dans le jeton sécurisé pourront rejoindre le cluster.
Revenez à votre espace de travail et créez un livre de lecture nommé + workers.yml +
:
nano ~/kube-cluster/workers.yml
Ajoutez le texte suivant au fichier pour ajouter les travailleurs au cluster:
~ / kube-cluster / workers.yml
- hosts: master
become: yes
gather_facts: false
tasks:
- name: get join command
shell: kubeadm token create --print-join-command
register: join_command_raw
- name: set join command
set_fact:
join_command: "{{ join_command_raw.stdout_lines[0] }}"
- hosts: workers
become: yes
tasks:
- name: join cluster
shell: "{{ hostvars['master'].join_command }} >> node_joined.txt"
args:
chdir: $HOME
creates: node_joined.txt
Voici ce que le playbook fait:
-
La première lecture obtient la commande join qui doit être exécutée sur les nœuds de travail. Cette commande aura le format suivant:
+ kubeadm join --token <jeton> <ip maître>: <port-maître> --discovery-token-ca-cert-hash sha256: <hash> +
. Une fois que la commande réelle avec les valeurs * token * et * hash * appropriées est obtenue, la tâche la définit comme un fait afin que la prochaine lecture puisse accéder à ces informations. -
La deuxième partie comporte une tâche unique qui exécute la commande de jointure sur tous les nœuds de travail. A la fin de cette tâche, les deux nœuds de travail feront partie du cluster.
Enregistrez et fermez le fichier lorsque vous avez terminé.
Exécutez le playbook en exécutant localement:
ansible-playbook -i hosts ~/kube-cluster/workers.yml
Une fois terminé, vous verrez une sortie semblable à celle-ci:
OutputPLAY [master] ****
TASK [get join command] ****
changed: [master]
TASK [set join command] *****
ok: [master]
PLAY [workers] *****
TASK [Gathering Facts] *****
ok: [worker1]
ok: [worker2]
TASK [join cluster] *****
changed: [worker1]
changed: [worker2]
PLAY RECAP *****
master : ok=2 changed=1 unreachable=0 failed=0
worker1 : ok=2 changed=1 unreachable=0 failed=0
worker2 : ok=2 changed=1 unreachable=0 failed=0
Avec l’ajout des nœuds de travail, votre cluster est maintenant entièrement opérationnel et fonctionnel. Les travailleurs sont prêts à exécuter des charges de travail. Avant de planifier des applications, vérifions que le cluster fonctionne comme prévu.
Étape 6 - Vérification du cluster
Un cluster peut parfois échouer lors de la configuration car un nœud est en panne ou la connectivité réseau entre le maître et l’ouvrier ne fonctionne pas correctement. Vérifions le cluster et assurez-vous que les nœuds fonctionnent correctement.
Vous devrez vérifier l’état actuel du cluster à partir du nœud maître pour vous assurer que les nœuds sont prêts. Si vous vous êtes déconnecté du nœud maître, vous pouvez y revenir à l’aide de la commande suivante:
ssh ubuntu@
Ensuite, exécutez la commande suivante pour obtenir le statut du cluster:
kubectl get nodes
Vous verrez une sortie semblable à celle-ci:
OutputNAME STATUS ROLES AGE VERSION
master Ready master 1d v1.14.0
worker1 Ready <none> 1d v1.14.0
worker2 Ready <none> 1d v1.14.0
Si tous vos noeuds ont la valeur + Ready +
pour + STATUS +
, cela signifie qu’ils font partie du cluster et qu’ils sont prêts à exécuter des workloads.
Cependant, si quelques nœuds ont + NotReady +
comme + STATUS +
, cela peut signifier que les nœuds de travail n’ont pas encore terminé leur configuration. Attendez environ cinq à dix minutes avant de réexécuter + kubectl get node +
et d’inspecter la nouvelle sortie. Si quelques nœuds ont toujours le statut + NotReady +
, vous devrez peut-être vérifier et réexécuter les commandes des étapes précédentes.
Maintenant que votre cluster est correctement vérifié, planifions un exemple d’application Nginx sur le cluster.
Étape 7 - Exécution d’une application sur le cluster
Vous pouvez maintenant déployer n’importe quelle application conteneurisée sur votre cluster. Pour rester familiers, déployons Nginx à l’aide de Deployments et Services pour voir comment cette application peut être déployée sur le cluster. Vous pouvez également utiliser les commandes ci-dessous pour d’autres applications conteneurisées, à condition de modifier le nom de l’image Docker et tous les indicateurs pertinents (tels que + ports +
et + volumes +
).
Toujours dans le nœud maître, exécutez la commande suivante pour créer un déploiement nommé + nginx +
:
kubectl create deployment --image=
Un déploiement est un type d’objet Kubernetes qui garantit qu’il existe toujours un nombre spécifié de pods s’appuyant sur un modèle défini, même si le pod se bloque pendant la durée de vie du cluster. Le déploiement ci-dessus crée un pod avec un conteneur à partir de l’image nginx Docker du registre Docker.
Ensuite, exécutez la commande suivante pour créer un service nommé + nginx +
qui exposera publiquement l’application. Cela se fera via un NodePort, un schéma qui rendra le pod accessible via un port arbitraire ouvert sur chaque nœud du cluster:
kubectl expose deploy --port --target-port --type NodePort
Les services sont un autre type d’objet Kubernetes qui expose les services internes du cluster aux clients, internes et externes. Ils sont également capables d’équilibrer la charge des demandes adressées à plusieurs pods et font partie intégrante de Kubernetes, interagissant fréquemment avec d’autres composants.
Exécutez la commande suivante:
kubectl get services
Cela produira un texte similaire à celui-ci:
OutputNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 1d
NodePort 10.109.228.209 <none> 80:/TCP 40m
À partir de la troisième ligne de la sortie ci-dessus, vous pouvez récupérer le port sur lequel Nginx est exécuté. Kubernetes attribuera automatiquement un port aléatoire supérieur à + 30000 +
, tout en veillant à ce que le port ne soit pas déjà lié à un autre service.
Pour vérifier que tout fonctionne, visitez + http: //: +
ou + http: //: +
via un navigateur sur votre ordinateur local. Vous verrez la page d’accueil familière de Nginx.
Si vous souhaitez supprimer l’application Nginx, commencez par supprimer le service + nginx +
du nœud maître:
kubectl delete service
Exécutez ce qui suit pour vous assurer que le service a été supprimé:
kubectl get services
Vous verrez la sortie suivante:
OutputNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 1d
Puis supprimez le déploiement:
kubectl delete deployment
Exécutez ce qui suit pour confirmer que cela a fonctionné:
kubectl get deployments
OutputNo resources found.
Conclusion
Dans ce guide, vous avez configuré avec succès un cluster Kubernetes sur Ubuntu 16.04 en utilisant Kubeadm et Ansible pour l’automatisation.
Si vous vous demandez quoi faire du cluster maintenant qu’il a été configuré, une bonne étape serait de vous familiariser avec le déploiement de vos propres applications et services sur le cluster. Voici une liste de liens contenant des informations supplémentaires pouvant vous guider dans le processus:
-
Dockerizing applications - répertorie des exemples détaillant la mise en conteneur des applications à l’aide de Docker.
-
Pod Overview - décrit en détail le fonctionnement des pods et leur relation avec les autres objets Kubernetes. Les pods sont omniprésents dans Kubernetes, alors les comprendre facilitera votre travail.
-
Deployments Overview - ceci fournit une vue d’ensemble des déploiements. Il est utile de comprendre le fonctionnement des contrôleurs, tels que les déploiements, car ils sont fréquemment utilisés dans des applications sans état pour la mise à l’échelle et la guérison automatisée des applications défectueuses.
-
Services Overview - couvre les services, un autre objet fréquemment utilisé dans les clusters Kubernetes. Comprendre les types de services et leurs options est essentiel pour exécuter des applications sans état et avec état.
Parmi les autres concepts importants que vous pouvez explorer, vous trouverez Volumes, Ingresses. et Secrets, qui sont tous pratiques lors du déploiement d’applications de production.
Kubernetes a beaucoup de fonctionnalités et de fonctionnalités à offrir. La documentation officielle de Kubernetes est le meilleur endroit pour en savoir plus sur les concepts, trouver des guides spécifiques à une tâche et rechercher des références d’API pour divers objets.