virli/tutorial/k8s/run.md
2021-09-11 14:41:48 +02:00

4.2 KiB

\newpage

Cookies dans Kube

Maintenant que nous en savons un peu plus sur Kubernetes, nous allons commencer à déployer notre application ChocoMiner dans notre cluster. Pour cela, nous allons devoir :

  • lancer des déploiements de ces images ;
  • exposer avec un ClusterIP les services qui ont besoin de communiquer entre-eux ;
  • exposer avec un NodePort l'interface graphique de contrôle.

Lancement des pods

Via Helm

Helm est l'équivalent d'un gestionnaire de paquets, mais 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 est une agrégation de différents dépôts, permettant de trouver facilement son bonheur. On va y trouver influxdb dont on va avoir besoin pour la suite.

Mais d'abord, il va nous falloir installer helm. 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 la documentation du chart d'InfluxDB, nous pouvons le déployer dans notre cluster :

helm install influxdata/influxdb --generate-name

Les valeurs de configuration indiquées dans le README du chart se modifient 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 utiliser la base de données.

Nous pouvons ensuite faire de même avec Chronograf ou 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 par lancer influxdb :

kubectl apply -f https://virli.nemunai.re/influxdb.yaml

Pour chronograf, la commande suivante fonctionnerait, mais prenons exemple sur le fichier YAML d'InfluxDB pour Chronograf :

kubectl create deployment chronograf --image=chronograf -- chronograf \
    --influxdb-url=http://influxdb:8086 \
    --influxdb-username=chronograf \
    --influxdb-password=eBoo8geingie8ziejeeg8bein6Yai1a

Notre application

TAG=0.1
for SERVICE in hasher rng worker; do
  kubectl create deployment $SERVICE --image=nemunaire/$SERVICE:$TAG
done

Exposer les ports

Pour trois des applications, des ClusterIP font l'affaire, car ils n'ont pas besoin d'être exposés en dehors du cluster.

kubectl expose deployment influxdb --port 8086
kubectl expose deployment rng --port 80
kubectl expose deployment hasher --port 80

Par contre, notre Chronograf doit être exposé, on lui alloue donc un NodePort :

kubectl create service nodeport chronograf --tcp=8888 --node-port=30001

À 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.

Montée en charge progressive dans Chronograph

Vous n'avez pas la même courbe de progression ? continuons le TP alors, pour augmenter la puissance de notre rig !