2019-11-26 15:00:39 +00:00
|
|
|
|
Vue d'ensemble de Kubernetes
|
2022-02-24 19:43:43 +00:00
|
|
|
|
----------------------------
|
2019-11-26 15:00:39 +00:00
|
|
|
|
|
2022-06-26 19:08:01 +00:00
|
|
|
|
*Kubernetes* (prononcé Ku-ber-né-tice[^prononciation-k8s] en grec) est
|
|
|
|
|
un système open source d'orchestration et de gestion de
|
2019-11-26 15:00:39 +00:00
|
|
|
|
conteneurs. C'est-à-dire qu'il se charge de coller constamment aux
|
2021-11-19 23:00:30 +00:00
|
|
|
|
spécifications qu'on lui aura demandées.
|
2019-11-26 15:00:39 +00:00
|
|
|
|
|
2022-06-26 19:08:01 +00:00
|
|
|
|
[^prononciation-k8s]: <https://github.com/kubernetes/kubernetes/issues/44308>
|
|
|
|
|
|
2022-02-24 19:43:43 +00:00
|
|
|
|
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*, ...).
|
2019-11-26 15:00:39 +00:00
|
|
|
|
|
|
|
|
|
Dans Kubernetes, il n'est pas question d'indiquer comment lancer ses
|
2021-11-19 23:00:30 +00:00
|
|
|
|
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
|
2019-11-26 15:00:39 +00:00
|
|
|
|
s'adapter pour répondre aux besoins.
|
|
|
|
|
|
2022-02-24 19:43:43 +00:00
|
|
|
|
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 ...
|
2019-11-26 15:00:39 +00:00
|
|
|
|
|
|
|
|
|
|
2022-02-24 19:43:43 +00:00
|
|
|
|
### Architecture de Kubernetes
|
2019-11-26 15:00:39 +00:00
|
|
|
|
|
|
|
|
|
![Architecture de Kubernetes](k8s-archi.png)
|
|
|
|
|
|
2022-02-24 19:43:43 +00:00
|
|
|
|
Un cluster Kubernetes est composé d’un (ou plusieurs) nœuds *master*, et d’une série de *workers*.
|
2019-11-26 15:00:39 +00:00
|
|
|
|
|
2022-02-24 19:43:43 +00:00
|
|
|
|
Sur le(s) *master(s)*, on retrouve les composants suivants :
|
2019-11-26 15:00:39 +00:00
|
|
|
|
|
|
|
|
|
API HTTP
|
|
|
|
|
: On distingue plusieurs API, elles sont toutes utilisées pour communiquer avec
|
|
|
|
|
le cluster, pour son administration.
|
|
|
|
|
|
|
|
|
|
L'ordonnanceur
|
|
|
|
|
: Il a la responsabilité de monitorer les ressources utilisées sur chaque nœud
|
|
|
|
|
et de répartir les conteneurs en fonction des ressources disponibles.
|
|
|
|
|
|
|
|
|
|
Le contrôleur
|
|
|
|
|
: Il va contrôler l'état des applications déployées au sein du cluster, pour
|
|
|
|
|
s'assurer d'être dans l'état désiré.
|
|
|
|
|
|
|
|
|
|
**`etcd`**
|
|
|
|
|
: Il s'agit d'une base de données clef/valeur, supportant la
|
|
|
|
|
haute-disponibilité, que Kubernetes emploie comme système de stockage
|
2021-11-19 23:00:30 +00:00
|
|
|
|
persistant pour les objets et ses états.
|
|
|
|
|
\
|
2019-11-26 15:00:39 +00:00
|
|
|
|
|
|
|
|
|
|
2021-11-19 23:00:30 +00:00
|
|
|
|
Chaque nœud (généralement, le nœud *master* est également *worker*) est utilisé
|
2022-02-24 19:43:43 +00:00
|
|
|
|
via deux composants :
|
2019-11-26 15:00:39 +00:00
|
|
|
|
|
|
|
|
|
`kubelet`
|
|
|
|
|
: C'est l'agent qui va se charger de créer les conteneurs et les manager, afin
|
|
|
|
|
de répondre aux spécifications.
|
|
|
|
|
|
|
|
|
|
`kube-proxy`
|
|
|
|
|
: Ce programme va servir de load-balancer pour se connecter aux pods.
|
|
|
|
|
|
|
|
|
|
Sans oublier le moteur de conteneurs (généralement Docker), qui va
|
|
|
|
|
effectivement se charger de lancer les conteneurs demandés par `kubelet`.
|
2021-11-19 23:00:30 +00:00
|
|
|
|
\
|
2019-11-26 15:00:39 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
É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
|
2022-02-24 19:43:43 +00:00
|
|
|
|
architecture Kubernetes : avec ou sans haute-disponibilité, un nœud master
|
2019-11-26 15:00:39 +00:00
|
|
|
|
dédié au contrôle, avec un moteur de conteneur exotique (`rkt`, `ctr`, ...).
|
|
|
|
|
|
|
|
|
|
|
2022-02-24 19:43:43 +00:00
|
|
|
|
### *Resources*
|
2019-11-26 15:00:39 +00:00
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
2021-11-19 23:00:30 +00:00
|
|
|
|
Parmi les plus courantes, citons les types (désignés *Kind* dans l'API, rien à
|
2022-02-24 19:43:43 +00:00
|
|
|
|
voir avec le projet `kind` au début du sujet) suivants :
|
2019-11-26 15:00:39 +00:00
|
|
|
|
|
|
|
|
|
node
|
2021-11-19 23:00:30 +00:00
|
|
|
|
: il s'agit d'une machine de notre cluster (elle peut être physique ou
|
|
|
|
|
virtuelle).
|
2019-11-26 15:00:39 +00:00
|
|
|
|
|
|
|
|
|
pod
|
|
|
|
|
: un groupe de conteneurs travaillant ensemble. Il s'agit de la ressource que
|
|
|
|
|
l'on déploie sur un *node*. Les conteneurs au sein d'un *pod* ne peuvent pas
|
2021-09-11 12:41:43 +00:00
|
|
|
|
être séparés pour travailler sur deux *nodes* différents.
|
2019-11-26 15:00:39 +00:00
|
|
|
|
|
|
|
|
|
service
|
|
|
|
|
: c'est un point de terminaison (*endpoint*), stable dans le temps, sur lequel
|
|
|
|
|
on peut se connecter pour accéder à un ou plusieurs
|
|
|
|
|
conteneurs. Historiquement, appelés portails/*portals*, on les retrouve
|
|
|
|
|
encore quelques fois désignés ainsi dans de vieux articles.
|
|
|
|
|
|
|
|
|
|
namespace
|
|
|
|
|
: à ne pas confondre avec les *namespaces* Linux. Ici il s'agit d'espaces de
|
|
|
|
|
noms divers, pour Kubernetes.
|
|
|
|
|
|
|
|
|
|
secret
|
|
|
|
|
: comme `docker secret`, il s'agit d'un moyen de passer des données sensibles à
|
|
|
|
|
un conteneur.
|
|
|
|
|
|
2022-02-24 19:43:43 +00:00
|
|
|
|
Pour voir la liste complète des *resources*, on utilise : `kubectl
|
2019-11-26 15:00:39 +00:00
|
|
|
|
api-resources`.
|
|
|
|
|
|
|
|
|
|
|
2022-02-24 19:43:43 +00:00
|
|
|
|
### Modèle réseau
|
2019-11-26 15:00:39 +00:00
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
*pods* ou les *nodes*, chacun doit pouvoir contacter n'importe quel autre
|
|
|
|
|
élément, sans qu'il y ait de routage.
|
|
|
|
|
|
|
|
|
|
C'est un modèle assez simpliste au premier abord, mais en raison de la
|
|
|
|
|
nécessité de faire un minimum de filtrage, de nombreuses extensions viennent
|
|
|
|
|
compléter ce schéma...
|
|
|
|
|
|
|
|
|
|
Chaque plugin implémente la [spécification
|
|
|
|
|
CNI](https://github.com/containernetworking/cni/blob/master/SPEC.md#network-configuration)
|
2021-11-19 23:00:30 +00:00
|
|
|
|
(Container Network Interface). On trouve donc autant de plugins qu'il y a de
|
|
|
|
|
besoins en termes de réseau.
|
2019-11-26 15:00:39 +00:00
|
|
|
|
|
|
|
|
|
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
|
2022-05-04 09:18:16 +00:00
|
|
|
|
configurer les routes, les règles de pare-feu, ...
|
2019-11-26 15:00:39 +00:00
|
|
|
|
|
|
|
|
|
|
2022-02-24 19:43:43 +00:00
|
|
|
|
### Pour aller plus loin
|
2019-11-26 15:00:39 +00:00
|
|
|
|
|
2022-02-24 19:43:43 +00:00
|
|
|
|
* 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>
|