tuto: Update k8s
This commit is contained in:
parent
3a866b10e8
commit
c954191b1a
|
|
@ -1,6 +1,6 @@
|
|||
include ../pandoc-opts.mk
|
||||
|
||||
SOURCES_TUTO = tutorial-el.md setup.md intro-srs.md intro.md overview.md discover.md discover-cmd-virli.md discover2.md run.md run-cmd-virli.md run2.md scaling.md rendu.md
|
||||
SOURCES_TUTO = tutorial-el.md chapter.md overview.md setup.md intro-srs.md intro.md discover.md discover-cmd-virli.md discover2.md run.md run-cmd-virli.md run2.md scaling.md rendu.md
|
||||
|
||||
|
||||
all: tutorial.pdf
|
||||
|
|
|
|||
|
|
@ -0,0 +1,29 @@
|
|||
Tour d'horizon de Kubernetes
|
||||
============================
|
||||
|
||||
Nous avons abordé plusieurs aspects des conteneurs qui les rendent
|
||||
particulièrement attrayants dans un environnement de production :
|
||||
principalement le fait de cloisonner les environnements de telle sorte
|
||||
qu’un développeur peut concevoir lui-même l’environnement d’exécution
|
||||
de son application, laissant à l’équipe d’administrateurs système le
|
||||
soin de gérer les machines et le système de base.
|
||||
|
||||
Docker est désormais considéré comme un projet mature et est digne
|
||||
d’être utilisé en production. Bien qu’il soit acceptable de déployer
|
||||
des conteneurs via des outils de provisionnement tels qu’Ansible ou
|
||||
Salt, on peut faire beaucoup mieux.
|
||||
|
||||
Kubernetes se place comme un orchestrateur de conteneur : il peut
|
||||
piloter, sur une grappe de machines, le lancement, le monitoring et la
|
||||
mise à jour de conteneurs. On peut ajouter ou retirer des machines au
|
||||
cluster, il va toujours faire en sorte de garder l’équilibre qu’on lui
|
||||
a demandé de conserver.
|
||||
|
||||
C’est une solution qui est particulièrement adaptée au monde des
|
||||
entreprises géantes, mais elle vient avec une courbe d’apprentissage
|
||||
particulièrement abrupte. Il faut bien veiller à jauger les avantages
|
||||
et les inconvénients d’une telle solution avant de la choisir, car si
|
||||
l’outil promet de résoudre des problèmes que vont rencontrer des très
|
||||
gros sites web à fort trafic, cela peut demander aussi beaucoup
|
||||
d’investissements tant humains que financiers pour des entreprises qui
|
||||
voudraient juste profiter de l’outil sans réel besoin.
|
||||
|
|
@ -1,3 +1,3 @@
|
|||
```bash
|
||||
kubectl create -f https://supplements.alpo.tf/493960009/insecure-dashboard.yaml
|
||||
kubectl create -f https://supplements.alpo.tf/493960009/dashboard-insecure.yaml
|
||||
```
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
```bash
|
||||
kubectl create -f https://virli.nemunai.re/insecure-dashboard.yaml
|
||||
kubectl create -f https://virli.nemunai.re/dashboard-insecure.yaml
|
||||
```
|
||||
|
|
|
|||
|
|
@ -75,26 +75,42 @@ Pour le moment, nous n'avons qu'un seul service, il s'agit de l'API Kubernetes.
|
|||
|
||||
Jetons un œil aux conteneurs actifs :
|
||||
|
||||
```bash
|
||||
kubectl get pods
|
||||
```
|
||||
42sh$ kubectl get pods
|
||||
No resources found in default namespace.
|
||||
```
|
||||
|
||||
Regardons maintenant les `namespaces` :
|
||||
A priori, nous n'avons rien lancé, donc cette commande ne nous
|
||||
retourne effectivement rien. Mais on nous précise que notre vue est
|
||||
limitée à l'espace par défaut.
|
||||
|
||||
Voyons s'il n'y a pas d'autres `namespaces` :
|
||||
|
||||
```bash
|
||||
kubectl get namespaces
|
||||
```
|
||||
|
||||
On l'a vu, les *namespaces* ici désignent des espaces de noms qui n'ont rien à
|
||||
voir avec les *namespaces* de Linux. Regardons par exemple les conteneurs d'un
|
||||
autre espace de noms :
|
||||
::::: {.warning}
|
||||
|
||||
Les *namespaces* ici désignent des espaces de noms qui n'ont rien à voir avec
|
||||
les *namespaces* de Linux. Il s'agit pour Kubernetes d'un groupe d'objets, qui
|
||||
permet notamment de mieux s'y retrouver.
|
||||
|
||||
:::::
|
||||
|
||||
Regardons par exemple les conteneurs d'un autre espace de noms :
|
||||
|
||||
```bash
|
||||
kubectl -n kube-system get pods
|
||||
42sh$ kubectl -n kube-system get pods
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
coredns-565d847f94-6f7ln 1/1 Running 0 14m
|
||||
etcd-kind-control-plane 1/1 Running 0 14m
|
||||
kindnet-2gwlp 1/1 Running 0 13m
|
||||
...
|
||||
```
|
||||
|
||||
Eh oui ! De nombreux services de base pour Kubernetes tournent dans des
|
||||
conteneurs, gérés par lui-même... notamment :
|
||||
Eh oui ! De nombreux services de base de Kubernetes tournent dans des
|
||||
conteneurs... qu'il gèren lui-même ! Notamment :
|
||||
|
||||
- `etcd` : notre base de données clef/valeur,
|
||||
- `kube-apiserver` : l'API REST avec qui communique `kubectl`,
|
||||
|
|
@ -119,9 +135,9 @@ Nous devons lancer un *pod* (qui ne contiendra qu'un seul conteneur).
|
|||
kubectl run pingpong --image alpine ping 1.1.1.1
|
||||
```
|
||||
|
||||
`kubectl` doit nous indiquer nous qu'un *pod* a été créé.
|
||||
`kubectl` doit nous indiquer en retour qu'un *pod* a été créé.
|
||||
|
||||
Si l'on affiche la liste des *pod*s, vous devriez avoir quelque chose qui
|
||||
Si l'on affiche la liste des *pod*s, nous devrions avoir quelque chose qui
|
||||
ressemble à cela :
|
||||
|
||||
```
|
||||
|
|
@ -193,7 +209,7 @@ Pas de panique, on peut très facilement le décortiquer :
|
|||
Les tâches de déploiement (*deployment.apps*) sont des ressources de
|
||||
haut niveau et sont là pour s'assurer que les migrations se font en douceur :
|
||||
elles vont permettre de basculer progressivement les *pod*s d'une version X à une
|
||||
version Y (par exemple si l'on change notre ping d'alpine 3.14 vers alpine
|
||||
version Y (par exemple si l'on change notre ping d'alpine 3.16 vers alpine
|
||||
edge), mais éventuellement de revenir sur la version X si besoin, en cours de
|
||||
migration. Elles délèguent ensuite aux *replicatsets* la gestion des *pod*s.
|
||||
|
||||
|
|
@ -225,7 +241,7 @@ la demande.
|
|||
Et que se passe-t-il alors, si l'on tue un *pod* ?
|
||||
|
||||
```bash
|
||||
kubectl delete pod pingpong-yyyy
|
||||
kubectl delete pod pingpong-yyyy-zzz
|
||||
```
|
||||
|
||||
Cela supprime bien un *pod*, mais un autre est relancé instantanément car le
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ on n'utilisera pas cette recette.
|
|||
Regardons où nous pouvons contacter notre dashboard :
|
||||
|
||||
```bash
|
||||
$ kubectl get svc
|
||||
$ kubectl -n kubernetes-dashboard get svc
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
dashboard NodePort 10.96.78.69 <none> 80:31505/TCP 3m10s
|
||||
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 6m51s
|
||||
|
|
@ -33,11 +33,12 @@ mais dans différents conteneurs Docker, nous ne pouvons pas accéder à
|
|||
configuration. Il va donc falloir indiquer à Kubernetes que l'on désire
|
||||
utiliser un port spécifique pour exposer le tableau de bord.
|
||||
|
||||
Pour ce faire, éditons le fichier `insecure-dashboard.yaml`, pour ajouter, dans
|
||||
Pour ce faire, éditons le fichier `dashboard-insecure.yaml`, pour ajouter, dans
|
||||
la partie `Service` un *node port* plus spécifique :
|
||||
|
||||
```yaml
|
||||
- port: 80
|
||||
- name: shared
|
||||
port: 80
|
||||
protocol: TCP
|
||||
targetPort: 80
|
||||
nodePort: 30002
|
||||
|
|
@ -47,7 +48,7 @@ Maintenant, nous n'allons pas recréer un nouveau dashboard : nous allons
|
|||
simplement « appliquer » la nouvelle configuration :
|
||||
|
||||
```bash
|
||||
kubectl apply -f my-insecure-dashboard.yaml
|
||||
kubectl apply -f my-dashboard-insecure.yaml
|
||||
```
|
||||
|
||||
En voyant la divergence entre la réalité et la configuration demandée,
|
||||
|
|
|
|||
|
|
@ -1,5 +1,3 @@
|
|||
\newpage
|
||||
|
||||
Présentation du fil rouge
|
||||
-------------------------
|
||||
|
||||
|
|
|
|||
|
|
@ -48,7 +48,7 @@ docker-compose up
|
|||
</div>
|
||||
|
||||
Une fois le `docker-compose` lancé, nous devrions pouvoir accéder à l'interface
|
||||
de chronograf pour voir l'avancement de recherche de pépites :
|
||||
de `chronograf` pour voir l'avancement de recherche de pépites :
|
||||
|
||||
<http://localhost:8888/sources/1/dashboards/1>
|
||||
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
|
|
|||
|
|
@ -3,41 +3,21 @@
|
|||
Rendu
|
||||
=====
|
||||
|
||||
Modalités de rendu
|
||||
------------------
|
||||
|
||||
Un service automatique s'occupe de réceptionner vos rendus, de faire des
|
||||
vérifications élémentaires et de vous envoyer un accusé de réception (ou de
|
||||
rejet).
|
||||
|
||||
Ce service écoute sur l'adresse <ανδροππήςρε@nemunai.re>. C'est donc à cette adresse
|
||||
et exclusivement à celle-ci que vous devez envoyer vos rendus. Tout rendu
|
||||
envoyé à une autre adresse et/ou non signé et/ou reçu après la correction ne
|
||||
sera pas pris en compte.
|
||||
|
||||
Afin d'orienter correctement votre rendu, ajoutez une balise `[TP6]` au sujet
|
||||
de votre courriel. N'hésitez pas à indiquer dans le corps du courriel votre
|
||||
ressenti et vos difficultés ou bien alors écrivez votre meilleure histoire
|
||||
drôle si vous n'avez rien à dire.
|
||||
|
||||
Mais n'oubliez pas de répondre au [sondage](https://virli.nemunai.re/quiz/16)
|
||||
pour me permettre d'améliorer ce cours.
|
||||
|
||||
|
||||
Tarball
|
||||
Arborescence attendue
|
||||
-------
|
||||
|
||||
Tous les exercices de ce TP sont à placer dans une tarball (pas d'archive ZIP,
|
||||
RAR, ...).
|
||||
Tous les fichiers identifiés comme étant à rendre sont à placer dans un dépôt
|
||||
Git privé, que vous partagerez avec [votre
|
||||
professeur](https://gitlab.cri.epita.fr/nemunaire/).
|
||||
|
||||
Voici une arborescence type :
|
||||
Voici une arborescence type (vous pourriez avoir des fichiers supplémentaires) :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
login_x-TP6/my-cluster.yml
|
||||
login_x-TP6/my-dashboard.yaml
|
||||
login_x-TP6/influxdb.yml # values.yml avec Helm ou le fichier passé à kubectl -f
|
||||
login_x-TP6/chronograph.yml
|
||||
login_x-TP6/daemonset-rng.yml
|
||||
./my-kind-cluster.yml
|
||||
./my-dashboard.yaml
|
||||
./influxdb.yml # values.yml avec Helm ou le fichier passé à kubectl -f
|
||||
./chronograph.yml
|
||||
./daemonset-rng.yml
|
||||
```
|
||||
</div>
|
||||
|
|
|
|||
|
|
@ -1,21 +1,23 @@
|
|||
Mise en place
|
||||
-------------
|
||||
|
||||
La mise en place d'un cluster Kuernetes est une opération qui peut s'avérer
|
||||
très longue et complexe, car elle nécessite l'installation et la configuration
|
||||
de nombreux composants avant de pouvoir être utilisé pleinement.
|
||||
La mise en place d'un cluster Kubernetes est une opération qui peut s'avérer
|
||||
très longue et complexe, car comme nous l'avons vu, elle nécessite
|
||||
l'installation et la configuration de nombreux composants avant de pouvoir être
|
||||
utilisé pleinement.
|
||||
|
||||
Cette opération n'étant pas très palpitante (c'est beaucoup de lecture de
|
||||
Cette installation n'étant pas très palpitante (c'est beaucoup de lecture de
|
||||
documentations et d'heures passées à essayer de faire tomber en marche tous les
|
||||
composants d'un seul coup), nous ne la verrons pas ici.
|
||||
|
||||
D'ailleurs, dans le milieu professionnel, il est plutôt rare de voir des
|
||||
D'ailleurs, dans les milieux professionnels, il est plutôt rare de voir des
|
||||
entreprises investir dans la gestion de leur propre cluster Kubernetes. La
|
||||
plupart des entreprises qui font le choix d'utiliser Kubernetes pour gérer leurs
|
||||
infrastructures, choisissent de passer par un prestataire. L'entreprise délègue
|
||||
donc la gestion de son/ses cluster(s) à une autre entreprise, dont c'est le cœur de
|
||||
métier. La plupart du temps, il va s'agir d'Amazon (via [Elastic Kubernetes
|
||||
Service](https://aws.amazon.com/fr/eks/)), d'Azure [Kubernetes
|
||||
plupart des entreprises qui font le choix d'utiliser Kubernetes pour gérer
|
||||
leurs infrastructures, choisissent de passer par un prestataire. L'entreprise
|
||||
délègue donc la gestion de son/ses cluster(s) à une autre entreprise, dont
|
||||
c'est le cœur de métier. La plupart du temps, il va s'agir d'Amazon (via
|
||||
[Elastic Kubernetes Service](https://aws.amazon.com/fr/eks/)), d'Azure
|
||||
[Kubernetes
|
||||
Service](https://azure.microsoft.com/fr-fr/services/kubernetes-service/)) ou
|
||||
Google ([Kubernetes Engine](https://cloud.google.com/kubernetes-engine/)), mais
|
||||
d'autres acteurs plus petits existent aussi
|
||||
|
|
@ -23,14 +25,39 @@ d'autres acteurs plus petits existent aussi
|
|||
|
||||
::::: {.more}
|
||||
|
||||
Lorsque l'on veut créer son cluster, on a le choix d'assembler tous les
|
||||
composants de *Kubernetes* soi-même (*vanilla*), ou alors de partir d'une
|
||||
distribution existante. On parle de *distribution* dans le même sens que l'on
|
||||
connaît les distributions GNU/Linux : chacun peut aller récupérer les sources
|
||||
du noyau Linux et des différents programmes nécessaires au démarrage et à
|
||||
l'exécution d'un système d'exploitation fonctionnel, ou alors on peut utiliser
|
||||
une distribution qui met à notre disposition un noyau Linux et tout un
|
||||
écosystème de programmes qui forment un système d'exploitation cohérent et qui
|
||||
fonctionne.\
|
||||
|
||||
Chaque distribution de *Kubernetes* aura donc pris soin de mettre à disposition
|
||||
des composants pour un usage plus ou moins spécifique. En dehors des composants
|
||||
strictement nécessaires qui ne changent pas, on verra d'une distribution à
|
||||
l'autre des choix quant au moteur d'exécution de conteneurs (tantot CRI-O,
|
||||
Containerd, KataContainers, ...), le réseau sera géré par une brique spécifique
|
||||
(Flannel, Calico, Canal, Wave, ...), le stockage peut également faire l'objet
|
||||
de choix.\
|
||||
|
||||
Devant la complexité de conception et le nombre grandissant de distributions,
|
||||
une certification est délivrée aux distributions sérieuses. On en dénombre tout
|
||||
de même plus d'une cinquantaine[^k8s-distributions-certified].\
|
||||
|
||||
[^k8s-distributions-certified]: Voir la liste sur
|
||||
<https://www.cncf.io/certification/software-conformance/>.
|
||||
|
||||
Pour l'IoT ou l'Edge Computing, sur du matériel léger, il existe le projet
|
||||
k3s[^k3s] : il s'agit d'une distribution Kubernetes beaucoup plus simple à
|
||||
déployer, et parfaitement adaptée à la production sur Raspberry Pi et autres.
|
||||
|
||||
:::::
|
||||
|
||||
[^k3s]: Lightweight Kubernetes : <https://k3s.io/>
|
||||
|
||||
:::::
|
||||
|
||||
Pour jouer, plusieurs solutions s'offrent à nous pour commencer à
|
||||
utiliser Kubernetes facilement :
|
||||
|
||||
|
|
@ -56,8 +83,8 @@ Une fois que tout sera opérationnel, nous devrions obtenir :
|
|||
<div lang="en-US">
|
||||
```
|
||||
42sh$ kubectl version
|
||||
Client Version: version.Info{Major:"1", minor:"22", GitVersion:"v1.22.2", [...]
|
||||
Server Version: version.Info{Major:"1", minor:"21", GitVersion:"v1.21.5", [...]
|
||||
Client Version: version.Info{Major:"1", minor:"25", GitVersion:"v1.25.3", [...]
|
||||
Server Version: version.Info{Major:"1", minor:"21", GitVersion:"v1.25.3", [...]
|
||||
```
|
||||
</div>
|
||||
|
||||
|
|
@ -77,9 +104,9 @@ votre `$PATH`.
|
|||
|
||||
|
||||
Notre prochaine étape est de décrire le cluster que l'on souhaite avoir : 1
|
||||
master et 2 workers, ça fera l'affaire. Attention tout de même de ne pas être
|
||||
trop extravagant, car chaque nœud consomme pas mal de RAM ! Et puis nous
|
||||
pourrons facilement changer cette configuration plus tard.
|
||||
*control-plane* et 2 *workers*, ça fera l'affaire. Attention tout de même à ne
|
||||
pas être trop extravagant, car chaque nœud consomme pas mal de RAM ! Et puis
|
||||
nous pourrons facilement changer cette configuration plus tard.
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
|
|
@ -105,7 +132,7 @@ kind create cluster --config my-cluster.yml
|
|||
La création du cluster peut prendre quelques minutes.
|
||||
|
||||
Profitons-en pour télécharger `kubectl` :\
|
||||
<https://storage.googleapis.com/kubernetes-release/release/v1.22.2/bin/linux/amd64/kubectl>
|
||||
<https://storage.googleapis.com/kubernetes-release/release/v1.25.3/bin/linux/amd64/kubectl>
|
||||
|
||||
C'est principalement grâce à cette commande que nous interagirons avec l'API de
|
||||
Kubernetes.
|
||||
|
|
@ -115,8 +142,8 @@ Une fois que tout sera opérationnel, nous devrions obtenir :
|
|||
<div lang="en-US">
|
||||
```
|
||||
42sh$ kubectl version
|
||||
Client Version: Version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.2", [...]
|
||||
Server Version: Version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.5", [...]
|
||||
Client Version: Version.Info{Major:"1", Minor:"22", GitVersion:"v1.25.3", [...]
|
||||
Server Version: Version.Info{Major:"1", Minor:"21", GitVersion:"v1.25.3", [...]
|
||||
```
|
||||
</div>
|
||||
|
||||
|
|
@ -136,16 +163,16 @@ cluster Kubernetes selon les autres méthodes décrites.
|
|||
|
||||
De la même manière que pour les exercices utilisant Docker, si vous avez des
|
||||
difficultés pour réaliser les exercices sur vos machines, vous pouvez utiliser
|
||||
le projet [Play With K8s](https://play-with-k8s.com/) qui vous donnera accès à
|
||||
un bac à sable avec lequel vous pourrez réaliser tous les exercices.
|
||||
le projet [Play With K8s](https://labs.play-with-k8s.com/) qui vous donnera
|
||||
accès à un bac à sable avec lequel vous pourrez réaliser tous les exercices.
|
||||
|
||||
Il nous faut créer plusieurs instances, disons 3 : parmi elles, 1 instance sera
|
||||
la master, nous l'utiliserons principalement, les deux autres ne feront
|
||||
qu'exécuter des conteneurs, nous pourrons les oublier dès qu'on les aura
|
||||
connectées au master.
|
||||
pour notre *control-plane*, que nous utiliserons principalement, les deux
|
||||
autres ne feront qu'exécuter des conteneurs, nous pourrons les oublier dès
|
||||
qu'on les aura connectées à notre nœud principal.
|
||||
|
||||
Pour initialiser notre cluster Kubernetes, nous allons devoir créer notre
|
||||
master. Pour cela, dans notre première instance, nous allons taper :
|
||||
Pour initialiser notre cluster Kubernetes, nous allons commencer par créer
|
||||
le contrôleur. Pour cela, dans notre première instance, nous allons taper :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
|
|
@ -182,14 +209,13 @@ nos deux autres instances. Cela permettra aux machines de se connecter au
|
|||
master.
|
||||
|
||||
Dernière étape pour la mise en place de notre cluster, il s'agit de définir un
|
||||
profil de politique réseau, sur le master (nous n'exécuterons plus de commande
|
||||
sur les autres workers) :
|
||||
plugin de modèle réseau, sur le nœud principal (nous n'exécuterons plus de
|
||||
commande sur les autres *workers*) :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
kubectl apply -n kube-system -f \
|
||||
"https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | \
|
||||
base64 | tr -d '\n')"
|
||||
kubectl apply -f \
|
||||
https://raw.githubusercontent.com/cloudnativelabs/kube-router/master/daemonset/kubeadm-kuberouter.yaml
|
||||
```
|
||||
</div>
|
||||
|
||||
|
|
|
|||
|
|
@ -3,13 +3,11 @@ title: Ελαφριά εικονικοποίηση -- Πρακτική δουλ
|
|||
subtitle: κυβερνήτης
|
||||
author: Πιέρ-Ολιβιέ *νεμυναιρε* [ῥαφοπώλης]{.smallcaps}
|
||||
institute: ΣΠκΠΤ
|
||||
date: Παρασκευή 19 Νοεμβρίου 2021
|
||||
date: Τετάρτη 30 Νοεμβρίου 2022
|
||||
abstract: |
|
||||
Ο στόχος αυτού του τελευταίου εργαστηρίου είναι να κατανοήσει το κυβερνήτης και την ενορχήστρωση εμπορευματοκιβωτίων.
|
||||
|
||||
\vspace{1em}
|
||||
|
||||
Οι ασκήσεις για αυτό το πρακτικό έργο μπορούν να επιστραφούν στη διεύθυνση <ανδροππήςρε@nemunai.re> το αργότερο την Παρασκευή 3 Δεκεμβρίουz 2021 στις 11:42 μ.μ., οι ερωτήσεις των μαθημάτων πρέπει επίσης να ολοκληρωθούν πριν από αυτήν την ημερομηνία. Δείτε το τελευταίο μέρος αυτού του εργαστηρίου για λεπτομέρειες.
|
||||
|
||||
Καθώς οι άνθρωποι γνωρίζουν την ασφάλεια των ηλεκτρονικών ανταλλαγών, πρέπει να μου στείλετε τις υπογεγραμμένες αποδόσεις σας με το κλειδί PGP. Θυμηθείτε να [με](https://keys.openpgp.org/search?q=nemunaire%40nemunai.re) υπογράψετε το κλειδί σας και μην διστάσετε [να υπογράψετε το δικό σας](https://www.meetup.com/fr/Paris-certification-de-cles-PGP-et-CAcert/).
|
||||
Οι ασκήσεις για αυτό το μάθημα πρέπει να υποβληθούν μέχρι την Τετάρτη 7 Δεκεμβρίου 2022 στις 23:42 μ.μ., εκτός αν γράψετε στο <ανδροππήςρε@nemunai.re>. Ανατρέξτε στα τμήματα που επισημαίνονται με κίτρινη ταινία και γρανάζι για περισσότερες πληροφορίες σχετικά με τα οφειλόμενα.
|
||||
...
|
||||
|
|
|
|||
|
|
@ -10,14 +10,8 @@ abstract: |
|
|||
|
||||
\vspace{1em}
|
||||
|
||||
Les exercices de ce TP peuvent être rendus à <virli@nemunai.re> au plus tard
|
||||
le jeudi 26 novembre 2020 à 23 h 42, des questions de cours sont également à
|
||||
compléter avant cette date. Consultez la dernière partie de ce TP pour les
|
||||
modalités.
|
||||
|
||||
En tant que personnes sensibilisées à la sécurité des échanges électroniques,
|
||||
vous devrez m'envoyer vos rendus signés avec votre clef PGP. Pensez à
|
||||
[me](https://keys.openpgp.org/search?q=nemunaire%40nemunai.re) faire signer
|
||||
votre clef et n'hésitez pas à [faire signer la
|
||||
vôtre](https://www.meetup.com/fr/Paris-certification-de-cles-PGP-et-CAcert/).
|
||||
Les exercices de ce cours sont à rendre au plus tard le mercredi 7
|
||||
décembre 2022 à 23 h 42. Consultez les sections matérialisées par un
|
||||
bandeau jaunes et un engrenage pour plus d'informations sur les
|
||||
éléments à rendre.
|
||||
...
|
||||
|
|
|
|||
Loading…
Reference in New Issue