2021 tuto
This commit is contained in:
parent
ba77aca73b
commit
c4bb727cd4
@ -1 +1 @@
|
|||||||
../../tutorial/4/project-rendu.md
|
../../tutorial/5/project-rendu.md
|
||||||
@ -7,8 +7,9 @@ Exemples
|
|||||||
```
|
```
|
||||||
42sh$ ./mymoulette -h
|
42sh$ ./mymoulette -h
|
||||||
MyMoulette, the students' nightmare, now highly secured
|
MyMoulette, the students' nightmare, now highly secured
|
||||||
Usage: ./mymoulette [-v student_workdir] environment moulette_prog [moulette_arg [...]]
|
Usage: ./mymoulette [-v student_workdir] <-I docker-img|rootfs-path> moulette_prog [moulette_arg [...]]
|
||||||
environment is the path to the directory containing the new rootfs
|
rootfs-path is the path to the directory containing the new rootfs (exclusive with -I option)
|
||||||
|
docker-img is an image available on hub.docker.com (exclusive with rootfs-path)
|
||||||
moulette_prog will be the first program to be launched, must already be in the environment
|
moulette_prog will be the first program to be launched, must already be in the environment
|
||||||
student_workdir is the directory containing the code to grade
|
student_workdir is the directory containing the code to grade
|
||||||
```
|
```
|
||||||
@ -44,7 +45,7 @@ rtt min/avg/max/mdev = 3.789/3.847/3.906/0.085 ms
|
|||||||
<div lang="en-US">
|
<div lang="en-US">
|
||||||
```
|
```
|
||||||
42sh$ ./mymoulette ./newrootfs/ /usr/bin/curl http://www.linuxcontainers.org/ | md5sum
|
42sh$ ./mymoulette ./newrootfs/ /usr/bin/curl http://www.linuxcontainers.org/ | md5sum
|
||||||
c7d68d1cb4737125a84cd69f55add202
|
79c12c02c8a08b4ec3fe219f97df8e78
|
||||||
```
|
```
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
|
|||||||
@ -2,7 +2,7 @@
|
|||||||
title: Virtualisation légère -- Projet
|
title: Virtualisation légère -- Projet
|
||||||
author: Pierre-Olivier *nemunaire* Mercier
|
author: Pierre-Olivier *nemunaire* Mercier
|
||||||
institute: EPITA
|
institute: EPITA
|
||||||
date: EPITA -- SRS 2020
|
date: EPITA -- SRS 2021
|
||||||
abstract: |
|
abstract: |
|
||||||
Le laboratoire des assistants a besoin de votre expertise afin de
|
Le laboratoire des assistants a besoin de votre expertise afin de
|
||||||
renforcer la sécurité et la réactivité de son système de correction
|
renforcer la sécurité et la réactivité de son système de correction
|
||||||
@ -29,7 +29,7 @@ abstract: |
|
|||||||
\vspace{1em}
|
\vspace{1em}
|
||||||
|
|
||||||
Ce projet est à rendre à <virli@nemunai.re> au plus tard le dimanche
|
Ce projet est à rendre à <virli@nemunai.re> au plus tard le dimanche
|
||||||
1er décembre 2019 à 23 h 42.
|
6 décembre 2020 à 23 h 42.
|
||||||
...
|
...
|
||||||
|
|
||||||
\newpage
|
\newpage
|
||||||
|
|||||||
@ -195,7 +195,7 @@ Et de ces quelques articles :
|
|||||||
* [Guidelines for extended attributes](https://www.freedesktop.org/wiki/CommonExtendedAttributes/)
|
* [Guidelines for extended attributes](https://www.freedesktop.org/wiki/CommonExtendedAttributes/)
|
||||||
* [File-based capabilities](https://lwn.net/Articles/211883/)
|
* [File-based capabilities](https://lwn.net/Articles/211883/)
|
||||||
* [A bid to resurrect Linux capabilities](https://lwn.net/Articles/199004/)
|
* [A bid to resurrect Linux capabilities](https://lwn.net/Articles/199004/)
|
||||||
* [False Boundaries and Arbitrary Code Execution](https://forums.grsecurity.net/viewtopic.php?f=7&t=2522&sid=c6fbcf62fd5d3472562540a7e608ce4e#p10271)
|
* [False Boundaries and Arbitrary Code Execution](https://forums.grsecurity.net/viewtopic.php?f=7&t=2522#p10271)
|
||||||
|
|
||||||
Pour revenir à Docker, par défaut, un certain nombre de *capabilities* sont
|
Pour revenir à Docker, par défaut, un certain nombre de *capabilities* sont
|
||||||
désactivées par défaut ; vous pouvez en ajouter et en retirer via les arguments
|
désactivées par défaut ; vous pouvez en ajouter et en retirer via les arguments
|
||||||
|
|||||||
@ -149,7 +149,7 @@ interagir avec InfluxDB :
|
|||||||
|
|
||||||
<div lang="en-US">
|
<div lang="en-US">
|
||||||
```bash
|
```bash
|
||||||
docker container exec -i mytsdb influxdb <<EOF
|
docker container exec -i mytsdb influx <<EOF
|
||||||
CREATE DATABASE metrics;
|
CREATE DATABASE metrics;
|
||||||
SHOW DATABASES;
|
SHOW DATABASES;
|
||||||
EOF
|
EOF
|
||||||
|
|||||||
@ -72,7 +72,7 @@ de base sous forme de tarball\ :
|
|||||||
|
|
||||||
<div lang="en-US">
|
<div lang="en-US">
|
||||||
```bash
|
```bash
|
||||||
wget http://gentoo.mirrors.ovh.net/gentoo-distfiles/releases/amd64/autobuilds/current-stage3-amd64/stage3-amd64-20191020T214501Z.tar.xz
|
wget http://gentoo.mirrors.ovh.net/gentoo-distfiles/releases/amd64/autobuilds/current-stage3-amd64/stage3-amd64-20201104T214503Z.tar.xz
|
||||||
tar xpf stage3-amd64-*.tar.xz -C newroot/
|
tar xpf stage3-amd64-*.tar.xz -C newroot/
|
||||||
```
|
```
|
||||||
</div>
|
</div>
|
||||||
|
|||||||
@ -98,5 +98,5 @@ requises seront a priori déjà sélectionnées et vous n'aurez donc pas à comp
|
|||||||
votre propre noyau. Néanmoins, durant ce TP, nous allons nous interfacer avec
|
votre propre noyau. Néanmoins, durant ce TP, nous allons nous interfacer avec
|
||||||
le noyau, il est donc nécessaire d'avoir les en-têtes de votre noyau.
|
le noyau, il est donc nécessaire d'avoir les en-têtes de votre noyau.
|
||||||
|
|
||||||
Sous Debian, vous pouvez les installer via le paquet au nom semblable
|
Sous Debian, vous pouvez les installer via le paquet au nom semblable à
|
||||||
à `linux-headers`.
|
`linux-headers`. Le paquet porte le même nom sous Arch Linux et ses dérivés.
|
||||||
|
|||||||
@ -10,7 +10,7 @@ envoyé à une autre adresse et/ou non signé et/ou reçu après la correction n
|
|||||||
sera pas pris en compte.
|
sera pas pris en compte.
|
||||||
|
|
||||||
Par ailleurs, n'oubliez pas de répondre à
|
Par ailleurs, n'oubliez pas de répondre à
|
||||||
[l'évaluation du cours](https://www.epitaf.fr/moodle/mod/quiz/view.php?id=308).
|
[l'évaluation du cours](https://virli.nemunai.re/quiz/6).
|
||||||
|
|
||||||
|
|
||||||
## Tarball
|
## Tarball
|
||||||
|
|||||||
@ -1,9 +1,9 @@
|
|||||||
---
|
---
|
||||||
title: Virtualisation légère -- TP n^o^ 3
|
title: Virtualisation légère -- TP n^o^ 4
|
||||||
subtitle: Linux Internals partie 1
|
subtitle: Linux Internals partie 1
|
||||||
author: Pierre-Olivier *nemunaire* [Mercier]{.smallcaps}
|
author: Pierre-Olivier *nemunaire* [Mercier]{.smallcaps}
|
||||||
institute: EPITA
|
institute: EPITA
|
||||||
date: Mercredi 23 octobre 2019
|
date: Jeudi 4 novembre 2020
|
||||||
abstract: |
|
abstract: |
|
||||||
Ce premier TP consacré aux Linux Internals va nous permettre
|
Ce premier TP consacré aux Linux Internals va nous permettre
|
||||||
d'appréhender les notions de pseudos systèmes de fichiers, de
|
d'appréhender les notions de pseudos systèmes de fichiers, de
|
||||||
@ -12,14 +12,13 @@ abstract: |
|
|||||||
\vspace{1em}
|
\vspace{1em}
|
||||||
|
|
||||||
Certains éléments de ce TP sont à rendre à <virli@nemunai.re> au
|
Certains éléments de ce TP sont à rendre à <virli@nemunai.re> au
|
||||||
plus tard le mercredi 6 novembre 2019 à 13 h 42. Consultez la
|
plus tard le jeudi 12 novembre 2020 à 12 h 42. Consultez la
|
||||||
dernière section de chaque partie pour plus d'information sur les
|
dernière section de chaque partie pour plus d'information sur les
|
||||||
éléments à rendre.
|
éléments à rendre.
|
||||||
|
|
||||||
En tant que personnes sensibilisées à la sécurité des échanges
|
En tant que personnes sensibilisées à la sécurité des échanges électroniques,
|
||||||
électroniques, vous devrez m'envoyer vos rendus signés avec votre
|
vous devrez m'envoyer vos rendus signés avec votre clef PGP. Pensez à
|
||||||
clef PGP. Pensez à
|
[me](https://keys.openpgp.org/search?q=nemunaire%40nemunai.re) faire signer
|
||||||
[me](https://keys.openpgp.org/search?q=nemunaire%40nemunai.re)
|
votre clef et n'hésitez pas à [faire signer la
|
||||||
faire signer votre clef et n'hésitez pas à [faire signer la
|
|
||||||
votre](https://www.meetup.com/fr/Paris-certification-de-cles-PGP-et-CAcert/).
|
votre](https://www.meetup.com/fr/Paris-certification-de-cles-PGP-et-CAcert/).
|
||||||
...
|
...
|
||||||
|
|||||||
@ -38,13 +38,15 @@ programmes s'exécutent dans les mêmes *namespaces*.
|
|||||||
```
|
```
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
Ici, `self` fait référence au processus actuellement exécuté.
|
Ici, `self` fait référence au processus actuellement exécuté (comme il existe
|
||||||
|
un dossier `/proc/self/`, vous n'avez pas besoin de gérer de cas particulier
|
||||||
|
pour ça !).
|
||||||
|
|
||||||
Et pourquoi pas :
|
Et pourquoi pas :
|
||||||
|
|
||||||
<div lang="en-US">
|
<div lang="en-US">
|
||||||
```
|
```
|
||||||
42sh$ unshare -m ./cmpns $$ self
|
42sh# unshare -m ./cmpns $$ self
|
||||||
- cgroup: same
|
- cgroup: same
|
||||||
- ipc: same
|
- ipc: same
|
||||||
- mnt: differ
|
- mnt: differ
|
||||||
|
|||||||
@ -10,8 +10,8 @@ Petite parenthèse avant de parler des *namespaces* ...
|
|||||||
Au premier abord, les points de montage dans l'arborescence d'un système de
|
Au premier abord, les points de montage dans l'arborescence d'un système de
|
||||||
fichiers n'ont pas l'air d'être remplis de notions complexes : un répertoire
|
fichiers n'ont pas l'air d'être remplis de notions complexes : un répertoire
|
||||||
peut être le point d'entrée d'un montage vers la partition d'un disque
|
peut être le point d'entrée d'un montage vers la partition d'un disque
|
||||||
physique... ou d'une partition virtuelle, comme nous l'avons vu dans la partie
|
physique... ou d'une partition virtuelle, comme nous l'avons vu dans le TP
|
||||||
précédente.
|
précédent.
|
||||||
|
|
||||||
Mais avez-vous déjà essayé de monter la même partition d'un disque physique à
|
Mais avez-vous déjà essayé de monter la même partition d'un disque physique à
|
||||||
deux endroits différents de votre arborescence ?
|
deux endroits différents de votre arborescence ?
|
||||||
@ -214,7 +214,7 @@ mount --make-private mountpoint
|
|||||||
|
|
||||||
### non-attachable -- *unbindable mount*
|
### non-attachable -- *unbindable mount*
|
||||||
|
|
||||||
Ce mode interdira tout tentative d'attache à un autre endroit.
|
Ce mode interdira toute tentative d'attache à un autre endroit.
|
||||||
|
|
||||||
<div lang="en-US">
|
<div lang="en-US">
|
||||||
```bash
|
```bash
|
||||||
@ -254,8 +254,9 @@ Il n'est pas nécessaire que le point d'accroche que l'on cherche à dupliquer
|
|||||||
pointe sur un point de montage (c'est-à-dire, dans la plupart des cas : une
|
pointe sur un point de montage (c'est-à-dire, dans la plupart des cas : une
|
||||||
partition ou un système de fichiers virtuel). Il peut parfaitement pointer sur
|
partition ou un système de fichiers virtuel). Il peut parfaitement pointer sur
|
||||||
un dossier, et même sur un simple fichier, à la manière d'un *hardlink*, mais
|
un dossier, et même sur un simple fichier, à la manière d'un *hardlink*, mais
|
||||||
que l'on pourrait faire entre plusieurs partitions et qui ne persisterait pas au
|
que l'on pourrait faire entre plusieurs partitions et qui ne persisterait pas
|
||||||
redémarrage.
|
au redémarrage (le *hardlink* persiste au redémarrage, mais doit se faire au
|
||||||
|
sein d'une même partition).
|
||||||
|
|
||||||
Nous verrons dans la partie [*namespace* réseau](#net-ns), une utilisation
|
Nous verrons dans la partie [*namespace* réseau](#net-ns), une utilisation
|
||||||
d'attache sur un fichier.
|
d'attache sur un fichier.
|
||||||
@ -269,7 +270,7 @@ faire même si un fichier est en cours d'utilisation. Il faut cependant veiller
|
|||||||
à ce que les programmes susceptibles d'aller chercher un fichier à l'ancien
|
à ce que les programmes susceptibles d'aller chercher un fichier à l'ancien
|
||||||
emplacement soient prévenus du changement.
|
emplacement soient prévenus du changement.
|
||||||
|
|
||||||
On utilise pour cela l'option `--move` de `mount(8)` :
|
Pour déplacer un point de montage, on utilise l'option `--move` de `mount(8)` :
|
||||||
|
|
||||||
<div lang="en-US">
|
<div lang="en-US">
|
||||||
```bash
|
```bash
|
||||||
@ -285,9 +286,9 @@ mount --move /dev /newroot/dev
|
|||||||
```
|
```
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
Il est courant de faire appel à cette option lorsque l'on souhaite changer la
|
Cette possibilité s'emploie notamment lorsque l'on souhaite changer la racine
|
||||||
racine de notre système de fichiers : par exemple pour passer de l'*initramfs*
|
de notre système de fichiers : par exemple pour passer de l'*initramfs* au
|
||||||
au système démarré, de notre système hôte au système d'un conteneur, ...
|
système démarré, de notre système hôte au système d'un conteneur, ...
|
||||||
|
|
||||||
|
|
||||||
## Aller plus loin {-}
|
## Aller plus loin {-}
|
||||||
|
|||||||
@ -10,8 +10,8 @@ dupliquer certaines structures, habituellement considérées uniques
|
|||||||
pour le noyau, dans le but de les isoler d'un groupe de processus à un
|
pour le noyau, dans le but de les isoler d'un groupe de processus à un
|
||||||
autre.
|
autre.
|
||||||
|
|
||||||
On en dénombre sept depuis Linux 4.6 : `cgroup`, `IPC`, `network`,
|
On en dénombre sept (le dernier ayant été ajouté dans Linux 4.6) : `cgroup`,
|
||||||
`mount`, `PID`, `user` et `UTS`.
|
`IPC`, `network`, `mount`, `PID`, `user` et `UTS`.
|
||||||
|
|
||||||
La notion d'espace de noms est relativement nouvelle et a été intégrée
|
La notion d'espace de noms est relativement nouvelle et a été intégrée
|
||||||
progressivement au sein du noyau Linux. Aussi, toutes les structures
|
progressivement au sein du noyau Linux. Aussi, toutes les structures
|
||||||
@ -27,12 +27,12 @@ Depuis Linux 2.4.19.
|
|||||||
|
|
||||||
Cet espace de noms isole la liste des points de montage.
|
Cet espace de noms isole la liste des points de montage.
|
||||||
|
|
||||||
Chaque processus appartenant à un *namespace* différent peut monter, démonter
|
Chaque processus appartenant à un *namespace mount* différent peut monter,
|
||||||
et réorganiser à sa guise les points de montage, sans que cela n'ait d'impact
|
démonter et réorganiser à sa guise les points de montage, sans que cela n'ait
|
||||||
sur les processus hors de cet espace de noms. Une partition ne sera donc pas
|
d'impact sur les processus hors de cet espace de noms. Une partition ne sera
|
||||||
nécessairement démontée après un appel à `umount(2)`, elle le sera lorsqu'elle
|
donc pas nécessairement démontée après un appel à `umount(2)`, elle le sera
|
||||||
aura effectivement été démontée de chaque *namespace* dans lequel elle était
|
lorsqu'elle aura effectivement été démontée de chaque *namespace mount* dans
|
||||||
montée.
|
lequel elle était montée.
|
||||||
|
|
||||||
Attention il convient cependant de prendre garde aux types de liaison existant
|
Attention il convient cependant de prendre garde aux types de liaison existant
|
||||||
entre vos points de montage (voir la partie sur
|
entre vos points de montage (voir la partie sur
|
||||||
@ -198,20 +198,23 @@ similaire à :
|
|||||||
```c
|
```c
|
||||||
#include <sched.h>
|
#include <sched.h>
|
||||||
|
|
||||||
#define STACKSIZE (1024*1024)
|
#define STACKSIZE (1024 * 1024)
|
||||||
static char child_stack[STACKSIZE];
|
static char child_stack[STACKSIZE];
|
||||||
|
|
||||||
int clone_flags = CLONE_CGROUP | CLONE_NEWNET | SIGCHLD;
|
int clone_flags = CLONE_CGROUP | CLONE_NEWNET | SIGCHLD;
|
||||||
|
|
||||||
pid_t pid = clone(do_execvp,
|
pid_t pid = clone(do_execvp, // First function executed by child
|
||||||
child_stack + STACKSIZE,
|
child_stack + STACKSIZE, // Assume stack grows downward
|
||||||
clone_flags,
|
clone_flags, // clone specials flags
|
||||||
&args);
|
args); // Arguments to pass to do_execvp
|
||||||
```
|
```
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
Le premier argument est un pointeur sur fonction. Il s'agit de la fonction qui
|
Dans cet exemple, le processus fils créé disposera d'un nouvel espace de noms
|
||||||
sera appelée par le nouveau processus.
|
pour les *CGroups* et disposera d'une nouvelle pile réseau.
|
||||||
|
|
||||||
|
Un exemple complet d'utilisation de `clone(2)` et du *namespace* `UTS` est
|
||||||
|
donné dans le `man` de l'appel système.
|
||||||
|
|
||||||
|
|
||||||
## Rejoindre un *namespace*
|
## Rejoindre un *namespace*
|
||||||
@ -310,6 +313,6 @@ les *namespaces*](https://lwn.net/Articles/531114/) est excellente ! Auquel il
|
|||||||
faut ajouter [le petit dernier sur le `cgroup`
|
faut ajouter [le petit dernier sur le `cgroup`
|
||||||
*namespace*](https://lwn.net/Articles/621006/).
|
*namespace*](https://lwn.net/Articles/621006/).
|
||||||
|
|
||||||
[Cet article de Michael Crosby montrant l'utilisation de clone(2)](http://crosbymichael.com/creating-containers-part-1.html)
|
[Cet article de Michael Crosby montrant l'utilisation de clone(2)](https://web.archive.org/web/20190206073558/http://crosbymichael.com/creating-containers-part-1.html)
|
||||||
est également des plus intéressants, pour ce qui concerne la programmation
|
est également des plus intéressants, pour ce qui concerne la programmation
|
||||||
plus bas-niveau.
|
plus bas-niveau.
|
||||||
|
|||||||
@ -235,3 +235,7 @@ Pour construire une nouvelle interface de ce type :
|
|||||||
Pour approfondir les différentes techniques de routage, je vous
|
Pour approfondir les différentes techniques de routage, je vous
|
||||||
recommande cet article :
|
recommande cet article :
|
||||||
[Linux Containers and Networking](https://blog.flameeyes.eu/2010/09/linux-containers-and-networking).
|
[Linux Containers and Networking](https://blog.flameeyes.eu/2010/09/linux-containers-and-networking).
|
||||||
|
|
||||||
|
Appliqué à Docker, vous apprécirez cet article : [Understanding Docker
|
||||||
|
Networking Drivers and their use
|
||||||
|
cases](https://www.docker.com/blog/understanding-docker-networking-drivers-use-cases/).
|
||||||
|
|||||||
@ -41,8 +41,8 @@ contenu de `/proc`. D'ailleurs, si l'on affiche le PID du processus courant
|
|||||||
|
|
||||||
En l'état, beaucoup d'informations sont divulguées. Mais il n'est pas possible
|
En l'état, beaucoup d'informations sont divulguées. Mais il n'est pas possible
|
||||||
de monter le bon `/proc` car il serait également monté pour les processus de
|
de monter le bon `/proc` car il serait également monté pour les processus de
|
||||||
notre système initial. Pour s'en sortir, il est nécessaire de s'isoler du
|
notre système initial. Pour s'en sortir, il est nécessaire de s'isoler dans un
|
||||||
*namespace* `mount`.
|
*namespace* `mount` séparé.
|
||||||
|
|
||||||
|
|
||||||
### Double isolation : ajout du *namespace* `mount`
|
### Double isolation : ajout du *namespace* `mount`
|
||||||
|
|||||||
@ -15,6 +15,9 @@ sera pas pris en compte.
|
|||||||
|
|
||||||
Pour différencier le rendu du TP, du rendu du projet, ajoutez une balise
|
Pour différencier le rendu du TP, du rendu du projet, ajoutez une balise
|
||||||
`[PROJET]` au sujet de votre courriel, afin qu'il soit traité comme tel.
|
`[PROJET]` au sujet de votre courriel, afin qu'il soit traité comme tel.
|
||||||
|
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.
|
||||||
|
|
||||||
Tarball
|
Tarball
|
||||||
-------
|
-------
|
||||||
|
|||||||
@ -23,8 +23,13 @@ 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
|
envoyé à une autre adresse et/ou non signé et/ou reçu après la correction ne
|
||||||
sera pas pris en compte.
|
sera pas pris en compte.
|
||||||
|
|
||||||
|
Afin d'orienter correctement votre rendu, ajoutez une balise `[TP5]` 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.
|
||||||
|
|
||||||
Par ailleurs, n'oubliez pas de répondre à
|
Par ailleurs, n'oubliez pas de répondre à
|
||||||
[l'évaluation du cours](https://www.epitaf.fr/moodle/mod/quiz/view.php?id=309).
|
[l'évaluation du cours](https://virli.nemunai.re/quiz/7).
|
||||||
|
|
||||||
|
|
||||||
Tarball
|
Tarball
|
||||||
@ -37,8 +42,8 @@ Voici une arborescence type :
|
|||||||
|
|
||||||
<div lang="en-US">
|
<div lang="en-US">
|
||||||
```
|
```
|
||||||
login_x-TP4/cmpns.sh
|
login_x-TP5/cmpns.sh
|
||||||
login_x-TP4/mydocker_exec.sh
|
login_x-TP5/mydocker_exec.sh
|
||||||
login_x-TP4/myswitch_root.sh
|
login_x-TP5/myswitch_root.sh
|
||||||
```
|
```
|
||||||
</div>
|
</div>
|
||||||
|
|||||||
@ -1,9 +1,9 @@
|
|||||||
---
|
---
|
||||||
title: Virtualisation légère -- TP n^o^ 4
|
title: Virtualisation légère -- TP n^o^ 5
|
||||||
subtitle: Linux Internals partie 2
|
subtitle: Linux Internals partie 2
|
||||||
author: Pierre-Olivier *nemunaire* [Mercier]{.smallcaps}
|
author: Pierre-Olivier *nemunaire* [Mercier]{.smallcaps}
|
||||||
institute: EPITA
|
institute: EPITA
|
||||||
date: Mercredi 6 novembre 2019
|
date: Jeudi 12 novembre 2020
|
||||||
abstract: |
|
abstract: |
|
||||||
Le but de ce second TP sur les mécanismes internes du noyau va nous
|
Le but de ce second TP sur les mécanismes internes du noyau va nous
|
||||||
permettre d'utiliser les commandes et les appels systèmes relatifs
|
permettre d'utiliser les commandes et les appels systèmes relatifs
|
||||||
@ -13,12 +13,11 @@ abstract: |
|
|||||||
\vspace{1em}
|
\vspace{1em}
|
||||||
|
|
||||||
Tous les exercices de ce TP sont à rendre à <virli@nemunai.re> au
|
Tous les exercices de ce TP sont à rendre à <virli@nemunai.re> au
|
||||||
plus tard le mercredi 20 novembre 2017 à 13 h 42.
|
plus tard le jeudi 19 novembre 2020 à 12 h 42.
|
||||||
|
|
||||||
En tant que personnes sensibilisées à la sécurité des échanges
|
En tant que personnes sensibilisées à la sécurité des échanges électroniques,
|
||||||
électroniques, vous devrez m'envoyer vos rendus signés avec votre
|
vous devrez m'envoyer vos rendus signés avec votre clef PGP. Pensez à
|
||||||
clef PGP. Pensez à
|
[me](https://keys.openpgp.org/search?q=nemunaire%40nemunai.re) faire signer
|
||||||
[me](https://keys.openpgp.org/search?q=nemunaire%40nemunai.re)
|
votre clef et n'hésitez pas à [faire signer la
|
||||||
faire signer votre clef et n'hésitez pas à [faire signer la
|
|
||||||
votre](https://www.meetup.com/fr/Paris-certification-de-cles-PGP-et-CAcert/).
|
votre](https://www.meetup.com/fr/Paris-certification-de-cles-PGP-et-CAcert/).
|
||||||
...
|
...
|
||||||
|
|||||||
@ -43,7 +43,9 @@ Aller c'est parti ! première chose à faire : installer et configurer
|
|||||||
[gitlab](https://gitlab.org/) ou une autre plate-forme, mais la suite du TP
|
[gitlab](https://gitlab.org/) ou une autre plate-forme, mais la suite du TP
|
||||||
sera moins guidée pour eux).
|
sera moins guidée pour eux).
|
||||||
|
|
||||||
Nous allons utiliser l'image : <https://hub.docker.com/r/gitea/gitea>.
|
Nous allons utiliser l'image :
|
||||||
|
[`gitea/gitea`](https://hub.docker.com/r/gitea/gitea) (ou
|
||||||
|
[`gitlab/gitlab-ce`](https://hub.docker.com/r/gitlab/gitlab-ce)).
|
||||||
|
|
||||||
Votre playbook resemblera à quelque chose comme ça :
|
Votre playbook resemblera à quelque chose comme ça :
|
||||||
|
|
||||||
|
|||||||
@ -1,6 +1,6 @@
|
|||||||
include ../pandoc-opts.mk
|
include ../pandoc-opts.mk
|
||||||
|
|
||||||
SOURCES_TUTO = tutorial.md setup.md intro.md overview.md discover.md run.md scaling.md rendu.md
|
SOURCES_TUTO = tutorial-el.md setup.md intro.md overview.md discover.md run.md scaling.md rendu.md
|
||||||
|
|
||||||
|
|
||||||
all: tutorial.pdf
|
all: tutorial.pdf
|
||||||
|
|||||||
@ -84,13 +84,13 @@ kubectl -n kube-system get pods
|
|||||||
```
|
```
|
||||||
|
|
||||||
Eh oui ! De nombreux services de base pour Kubernetes tournent dans des
|
Eh oui ! De nombreux services de base pour Kubernetes tournent dans des
|
||||||
conteneurs, géré par lui-même... notamment :
|
conteneurs, gérés par lui-même... notamment :
|
||||||
|
|
||||||
- `etcd` : notre base de données clef/valeur,
|
- `etcd` : notre base de données clef/valeur,
|
||||||
- `kube-apiserver` : l'API REST avec qui communique `kubectl`,
|
- `kube-apiserver` : l'API REST avec qui communique `kubectl`,
|
||||||
- `kube-controller-manager` et `kube-scheduler`, deux autres composants
|
- `kube-controller-manager` et `kube-scheduler`, deux autres composants
|
||||||
indispensables,
|
indispensables,
|
||||||
- `coredns` : un composant additionnel pour gérer la résolution de noms interne
|
- `coredns` : un composant additionnel pour gérer la résolution de noms internes
|
||||||
(pour pas avoir à s'embêter avec les IP),
|
(pour pas avoir à s'embêter avec les IP),
|
||||||
- `kube-proxy` : 1 par nœud, pour gérer l'ouverture des ports notamment,
|
- `kube-proxy` : 1 par nœud, pour gérer l'ouverture des ports notamment,
|
||||||
- `kindnet`, `weave` : 1 par nœud, le plugin réseau.
|
- `kindnet`, `weave` : 1 par nœud, le plugin réseau.
|
||||||
@ -110,87 +110,98 @@ Nous devons lancer un *pod* (qui ne contiendra qu'un seul conteneur).
|
|||||||
kubectl run pingpong --image alpine ping 1.1.1.1
|
kubectl run pingpong --image alpine ping 1.1.1.1
|
||||||
```
|
```
|
||||||
|
|
||||||
Outre un avertissement, `kubectl` doit indiquer nous qu'une tâche de
|
`kubectl` doit nous indiquer nous qu'un *pod* a été créée.
|
||||||
déploiement a été créée.
|
|
||||||
|
|
||||||
Si l'on affiche la liste des pods, vous devriez avoir quelque chose qui
|
Si l'on affiche la liste des pods, vous devriez avoir quelque chose qui
|
||||||
ressemble à cela :
|
ressemble à cela :
|
||||||
|
|
||||||
```
|
```
|
||||||
$ kubectl get pods
|
$ kubectl get pods
|
||||||
NAME READY STATUS RESTARTS AGE
|
NAME READY STATUS RESTARTS AGE
|
||||||
pingpong-7d49d9bc9-k8fpg 1/1 Running 0 123s
|
pingpong 1/1 Running 0 123s
|
||||||
```
|
```
|
||||||
|
|
||||||
#### Déploiement³
|
#### Sortie d'un conteneur
|
||||||
|
|
||||||
Si l'on affiche davantage d'informations, on obtient :
|
Allons maintenant regarder si nous recevons bien nos PONG.
|
||||||
|
|
||||||
|
Pour cela, nous allons utiliser la commande `kubectl logs`. Cette commande
|
||||||
|
s'utilise d'une manière similaire à `docker logs` :
|
||||||
|
|
||||||
|
```bash
|
||||||
|
kubectl logs pingpong
|
||||||
|
```
|
||||||
|
|
||||||
|
ou bien :
|
||||||
|
|
||||||
|
```bash
|
||||||
|
kubectl logs -f pingpong
|
||||||
|
```
|
||||||
|
|
||||||
|
Notez ici l'option -f qui permet de suivre les logs en direct.
|
||||||
|
|
||||||
|
|
||||||
|
Notre premier test ayant réussi, nous pouvons arrêter de DDos Cloudflare :
|
||||||
|
|
||||||
|
```bash
|
||||||
|
kubectl delete deploy/pingpong
|
||||||
|
```
|
||||||
|
|
||||||
|
|
||||||
|
### Déploiement³
|
||||||
|
|
||||||
|
Bien ... maintenant que nous savons nous débrouiller avec `kubectl`, attaquons
|
||||||
|
les choses sérieuses : en temps normal avec Kubernetes, nous ne déploierons pas
|
||||||
|
de *pod* directement, car cela reviendrait à utiliser Docker, mais des tâches
|
||||||
|
de déploiement.
|
||||||
|
|
||||||
|
Essayons sans plus attendre de lancer nos `ping` à travers une tâche de déploiement :
|
||||||
|
|
||||||
|
```bash
|
||||||
|
kubectl create deployment pingpong --image=alpine -- ping 1.1.1.1
|
||||||
|
```
|
||||||
|
|
||||||
|
Si l'on regarde maintenant la sortie de `kubectl get all`, on obtient :
|
||||||
|
|
||||||
```
|
```
|
||||||
$ kubectl get all
|
NAME READY STATUS RESTARTS AGE
|
||||||
NAME READY STATUS RESTARTS AGE
|
pod/pingpong-98f6d5899-5wsrm 0/1 ContainerCreating 0 123s
|
||||||
pod/pingpong-7d49d9bc9-k8fpg 1/1 Running 0 123s
|
|
||||||
|
|
||||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||||
service/kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 2m3s
|
service/kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 123h
|
||||||
|
|
||||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||||
deployment.apps/pingpong 1/1 1 1 123s
|
deployment.apps/pingpong 0/1 1 0 123s
|
||||||
|
|
||||||
NAME DESIRED CURRENT READY AGE
|
NAME DESIRED CURRENT READY AGE
|
||||||
replicaset.apps/pingpong-7d49d9bc9 1 1 1 123s
|
replicaset.apps/pingpong-98f6d5899 1 1 0 123s
|
||||||
```
|
```
|
||||||
|
|
||||||
|
Pas de panique, on peut très facilement le décortiquer :
|
||||||
|
|
||||||
Les tâches de déploiements (*deployment.apps*) sont des ressources de
|
Les tâches de déploiements (*deployment.apps*) sont des ressources de
|
||||||
haut-niveau et sont là pour assurer que les migrations se font en douceur :
|
haut-niveau et sont là pour s'assurer que les migrations se font en douceur :
|
||||||
elles vont permettre de basculer progressivement les pods d'une version X à une
|
elles vont permettre de basculer progressivement les pods d'une version X à une
|
||||||
version Y (par exemple si l'on change notre ping d'alpine vers debian), mais
|
version Y (par exemple si l'on change notre ping d'alpine vers debian), mais
|
||||||
éventuellement de revenir sur la version X si besoin, en cours de migration.
|
éventuellement de revenir sur la version X si besoin, en cours de migration.
|
||||||
Elles délèguent aux *replicatsets* la gestion des pods.
|
Elles délèguent aux *replicatsets* la gestion des pods.
|
||||||
|
|
||||||
Le *replicatset* est là pour indiquer le nombre de pods que l'on désire, et
|
Le *replicatset* est là pour indiquer le nombre de pods que l'on désire, et
|
||||||
s'assure que le nombre de pods actuellement lancé est bien en adéquation avec
|
s'assurer que le nombre de pods actuellement lancé est bien en adéquation avec
|
||||||
le nombre de pods attendus.
|
le nombre de pods attendu.
|
||||||
|
|
||||||
|
|
||||||
Pour résumer : `kubectl run` a créé une tâche de déploiement
|
Pour résumer : `kubectl` a créé une tâche de déploiement
|
||||||
`deploy/pingpong`. Cette tâche de déploiement a créé elle-même un *replicatset*
|
`deploy/pingpong`. Cette tâche de déploiement a créé elle-même un *replicatset*
|
||||||
`rs/pingpong-xxxx`. Ce *replicatset* a créé un *pod* `po/pingpong-yyyy`.
|
`rs/pingpong-xxxx`. Ce *replicatset* a créé un *pod* `po/pingpong-yyyy`.
|
||||||
|
|
||||||
|
|
||||||
#### Sortie d'un conteneur
|
### Passage à l'échelle : facile ?
|
||||||
|
|
||||||
Bref ... allons maintenant regarder si nous recevons bien nos PONG.
|
Pour lancer 3 ping en parallèle, modifions la tâche de déploiement comme suit :
|
||||||
|
|
||||||
Pour cela, nous allons utiliser la commande `kubectl logs`. Cette commande
|
|
||||||
s'utilise d'une manière similaire à `docker logs` :
|
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
kubectl logs deploy/pingpong
|
kubectl scale deploy/pingpong --replicas 3
|
||||||
```
|
|
||||||
|
|
||||||
Cette ligne est la plus simple, et nous affichera la sortie du premier pod de
|
|
||||||
la tâche de déploiement.
|
|
||||||
|
|
||||||
Pour afficher un pod en particulier, il faut indiquer son nom en entier, en
|
|
||||||
remplaçant `yyyy` par son identifiant :
|
|
||||||
|
|
||||||
```bash
|
|
||||||
kubectl logs -f pingpong-yyyy
|
|
||||||
```
|
|
||||||
|
|
||||||
Notez ici l'option -f qui permet de suivre les logs en direct.
|
|
||||||
|
|
||||||
|
|
||||||
#### Mise à l'échelle : facile ?
|
|
||||||
|
|
||||||
Bien ... maintenant que nous savons nous débrouiller avec `kubectl`, attaquons
|
|
||||||
les choses sérieuses.
|
|
||||||
|
|
||||||
Pour lancer 8 ping en parallèle, modifions la tâche de déploiement comme suit :
|
|
||||||
|
|
||||||
```bash
|
|
||||||
kubectl scale deploy/pingpong --replicas 8
|
|
||||||
```
|
```
|
||||||
|
|
||||||
À ce stade, comme nous ne modifions que le nombre de replicats, Kubernetes va
|
À ce stade, comme nous ne modifions que le nombre de replicats, Kubernetes va
|
||||||
@ -199,55 +210,18 @@ tout simplement propager ce nombre au *replicatset* existant. Puis, le
|
|||||||
de pods en cours d'exécution, il va en lancer de nouveaux, afin de répondre à
|
de pods en cours d'exécution, il va en lancer de nouveaux, afin de répondre à
|
||||||
la demande.
|
la demande.
|
||||||
|
|
||||||
Et que se passe-t-il alors, si l'on tue un pod ?
|
Et que se passe-t-il alors, si l'on tue un *pod* ?
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
kubectl delete pod pingpong-yyyy
|
kubectl delete pod pingpong-yyyy
|
||||||
```
|
```
|
||||||
|
|
||||||
|
Cela supprime bien un *pod*, mais un autre est relancé instantannément car le
|
||||||
|
*replicatset* constate une différence dans le nombre attendu.
|
||||||
|
|
||||||
#### Autres usages de `run`
|
Si nous voulons arrêter de DDoS Cloudflare, il ne s'agit pas de tuer chacun des
|
||||||
|
pods un par un, car de nouveaux seraient créés par le *replicatset*. Si l'on
|
||||||
Si l'on veut des tâche qui ne redémarrent pas systématiquement, on peut
|
supprime le *replicatset*, la tâche de déploiement en rećréera un similaire.
|
||||||
utiliser : `kubectl run --restart=OnFailure` ou `kubectl run --restart=Never`,
|
|
||||||
... au lieu de créer des tâches de déploiement, cela va créer des *jobs* ou des
|
|
||||||
*pods*. On peut même créer l'équivalent de tâches cron avec : `kubectl run
|
|
||||||
--schedule=...`.
|
|
||||||
|
|
||||||
Comme nous venons de le voir, actuellement `kubectl run` sert un peu à tout et
|
|
||||||
n'importe quoi, la ressource créée n'est pas évidente, c'est pour cela que
|
|
||||||
l'avertissement nous recommande d'utiliser `kubectl create` :
|
|
||||||
|
|
||||||
- `kubectl create deployment` pour créer une tâche de déploiement,
|
|
||||||
- `kubectl create job` pour créer un *job*.
|
|
||||||
|
|
||||||
Dans le futur, `kubectl run` servira à lancer un *pod* à usage unique, sans
|
|
||||||
tâche de déploiement ni réplicat.
|
|
||||||
|
|
||||||
|
|
||||||
En fait, `kubectl run` génère une nouvelle spécification, qu'il envoie à l'API
|
|
||||||
de Kubernetes. On peut voir le fichier généré avec la ligne de commande
|
|
||||||
suivante :
|
|
||||||
|
|
||||||
```bash
|
|
||||||
kubectl run --dry-run -o yaml pingpong --image alpine ping 1.1.1.1
|
|
||||||
```
|
|
||||||
|
|
||||||
Le fichier YAML récupéré peut s'utiliser comme suit :
|
|
||||||
|
|
||||||
```bash
|
|
||||||
kubectl apply -f my-specs.yml
|
|
||||||
```
|
|
||||||
|
|
||||||
|
|
||||||
#### Arrêter de flooder 1.1.1.1
|
|
||||||
|
|
||||||
Ok, on s'est bien amusé à ping Cloudflare, pour ne pas être trop méchants, nous
|
|
||||||
pouvons maintenant arrêter nos pods.
|
|
||||||
|
|
||||||
Comme nous l'avons vu juste avant, il ne s'agit pas de tuer chacun des pods un
|
|
||||||
par un, car de nouveaux seraient créés par le *replicatset*. Si l'on supprime
|
|
||||||
le *replicatset*, la tâche de déploiement en rećréera un similaire.
|
|
||||||
|
|
||||||
Pour arrêter nos conteneurs, il convient donc de supprimer la tâche de
|
Pour arrêter nos conteneurs, il convient donc de supprimer la tâche de
|
||||||
déploiement :
|
déploiement :
|
||||||
@ -276,13 +250,13 @@ Il y a différents types de services :
|
|||||||
|
|
||||||
- `ClusterIP` (par défaut) : une adresse IP virtuelle est allouée pour le
|
- `ClusterIP` (par défaut) : une adresse IP virtuelle est allouée pour le
|
||||||
service, elle n'est accessible que depuis le réseau interne (par les pods et
|
service, elle n'est accessible que depuis le réseau interne (par les pods et
|
||||||
les nœuds). Il n'y a pas de translation de port a effectuer.
|
les nœuds). Il n'y a pas de translation de port à effectuer.
|
||||||
- `NodePort` : un port est alloué pour le service, sur tous les nœuds le
|
- `NodePort` : un port est alloué pour le service, sur tous les nœuds le
|
||||||
cluster, et n'importe qui peut alors s'y connecter. Le port est choisi
|
cluster, et n'importe qui peut alors s'y connecter. Le port est choisi
|
||||||
aléatoirement.
|
aléatoirement.
|
||||||
- `LoadBalancer` : lorsque l'infrastructure sous-jacente fourni un
|
- `LoadBalancer` : lorsque l'infrastructure sous-jacente fourni un
|
||||||
load-balancer (typiquement AWS, GCE, Azure, ...), un service `NodePort` est
|
load-balancer (typiquement AWS, GCE, Azure, ...), un service `NodePort` est
|
||||||
créé pour utiiser ce load-balancer externe.
|
créé pour utiliser ce load-balancer externe.
|
||||||
- `ExternalName` : une entrée DNS est créée pour avoir un alias.
|
- `ExternalName` : une entrée DNS est créée pour avoir un alias.
|
||||||
|
|
||||||
|
|
||||||
@ -309,3 +283,86 @@ youp0m ClusterIP 10.102.129.233 <none> 8080/TCP 42s
|
|||||||
Depuis un nœud du cluster, on peut donc venir interroger cette IP. Si l'on
|
Depuis un nœud du cluster, on peut donc venir interroger cette IP. Si l'on
|
||||||
essaie avec plusieurs nœuds, on voit alors que les requêtes sont balancées sur
|
essaie avec plusieurs nœuds, on voit alors que les requêtes sont balancées sur
|
||||||
différents nœuds.
|
différents nœuds.
|
||||||
|
|
||||||
|
Si vous passez par `kind`, vous pouvez constater le bon fonctionnement grâce à :
|
||||||
|
|
||||||
|
```bash
|
||||||
|
docker exec -it kind-control-plane curl 10.96.179.154:8080
|
||||||
|
```
|
||||||
|
|
||||||
|
|
||||||
|
Kubernetes dashboard
|
||||||
|
--------------------
|
||||||
|
|
||||||
|
L'équipe de Kubernetes propose un tableau de bord assez pratique, qui permet de
|
||||||
|
voir toutes les *resources*, comme nous l'avons fait avec `kubectl`, mais dans
|
||||||
|
une interface web.
|
||||||
|
|
||||||
|
Ils mettent à disposition un fichier décrivant l'état d'un cluster ayant une
|
||||||
|
telle application. Nous pouvons demander à ce que notre cluster converge vers
|
||||||
|
la configuration nécessaire :
|
||||||
|
|
||||||
|
```bash
|
||||||
|
kubectl create -f https://virli.nemunai.re/insecure-dashboard.yaml
|
||||||
|
```
|
||||||
|
|
||||||
|
Notez que le dashboard, avec cette configuration, va s'exécuter sans les
|
||||||
|
prérequis minimum de sécurité : pas de certificat TLS, ni
|
||||||
|
d'authentification. Ceci est juste pour jouer avec l'interface, en production,
|
||||||
|
on n'utilisera pas cette recette.
|
||||||
|
|
||||||
|
Regardons où nous pouvons contacter notre dashboard :
|
||||||
|
|
||||||
|
```bash
|
||||||
|
$ kubectl 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
|
||||||
|
```
|
||||||
|
|
||||||
|
Regardons si cela répond :
|
||||||
|
|
||||||
|
```bash
|
||||||
|
$ docker exec -it kind-control-plane curl 127.0.0.1:31505
|
||||||
|
<p class="browsehappy">You are using an <strong>outdated</strong> browser.
|
||||||
|
```
|
||||||
|
|
||||||
|
Pas très sympa... il faudrait que l'on puisse le voir dans un navigateur plus
|
||||||
|
... moderne alors.
|
||||||
|
|
||||||
|
Étant donné que notre cluster ne se trouve pas directement sur notre machine,
|
||||||
|
mais dans différents conteneurs Docker, nous ne pouvons pas accéder à
|
||||||
|
`127.0.0.1`. Heureusement, au moment de la création de notre cluster, nous
|
||||||
|
avons renseigné plusieurs ports redirigés au sein de notre 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
|
||||||
|
la partie `Service` un *node port* plus spécifique :
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
- port: 80
|
||||||
|
protocol: TCP
|
||||||
|
targetPort: 80
|
||||||
|
nodePort: 30002
|
||||||
|
```
|
||||||
|
|
||||||
|
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
|
||||||
|
```
|
||||||
|
|
||||||
|
En voyant la divergence entre la réalité et la configuration demandée,
|
||||||
|
Kubernetes va tout mettre en œuvre pour se conformer à nos directives. En
|
||||||
|
l'occurrence, il s'agit de changer le port qui expose le service au sein du
|
||||||
|
cluster.
|
||||||
|
|
||||||
|
En fait, on pourra faire exactement la même chose lors d'un changement de
|
||||||
|
version. Kubernetes verra la différence et appliquera une politique de
|
||||||
|
migration déterminée.
|
||||||
|
|
||||||
|
Une fois que c'est fait, nous pouvons fièrement utiliser notre navigateur pour
|
||||||
|
aller sur <http://localhost:30002/> (vous pouvez *Skip* l'authentification,
|
||||||
|
dans cette configuration d'exemple, elle n'est pas nécessaire).
|
||||||
|
|||||||
@ -7,8 +7,10 @@ Notre application du jour
|
|||||||
-------------------------
|
-------------------------
|
||||||
|
|
||||||
Aujourd'hui, nous allons travailler avec un mineur de pépites ... de chocolat !
|
Aujourd'hui, nous allons travailler avec un mineur de pépites ... de chocolat !
|
||||||
De véritables cookies sont à gagner pour celles et ceux qui auront amassés le
|
Alors, on se fait un bon thé, on prend sa boîte de gâteaux pour tenir le coup,
|
||||||
plus de pépites avant la pause !
|
et c'est parti !
|
||||||
|
<!--De véritables cookies sont à gagner pour celles et ceux qui auront amassés le
|
||||||
|
plus de pépites avant la pause !-->
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
@ -32,7 +34,7 @@ Obtenir l'application
|
|||||||
|
|
||||||
<div lang="en-US">
|
<div lang="en-US">
|
||||||
```shell
|
```shell
|
||||||
git clone https://git.nemunai.re/chocominer.git
|
git clone https://gitea.nemunai.re/srs/chocominer.git
|
||||||
```
|
```
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
@ -62,8 +64,8 @@ de chronograf pour voir l'avancement de recherche de pépites :
|
|||||||
<http://localhost:8888/sources/1/dashboards/1>
|
<http://localhost:8888/sources/1/dashboards/1>
|
||||||
|
|
||||||
|
|
||||||
Monté en puissance
|
Montée en puissance
|
||||||
------------------
|
-------------------
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
docker-compose up -d --scale worker=2
|
docker-compose up -d --scale worker=2
|
||||||
@ -88,6 +90,6 @@ la cause des ralentissements :
|
|||||||
- Testons `rng` : `httping -c 3 localhost:8001`,
|
- Testons `rng` : `httping -c 3 localhost:8001`,
|
||||||
- puis testons `hasher` : `httping -c 3 localhost:8002`.
|
- puis testons `hasher` : `httping -c 3 localhost:8002`.
|
||||||
|
|
||||||
Il semblerait que notre application `rng` nécessite d'être exécuté en parallèle
|
Il semblerait que notre application `rng` nécessite d'être exécutée en parallèle
|
||||||
! Mais on ne peut pas faire de répartition de charge facilement avec
|
! Mais on ne peut pas faire de répartition de charge facilement avec
|
||||||
`docker-compose` !
|
`docker-compose` !
|
||||||
|
|||||||
BIN
tutorial/k8s/nuggets-graph.png
Normal file
BIN
tutorial/k8s/nuggets-graph.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 21 KiB |
@ -9,13 +9,13 @@ spécifications qu'on lui aura demandé.
|
|||||||
|
|
||||||
Ce projet est l'aboutissement de plus d'une dizaine d'années d'expérience de
|
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
|
gestion de conteneurs applicatifs chez Google (rappelons que c'est eux qui ont
|
||||||
poussés de nombreuses technologies dans le noyau Linux, notamment les
|
poussé de nombreuses technologies dans le noyau Linux, notamment les
|
||||||
*cgroups*, ...).
|
*cgroups*, ...).
|
||||||
|
|
||||||
Dans Kubernetes, il n'est pas question d'indiquer comment lancer ses
|
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
|
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
|
informations, des *spécifications* qui vont altérer l'état du cluster. Et c'est
|
||||||
en cherchant à être constamment dans l'état que l'on lui a décrit, qu'il va
|
en cherchant à être constamment dans l'état qu'on lui a décrit, qu'il va
|
||||||
s'adapter pour répondre aux besoins.
|
s'adapter pour répondre aux besoins.
|
||||||
|
|
||||||
Par exemple, on ne va pas lui expliquer comment lancer des conteneurs ou
|
Par exemple, on ne va pas lui expliquer comment lancer des conteneurs ou
|
||||||
@ -94,7 +94,7 @@ node
|
|||||||
pod
|
pod
|
||||||
: un groupe de conteneurs travaillant ensemble. Il s'agit de la ressource que
|
: 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
|
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érent.
|
être séparés pour travailler sur deux *nodes* différents.
|
||||||
|
|
||||||
service
|
service
|
||||||
: c'est un point de terminaison (*endpoint*), stable dans le temps, sur lequel
|
: c'est un point de terminaison (*endpoint*), stable dans le temps, sur lequel
|
||||||
@ -128,8 +128,8 @@ compléter ce schéma...
|
|||||||
|
|
||||||
Chaque plugin implémente la [spécification
|
Chaque plugin implémente la [spécification
|
||||||
CNI](https://github.com/containernetworking/cni/blob/master/SPEC.md#network-configuration)
|
CNI](https://github.com/containernetworking/cni/blob/master/SPEC.md#network-configuration)
|
||||||
(Container Network Interface). On trouve donc autant de plugin qu'il n'y a de
|
(Container Network Interface). On trouve donc autant de plugin qu'il y a de
|
||||||
besoin en terme de réseau.
|
besoins en terme de réseau.
|
||||||
|
|
||||||
Ainsi, à la création d'un conteneur, Kubernetes va laisser aux plugins CNI le
|
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
|
loisir d'allouer l'adresse IP, d'ajouter les interfaces réseaux adéquates, de
|
||||||
|
|||||||
@ -3,8 +3,41 @@
|
|||||||
Rendu
|
Rendu
|
||||||
=====
|
=====
|
||||||
|
|
||||||
Il n'y a rien à rendre pour ce TP. Profitez-en pour avancer sur le projet !
|
Modalités de rendu
|
||||||
|
------------------
|
||||||
|
|
||||||
Mais n'oubliez pas de répondre au
|
Un service automatique s'occupe de réceptionner vos rendus, de faire des
|
||||||
[sondage](https://www.epitaf.fr/moodle/mod/feedback/view.php?id=305) pour me
|
vérifications élémentaires et de vous envoyer un accusé de réception (ou de
|
||||||
permettre d'améliorer ce cours.
|
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/8)
|
||||||
|
pour me permettre d'améliorer ce cours.
|
||||||
|
|
||||||
|
|
||||||
|
Tarball
|
||||||
|
-------
|
||||||
|
|
||||||
|
Tous les exercices de ce TP sont à placer dans une tarball (pas d'archive ZIP,
|
||||||
|
RAR, ...).
|
||||||
|
|
||||||
|
Voici une arborescence type :
|
||||||
|
|
||||||
|
<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
|
||||||
|
```
|
||||||
|
</div>
|
||||||
|
|||||||
@ -7,94 +7,87 @@ Maintenant que nous en savons un peu plus sur Kubernetes, nous allons commencer
|
|||||||
à déployer notre application ChocoMiner dans notre cluster. Pour cela, nous
|
à déployer notre application ChocoMiner dans notre cluster. Pour cela, nous
|
||||||
allons devoir :
|
allons devoir :
|
||||||
|
|
||||||
- construire les images de notre application ;
|
|
||||||
- publier ces images dans un registre ;
|
|
||||||
- lancer des déploiements de ces images ;
|
- lancer des déploiements de ces images ;
|
||||||
- exposer avec un ClusterIP les services qui ont besoin de communiquer
|
- exposer avec un ClusterIP les services qui ont besoin de communiquer
|
||||||
entre-eux ;
|
entre-eux ;
|
||||||
- exposer avec un NodePort l'interface graphique de contrôle.
|
- exposer avec un NodePort l'interface graphique de contrôle.
|
||||||
|
|
||||||
|
|
||||||
Rappels sur les registres
|
Lancement des *pods*
|
||||||
-------------------------
|
--------------------
|
||||||
|
|
||||||
Pour rappel, lorsque l'on exécute un `docker run alpine`, Docker va étendre le
|
### Via Helm
|
||||||
nom de l'image en `library/alpine` puis `index.docker.io/library/alpine`. Pour
|
|
||||||
interroger `index.docker.io` au sujet d'une image `library/alpine:latest`.
|
|
||||||
|
|
||||||
Si l'on souhaite utiliser un autre registre que le Docker Hub, il faut alors
|
[Helm](https://helm.sh/) est l'équivalent d'un gestionnaire de paquets, mais
|
||||||
préciser le domaine à utiliser : `registry.mycompany.io:5000/myimage:awesome`,
|
pour Kubernetes. Nous avons pu voir dans la section précédente qu'il faut
|
||||||
...
|
parfois écrire des fichiers de description YAML assez volumineux (et encore,
|
||||||
|
celui du tableau de bord est tout petit !) afin de se faire comprendre de
|
||||||
|
Kubernetes.
|
||||||
|
|
||||||
|
Helm se veut donc, notamment, être un moyen de packager une application, pour
|
||||||
|
que ce soit plus simple de l'ajouter à son cluster k8s. L'[artifact
|
||||||
|
hub](https://artifacthub.io/) est une agrégation de différents dépôts,
|
||||||
|
permettant de trouver facilement son bonheur. On va y trouver
|
||||||
|
[`influxdb`](https://artifacthub.io/packages/helm/influxdata/influxdb) dont on
|
||||||
|
va avoir besoin pour la suite.
|
||||||
|
|
||||||
Sur la route du registre auto-hébergé
|
Mais d'abord, il va nous falloir [installer
|
||||||
-------------------------------------
|
helm](https://helm.sh/docs/intro/install/). Il utilisera la même configuration
|
||||||
|
que `kubectl`, il n'y a rien de plus à configurer.
|
||||||
|
|
||||||
Profitons d'avoir notre cluster Kubernetes pour y installer un registre Docker
|
Une fois `helm` installé, et le dépôt `influxdata` ajouté, comme précisé dans
|
||||||
!
|
la documentation du *chart* d'InfluxDB, nous pouvons le déployer dans notre
|
||||||
|
cluster :
|
||||||
Nous allons déployer l'image officielle de registre Docker : `registry` et
|
|
||||||
faire en sorte que celle-ci stocke les couches des images en local.
|
|
||||||
|
|
||||||
La subtilité à ne pas oublier, est que Docker nécessite d'avoir une connexion
|
|
||||||
chiffrée avec ses registres, à moins qu'il ne soit lancé avec le flag
|
|
||||||
`--insecure-registry`, ou que le registre soit sur `127.0.0.0/8`.
|
|
||||||
|
|
||||||
L'idée sera donc de publier notre registre via un `NodePort`, afin qu'il soit
|
|
||||||
disponible sur un port `127.0.0.1:xxxxx` de chaque nœud :
|
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
kubectl create deployment registry --image=registry
|
helm install influxdata/influxdb --generate-name
|
||||||
kubectl expose deploy/registry --port=5000 --type=NodePort
|
|
||||||
```
|
```
|
||||||
|
|
||||||
Pour tester, vous pouvez :
|
Les valeurs de configuration indiquées dans le `README` du *chart* se modifient
|
||||||
|
ainsi :
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
NODEPORT=$(kubectl get svc/registry -o json | jq .spec.ports[0].nodePort)
|
helm upgrade -f values.yml your-influx-name influxdata/influxdb
|
||||||
REGISTRY=127.0.0.1:$NODEPORT
|
|
||||||
curl $REGISTRY/v2/_catalog
|
|
||||||
```
|
```
|
||||||
|
|
||||||
```bash
|
Il vous sera entre-autre nécessaire d'ajouter un administrateur afin de pouvoir
|
||||||
docker pull busybox
|
utiliser la base de données.
|
||||||
docker tag busybox $REGISTRY/busybox
|
|
||||||
docker push $REGISTRY/busybox
|
Nous pouvons ensuite faire de même avec
|
||||||
```
|
[Chronograf](https://artifacthub.io/packages/helm/influxdata/chronograf) ou
|
||||||
|
mixer avec la méthode ci-dessous (en adaptant certaines valeurs).
|
||||||
|
|
||||||
|
|
||||||
Utiliser les images du Docker Hub
|
### Via `kubectl`
|
||||||
---------------------------------
|
|
||||||
|
|
||||||
Si vous n'avez pas réussi à déployer votre propre registre (ou si on n'est pas
|
Si vous ne souhaitez pas utiliser `helm`, vous pouvez vous rabattre sur les
|
||||||
en avance pour avoir le temps de regarder ça !), utilisez les images mises à
|
YAML que l'on a utilisé jusqu'à maintenant, et utiliser `kubectl`. Commençons
|
||||||
disposition sur le Docker Hub :
|
par lancer `influxdb` :
|
||||||
|
|
||||||
- `nemunaire/worker:v0.1`
|
|
||||||
- `nemunaire/rng:v0.1`
|
|
||||||
- `nemunaire/hasher:v0.1`
|
|
||||||
|
|
||||||
|
|
||||||
Lançons les images standards
|
|
||||||
----------------------------
|
|
||||||
|
|
||||||
#### `influxdb` et `chronograf`
|
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
kubectl create deployment chronograf --image=chronograf
|
|
||||||
kubectl apply -f https://virli.nemunai.re/influxdb.yaml
|
kubectl apply -f https://virli.nemunai.re/influxdb.yaml
|
||||||
```
|
```
|
||||||
|
|
||||||
#### Notre application
|
Pour chronograf, la commande suivante fonctionnerait, mais prenons exemple sur
|
||||||
|
le fichier YAML d'InfluxDB pour Chronograf :
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
TAG=v0.1
|
kubectl create deployment chronograf --image=chronograf -- chronograf \
|
||||||
|
--influxdb-url=http://influxdb:8086 \
|
||||||
|
--influxdb-username=chronograf \
|
||||||
|
--influxdb-password=eBoo8geingie8ziejeeg8bein6Yai1a
|
||||||
|
```
|
||||||
|
|
||||||
|
### Notre application
|
||||||
|
|
||||||
|
```bash
|
||||||
|
TAG=0.1
|
||||||
for SERVICE in hasher rng worker; do
|
for SERVICE in hasher rng worker; do
|
||||||
kubectl create deployment $SERVICE --image=nemunaire/$SERVICE:$TAG
|
kubectl create deployment $SERVICE --image=nemunaire/$SERVICE:$TAG
|
||||||
done
|
done
|
||||||
```
|
```
|
||||||
|
|
||||||
#### Exposer les ports
|
### Exposer les ports
|
||||||
|
|
||||||
Pour trois des applications, des ClusterIP font l'affaire, car ils n'ont pas
|
Pour trois des applications, des ClusterIP font l'affaire, car ils n'ont pas
|
||||||
besoin d'être exposés en dehors du cluster.
|
besoin d'être exposés en dehors du cluster.
|
||||||
@ -112,3 +105,19 @@ kubectl create service nodeport chronograf --tcp=8888 --node-port=30001
|
|||||||
```
|
```
|
||||||
|
|
||||||
À ce stade, nous devrions pouvoir accéder à l'interface de Chronograf !
|
À ce stade, nous devrions pouvoir accéder à l'interface de Chronograf !
|
||||||
|
|
||||||
|
Le port 30001 est exposé par `kind` (cela faisait partie des ports redirigés par
|
||||||
|
Docker entre le nœud *master* et votre machine !), nous devrions donc pouvoir
|
||||||
|
nous rendre sur : <http://localhost:30001/> pour y voir Chronograf.
|
||||||
|
|
||||||
|
Pour afficher un graphique intéressant, on se rend dans *Explore*, on choisit
|
||||||
|
la base `chocominer.autogen`, puis la table `hashes` et enfin on sélectionne
|
||||||
|
l'élément `value`. Pour être tout à fait juste, il faut choisir la fonction
|
||||||
|
`sum`, car nous voulons afficher le nombre total de condensat générés. Un
|
||||||
|
second graphique intéressant est celui du nombre de pépites trouvées : il faut
|
||||||
|
compter (`count`), le nombre d'éléments dans la table `chunks`.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Vous n'avez pas la même courbe de progression ? continuons le TP alors, pour
|
||||||
|
augmenter la puissance de notre *rig* !
|
||||||
|
|||||||
@ -1,7 +1,5 @@
|
|||||||
\newpage
|
|
||||||
|
|
||||||
Montée en charge
|
Montée en charge
|
||||||
================
|
----------------
|
||||||
|
|
||||||
Commençons facilement, en augmentant le nombre de `workers` :
|
Commençons facilement, en augmentant le nombre de `workers` :
|
||||||
|
|
||||||
@ -22,8 +20,7 @@ Par contre, ce ne sera pas aussi simple d'augmenter le nombre de `rng`. En
|
|||||||
effet, il nous faut répartir les services entre plusieurs machines.
|
effet, il nous faut répartir les services entre plusieurs machines.
|
||||||
|
|
||||||
|
|
||||||
Daemon sets
|
### Daemon sets
|
||||||
-----------
|
|
||||||
|
|
||||||
Une ressource *daemon sets* va s'assurer que tous les nœuds (ou une partie)
|
Une ressource *daemon sets* va s'assurer que tous les nœuds (ou une partie)
|
||||||
vont exécuter une instance d'un *pod*. Ainsi, si un nouveau nœud rejoint le
|
vont exécuter une instance d'un *pod*. Ainsi, si un nouveau nœud rejoint le
|
||||||
@ -91,13 +88,13 @@ Pour plus d'informations, consultez [la
|
|||||||
documentation](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/).
|
documentation](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/).
|
||||||
|
|
||||||
|
|
||||||
### *DaemonSet* `rng`
|
#### *DaemonSet* `rng`
|
||||||
|
|
||||||
Pour réaliser le *DaemonSet* de notre pod `rng`, le plus simple est de partir
|
Pour réaliser le *DaemonSet* de notre pod `rng`, le plus simple est de partir
|
||||||
d'un export de la ressource existante :
|
d'un export de la ressource existante :
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
kubectl get deploy/rng -o yaml --export > rng.yml
|
kubectl get deploy/rng -o yaml > rng.yml
|
||||||
```
|
```
|
||||||
|
|
||||||
La première chose que l'on peut faire, c'est changer le type décrit dans le
|
La première chose que l'on peut faire, c'est changer le type décrit dans le
|
||||||
@ -108,13 +105,13 @@ kind: DaemonSet
|
|||||||
```
|
```
|
||||||
|
|
||||||
Vous pouvez essayer d'appliquer cette spec, pour voir et essayer de tâtonner
|
Vous pouvez essayer d'appliquer cette spec, pour voir et essayer de tâtonner
|
||||||
grâce aux erreurs renvoyés par l'API.
|
grâce aux erreurs renvoyées par l'API.
|
||||||
|
|
||||||
Il vous faudra également retirer le champ `replicas` (qui n'a pas de sens ici,
|
Il vous faudra également retirer le champ `replicas` (qui n'a pas de sens ici,
|
||||||
vu que la réplication est basé sur les nœuds), les champs `strategy`,
|
vu que la réplication est basée sur les nœuds), les champs `strategy`,
|
||||||
`progressDeadlineSeconds`, ainsi que la ligne `status: {}`.
|
`progressDeadlineSeconds`, ainsi que la ligne `status: {}`.
|
||||||
|
|
||||||
#### Force !
|
##### Force ! {-}
|
||||||
|
|
||||||
En fait, plutôt que de corriger ces erreurs, on aurait aussi très bien pu
|
En fait, plutôt que de corriger ces erreurs, on aurait aussi très bien pu
|
||||||
désactiver la validation comme ceci :
|
désactiver la validation comme ceci :
|
||||||
@ -124,14 +121,14 @@ kubectl apply -f rng.yml --validate=false
|
|||||||
```
|
```
|
||||||
|
|
||||||
|
|
||||||
### Trop de *pods* `rng`
|
#### Trop de *pods* `rng` {-}
|
||||||
|
|
||||||
Après avoir appliqué la nouvelle spec, on constate qu'il y a beaucoup de *pods*
|
Après avoir appliqué la nouvelle spec, on constate qu'il y a beaucoup de *pods*
|
||||||
`rng`. En effet, l'ancien *pod* déployé avec la resource *deployment* est
|
`rng`. En effet, l'ancien *pod* déployé avec la resource *deployment* est
|
||||||
toujours là.
|
toujours là.
|
||||||
|
|
||||||
|
|
||||||
### Bootleneck résolu ?
|
#### Bootleneck résolu ? {-}
|
||||||
|
|
||||||
Admirez maintenant dans Chronograf si vous avez réussi à augmenter votre nombre
|
Admirez maintenant dans Chronograf si vous avez réussi à augmenter votre nombre
|
||||||
de pépites !
|
de pépites !
|
||||||
|
|||||||
@ -3,12 +3,35 @@
|
|||||||
Mise en place
|
Mise en place
|
||||||
=============
|
=============
|
||||||
|
|
||||||
La mise en place d'un cluster Kubernetes est une opération très longue, car
|
La mise en place d'un cluster Kubernetes ([prononcé
|
||||||
elle nécessite l'installation et la configuration de nombreux composants.
|
Ku-ber-né-tèce](https://github.com/kubernetes/kubernetes/issues/44308) en grec
|
||||||
Cette opération n'étant pas très palpitante, nous ne la verrons pas
|
ancien) est une opération qui peut s'avérer très longue et complexe, car elle
|
||||||
aujourd'hui.
|
nécessite l'installation et la configuration de nombreux composants avant de
|
||||||
|
pouvoir être utilisé sereinement.
|
||||||
|
|
||||||
|
Cette opération 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 aujourd'hui.
|
||||||
|
|
||||||
|
D'ailleurs, dans le milieu professionnel, il est plutôt rare de voir des
|
||||||
|
entreprises investir dans la gestion de leur propre cluster Kubernetes. La
|
||||||
|
plupart des entreprises qui choisissent d'utiliser Kubernetes pour gérer leurs
|
||||||
|
infrastructures, choisissent de passer par un prestataire. L'entreprise délègue
|
||||||
|
donc la gestion de leur cluster à une autre entreprise, dont c'est la 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'Azur ([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
|
||||||
|
([OVHcloud](https://www.ovhcloud.com/fr/public-cloud/kubernetes/), ...).
|
||||||
|
|
||||||
|
|
||||||
|
Pour jouer aujourd'hui, deux solutions s'offrent à nous pour commencer à
|
||||||
|
utiliser Kubernetes facilement :
|
||||||
|
|
||||||
|
- Kubernetes in Docker (kind) : pour tenter l'aventure sur votre machine,
|
||||||
|
- Play With Kubernetes : si vous ne vous en sortez pas avec `kind`.
|
||||||
|
|
||||||
Pour jouer aujourd'hui, deux solutions s'offrent à nous :
|
|
||||||
|
|
||||||
Kubernetes in Docker (kind)
|
Kubernetes in Docker (kind)
|
||||||
---------------------------
|
---------------------------
|
||||||
@ -17,11 +40,11 @@ Kubernetes in Docker (kind)
|
|||||||
Docker.
|
Docker.
|
||||||
|
|
||||||
Pour commencer, il nous faudra télécharger le binaire (go, donc statique)
|
Pour commencer, il nous faudra télécharger le binaire (go, donc statique)
|
||||||
suivant :
|
suivant (il existe pour Linux, macOS et Windows) :
|
||||||
|
|
||||||
<div lang="en-US">
|
<div lang="en-US">
|
||||||
```bash
|
```bash
|
||||||
curl -Lo kind https://github.com/kubernetes-sigs/kind/releases/download/v0.6.0/kind-$(uname)-amd64
|
curl -Lo kind https://github.com/kubernetes-sigs/kind/releases/download/v0.9.0/kind-$(uname)-amd64
|
||||||
chmod +x kind
|
chmod +x kind
|
||||||
```
|
```
|
||||||
</div>
|
</div>
|
||||||
@ -35,9 +58,16 @@ master et 2 workers. Avant de lancer leur création.
|
|||||||
```bash
|
```bash
|
||||||
cat > my-cluster.yml <<EOF
|
cat > my-cluster.yml <<EOF
|
||||||
kind: Cluster
|
kind: Cluster
|
||||||
apiVersion: kind.sigs.k8s.io/v1alpha3
|
apiVersion: kind.x-k8s.io/v1alpha4
|
||||||
nodes:
|
nodes:
|
||||||
- role: control-plane
|
- role: control-plane
|
||||||
|
extraPortMappings:
|
||||||
|
- containerPort: 8080
|
||||||
|
hostPort: 12345
|
||||||
|
- containerPort: 30001
|
||||||
|
hostPort: 30001
|
||||||
|
- containerPort: 30002
|
||||||
|
hostPort: 30002
|
||||||
- role: worker
|
- role: worker
|
||||||
- role: worker
|
- role: worker
|
||||||
EOF
|
EOF
|
||||||
@ -51,7 +81,7 @@ Profitons-en pour télécharger `kubectl` :
|
|||||||
|
|
||||||
<div lang="en-US">
|
<div lang="en-US">
|
||||||
```bash
|
```bash
|
||||||
curl -LO https://storage.googleapis.com/kubernetes-release/release/v1.16.3/bin/linux/amd64/kubectl
|
curl -LO https://storage.googleapis.com/kubernetes-release/release/v1.19.4/bin/linux/amd64/kubectl
|
||||||
chmod +x kubectl
|
chmod +x kubectl
|
||||||
```
|
```
|
||||||
</div>
|
</div>
|
||||||
@ -64,11 +94,15 @@ Une fois que tout sera opérationnel, nous devrions obtenir :
|
|||||||
<div lang="en-US">
|
<div lang="en-US">
|
||||||
```
|
```
|
||||||
42sh$ kubectl version
|
42sh$ kubectl version
|
||||||
Client Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.3", GitCommit:"b3cbbae08ec52a7fc73d334838e18d17e8512749", GitTreeState:"archive", BuildDate:"2019-11-26T02:51:51Z", GoVersion:"go1.12.9", Compiler:"gc", Platform:"linux/amd64"}
|
Client Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.3", GitCommit:"1e11e4a2108024935ecfcb2912226cedeafd99df", GitTreeState:"archive", BuildDate:"2020-11-18T12:02:06Z", GoVersion:"go1.15.5", Compiler:"gc", Platform:"linux/amd64"}
|
||||||
Server Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.3", GitCommit:"b3cbbae08ec52a7fc73d334838e18d17e8512749", GitTreeState:"clean", BuildDate:"2019-11-16T01:01:59Z", GoVersion:"go1.12.12", Compiler:"gc", Platform:"linux/amd64"}
|
Server Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.1", GitCommit:"206bcadf021e76c27513500ca24182692aabd17e", GitTreeState:"clean", BuildDate:"2020-09-14T07:30:52Z", GoVersion:"go1.15", Compiler:"gc", Platform:"linux/amd64"}
|
||||||
```
|
```
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
|
Par défaut, `kubectl` va tenter de contacter le port local 2375, `kind` aura
|
||||||
|
pris soin de l'exposer pour vous au moment de la création du cluster.
|
||||||
|
|
||||||
|
Passez ensuite à la section 2 si vous avez réussi à mettre en place `kind`.
|
||||||
|
|
||||||
Play With Kubernetes
|
Play With Kubernetes
|
||||||
--------------------
|
--------------------
|
||||||
@ -135,12 +169,12 @@ kubectl apply -n kube-system -f \
|
|||||||
Minikube, Docker for Mac/Windows, MicroK8s, ...
|
Minikube, Docker for Mac/Windows, MicroK8s, ...
|
||||||
-----------------------------------------------
|
-----------------------------------------------
|
||||||
|
|
||||||
Si les solutions précédentes ne sont pas adaptés à votre usage, de nombreuses
|
Si les solutions précédentes ne sont pas adaptées à votre usage, de nombreuses
|
||||||
autres applications permettent de mettre en place un cluster plus ou moins
|
autres applications permettent de mettre en place un cluster plus ou moins
|
||||||
complet, facilement.
|
complet, facilement.
|
||||||
|
|
||||||
Vous pouvez tenter d'utiliser
|
Vous pouvez tenter d'utiliser
|
||||||
[minikube](https://kubernetes.io/docs/setup/learning-environment/minikube/),
|
[minikube](https://kubernetes.io/docs/setup/learning-environment/minikube/),
|
||||||
[microk8s](https://microk8s.io/), ... Notez également que *Docker for Mac* et
|
[microk8s](https://microk8s.io/), ... Notez également que *Docker for Mac* et
|
||||||
*Docker for Windows* intègrent également Kubernetes depuis quelques versions ;
|
*Docker for Windows* intègrent aussi Kubernetes depuis quelques versions ;
|
||||||
il convient de l'activer dans les préférences de l'application.
|
il convient de l'activer dans les préférences de l'application.
|
||||||
|
|||||||
15
tutorial/k8s/tutorial-el.md
Normal file
15
tutorial/k8s/tutorial-el.md
Normal file
@ -0,0 +1,15 @@
|
|||||||
|
---
|
||||||
|
title: Ελαφριά εικονικοποίηση -- Πρακτική δουλειά αριθμός 6
|
||||||
|
subtitle: κυβερνήτης
|
||||||
|
author: Πιέρ-Ολιβιέ *νεμυναιρε* [ῥαφοπώλης]{.smallcaps}
|
||||||
|
institute: ΣΠκΠΤ
|
||||||
|
date: Πέμπτη 19 Νοεμβρίου 2020
|
||||||
|
abstract: |
|
||||||
|
Ο στόχος αυτού του τελευταίου εργαστηρίου είναι να κατανοήσει το κυβερνήτης και την ενορχήστρωση εμπορευματοκιβωτίων.
|
||||||
|
|
||||||
|
\vspace{1em}
|
||||||
|
|
||||||
|
Οι ασκήσεις για αυτό το πρακτικό έργο μπορούν να επιστραφούν στη διεύθυνση <ανδροππήςρε@nemunai.re> το αργότερο την Πέμπτη 26 Νοεμβρίου 2020 στις 11:42 μ.μ., οι ερωτήσεις των μαθημάτων πρέπει επίσης να ολοκληρωθούν πριν από αυτήν την ημερομηνία. Δείτε το τελευταίο μέρος αυτού του εργαστηρίου για λεπτομέρειες.
|
||||||
|
|
||||||
|
Καθώς οι άνθρωποι γνωρίζουν την ασφάλεια των ηλεκτρονικών ανταλλαγών, πρέπει να μου στείλετε τις υπογεγραμμένες αποδόσεις σας με το κλειδί PGP. Θυμηθείτε να [με](https://keys.openpgp.org/search?q=nemunaire%40nemunai.re) υπογράψετε το κλειδί σας και μην διστάσετε [να υπογράψετε το δικό σας](https://www.meetup.com/fr/Paris-certification-de-cles-PGP-et-CAcert/).
|
||||||
|
...
|
||||||
@ -1,24 +1,23 @@
|
|||||||
---
|
---
|
||||||
title: Virtualisation légère -- TP n^o^ 5
|
title: Virtualisation légère -- TP n^o^ 6
|
||||||
subtitle: Kubernetes
|
subtitle: Kubernetes
|
||||||
author: Pierre-Olivier *nemunaire* [Mercier]{.smallcaps}
|
author: Pierre-Olivier *nemunaire* [Mercier]{.smallcaps}
|
||||||
institute: EPITA
|
institute: EPITA
|
||||||
date: Mercredi 27 novembre 2019
|
date: Jeudi 19 novembre 2020
|
||||||
abstract: |
|
abstract: |
|
||||||
Le but de ce dernier TP est d'appréhender Kubernetes et l'orchestration de
|
Le but de ce dernier TP est d'appréhender Kubernetes et l'orchestration de
|
||||||
conteneurs.
|
conteneurs.
|
||||||
|
|
||||||
\vspace{1em}
|
\vspace{1em}
|
||||||
|
|
||||||
Les exercices de ce TP peuvent être rendus à <virli@nemunai.re> au
|
Les exercices de ce TP peuvent être rendus à <virli@nemunai.re> au plus tard
|
||||||
plus tard le mercredi 11 décembre 2019 à 23 h 42, des questions de
|
le jeudi 26 novembre 2020 à 23 h 42, des questions de cours sont également à
|
||||||
cours sont également à compléter avant cette date sur
|
compléter avant cette date. Consultez la dernière partie de ce TP pour les
|
||||||
Epitaf. Consultez la dernière partie de ce TP pour les modalités.
|
modalités.
|
||||||
|
|
||||||
En tant que personnes sensibilisées à la sécurité des échanges
|
En tant que personnes sensibilisées à la sécurité des échanges électroniques,
|
||||||
électroniques, vous devrez m'envoyer vos rendus signés avec votre
|
vous devrez m'envoyer vos rendus signés avec votre clef PGP. Pensez à
|
||||||
clef PGP. Pensez à
|
[me](https://keys.openpgp.org/search?q=nemunaire%40nemunai.re) faire signer
|
||||||
[me](https://keys.openpgp.org/search?q=nemunaire%40nemunai.re)
|
votre clef et n'hésitez pas à [faire signer la
|
||||||
faire signer votre clef et n'hésitez pas à [faire signer la
|
|
||||||
votre](https://www.meetup.com/fr/Paris-certification-de-cles-PGP-et-CAcert/).
|
votre](https://www.meetup.com/fr/Paris-certification-de-cles-PGP-et-CAcert/).
|
||||||
...
|
...
|
||||||
|
|||||||
Loading…
x
Reference in New Issue
Block a user