312 lines
8.8 KiB
Markdown
312 lines
8.8 KiB
Markdown
\newpage
|
|
|
|
Découverte de `kubectl`
|
|
=======================
|
|
|
|
`kubectl`
|
|
([prononcé](https://www.reddit.com/r/kubernetes/comments/5qthoc/how_should_i_pronounce_kubectl/)
|
|
'cube C T L', 'cube cuttle', 'kyoob cuddle', 'cube control', ...) est le principal
|
|
programme que l'on utilise pour interagir avec notre cluster.
|
|
|
|
Étant donné qu'il s'agit d'un programme client, qui ne fait rien de plus que
|
|
discuter avec une API REST HTTP, on peut le considérer comme un gros wrapper au
|
|
dessus de `curl`.
|
|
|
|
Obtenir de l'aide
|
|
-----------------
|
|
|
|
```bash
|
|
kubectl describe type/name
|
|
kubectl describe type name
|
|
kubectl explain type
|
|
```
|
|
|
|
|
|
`get`
|
|
-----
|
|
|
|
```bash
|
|
kubectl get node
|
|
```
|
|
|
|
Plus d'infos :
|
|
|
|
```bash
|
|
kubectl get nodes -o wide
|
|
```
|
|
|
|
Lisible par une machine :
|
|
|
|
```bash
|
|
kubectl get no -o yaml
|
|
kubectl get no -o json
|
|
```
|
|
|
|
On aimera utiliser `jq(1)` avec la sortie `-o json` :
|
|
|
|
```bash
|
|
kubectl get no -o json | \
|
|
jq ".items[] | {name:.metadata.name} + .status.capacity"
|
|
```
|
|
|
|
### Services
|
|
|
|
```bash
|
|
kubectl get services
|
|
kubectl get svc
|
|
```
|
|
|
|
Pour le moment, nous n'avons qu'un seul service, il s'agit de l'API Kubernetes.
|
|
|
|
`ClusterIP` désigne l'IP d'un service accessible en interne, pour le cluster.
|
|
|
|
|
|
### Conteneurs actifs
|
|
|
|
Jetons un œil aux conteneurs actifs :
|
|
|
|
```bash
|
|
kubectl get pods
|
|
```
|
|
|
|
Regardons maintenant les `namespaces` :
|
|
|
|
```bash
|
|
kubectl get namespaces
|
|
```
|
|
|
|
On l'a vu, les *namespaces* ici désignent des espaces de noms qui n'ont rien à
|
|
voir avec les *namespaces* de Linux. Regardons par exemple les conteneurs d'un
|
|
autre espace de noms :
|
|
|
|
```bash
|
|
kubectl -n kube-system get pods
|
|
```
|
|
|
|
Eh oui ! De nombreux services de base pour Kubernetes tournent dans des
|
|
conteneurs, géré par lui-même... notamment :
|
|
|
|
- `etcd` : notre base de données clef/valeur,
|
|
- `kube-apiserver` : l'API REST avec qui communique `kubectl`,
|
|
- `kube-controller-manager` et `kube-scheduler`, deux autres composants
|
|
indispensables,
|
|
- `coredns` : un composant additionnel pour gérer la résolution de noms interne
|
|
(pour 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.
|
|
|
|
|
|
Mon premier conteneur
|
|
---------------------
|
|
|
|
Prêt à lancer notre premier conteneur ?!
|
|
|
|
Pas si vite ! En fait ... Kubernetes ne permet pas de lancer de conteneur...
|
|
Nous devons lancer un *pod* (qui ne contiendra qu'un seul conteneur).
|
|
|
|
### Mon premier pod
|
|
|
|
```bash
|
|
kubectl run pingpong --image alpine ping 1.1.1.1
|
|
```
|
|
|
|
Outre un avertissement, `kubectl` doit indiquer nous qu'une tâche de
|
|
déploiement a été créée.
|
|
|
|
Si l'on affiche la liste des pods, vous devriez avoir quelque chose qui
|
|
ressemble à cela :
|
|
|
|
```
|
|
$ kubectl get pods
|
|
NAME READY STATUS RESTARTS AGE
|
|
pingpong-7d49d9bc9-k8fpg 1/1 Running 0 123s
|
|
```
|
|
|
|
#### Déploiement³
|
|
|
|
Si l'on affiche davantage d'informations, on obtient :
|
|
|
|
```
|
|
$ kubectl get all
|
|
NAME READY STATUS RESTARTS AGE
|
|
pod/pingpong-7d49d9bc9-k8fpg 1/1 Running 0 123s
|
|
|
|
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
|
service/kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 2m3s
|
|
|
|
NAME READY UP-TO-DATE AVAILABLE AGE
|
|
deployment.apps/pingpong 1/1 1 1 123s
|
|
|
|
NAME DESIRED CURRENT READY AGE
|
|
replicaset.apps/pingpong-7d49d9bc9 1 1 1 123s
|
|
```
|
|
|
|
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 :
|
|
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'assure que le nombre de pods actuellement lancé est bien en adéquation avec
|
|
le nombre de pods attendus.
|
|
|
|
|
|
Pour résumer : `kubectl run` a créé une tâche de déploiement
|
|
`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`.
|
|
|
|
|
|
#### Sortie d'un conteneur
|
|
|
|
Bref ... 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 deploy/pingpong
|
|
```
|
|
|
|
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
|
|
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 à
|
|
la demande.
|
|
|
|
Et que se passe-t-il alors, si l'on tue un pod ?
|
|
|
|
```bash
|
|
kubectl delete pod pingpong-yyyy
|
|
```
|
|
|
|
|
|
#### Autres usages de `run`
|
|
|
|
Si l'on veut des tâche qui ne redémarrent pas systématiquement, on peut
|
|
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
|
|
déploiement :
|
|
|
|
```bash
|
|
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*.
|
|
|
|
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
|
|
nom du *pod* depuis les autres conteneurs.
|
|
|
|
|
|
#### Types de services
|
|
|
|
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
|
|
les nœuds). Il n'y a pas de translation de port a 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
|
|
aléatoirement.
|
|
- `LoadBalancer` : lorsque l'infrastructure sous-jacente fourni un
|
|
load-balancer (typiquement AWS, GCE, Azure, ...), un service `NodePort` est
|
|
créé pour utiiser ce load-balancer externe.
|
|
- `ExternalName` : une entrée DNS est créée pour avoir un alias.
|
|
|
|
|
|
#### Le retour de `youp0m`
|
|
|
|
```bash
|
|
kubectl create deployment youp0m --image=nemunaire/youp0m
|
|
```
|
|
|
|
Commençons par créer un service `ClusterIP` :
|
|
|
|
```bash
|
|
kubectl expose deployment youp0m --port 8080
|
|
```
|
|
|
|
Ce qui donne :
|
|
|
|
```
|
|
$ kubectl get service
|
|
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
|
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
|
|
essaie avec plusieurs nœuds, on voit alors que les requêtes sont balancées sur
|
|
différents nœuds.
|