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 de 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 / macOS / BSD local. Si vous n’avez jamais utilisé de clés SSH, vous pouvez apprendre à les configurer en suivant les explications fournies à l’adresse https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients. -and-keys # générer-et-travailler-avec-ssh-keys [comment configurer des clés SSH sur votre machine locale].
-
Trois serveurs exécutant CentOS 7 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. Veillez également à ajouter votre clé publique au compte de l’utilisateur * centos * sur le nœud maître. Si vous avez besoin de conseils pour ajouter une clé SSH à un compte d’utilisateur particulier, consultez ce didacticiel à l’adresse How Configurer les clés SSH sur CentOS7.
-
Ansible installé sur votre machine locale. Pour obtenir des instructions sur l’installation, suivez les http://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html #installing-the-control-machine[fichier officiel 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. Reportez-vous à «Étape 5 - Utilisation d’un conteneur Docker» dans https://www.digitalocean.com/community/tutorials/how-to-install-and-use-docker-on-centos-7#step-5-%E2. % 80% 94-running-a-docker-container [Comment installer et utiliser Docker sur CentOS 7] si vous avez besoin d’un rafraîchissement.
É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 + vi +
ou votre éditeur de texte favori:
vi ~/kube-cluster/hosts
Appuyez sur + i +
pour insérer le texte suivant dans le 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
Lorsque vous avez terminé, appuyez sur + ESC +
suivi de +: wq +
pour écrire les modifications dans le fichier et quitter.
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.
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 - Installation des dépendances de Kubernetes
Dans cette section, vous allez installer les packages au niveau du système d’exploitation requis par Kubernetes avec le gestionnaire de packages + yum +
de CentOS. Ces forfaits sont:
-
Docker - une exécution de conteneur. C’est le composant qui exécute vos conteneurs. La prise en charge d’autres applications telles 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:
vi ~/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
yum:
name: docker
state: present
update_cache: true
- name: start Docker
service:
name: docker
state: started
- name: disable SELinux
command: setenforce 0
- name: disable SELinux on reboot
selinux:
state: disabled
- name: ensure net.bridge.bridge-nf-call-ip6tables is set to 1
sysctl:
name: net.bridge.bridge-nf-call-ip6tables
value: 1
state: present
- name: ensure net.bridge.bridge-nf-call-iptables is set to 1
sysctl:
name: net.bridge.bridge-nf-call-iptables
value: 1
state: present
- name: add Kubernetes' YUM repository
yum_repository:
name: Kubernetes
description: Kubernetes YUM repository
baseurl: https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
gpgkey: https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
gpgcheck: yes
- name: install kubelet
yum:
name: kubelet-1.14.0
state: present
update_cache: true
- name: install kubeadm
yum:
name: kubeadm-1.14.0
state: present
- name: start kubelet
service:
name: kubelet
enabled: yes
state: started
- hosts: master
become: yes
tasks:
- name: install kubectl
yum:
name: kubectl-1.14.0
state: present
allow_downgrade: yes
La première pièce du livre de jeu a les effets suivants:
-
Installe Docker, l’environnement d’exécution du conteneur.
-
Démarre le service Docker.
-
Désactive SELinux car il n’est pas encore totalement supporté par Kubernetes.
-
Définit quelques valeurs
+ sysctl +
liées à netfilter requises pour la mise en réseau. Cela permettra à Kubernetes de définir des règles iptables pour la réception du trafic réseau ponté IPv4 et IPv6 sur les nœuds. -
Ajoute le référentiel Kubernetes YUM aux listes de référentiels 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:
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 [disable SELinux] ****
changed: [master]
changed: [worker1]
changed: [worker2]
TASK [disable SELinux on reboot] ****
changed: [master]
changed: [worker1]
changed: [worker2]
TASK [ensure net.bridge.bridge-nf-call-ip6tables is set to 1] ****
changed: [master]
changed: [worker1]
changed: [worker2]
TASK [ensure net.bridge.bridge-nf-call-iptables is set to 1] ****
changed: [master]
changed: [worker1]
changed: [worker2]
TASK [start Docker] ****
changed: [master]
changed: [worker1]
changed: [worker2]
TASK [add Kubernetes' YUM 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]
TASK [start kubelet] ****
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:
vi ~/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: centos
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/centos/.kube/config
remote_src: yes
owner: centos
- name: install Pod network
become: yes
become_user: centos
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 / centos`. 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 * centos *. 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:
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 centos@
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 +
:
vi ~/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 }} --ignore-preflight-errors all >> 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:
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 centos@
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 que tout reste familier, déployons Nginx en utilisant 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 correctement configuré un cluster Kubernetes sous CentOS 7 à l’aide de Kubeadm et d’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.