4.3 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 influxdb influxdata/influxdb
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 autres 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és 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
Si vous avez utilisé le chart Helm d'InfluxDB, Un ClusterIP
a été
automatiquement créé.
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 la partie
Explore, puis 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 summ
, 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
.
Vous n'avez pas la même courbe de progression ? Alors continuons pour augmenter la puissance de notre rig !