Aller au contenu

Mes premières commandes

Pour se familiariser avec k8s, nous allons lancer les commandes de base (instructions impératives).

Namespace

Les espaces de nom permettent de gérer simplement des groupes d'utilisateurs et les applications multiples sur un cluster.

Remarque

Il est utile de déployer une application par namespace. Cela ne vise pas à renforcer la sécurité, mais à améliorer le côté opérationnel.

Pour afficher les espaces de nom :

k get ns

Pour afficher les ressources dans l'espace de nom de l'utilisateur (default par défaut) et de tout le système (kube-system) :

k get all &&\
k get all -A

Pour changer d'espace de nom, créer un nouvel espace tuto :

k create ns tuto &&\
k get ns

Puis passer à ce nouvel espace avec kubens :

kubens tuto &&\
kubens -c

Mon premier pod

Les pods sont des collections de conteneurs. Ils peuvent être interactifs ou détachés comme les ceux-ci. Les pods sont éphémères et peuvent être recréés à tout moment, il ne faut donc pas les modifier à la volée.

Pour exécuter un pod avec une image de base Ubuntu en mode interactif :

k run --rm --restart=Never -i -t --image ubuntu test /bin/bash

Dans un autre terminal, effectuer les commandes suivantes :

  • pour suivre de manière interactive les statuts du pod :

    k get pods -w

  • Pour accéder aux informations du pod (métadonnées, status, évènements...) :

    k describe pod test

  • Pour accèder au log complet du pod :

    k logs test

Comme pour les conteneurs, il est possible de créer une session interactive dans un pod en cours d'éxecution :

k exec -it test -- /bin/bash

Les labels sont utiles pour retrouver toutes les ressources d'une application spécifique :

k get pods -l run=test

Mon deuxième pod

Nous allons créer un pod comme précédemment, mais avec l'image jupyter de base qui est une application web sans état ("serverless"). Nous devons aussi configurer des accès réseaux afin de pouvoir accéder à l'interface du Jupyter Lab. Pour cela, nous allons donc faire appel aux services.

Création d'un pod

Exercice

Comme pour le premier pod, lancer un pod avec l'image jupyter de base et récupérer le token dans le log.

Solution 
k run --restart=Never --image jupyter/base-notebook test-jupyter

Le statut du pod doit évoluer :

k get pods -w
NAME           READY   STATUS              RESTARTS   AGE
test-jupyter   0/1     ContainerCreating   0          18s
test-jupyter   1/1     Running             0          30s

Puis quand l'image a été pullée dans le registre du cluster et que le conteneur fonctionne, il est possible d'afficher le log :

k logs pod/test-jupyter

Il est aussi possible d'afficher le log des pods avec Stern :

stern test-jupyter

Création d'un service

Les services permettent d'exposer et de connecter les pods ou les déploiements (que nous verrons après). Ce sont des points d’accès stables et persistants.

Après avoir créé un pod Jupyter, il reste à créer un service de type NodePort pour exposer l'application du pod.

Remarque

NodePort expose un pod sous la forme d'un port statique (dans le domaine 30000-32767) sur chaque IP des noeuds. C'est un service très basique, associé au namespace et seulement utile pour du test mais c'est méthode la plus simple pour acceder à un pod depuis l'exterieur du cluster. Dans le cas d'un cluster local k3d, il est aussi possible d'utiliser un service de type ClusterIP pour faires de tests. En production, ClusterIP est accessible uniquement à l’intérieur du cluster via une adresse IP interne. Le troisième type de service est le LoadBalancer utilisé principalement dans les environnements cloud.

**NodePort** @k8s

Pour cela, il faut préciser le port de Jupyter que nous souhaitons exporter :

k expose pod test-jupyter --type=NodePort --port=8888

Et vérifier que toutes les ressources sont prètes :

$ k get all
NAME               READY   STATUS    RESTARTS   AGE
pod/test-jupyter   1/1     Running   0          1m

NAME                   TYPE       CLUSTER-IP     EXTERNAL-IP   PORT(S)          AGE
service/test-jupyter   NodePort   10.43.70.78   <none>        8888:30254/TCP   5s

Remarque

CLUSTER-IP est une IP virtuelle interne du service et ne peut donc pas être utilisée pour accéder à l'interface web.

S'il y a un problème avec le service, il est possible d'afficher ses informations comme pour les pods :

k describe service test-jupyter

Connection au réseau

Chaque pod possède sa propre adresse IP et peut communiquer directement avec les autres pods sans NAT (modèle de réseau plat). Mais quand nous souhaitons accéder aux services web d'un pod, quelques étapes supplémentaires sont necessaires.

Il est possible de forwarder le port du pod pour le connecter au réseau local :

k port-forward service/test-jupyter 8888:8888

Forwarding from 127.0.0.1:8888 -> 8888
Forwarding from [::1]:8888 -> 8888

Puis :

open http://0.0.0.0:8888/

Nous verrons par la suite qu'il y a différents moyens d'accéder au réseau du pod.

Relache des ressources

Pour libérer les ressources :

k delete all --all

Sinon, le moyen le plus propre est de détruire le namespace et le recréer :

k delete ns tuto

Debug

En cas de problème, il faut regarder :

  1. les métadonnées du pod
  2. le log du pod

Sinon suivre le chartflow suivant pour résoudre les problèmes de déploiement.

troubleshooting-deployments

Authors: Cécile Cavet