tuto 2022 5, 6
This commit is contained in:
parent
3d7c03fbbd
commit
2af52619c7
43 changed files with 1073 additions and 431 deletions
|
|
@ -5,7 +5,7 @@ Vue d'ensemble de Kubernetes
|
|||
|
||||
*Kubernetes* est un système open source d'orchestration et de gestion de
|
||||
conteneurs. C'est-à-dire qu'il se charge de coller constamment aux
|
||||
spécifications qu'on lui aura demandé.
|
||||
spécifications qu'on lui aura demandées.
|
||||
|
||||
Ce projet est l'aboutissement de plus d'une dizaine d'années d'expérience de
|
||||
gestion de conteneurs applicatifs chez Google (rappelons que c'est eux qui ont
|
||||
|
|
@ -13,13 +13,13 @@ poussé de nombreuses technologies dans le noyau Linux, notamment les
|
|||
*cgroups*, ...).
|
||||
|
||||
Dans Kubernetes, il n'est pas question d'indiquer comment lancer ses
|
||||
conteneurs, ni même quels cgroups utiliser. On va fournir à l'orchestrateur des
|
||||
informations, des *spécifications* qui vont altérer l'état du cluster. Et c'est
|
||||
en cherchant à être constamment dans l'état qu'on lui a décrit, qu'il va
|
||||
conteneurs, ni même quels *cgroups* utiliser. On va fournir à l'orchestrateur
|
||||
des informations, des *spécifications*, qui vont altérer l'état du cluster. Et
|
||||
c'est en cherchant à être constamment dans l'état qu'on lui a décrit, qu'il va
|
||||
s'adapter pour répondre aux besoins.
|
||||
|
||||
Par exemple, on ne va pas lui expliquer comment lancer des conteneurs ou
|
||||
récupérer des images ; mais on va lui demander d'avoir 5 conteneurs youp0m
|
||||
récupérer des images ; mais on va lui demander d'avoir 5 conteneurs `youp0m`
|
||||
lancés, de placer ces conteneurs derrière un load-balancer ; on pourra
|
||||
également lui demander d'adapter la charge pour absorber les pics de trafic
|
||||
(par exemple lors du Black Friday sur une boutique), mais également, il pourra
|
||||
|
|
@ -34,7 +34,7 @@ Architecture de Kubernetes
|
|||
Un cluster Kubernetes est composé d'un (ou plusieurs) nœuds *master*, et d'une
|
||||
série de *workers*.
|
||||
|
||||
Sur le master, on retrouve les composants suivants :
|
||||
Sur le(s) *master(s)*, on retrouve les composants suivants :
|
||||
|
||||
API HTTP
|
||||
: On distingue plusieurs API, elles sont toutes utilisées pour communiquer avec
|
||||
|
|
@ -51,16 +51,13 @@ Le contrôleur
|
|||
**`etcd`**
|
||||
: Il s'agit d'une base de données clef/valeur, supportant la
|
||||
haute-disponibilité, que Kubernetes emploie comme système de stockage
|
||||
persistant pour les objets d'API.
|
||||
persistant pour les objets et ses états.
|
||||
\
|
||||
|
||||
|
||||
Chaque nœud[^minion] (généralement, le nœud *master* est également *worker*) est utilisé
|
||||
Chaque nœud (généralement, le nœud *master* est également *worker*) est utilisé
|
||||
via deux composants :
|
||||
|
||||
[^minion]: historiquement, avant de parler de *node*, on parlait de
|
||||
*minion*. Vous êtes susceptibles de rencontrer encore ce terme dans
|
||||
certaines documentations.
|
||||
|
||||
`kubelet`
|
||||
: C'est l'agent qui va se charger de créer les conteneurs et les manager, afin
|
||||
de répondre aux spécifications.
|
||||
|
|
@ -70,6 +67,7 @@ via deux composants :
|
|||
|
||||
Sans oublier le moteur de conteneurs (généralement Docker), qui va
|
||||
effectivement se charger de lancer les conteneurs demandés par `kubelet`.
|
||||
\
|
||||
|
||||
|
||||
Évidemment, chaque élément de l'architecture est malléable à souhait, c'est la
|
||||
|
|
@ -85,11 +83,12 @@ Avec Docker, nous avons eu l'habitude de travailler avec des objets (images,
|
|||
containers, networks, volumes, secrets, ...). Au sein de Kubernetes, cela
|
||||
s'appelle des *resources* et elles sont très nombreuses.
|
||||
|
||||
Parmi les plus courantes, citons les types (désignés *Kind* dans l'API)
|
||||
suivants :
|
||||
Parmi les plus courantes, citons les types (désignés *Kind* dans l'API, rien à
|
||||
voir avec le projet `kind` au début du sujet) suivants :
|
||||
|
||||
node
|
||||
: il s'agit d'une machine physique ou virtuelle, de notre cluster.
|
||||
: il s'agit d'une machine de notre cluster (elle peut être physique ou
|
||||
virtuelle).
|
||||
|
||||
pod
|
||||
: un groupe de conteneurs travaillant ensemble. Il s'agit de la ressource que
|
||||
|
|
@ -128,8 +127,8 @@ compléter ce schéma...
|
|||
|
||||
Chaque plugin implémente la [spécification
|
||||
CNI](https://github.com/containernetworking/cni/blob/master/SPEC.md#network-configuration)
|
||||
(Container Network Interface). On trouve donc autant de plugin qu'il y a de
|
||||
besoins en terme de réseau.
|
||||
(Container Network Interface). On trouve donc autant de plugins qu'il y a de
|
||||
besoins en termes de réseau.
|
||||
|
||||
Ainsi, à la création d'un conteneur, Kubernetes va laisser aux plugins CNI le
|
||||
loisir d'allouer l'adresse IP, d'ajouter les interfaces réseaux adéquates, de
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue