Save tuto corrections
This commit is contained in:
parent
f5ee6b8534
commit
10448a6c8d
115 changed files with 1423 additions and 1289 deletions
|
|
@ -1,16 +1,16 @@
|
|||
\newpage
|
||||
|
||||
Vue d'ensemble de Kubernetes
|
||||
============================
|
||||
----------------------------
|
||||
|
||||
*Kubernetes* est un système open source d'orchestration et de gestion de
|
||||
*Kubernetes* (prononcé
|
||||
Ku-ber-né-tice](https://github.com/kubernetes/kubernetes/issues/44308) en grec)
|
||||
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é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
|
||||
poussé de nombreuses technologies dans le noyau Linux, notamment les
|
||||
*cgroups*, ...).
|
||||
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 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
|
||||
|
|
@ -18,23 +18,22 @@ des informations, des *spécifications*, qui vont altérer l'état du cluster. E
|
|||
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`
|
||||
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
|
||||
gérer les mises à jour des conteneurs selon différentes méthodes, ...
|
||||
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` 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, on pourra gérer les mises à jour des conteneurs selon
|
||||
différentes méthodes ...
|
||||
|
||||
|
||||
Architecture de Kubernetes
|
||||
--------------------------
|
||||
### Architecture de Kubernetes
|
||||
|
||||
|
||||
|
||||
Un cluster Kubernetes est composé d'un (ou plusieurs) nœuds *master*, et d'une
|
||||
série de *workers*.
|
||||
Un cluster Kubernetes est composé d’un (ou plusieurs) nœuds *master*, et d’une série de *workers*.
|
||||
|
||||
Sur le(s) *master(s)*, 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
|
||||
|
|
@ -56,7 +55,7 @@ Le contrôleur
|
|||
|
||||
|
||||
Chaque nœud (généralement, le nœud *master* est également *worker*) est utilisé
|
||||
via deux composants :
|
||||
via deux composants :
|
||||
|
||||
`kubelet`
|
||||
: C'est l'agent qui va se charger de créer les conteneurs et les manager, afin
|
||||
|
|
@ -72,19 +71,18 @@ 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
|
||||
raison pour laquelle il peut être très difficile de mettre en place une
|
||||
architecture Kubernetes : avec ou sans haute-disponibilité, un nœud master
|
||||
architecture Kubernetes : avec ou sans haute-disponibilité, un nœud master
|
||||
dédié au contrôle, avec un moteur de conteneur exotique (`rkt`, `ctr`, ...).
|
||||
|
||||
|
||||
*Resources*
|
||||
-----------
|
||||
### *Resources*
|
||||
|
||||
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, rien à
|
||||
voir avec le projet `kind` au début du sujet) suivants :
|
||||
voir avec le projet `kind` au début du sujet) suivants :
|
||||
|
||||
node
|
||||
: il s'agit d'une machine de notre cluster (elle peut être physique ou
|
||||
|
|
@ -109,12 +107,11 @@ secret
|
|||
: comme `docker secret`, il s'agit d'un moyen de passer des données sensibles à
|
||||
un conteneur.
|
||||
|
||||
Pour voir la liste complète des *resources*, on utilise : `kubectl
|
||||
Pour voir la liste complète des *resources*, on utilise : `kubectl
|
||||
api-resources`.
|
||||
|
||||
|
||||
Modèle réseau
|
||||
-------------
|
||||
### Modèle réseau
|
||||
|
||||
Pour Kubernetes, il n'y a qu'un seul gros réseau au sein duquel se retrouve
|
||||
tous les conteneurs. Il ne doit pas y avoir de NAT, que ce soit entre les
|
||||
|
|
@ -135,8 +132,9 @@ loisir d'allouer l'adresse IP, d'ajouter les interfaces réseaux adéquates, de
|
|||
configurer les routes, les règles de pare-feu, ...
|
||||
|
||||
|
||||
Pour aller plus loin
|
||||
--------------------
|
||||
### Pour aller plus loin
|
||||
|
||||
* [Kubernetes Documentation](https://kubernetes.io/docs/)
|
||||
* [A Reference Architecture for Deploying WSO2 Middleware on Kubernetes](https://medium.com/containermind/a-reference-architecture-for-deploying-wso2-middleware-on-kubernetes-d4dee7601e8e)
|
||||
* La documentation de Kubernetes : <https://kubernetes.io/docs/>
|
||||
* A Reference Architecture for Deploying WSO2 Middleware on Kubernetes :\
|
||||
<https://medium.com/containermind/a-reference-architecture-for-deploying-wso2-middleware-on-kubernetes-d4dee7601e8e>
|
||||
* Les spécifications CNI : <https://github.com/containernetworking/cni/blob/master/SPEC.md#network-configuration>
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue