Kontena Pharos 2.4, Kontena Network Loadbalancer / Universal Loadbalancer, Kontena Lens et Kontena Storage en action dans des instances Bare Metal de Scaleway …

Image for post
Image for post

Kontena Pharos 2.4 a été annoncé avec des nouvelles fonctionnalités et une indépendance de la brique Kontena Lens en plus de la mise en oeuvre de la version 1.14.3 de Kubernetes :

Image for post
Image for post

Comme précédemment, je lance trois instances Bare Metal chez Scaleway de type ici C2L avec Ubuntu 18.04 LTS (dans la région d’Amsterdam) :

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

Pour déployer mon cluster Kubernetes, je vais donc utiliser cette nouvelle version de Kontena Pharos. On peut avoir accès au choix à la version communautaire sur github :

Image for post
Image for post
Image for post
Image for post

ou Pro :

Image for post
Image for post

Kontena Pharos OSS est la version de base et contient toutes les fonctionnalités essentielles pour profiter pleinement de Kubernetes à n’importe quelle échelle, sur n’importe quelle infrastructure. Il est 100% open source sous licence Apache 2. Vous pouvez l’utiliser gratuitement, pour n’importe quel usage.

Kontena Pharos PRO est basé sur Kontena Pharos OSS, mais possède plus de fonctionnalités et des fonctionnalités avancées. Il est commercial, mais vous pouvez l’évaluer gratuitement, tant que vous en avez besoin !

Je commence par préparer mon fichier de configuration cluster.yml qui contient un certain nombre d’add-ons pris en charge par la version PRO de Kontena :

Image for post
Image for post
cluster.yml

Au préalable j’ai appliqué ce script pour cloud-init au niveau de ces instances :

#!/bin/shapt install sudo iputils-ping -yecho "root ALL=(ALL) NOPASSWD: ALL" | tee /etc/sudoers.d/rootyes | mkfs.ext4 /dev/sdamkdir -p /var/lib/dockerfs_uuid=$(blkid -o value -s UUID /dev/sda)echo "UUID=$fs_uuid /var/lib/docker ext4 defaults 0 0" >> /etc/fstab mount -a
curl -s https://install.zerotier.com/ | bash
zerotier-cli join <YOUR NETWORK-ID>

Je dispose en effet d’un second disque de 250 Go sur ces instances (notamment à destination de Kontena Storage) :

Image for post
Image for post

Ces instances sont ajoutées à ZeroTier (P2P VPN) sur un subnet privé où le mode Ethernet Bridging est activé (pour Kontena Network Load Balancer):

Image for post
Image for post
Image for post
Image for post

et je lance le tout :

$ pharos up -c cluster.yml
Image for post
Image for post

Le cluster Kubernetes est alors disponible :

Image for post
Image for post

Je dispose de l’accès au dashboard de Kontena Lens :

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

J’ai déployé ici Kontena Storage qui reprend Rook (Ceph) dans le cluster ainsi qu’un dashboard associé. Pour rendre accessible ce dernier, je modifie le manifest de son service (pour le mettre en type Load Balancer via Kontena Netwok Balancer qui reprend MetalLB) :

Image for post
Image for post

Une adresse du pool du réseau privé de ZeroTier est attribuée de manière automatique par Kontena Network Load Balancer :

Image for post
Image for post

Permettant l’accès au dashboard. Le mot de passe associé à admin est récupéré ainsi :

$ kubectl -n kontena-storage get secret rook-ceph-dashboard-password -o jsonpath="{['data']['password']}" | base64 --decode && echo
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

Je peux également utiliser la ligne de commande pour connaître l’état de santé du cluster Ceph :

Image for post
Image for post

Kontena Lens offre la possibilité d’accéder à un catalogue de Charts pour y installer des applications dans le cluster Kubernetes :

Image for post
Image for post

Je modifie les paramêtres du Chart pour Weave Scope depuis un terminal de Kontena Lens en mettant un service de type Load Balancer encore une fois :

Image for post
Image for post

et déploiement :

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

J’ai accès au visualiseur via Weave Scope déployé dans le cluster :

Image for post
Image for post
Image for post
Image for post

Rook offre la possibilité (comme OpenEBS) de déployer par exemple Minio. J’ai déployé ici Minio en mode distribué dans le cluster :

Image for post
Image for post
Image for post
Image for post

Je reprend les sources de mon chatbot FC pour le déployer en statique au sein d’un bucket dans Minio :

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
https://cdn-images-1.medium.com/max/1600/1*MFQGurn3NsytA1WKA_P8Zw.jpeg

Le Chatbot est accessible via l’URL retournée par Argo Tunnel :

Image for post
Image for post
Image for post
Image for post

aux performances correctes :

Image for post
Image for post
Image for post
Image for post

Un autre test de “GitOps” via Flagger et Istio dans ce cluster. Je pars des sources offert via ce dépôt Github :

selon cette cinématique :

Image for post
Image for post

Isitio, Weave Flux, Flagger, Prometheus et Helm sont chargés dans le cluster :

kubectl -n kube-system create sa tiller

kubectl create clusterrolebinding tiller-cluster-rule \
--clusterrole=cluster-admin \
--serviceaccount=kube-system:tiller

helm init --service-account tiller --wait
git clone https://github.com/<YOUR-USERNAME>/gitops-istio
cd gitops-istio
./scripts/flux-init.sh git@github.com:<YOUR-USERNAME>/gitops-istio

Au démarrage, Weave Flux génère une clé SSH et enregistre la clé publique. La commande en gras ci-dessus imprimera la clé publique.

Image for post
Image for post

Pour synchroniser l’état de votre cluster avec git, il faut copier la clé publique et créer une clé de déploiement avec un accès en écriture sur son dépôt GitHub. Sur GitHub, sélectionner Paramètres> Déployer les clés, cliquer sur Ajouter une clé de déploiement, cocher Autoriser l’accès en écriture, coller la clé publique Flux et cliquer sur Ajouter une clé.

Image for post
Image for post

Lorsque Weave Flux aura un accès en écriture à votre référentiel, il procédera comme suit:

  • Il crée les espaces de noms istio-system et prod
  • Il crée les CRD pour Istio
  • Il installe Flagger avec Helm
  • Il installe Grafana pour Flagger
  • Il crée le déploiement du test de charge
  • Il crée le déploiement frontal en mode canary
  • Il crée le déploiement backend en mode canary
  • Il crée la passerelle publique Istio
Image for post
Image for post

Lorsque Weave Flux synchronise le dépôt Git avec le cluster, il crée le déploiement front-end/backend, HPA et un objet en moide canary. Flagger utilise cette définition pour créer une série d’objets : Déploiements Kubernetes, services ClusterIP et services virtuels Istio :

Image for post
Image for post

Flagger détecte que la révision de déploiement a changé et lance un nouveau déploiement :

Image for post
Image for post

Tout ceci est monitoré avec Grafana :

Image for post
Image for post
Image for post
Image for post

et visualisable dans Weave Scope :

Image for post
Image for post

Ou dans Weave Cloud où il est possible d’initier un déploiement automatisé en mode GitOps (exemple ici avec le démonstrateur FC) :

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

J’effectue un changement sur son dépôt github du manifest de déploiement et détection automatique du changement intervenu puis redéploiement :

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

accompagné du monitoring :

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

Le démonstrateur FC reste toujours accessible (via l’adresse IP fournie par Kontena Network Load Balancer) :

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

Le déploiement terminé, Kontena Universal Load Balancer (Akrobateo) est installé (Akrobateo étant un simple opérateur Kubernetes permettant d’exposer les services LoadBalancer du cluster en tant que nœud hostPorts à l’aide de DaemonSets) :

Image for post
Image for post

et avec toujours Kontena Lens :

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

A suivre ! …

Image for post
Image for post

Above the clouds, the sky is always blue ...

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store