tuto 2022 5, 6
This commit is contained in:
parent
3d7c03fbbd
commit
2af52619c7
43 changed files with 1073 additions and 431 deletions
|
|
@ -15,27 +15,41 @@ dessus de `curl`.
|
|||
Obtenir de l'aide
|
||||
-----------------
|
||||
|
||||
Commençons par apprivoiser `kubectl` en prenant quelques
|
||||
renseignements et surtout en apprennant comment obtenir de l'aide :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
kubectl describe type/name
|
||||
kubectl describe type name
|
||||
kubectl explain type
|
||||
```
|
||||
</div>
|
||||
|
||||
Les `type`s que vous pouvez découvrir sont ceux que l'on a vu à la
|
||||
sections précédentes : `node`, `pod`, ...
|
||||
|
||||
La commande `describe` permet d'afficher l'état tel qu'il est attendu
|
||||
et tel qu'il est actuellement (cela permet de se rendre lorsque les
|
||||
deux divergent).
|
||||
|
||||
|
||||
`get`
|
||||
-----
|
||||
|
||||
Une autre manière, moins verbeuse, de récupérer des informations est
|
||||
d'utiliser `get` :
|
||||
|
||||
```bash
|
||||
kubectl get node
|
||||
```
|
||||
|
||||
Plus d'infos :
|
||||
On peut ajouter des options pour avoir plus d'infos :
|
||||
|
||||
```bash
|
||||
kubectl get nodes -o wide
|
||||
```
|
||||
|
||||
Lisible par une machine :
|
||||
... ou rendre la sortie lisible par une machine :
|
||||
|
||||
```bash
|
||||
kubectl get no -o yaml
|
||||
|
|
@ -91,7 +105,7 @@ conteneurs, gérés par lui-même... notamment :
|
|||
- `kube-controller-manager` et `kube-scheduler`, deux autres composants
|
||||
indispensables,
|
||||
- `coredns` : un composant additionnel pour gérer la résolution de noms internes
|
||||
(pour pas avoir à s'embêter avec les IP),
|
||||
(pour ne pas avoir à s'embêter avec les IP),
|
||||
- `kube-proxy` : 1 par nœud, pour gérer l'ouverture des ports notamment,
|
||||
- `kindnet`, `weave` : 1 par nœud, le plugin réseau.
|
||||
|
||||
|
|
@ -110,9 +124,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éée.
|
||||
`kubectl` doit nous indiquer nous qu'un *pod* a été créé.
|
||||
|
||||
Si l'on affiche la liste des pods, vous devriez avoir quelque chose qui
|
||||
Si l'on affiche la liste des *pod*s, vous devriez avoir quelque chose qui
|
||||
ressemble à cela :
|
||||
|
||||
```
|
||||
|
|
@ -144,7 +158,7 @@ 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
|
||||
kubectl delete pods pingpong
|
||||
```
|
||||
|
||||
|
||||
|
|
@ -152,13 +166,13 @@ kubectl delete deploy/pingpong
|
|||
|
||||
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.
|
||||
de *pod* directement, car cela reviendrait à utiliser Docker. Nous allons
|
||||
plutôt créer 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
|
||||
kubectl create deployment pingpong --image=alpine -- ping 8.8.8.8
|
||||
```
|
||||
|
||||
Si l'on regarde maintenant la sortie de `kubectl get all`, on obtient :
|
||||
|
|
@ -177,19 +191,21 @@ NAME DESIRED CURRENT READY AGE
|
|||
replicaset.apps/pingpong-98f6d5899 1 1 0 123s
|
||||
```
|
||||
|
||||
Oula, on a vraiment lancé tout ça ?!
|
||||
|
||||
Pas de panique, on peut très facilement le décortiquer :
|
||||
|
||||
Les tâches de déploiements (*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 pods d'une version X à une
|
||||
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.
|
||||
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
|
||||
s'assurer que le nombre de pods actuellement lancé est bien en adéquation avec
|
||||
le nombre de pods attendu.
|
||||
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
|
||||
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.
|
||||
|
||||
Le *replicatset* est là pour indiquer le nombre de *pod*s que l'on désire et
|
||||
s'assurer que le nombre de *pod*s actuellement lancé est bien en adéquation avec
|
||||
le nombre de *pod*s attendu.
|
||||
\
|
||||
|
||||
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*
|
||||
|
|
@ -198,7 +214,7 @@ Pour résumer : `kubectl` a créé une tâche de déploiement
|
|||
|
||||
### Passage à l'échelle : facile ?
|
||||
|
||||
Pour lancer 3 ping en parallèle, modifions la tâche de déploiement comme suit :
|
||||
Pour lancer 3 `ping`s en parallèle, modifions la tâche de déploiement comme suit :
|
||||
|
||||
```bash
|
||||
kubectl scale deploy/pingpong --replicas 3
|
||||
|
|
@ -206,9 +222,10 @@ kubectl scale deploy/pingpong --replicas 3
|
|||
|
||||
À ce stade, comme nous ne modifions que le nombre de replicats, Kubernetes va
|
||||
tout simplement propager ce nombre au *replicatset* existant. Puis, le
|
||||
*replicatset* voyant un décalage entre le nombre de pods attendus et le nombre
|
||||
de pods en cours d'exécution, il va en lancer de nouveaux, afin de répondre à
|
||||
*replicatset* voyant un décalage entre le nombre de *pod*s attendus et le nombre
|
||||
de *pod*s en cours d'exécution, il va en lancer de nouveaux, afin de répondre à
|
||||
la demande.
|
||||
\
|
||||
|
||||
Et que se passe-t-il alors, si l'on tue un *pod* ?
|
||||
|
||||
|
|
@ -216,31 +233,32 @@ Et que se passe-t-il alors, si l'on tue un *pod* ?
|
|||
kubectl delete pod pingpong-yyyy
|
||||
```
|
||||
|
||||
Cela supprime bien un *pod*, mais un autre est relancé instantannément car le
|
||||
Cela supprime bien un *pod*, mais un autre est relancé instantanément car le
|
||||
*replicatset* constate une différence dans le nombre attendu.
|
||||
|
||||
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
|
||||
supprime le *replicatset*, la tâche de déploiement en rećréera un similaire.
|
||||
Si nous voulons arrêter de DDoS Google/Cloudflare, il ne s'agit pas de tuer
|
||||
chacun des *pod*s 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
|
||||
recréera un similaire (avec de nouveaux *pod*s).
|
||||
|
||||
Pour arrêter nos conteneurs, il convient donc de supprimer la tâche de
|
||||
déploiement :
|
||||
|
||||
```bash
|
||||
kubectl delete deploy/pingpong
|
||||
kubectl delete deploy pingpong
|
||||
```
|
||||
|
||||
|
||||
### Exposer son conteneur
|
||||
|
||||
Exposer un conteneur revient à créer un nouveau service (une *resource*
|
||||
service). Un service est une adresse IP que l'on peut considérer comme stable
|
||||
pour un *pod* ou un groupe de *pods*.
|
||||
Exposer un conteneur revient à créer un nouveau service (une ressource
|
||||
*service*). Un service est une adresse IP que l'on peut considérer comme stable
|
||||
pour un *pod* ou un groupe de *pod*s.
|
||||
|
||||
Il est nécessaire de créer un service si l'on veut pouvoir se connecter à un
|
||||
Il est nécessaire de créer un *service* si l'on veut pouvoir se connecter à un
|
||||
*pod*.
|
||||
|
||||
Une fois le service créé, le serveur DNS interne va permettre de résoudre le
|
||||
Une fois le *service* créé, le serveur DNS interne va permettre de résoudre le
|
||||
nom du *pod* depuis les autres conteneurs.
|
||||
|
||||
|
||||
|
|
@ -249,12 +267,12 @@ nom du *pod* depuis les autres conteneurs.
|
|||
Il y a différents types de services :
|
||||
|
||||
- `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 *pod*s et
|
||||
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
|
||||
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.
|
||||
- `LoadBalancer` : lorsque l'infrastructure sous-jacente fourni un
|
||||
- `LoadBalancer` : lorsque l'infrastructure sous-jacente fournit un
|
||||
load-balancer (typiquement AWS, GCE, Azure, ...), un service `NodePort` est
|
||||
créé pour utiliser ce load-balancer externe.
|
||||
- `ExternalName` : une entrée DNS est créée pour avoir un alias.
|
||||
|
|
@ -262,6 +280,8 @@ Il y a différents types de services :
|
|||
|
||||
#### Le retour de `youp0m`
|
||||
|
||||
Déployons maintenant l'image `youp0m` pour voir comment utiliser les *service*s :
|
||||
|
||||
```bash
|
||||
kubectl create deployment youp0m --image=nemunaire/youp0m
|
||||
```
|
||||
|
|
@ -287,7 +307,7 @@ 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
|
||||
docker exec -it kind-control-plane curl 10.102.129.233:8080
|
||||
```
|
||||
|
||||
|
||||
|
|
@ -306,11 +326,15 @@ la configuration nécessaire :
|
|||
kubectl create -f https://virli.nemunai.re/insecure-dashboard.yaml
|
||||
```
|
||||
|
||||
::::: {.warning}
|
||||
|
||||
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
|
||||
|
|
@ -323,7 +347,7 @@ 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
|
||||
$ docker exec -it kind-control-plane curl 10.96.78.69:80
|
||||
<p class="browsehappy">You are using an <strong>outdated</strong> browser.
|
||||
```
|
||||
|
||||
|
|
@ -332,10 +356,10 @@ Pas très sympa... il faudrait que l'on puisse le voir dans un navigateur plus
|
|||
|
||||
É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.
|
||||
`127.0.0.1`. Heureusement, au moment de la création de notre cluster avec
|
||||
`kind`, 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 :
|
||||
|
|
|
|||
BIN
tutorial/k8s/docker-desktop-k8s.png
Normal file
BIN
tutorial/k8s/docker-desktop-k8s.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 14 KiB |
|
|
@ -3,14 +3,16 @@
|
|||
Introduction
|
||||
============
|
||||
|
||||
Notre application du jour
|
||||
-------------------------
|
||||
|
||||
Aujourd'hui, nous allons travailler avec un mineur de pépites ... de chocolat !
|
||||
Alors, on se fait un bon thé, on prend sa boîte de gâteaux pour tenir le coup,
|
||||
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 !-->
|
||||
|
||||
<!--Alors, on se fait un bon thé, on prend sa boîte de gâteaux pour tenir le coup,
|
||||
et c'est parti !-->
|
||||
Comme c'est notre dernier cours ensemble, de véritables cookies sont à
|
||||
gagner pour celles et ceux qui auront amassé le plus de pépites d'ici
|
||||
la fin du TP[^cookies] ! Vous pouvez suivre votre progression sur
|
||||
[cette page](https://virli.nemunai.re/scores.html).
|
||||
|
||||
[^cookies]: Dans la limite des stocks disponibles.
|
||||
|
||||
|
||||
|
||||
|
|
@ -34,7 +36,7 @@ Obtenir l'application
|
|||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
git clone https://gitea.nemunai.re/srs/chocominer.git
|
||||
git clone https://git.nemunai.re/srs/chocominer.git
|
||||
```
|
||||
</div>
|
||||
|
||||
|
|
@ -47,7 +49,7 @@ des conteneurs : un serveur DNS nous permettait de se connecter aux différents
|
|||
services à partir de leurs noms.
|
||||
|
||||
Dans Kubernetes, le même principe s'applique : dans aucun cas, nous ne devrions
|
||||
coder en dur des adresses IP. Il convient d'utiliser au maximum le système de
|
||||
inscrire en dur des adresses IP. Il convient d'utiliser au maximum le système
|
||||
DNS, car les IP sont susceptibles de changer !
|
||||
|
||||
|
||||
|
|
@ -71,13 +73,13 @@ Montée en puissance
|
|||
docker-compose up -d --scale worker=2
|
||||
```
|
||||
|
||||
On remarque que le nombre de hash calculés augmente ! Génial !
|
||||
On remarque que le nombre de hashs calculés augmente ! Génial !
|
||||
|
||||
```bash
|
||||
docker-compose up -d --scale worker=10
|
||||
```
|
||||
|
||||
Mais ça atteint un palier au bout d'un moment ...
|
||||
Mais ça atteint un palier au bout d'un moment...
|
||||
|
||||
|
||||
Identification du goulot d'étranglement
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ Vue d'ensemble de Kubernetes
|
|||
|
||||
*Kubernetes* 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é.
|
||||
spécifications qu'on lui aura demandées.
|
||||
|
||||
Ce projet est l'aboutissement de plus d'une dizaine d'années d'expérience de
|
||||
gestion de conteneurs applicatifs chez Google (rappelons que c'est eux qui ont
|
||||
|
|
@ -13,13 +13,13 @@ poussé de nombreuses technologies dans le noyau Linux, notamment les
|
|||
*cgroups*, ...).
|
||||
|
||||
Dans Kubernetes, il n'est pas question d'indiquer comment lancer ses
|
||||
conteneurs, ni même quels cgroups utiliser. On va fournir à l'orchestrateur des
|
||||
informations, des *spécifications* qui vont altérer l'état du cluster. Et c'est
|
||||
en cherchant à être constamment dans l'état qu'on lui a décrit, qu'il va
|
||||
conteneurs, ni même quels *cgroups* utiliser. On va fournir à l'orchestrateur
|
||||
des informations, des *spécifications*, qui vont altérer l'état du cluster. Et
|
||||
c'est en cherchant à être constamment dans l'état qu'on lui a décrit, qu'il va
|
||||
s'adapter pour répondre aux besoins.
|
||||
|
||||
Par exemple, on ne va pas lui expliquer comment lancer des conteneurs ou
|
||||
récupérer des images ; mais on va lui demander d'avoir 5 conteneurs youp0m
|
||||
récupérer des images ; mais on va lui demander d'avoir 5 conteneurs `youp0m`
|
||||
lancés, de placer ces conteneurs derrière un load-balancer ; on pourra
|
||||
également lui demander d'adapter la charge pour absorber les pics de trafic
|
||||
(par exemple lors du Black Friday sur une boutique), mais également, il pourra
|
||||
|
|
@ -34,7 +34,7 @@ Architecture de Kubernetes
|
|||
Un cluster Kubernetes est composé d'un (ou plusieurs) nœuds *master*, et d'une
|
||||
série de *workers*.
|
||||
|
||||
Sur le master, on retrouve les composants suivants :
|
||||
Sur le(s) *master(s)*, on retrouve les composants suivants :
|
||||
|
||||
API HTTP
|
||||
: On distingue plusieurs API, elles sont toutes utilisées pour communiquer avec
|
||||
|
|
@ -51,16 +51,13 @@ Le contrôleur
|
|||
**`etcd`**
|
||||
: Il s'agit d'une base de données clef/valeur, supportant la
|
||||
haute-disponibilité, que Kubernetes emploie comme système de stockage
|
||||
persistant pour les objets d'API.
|
||||
persistant pour les objets et ses états.
|
||||
\
|
||||
|
||||
|
||||
Chaque nœud[^minion] (généralement, le nœud *master* est également *worker*) est utilisé
|
||||
Chaque nœud (généralement, le nœud *master* est également *worker*) est utilisé
|
||||
via deux composants :
|
||||
|
||||
[^minion]: historiquement, avant de parler de *node*, on parlait de
|
||||
*minion*. Vous êtes susceptibles de rencontrer encore ce terme dans
|
||||
certaines documentations.
|
||||
|
||||
`kubelet`
|
||||
: C'est l'agent qui va se charger de créer les conteneurs et les manager, afin
|
||||
de répondre aux spécifications.
|
||||
|
|
@ -70,6 +67,7 @@ via deux composants :
|
|||
|
||||
Sans oublier le moteur de conteneurs (généralement Docker), 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
|
||||
|
|
@ -85,11 +83,12 @@ 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)
|
||||
suivants :
|
||||
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 physique ou virtuelle, de notre cluster.
|
||||
: 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
|
||||
|
|
@ -128,8 +127,8 @@ compléter ce schéma...
|
|||
|
||||
Chaque plugin implémente la [spécification
|
||||
CNI](https://github.com/containernetworking/cni/blob/master/SPEC.md#network-configuration)
|
||||
(Container Network Interface). On trouve donc autant de plugin qu'il y a de
|
||||
besoins en terme de réseau.
|
||||
(Container Network Interface). On trouve donc autant de plugins qu'il y a de
|
||||
besoins en termes de réseau.
|
||||
|
||||
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
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ 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)
|
||||
Mais n'oubliez pas de répondre au [sondage](https://virli.nemunai.re/quiz/16)
|
||||
pour me permettre d'améliorer ce cours.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ allons devoir :
|
|||
- exposer avec un NodePort l'interface graphique de contrôle.
|
||||
|
||||
|
||||
Lancement des *pods*
|
||||
Lancement des *pod*s
|
||||
--------------------
|
||||
|
||||
### Via Helm
|
||||
|
|
@ -32,7 +32,7 @@ permettant de trouver facilement son bonheur. On va y trouver
|
|||
va avoir besoin pour la suite.
|
||||
|
||||
Mais d'abord, il va nous falloir [installer
|
||||
helm](https://helm.sh/docs/intro/install/). Il utilisera la même configuration
|
||||
Helm](https://helm.sh/docs/intro/install/). Il utilisera la même configuration
|
||||
que `kubectl`, il n'y a rien de plus à configurer.
|
||||
|
||||
Une fois `helm` installé, et le dépôt `influxdata` ajouté, comme précisé dans
|
||||
|
|
@ -40,7 +40,7 @@ la documentation du *chart* d'InfluxDB, nous pouvons le déployer dans notre
|
|||
cluster :
|
||||
|
||||
```bash
|
||||
helm install influxdata/influxdb --generate-name
|
||||
helm install influxdb influxdata/influxdb
|
||||
```
|
||||
|
||||
Les valeurs de configuration indiquées dans le `README` du *chart* se modifient
|
||||
|
|
@ -50,7 +50,7 @@ ainsi :
|
|||
helm upgrade -f values.yml your-influx-name influxdata/influxdb
|
||||
```
|
||||
|
||||
Il vous sera entre-autre nécessaire d'ajouter un administrateur afin de pouvoir
|
||||
Il vous sera entre autres nécessaire d'ajouter un administrateur afin de pouvoir
|
||||
utiliser la base de données.
|
||||
|
||||
Nous pouvons ensuite faire de même avec
|
||||
|
|
@ -61,7 +61,7 @@ mixer avec la méthode ci-dessous (en adaptant certaines valeurs).
|
|||
### Via `kubectl`
|
||||
|
||||
Si vous ne souhaitez pas utiliser `helm`, vous pouvez vous rabattre sur les
|
||||
YAML que l'on a utilisé jusqu'à maintenant, et utiliser `kubectl`. Commençons
|
||||
YAML que l'on a utilisés jusqu'à maintenant, et utiliser `kubectl`. Commençons
|
||||
par lancer `influxdb` :
|
||||
|
||||
```bash
|
||||
|
|
@ -89,7 +89,7 @@ done
|
|||
|
||||
### 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.
|
||||
|
||||
```bash
|
||||
|
|
@ -98,6 +98,9 @@ kubectl expose deployment rng --port 80
|
|||
kubectl expose deployment hasher --port 80
|
||||
```
|
||||
|
||||
Si vous avez utilisé le *chart* Helm d'InfluxDB, Un `ClusterIP` a été
|
||||
automatiquement créé.
|
||||
|
||||
Par contre, notre Chronograf doit être exposé, on lui alloue donc un NodePort :
|
||||
|
||||
```bash
|
||||
|
|
@ -115,9 +118,9 @@ 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`.
|
||||
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
|
||||
Vous n'avez pas la même courbe de progression ? Continuons le TP alors, pour
|
||||
augmenter la puissance de notre *rig* !
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ effet, il nous faut répartir les services entre plusieurs machines.
|
|||
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
|
||||
cluster, le *pod* sera automatiquement lancé dessus. Inversement, lorsqu'un
|
||||
nœud quitte le cluster, le pod est nettoyé.
|
||||
nœud quitte le cluster, le *pod* est nettoyé.
|
||||
|
||||
On s'en sert principalement pour exécuter une instance de daemon de stockage
|
||||
(tel que Ceph, `glusterd`, ...) ou pour la collecte de logs (`fluentd`,
|
||||
|
|
@ -90,7 +90,7 @@ documentation](https://kubernetes.io/docs/concepts/workloads/controllers/daemons
|
|||
|
||||
#### *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 :
|
||||
|
||||
```bash
|
||||
|
|
@ -123,8 +123,8 @@ kubectl apply -f rng.yml --validate=false
|
|||
|
||||
#### Trop de *pods* `rng` {-}
|
||||
|
||||
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
|
||||
Après avoir appliqué la nouvelle spec, on constate qu'il y a beaucoup de *pod*s
|
||||
`rng`. En effet, l'ancien *pod* déployé avec la ressource *deployment* est
|
||||
toujours là.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -4,10 +4,10 @@ Mise en place
|
|||
=============
|
||||
|
||||
La mise en place d'un cluster Kubernetes ([prononcé
|
||||
Ku-ber-né-tèce](https://github.com/kubernetes/kubernetes/issues/44308) en grec
|
||||
ancien) 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é sereinement.
|
||||
Ku-ber-né-tice](https://github.com/kubernetes/kubernetes/issues/44308) en grec)
|
||||
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é 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
|
||||
|
|
@ -15,9 +15,9 @@ 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
|
||||
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 leur cluster à une autre entreprise, dont c'est la cœur de
|
||||
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'Azur ([Kubernetes
|
||||
Service](https://azure.microsoft.com/fr-fr/services/kubernetes-service/)) ou
|
||||
|
|
@ -25,18 +25,54 @@ 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/), ...).
|
||||
|
||||
::::: {.more}
|
||||
|
||||
Pour jouer aujourd'hui, deux solutions s'offrent à nous pour commencer à
|
||||
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]: https://k3s.io/
|
||||
|
||||
Pour jouer aujourd'hui, plusieurs 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`.
|
||||
- [Docker Desktop (for Mac ou for Windows) :](#dockerdesktop) si vous êtes sur l'un de ces
|
||||
systèmes c'est la solution la plus simple,
|
||||
- [Kubernetes in Docker (kind) :](#kind) pour tenter l'aventure sur votre machine,
|
||||
- [Play With Kubernetes :](#pwk) si vous ne vous en sortez pas avec `kind`.
|
||||
|
||||
\newpage
|
||||
|
||||
Docker for Mac/Windows {#dockerdesktop}
|
||||
----------------------
|
||||
|
||||
*Docker Desktop* pour Mac ou pour Windows intégre Kubernetes directement. Il
|
||||
n'est pas activé par défaut, pour cela il convient d'activer l'option dans les
|
||||
préférences de l'application :
|
||||
|
||||
|
||||
|
||||
Une fois l'option activée, vous pouvez passer au chapitre suivant, la commande
|
||||
`kubectl` devrait marcher directement pour vous. C'est principalement grâce à
|
||||
cette commande que nous interagirons avec l'API de Kubernetes.
|
||||
|
||||
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", GitCommit:"8b5a19147530eaac9476b0ab82980b4088bbc1b2", GitTreeState:"archive", BuildDate:"2021-11-18T15:50:50Z", GoVersion:"go1.17.2", Compiler:"gc", Platform:"linux/amd64"}
|
||||
Server Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.5+k3s2", GitCommit:"724ef700bab896ff252a75e2be996d5f4ff1b842", GitTreeState:"clean", BuildDate:"2021-10-05T19:59:14Z", GoVersion:"go1.16.8", Compiler:"gc", Platform:"linux/amd64"}
|
||||
```
|
||||
</div>
|
||||
|
||||
|
||||
Kubernetes in Docker (kind)
|
||||
Kubernetes in Docker (kind) {#kind}
|
||||
---------------------------
|
||||
|
||||
`kind` est un projet permettant de lancer un cluster kubernetes directement via
|
||||
`kind` est un projet permettant de lancer un cluster Kubernetes directement via
|
||||
Docker.
|
||||
|
||||
Pour commencer, il nous faudra télécharger le binaire (go, donc statique)
|
||||
|
|
@ -44,15 +80,28 @@ suivant (il existe pour Linux, macOS et Windows) :
|
|||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
curl -Lo kind https://github.com/kubernetes-sigs/kind/releases/download/v0.9.0/kind-$(uname)-amd64
|
||||
curl -Lo kind https://github.com/kubernetes-sigs/kind/releases/download/v0.11.1/kind-$(uname)-amd64
|
||||
chmod +x kind
|
||||
```
|
||||
</div>
|
||||
|
||||
Placez-le dans un endroit où il sera accessible de votre `$PATH`.
|
||||
Placez le binaire dans un endroit où il sera accessible de votre `$PATH`.
|
||||
|
||||
::::: {.question}
|
||||
|
||||
`uname` est à remplacer par votre système d'exploitation : `darwin` (macOS), `linux`, `windows`.
|
||||
|
||||
Il existe également pour d'autres architectures, consultez la [page des
|
||||
versions](https://github.com/kubernetes-sigs/kind/releases/latest) pour voir
|
||||
les différents binaires existants.
|
||||
|
||||
:::::
|
||||
|
||||
|
||||
Notre prochaine étape est de décrire le cluster que l'on souhaite avoir : 1
|
||||
master et 2 workers. Avant de lancer leur création.
|
||||
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.
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
|
|
@ -81,12 +130,12 @@ Profitons-en pour télécharger `kubectl` :
|
|||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
curl -LO https://storage.googleapis.com/kubernetes-release/release/v1.19.4/bin/linux/amd64/kubectl
|
||||
curl -LO https://storage.googleapis.com/kubernetes-release/release/v1.22.2/bin/linux/amd64/kubectl
|
||||
chmod +x kubectl
|
||||
```
|
||||
</div>
|
||||
|
||||
C'est via cette commande que nous interagirons principalement avec l'API de
|
||||
C'est principalement grâce à cette commande que nous interagirons avec l'API de
|
||||
Kubernetes.
|
||||
|
||||
Une fois que tout sera opérationnel, nous devrions obtenir :
|
||||
|
|
@ -94,19 +143,26 @@ Une fois que tout sera opérationnel, nous devrions obtenir :
|
|||
<div lang="en-US">
|
||||
```
|
||||
42sh$ kubectl version
|
||||
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:"19", GitVersion:"v1.19.1", GitCommit:"206bcadf021e76c27513500ca24182692aabd17e", GitTreeState:"clean", BuildDate:"2020-09-14T07:30:52Z", GoVersion:"go1.15", Compiler:"gc", Platform:"linux/amd64"}
|
||||
Client Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.2", GitCommit:"8b5a19147530eaac9476b0ab82980b4088bbc1b2", GitTreeState:"archive", BuildDate:"2021-11-18T15:50:50Z", GoVersion:"go1.17.2", Compiler:"gc", Platform:"linux/amd64"}
|
||||
Server Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.5+k3s2", GitCommit:"724ef700bab896ff252a75e2be996d5f4ff1b842", GitTreeState:"clean", BuildDate:"2021-10-05T19:59:14Z", GoVersion:"go1.16.8", Compiler:"gc", Platform:"linux/amd64"}
|
||||
```
|
||||
</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`.
|
||||
Passez ensuite au chapitre suivant si vous avez réussi à mettre en place `kind`.
|
||||
|
||||
Play With Kubernetes
|
||||
Play With Kubernetes {#pwk}
|
||||
--------------------
|
||||
|
||||
::::: {.warning}
|
||||
|
||||
Cette section vous concerne uniquement si vous n'avez pas réussi à créer de
|
||||
cluster Kubernetes selon les autres méthodes décrites.
|
||||
|
||||
:::::
|
||||
|
||||
De la même manière que pour les TP 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 à
|
||||
|
|
@ -126,7 +182,7 @@ kubeadm init --apiserver-advertise-address $(hostname -i)
|
|||
```
|
||||
</div>
|
||||
|
||||
Cette action peut prendre quelques minutes, et devrait se finir, si tout se
|
||||
Cette action peut prendre quelques minutes et devrait se finir, si tout se
|
||||
passe bien, par :
|
||||
|
||||
<div lang="en-US">
|
||||
|
|
@ -166,15 +222,27 @@ kubectl apply -n kube-system -f \
|
|||
</div>
|
||||
|
||||
|
||||
Minikube, Docker for Mac/Windows, MicroK8s, ...
|
||||
-----------------------------------------------
|
||||
Minikube, k3d, MicroK8s, ...
|
||||
----------------------------
|
||||
|
||||
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
|
||||
complet, facilement.
|
||||
complet facilement.
|
||||
|
||||
Vous pouvez tenter d'utiliser
|
||||
[k3d](https://k3d.io/),
|
||||
[minikube](https://kubernetes.io/docs/setup/learning-environment/minikube/),
|
||||
[microk8s](https://microk8s.io/), ... Notez également que *Docker for Mac* et
|
||||
*Docker for Windows* intègrent aussi Kubernetes depuis quelques versions ;
|
||||
il convient de l'activer dans les préférences de l'application.
|
||||
[microk8s](https://microk8s.io/), ...
|
||||
|
||||
##### `k3d` {-}
|
||||
|
||||
est un script similaire à `kind`, mais utilise `k3s`, une version plus légère
|
||||
et compacte de Kubernetes.
|
||||
|
||||
Après l'avoir installé, vous pouvez lancer
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
k3d cluster create mycluster --agents 2 --kubeconfig-switch-context
|
||||
```
|
||||
</div>
|
||||
|
|
|
|||
|
|
@ -3,13 +3,13 @@ title: Ελαφριά εικονικοποίηση -- Πρακτική δουλ
|
|||
subtitle: κυβερνήτης
|
||||
author: Πιέρ-Ολιβιέ *νεμυναιρε* [ῥαφοπώλης]{.smallcaps}
|
||||
institute: ΣΠκΠΤ
|
||||
date: Πέμπτη 19 Νοεμβρίου 2021
|
||||
date: Παρασκευή 19 Νοεμβρίου 2021
|
||||
abstract: |
|
||||
Ο στόχος αυτού του τελευταίου εργαστηρίου είναι να κατανοήσει το κυβερνήτης και την ενορχήστρωση εμπορευματοκιβωτίων.
|
||||
|
||||
\vspace{1em}
|
||||
|
||||
Οι ασκήσεις για αυτό το πρακτικό έργο μπορούν να επιστραφούν στη διεύθυνση <ανδροππήςρε@nemunai.re> το αργότερο την Πέμπτη 26 Νοεμβρίου 2021 στις 11:42 μ.μ., οι ερωτήσεις των μαθημάτων πρέπει επίσης να ολοκληρωθούν πριν από αυτήν την ημερομηνία. Δείτε το τελευταίο μέρος αυτού του εργαστηρίου για λεπτομέρειες.
|
||||
Οι ασκήσεις για αυτό το πρακτικό έργο μπορούν να επιστραφούν στη διεύθυνση <ανδροππήςρε@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/).
|
||||
...
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: Virtualisation légère -- TP n^o^ 6
|
|||
subtitle: Kubernetes
|
||||
author: Pierre-Olivier *nemunaire* [Mercier]{.smallcaps}
|
||||
institute: EPITA
|
||||
date: Jeudi 19 novembre 2021
|
||||
date: Vendredi 19 novembre 2021
|
||||
abstract: |
|
||||
Le but de ce dernier TP est d'appréhender Kubernetes et l'orchestration de
|
||||
conteneurs.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue