Kontena Pharos 2.4, Kontena Network Loadbalancer / Universal Loadbalancer, Kontena Lens et K...

title: Kontena Pharos 2.4 published: true tags: weave,kontena,docker,kubernetes canonical_url: https://medium.com/@abenahmed1/kontena-pharos-2-4-7c81290d7122

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

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 :

Kontena Pharos 2.4 Released

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) :

Bare Metal Instances

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 :

kontena/pharos-cluster

ou Pro :

Compare Editions · Kontena Pharos

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 :

Introduction · Kontena Pharos

cluster.yml

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

```

!/bin/sh

apt install sudo iputils-ping -y

echo "root ALL=(ALL) NOPASSWD: ALL" | tee /etc/sudoers.d/root

yes | mkfs.ext4 /dev/sda

mkdir -p /var/lib/docker

fs_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) :

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

et je lance le tout :

$ pharos up -c cluster.yml

Le cluster Kubernetes est alors disponible :

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

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) :

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

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

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

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

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 :

et déploiement :

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

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

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

Je réutilise Cloudflared Argo Tunnel pour rendre accessible publiquement ce Chatbot :

Getting Started - Argo Tunnel

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

aux performances correctes :

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

stefanprodan/gitops-istio

selon cette cinématique :

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.

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

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

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 :

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

Tout ceci est monitoré avec Grafana :

et visualisable dans Weave Scope :

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

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 :

accompagné du monitoring :

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

Pour terminer, je peux utiliser Kontena Universal Load Balancer qui reprend Akrobateo vu précédemment en modifiant le fichier cluster.yml au niveau des add-ons :

addons: kontena-universal-lb: enabled: true

Pour cela, je repars d’un cluster d’instances Bare Metal dans Scaleway de type C2M:

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) :