virli/tutorial/k8s/run.md

127 lines
4.2 KiB
Markdown
Raw Normal View History

2019-11-26 15:00:39 +00:00
\newpage
Cookies dans Kube
=================
Maintenant que nous en savons un peu plus sur Kubernetes, nous allons commencer
2019-11-27 12:11:20 +00:00
à déployer notre application ChocoMiner dans notre cluster. Pour cela, nous
2019-11-26 15:00:39 +00:00
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.
2021-11-19 23:00:30 +00:00
Lancement des *pod*s
2021-09-11 12:41:43 +00:00
--------------------
2019-11-26 15:00:39 +00:00
2021-09-11 12:41:43 +00:00
### Via Helm
2019-11-26 15:00:39 +00:00
2021-09-11 12:41:43 +00:00
[Helm](https://helm.sh/) 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.
2019-11-26 15:00:39 +00:00
2021-09-11 12:41:43 +00:00
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](https://artifacthub.io/) est une agrégation de différents dépôts,
permettant de trouver facilement son bonheur. On va y trouver
[`influxdb`](https://artifacthub.io/packages/helm/influxdata/influxdb) dont on
va avoir besoin pour la suite.
2019-11-26 15:00:39 +00:00
2021-09-11 12:41:43 +00:00
Mais d'abord, il va nous falloir [installer
2021-11-19 23:00:30 +00:00
Helm](https://helm.sh/docs/intro/install/). Il utilisera la même configuration
2021-09-11 12:41:43 +00:00
que `kubectl`, il n'y a rien de plus à configurer.
2019-11-26 15:00:39 +00:00
2021-09-11 12:41:43 +00:00
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 :
2019-11-26 15:00:39 +00:00
```bash
2021-11-19 23:00:30 +00:00
helm install influxdb influxdata/influxdb
2019-11-26 15:00:39 +00:00
```
2021-09-11 12:41:43 +00:00
Les valeurs de configuration indiquées dans le `README` du *chart* se modifient
ainsi :
2019-11-26 15:00:39 +00:00
```bash
2021-09-11 12:41:43 +00:00
helm upgrade -f values.yml your-influx-name influxdata/influxdb
2019-11-26 15:00:39 +00:00
```
2021-11-19 23:00:30 +00:00
Il vous sera entre autres nécessaire d'ajouter un administrateur afin de pouvoir
2021-09-11 12:41:43 +00:00
utiliser la base de données.
2019-11-26 15:00:39 +00:00
2021-09-11 12:41:43 +00:00
Nous pouvons ensuite faire de même avec
[Chronograf](https://artifacthub.io/packages/helm/influxdata/chronograf) ou
mixer avec la méthode ci-dessous (en adaptant certaines valeurs).
2019-11-26 15:00:39 +00:00
2021-09-11 12:41:43 +00:00
### Via `kubectl`
2019-11-26 15:00:39 +00:00
2021-09-11 12:41:43 +00:00
Si vous ne souhaitez pas utiliser `helm`, vous pouvez vous rabattre sur les
2021-11-19 23:00:30 +00:00
YAML que l'on a utilisés jusqu'à maintenant, et utiliser `kubectl`. Commençons
2021-09-11 12:41:43 +00:00
par lancer `influxdb` :
2019-11-26 15:00:39 +00:00
2021-09-11 12:41:43 +00:00
```bash
kubectl apply -f https://virli.nemunai.re/influxdb.yaml
```
2019-11-26 15:00:39 +00:00
2021-09-11 12:41:43 +00:00
Pour chronograf, la commande suivante fonctionnerait, mais prenons exemple sur
le fichier YAML d'InfluxDB pour Chronograf :
2019-11-26 15:00:39 +00:00
```bash
2021-09-11 12:41:43 +00:00
kubectl create deployment chronograf --image=chronograf -- chronograf \
--influxdb-url=http://influxdb:8086 \
--influxdb-username=chronograf \
--influxdb-password=eBoo8geingie8ziejeeg8bein6Yai1a
2019-11-26 15:00:39 +00:00
```
2021-09-11 12:41:43 +00:00
### Notre application
2019-11-26 15:00:39 +00:00
```bash
2021-09-11 12:41:43 +00:00
TAG=0.1
2019-11-26 15:00:39 +00:00
for SERVICE in hasher rng worker; do
kubectl create deployment $SERVICE --image=nemunaire/$SERVICE:$TAG
done
```
2021-09-11 12:41:43 +00:00
### Exposer les ports
2019-11-26 15:00:39 +00:00
2021-11-19 23:00:30 +00:00
Pour trois des applications, des `ClusterIP` font l'affaire, car ils n'ont pas
2019-11-26 17:20:26 +00:00
besoin d'être exposés en dehors du cluster.
2019-11-26 15:00:39 +00:00
```bash
2020-09-14 13:46:13 +00:00
kubectl expose deployment influxdb --port 8086
2019-11-26 15:00:39 +00:00
kubectl expose deployment rng --port 80
kubectl expose deployment hasher --port 80
```
2021-11-19 23:00:30 +00:00
Si vous avez utilisé le *chart* Helm d'InfluxDB, Un `ClusterIP` a été
automatiquement créé.
2019-11-26 17:20:26 +00:00
Par contre, notre Chronograf doit être exposé, on lui alloue donc un NodePort :
2019-11-26 15:00:39 +00:00
```bash
kubectl create service nodeport chronograf --tcp=8888 --node-port=30001
```
2019-11-26 17:20:26 +00:00
À ce stade, nous devrions pouvoir accéder à l'interface de Chronograf !
2021-09-11 12:41:43 +00:00
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
2021-11-19 23:00:30 +00:00
compter (`count`) le nombre d'éléments dans la table `chunks`.
2021-09-11 12:41:43 +00:00
![Montée en charge progressive dans Chronograph](nuggets-graph.png)
2021-11-19 23:00:30 +00:00
Vous n'avez pas la même courbe de progression ? Continuons le TP alors, pour
2021-09-11 12:41:43 +00:00
augmenter la puissance de notre *rig* !