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 :
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue