tuto: Update k8s
This commit is contained in:
parent
3a866b10e8
commit
c954191b1a
13 changed files with 211 additions and 147 deletions
|
|
@ -1,14 +1,14 @@
|
|||
Vue d'ensemble de Kubernetes
|
||||
----------------------------
|
||||
|
||||
*Kubernetes* (prononcé Ku-ber-né-tice[^prononciation-k8s] 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.
|
||||
*Kubernetes* (prononcé Ku-ber-né-tice[^prononciation-k8s] en grec) est un
|
||||
système *open source* d'orchestration et de gestion de conteneurs. C'est-à-dire
|
||||
qu'il se charge de faire coller constamment la liste des conteneurs qu'il voit
|
||||
vivant aux spécifications qu'on lui aura demandées.
|
||||
|
||||
[^prononciation-k8s]: <https://github.com/kubernetes/kubernetes/issues/44308>
|
||||
|
||||
Ce projet est l'aboutissement de plus d'une dizaine d'années
|
||||
Ce projet est l'aboutissement de plus d'une quinzaine 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*, ...).
|
||||
|
|
@ -32,9 +32,15 @@ différentes méthodes ...
|
|||
|
||||
|
||||
|
||||
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 *control-plane*, et
|
||||
d’une série de nœuds *workers*.
|
||||
|
||||
Sur le(s) *master(s)*, on retrouve les composants suivants :
|
||||
Le(s) *control-plane(s)* sont en charge de prendre des décisions globales sur
|
||||
le déroulement des opérations du cluster : cela va de la détection d'anomalies
|
||||
sur le cluster ou encore le traiter d'événements et l'organisation de leur
|
||||
réponse, ...
|
||||
|
||||
On retrouve sur ces nœuds centraux les composants suivants :
|
||||
|
||||
API HTTP
|
||||
: On distingue plusieurs API, elles sont toutes utilisées pour communiquer avec
|
||||
|
|
@ -42,11 +48,15 @@ API HTTP
|
|||
|
||||
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.
|
||||
et de répartir les nouveaux 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é.
|
||||
Les contrôleurs
|
||||
: Ils vont contrôler l'état des différents composants déployées au sein du
|
||||
cluster, pour s'assurer d'être dans l'état désiré. Il y a en fait plusieurs
|
||||
contrôleurs ayant chacun la responsabilité de veiller sur une partie des
|
||||
objets, ainsi que le `cloud-controller-manager` lorsque le cluster se trouve
|
||||
chez un hébergeur cloud compatibles.
|
||||
|
||||
**`etcd`**
|
||||
: Il s'agit d'une base de données clef/valeur, supportant la
|
||||
|
|
@ -60,56 +70,24 @@ via deux composants :
|
|||
|
||||
`kubelet`
|
||||
: C'est l'agent qui va se charger de créer les conteneurs et les manager, afin
|
||||
de répondre aux spécifications.
|
||||
de répondre aux spécifications demandées par les *control-planes*.
|
||||
|
||||
`kube-proxy`
|
||||
: Ce programme va servir de load-balancer pour se connecter aux pods.
|
||||
: Ce programme va servir de load-balancer pour se connecter aux conteneurs. Il
|
||||
se base généralement sur le système de filtrage de paquet du système et est
|
||||
donc amené à l'altérer.
|
||||
|
||||
Sans oublier le moteur de conteneurs (généralement Docker), qui va
|
||||
effectivement se charger de lancer les conteneurs demandés par `kubelet`.
|
||||
Sans oublier le moteur de conteneurs (généralement [CRI-O](https://cri-o.io/)),
|
||||
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
|
||||
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
|
||||
dédié au contrôle, avec un moteur de conteneur exotique (`rkt`, `ctr`, ...).
|
||||
|
||||
|
||||
### *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 :
|
||||
|
||||
node
|
||||
: 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
|
||||
l'on déploie sur un *node*. Les conteneurs au sein d'un *pod* ne peuvent pas
|
||||
être séparés pour travailler sur deux *nodes* différents.
|
||||
|
||||
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.
|
||||
|
||||
Pour voir la liste complète des *resources*, on utilise : `kubectl
|
||||
api-resources`.
|
||||
architecture Kubernetes : avec ou sans haute-disponibilité, avec le bon nombre
|
||||
de nœuds décideurs, avec un gestionnaire de réseau qui correspond aux besoins,
|
||||
avec un moteur de conteneur exotique (`rkt`, `ctr`, ...), etc.
|
||||
|
||||
|
||||
### Modèle réseau
|
||||
|
|
@ -120,22 +98,66 @@ tous les conteneurs. Il ne doit pas y avoir de NAT, que ce soit entre les
|
|||
é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...
|
||||
diversité des infrastructures et des besoins différents de chacun, de
|
||||
nombreuses extensions viennent compléter ce schéma.
|
||||
|
||||
Chaque plugin implémente la [spécification
|
||||
La [spécification
|
||||
CNI](https://github.com/containernetworking/cni/blob/master/SPEC.md#network-configuration)
|
||||
(Container Network Interface). On trouve donc autant de plugins qu'il y a de
|
||||
besoins en termes de réseau.
|
||||
(pour Container Network Interface) définit l'interface commune que les plugins
|
||||
doivent gérer : il s'agit de pouvoir ajouter et configurer une interface, la
|
||||
supprimer ou de vérifier qu'une interface va bien.
|
||||
|
||||
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
|
||||
configurer les routes, les règles de pare-feu, ...
|
||||
loisir d'ajouter les interfaces réseaux adéquates, d'allouer l'adresse IP, de
|
||||
configurer les routes, les règles de pare-feu, ... quelque soit
|
||||
l'infrastructure et la complexité du réseau utilisé derrière.
|
||||
\
|
||||
|
||||
Terminons en ajoutant qu'un serveur DNS faisant autorité est nécessaire pour
|
||||
que, de la même manière que Docker, il soit possible d'accéder aux autres
|
||||
conteneurs via leur nom (sans qu'il ne soit nécessaire de le déclarer sur un
|
||||
serveur de noms public). Il n'y a pas de projet de porté par Kubernetes pour
|
||||
cela, mais cette tâche est généralement assurée par
|
||||
[CoreDNS](https://coredns.io/).
|
||||
|
||||
|
||||
### *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` dont on va parler par ailleurs) suivants :
|
||||
|
||||
node
|
||||
: il s'agit d'une machine de notre cluster (elle peut être physique ou
|
||||
virtuelle).
|
||||
|
||||
pod
|
||||
: un groupe de conteneurs travaillant ensemble. C'est la ressource que l'on
|
||||
déploie sur un *node*. Les conteneurs au sein d'un *pod* ne peuvent pas être
|
||||
séparés pour travailler sur deux *nodes* différents.
|
||||
|
||||
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
|
||||
nommés que Kubernetes va utiliser pour regrouper des objets ensembles.
|
||||
|
||||
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
|
||||
api-resources`.
|
||||
|
||||
|
||||
### Pour aller plus loin
|
||||
|
||||
* 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>
|
||||
* Les spécifications CNI : <https://github.com/containernetworking/cni/blob/main/SPEC.md>
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue