Kontena Pharos 2.4
Tags: weave, kontena, docker, kubernetes
Published: 2019-08-24 18:16:25

---
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 …

![](https://cdn-images-1.medium.com/max/1024/1*p-qSpMYjvOazPJQhTpwgvg.png)

**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](https://blog.kontena.io/kontena-pharos-2-4-released/)

![](https://cdn-images-1.medium.com/max/1024/1*sNUURS5RDg7MU7kiR6QBRw.jpeg)

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](https://www.scaleway.com/fr/bare-metal-instances/)

![](https://cdn-images-1.medium.com/max/931/1*UseR0S7kmZqrQXBQ9CWFZw.jpeg)

![](https://cdn-images-1.medium.com/max/1024/1*rsq8UDNXJggfmYzS5KQyCQ.jpeg)

![](https://cdn-images-1.medium.com/max/400/0*RLrhGfd7ZMKqRGZE.jpg)

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](https://github.com/kontena/pharos-cluster)

![](https://cdn-images-1.medium.com/max/1024/1*-qq7lyhbzzSrddIcYut4mg.jpeg)

![](https://cdn-images-1.medium.com/max/1024/1*w3AvWhxE9tsHvDpjEZU00g.jpeg)

ou Pro :

![](https://cdn-images-1.medium.com/max/1024/1*p3_i0Z26RS_LWShpuKAQRA.jpeg)

[Compare Editions · Kontena Pharos](https://pharos.sh/docs/editions.html)

**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](https://pharos.sh/docs/configuration.md)

![](https://cdn-images-1.medium.com/max/1024/1*DiNKZjAtTXb1dAvPAWX4Gw.png)<figcaption>cluster.yml</figcaption>

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/](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) :

![](https://cdn-images-1.medium.com/max/1024/1*CmaO019SXTmtvVo5HzkHOQ.jpeg)

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

![](https://cdn-images-1.medium.com/max/1024/1*WD82Mi-26KmuSR1aEWJuvA.jpeg)

![](https://cdn-images-1.medium.com/max/1024/1*2HMTi3-Kjdh9HBpu5q_5LQ.jpeg)

et je lance le tout :

```
$ pharos up -c cluster.yml
```

![](https://cdn-images-1.medium.com/max/1024/1*-cTPOELYjF_q5S3rBmJ6Dw.png)

Le cluster Kubernetes est alors disponible :

![](https://cdn-images-1.medium.com/max/1024/1*gHAEf2KnTxt9PgiAnpXi6w.png)

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

![](https://cdn-images-1.medium.com/max/1024/1*4Ps8ktih0h3p2Gbv4Wuztg.jpeg)

![](https://cdn-images-1.medium.com/max/1024/1*vSrXlR1fQxLvSdMvfEr1QA.jpeg)

![](https://cdn-images-1.medium.com/max/1024/1*IgrZ5cAkmV_xwBgPRaPaIg.jpeg)

![](https://cdn-images-1.medium.com/max/1024/1*pdPF8HxZQksbTQJu-zr0Vw.jpeg)

![](https://cdn-images-1.medium.com/max/1024/1*dZ28I6tkbVGyvqFSVew3Xg.jpeg)

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

![](https://cdn-images-1.medium.com/max/814/1*8rPZEM3zW6I7p_dowg9pdQ.jpeg)

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

![](https://cdn-images-1.medium.com/max/1024/1*cVGVoo4Cv6vx202iK4PPng.jpeg)

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
```

![](https://cdn-images-1.medium.com/max/1024/1*wAr7gTXKkOLE8innI4yJxw.jpeg)

![](https://cdn-images-1.medium.com/max/1024/1*jIliX1VbDvm1y7YkOifgIw.jpeg)

![](https://cdn-images-1.medium.com/max/1024/1*3e38bSLSqPdTmeFIF-Nodg.jpeg)

![](https://cdn-images-1.medium.com/max/1024/1*hJjyaZM9yO-dK7fspZrodw.jpeg)

![](https://cdn-images-1.medium.com/max/1024/1*R56Wl-EO42G7YGIjwBYQYA.jpeg)

![](https://cdn-images-1.medium.com/max/1024/1*TBegw0o6aTHB4aOlMcSKcA.jpeg)

![](https://cdn-images-1.medium.com/max/1024/1*qb9rHGmigrRhNTTbcvbPrw.jpeg)

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

![](https://cdn-images-1.medium.com/max/1024/1*p4iB-5x-aQ2jAgK_E4IZjw.png)

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

![](https://cdn-images-1.medium.com/max/1024/1*5pUcCvs3DYSoIlmpCuZezw.jpeg)

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 :

![](https://cdn-images-1.medium.com/max/1024/1*PiC18fHBuo3OnzBhU0Q08A.jpeg)

et déploiement :

![](https://cdn-images-1.medium.com/max/1024/1*Wntafl1RL5sYTpqFzWheRw.jpeg)

![](https://cdn-images-1.medium.com/max/1024/1*Opwch4stMhZFJ6aVIQdxBA.jpeg)

![](https://cdn-images-1.medium.com/max/1024/1*Drl6YD2Nk_dJL5KdNhXB_Q.jpeg)

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

![](https://cdn-images-1.medium.com/max/1024/1*6d0c0DEItHJsjbMXGTONfw.jpeg)

![](https://cdn-images-1.medium.com/max/1024/1*QqLF9xJEj4_xj4_1VwNc1g.jpeg)

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

![](https://cdn-images-1.medium.com/max/1024/1*DTzLI7uI7h-L9kOz_LPpKw.jpeg)

![](https://cdn-images-1.medium.com/max/1024/1*kjpFf9Zoz3hmZwVkeIttZA.jpeg)

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

![](https://cdn-images-1.medium.com/max/1024/1*BCQXGAmd6OOPlVDEkR6tIQ.jpeg)

![](https://cdn-images-1.medium.com/max/1024/1*-emcm_83gJrzbt2jRJGueA.jpeg)

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

[Getting Started - Argo Tunnel](https://developers.cloudflare.com/argo-tunnel/quickstart/)

![](https://cdn-images-1.medium.com/max/884/1*y9Gf8ond71wM9Xb-aZyJ2A.jpeg)

![](https://cdn-images-1.medium.com/max/1024/1*sEX876q1gnQf8jpH2a665g.jpeg)

![https://cdn-images-1.medium.com/max/1600/1*MFQGurn3NsytA1WKA_P8Zw.jpeg](https://cdn-images-1.medium.com/proxy/1*MFQGurn3NsytA1WKA_P8Zw.jpeg)

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

![](https://cdn-images-1.medium.com/max/776/1*bkR8r2fICEe9_cltGAh-Tg.jpeg)

![](https://cdn-images-1.medium.com/max/783/1*umxa7IViVICPsahi1cGZxw.jpeg)

aux performances correctes :

![](https://cdn-images-1.medium.com/max/1024/1*FXmRFvRjsQwDlW5LKgSaSg.jpeg)

![](https://cdn-images-1.medium.com/max/1024/1*Hhq8MfsAIu-Y85__Q3m0bw.jpeg)

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](https://github.com/stefanprodan/gitops-istio)

selon cette cinématique :

![](https://cdn-images-1.medium.com/max/1024/0*cfn8b0-F19BdQAvZ.png)

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.

![](https://cdn-images-1.medium.com/max/1024/1*4jTACW1itYh9cmPv-Olafw.jpeg)

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

![](https://cdn-images-1.medium.com/max/1024/1*-SlrLBdfkzn7p5KedTEiXg.jpeg)

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

![](https://cdn-images-1.medium.com/max/1024/0*PQzsvyYenVc-2rG5.png)

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 :

![](https://cdn-images-1.medium.com/max/1024/1*jnvw_7KgmOkGe8KJa3tpkA.jpeg)

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

![](https://cdn-images-1.medium.com/max/1024/1*NaX9FJcx0t-oz5qonvmNEw.jpeg)

Tout ceci est monitoré avec Grafana :

![](https://cdn-images-1.medium.com/max/714/1*ITv1JYdGuyvnji7KPP1lFg.jpeg)

![](https://cdn-images-1.medium.com/max/711/1*xQ7-SeqJL1rFEi9D5qGDDA.jpeg)

et visualisable dans Weave Scope :

![](https://cdn-images-1.medium.com/max/1024/1*Fs5wjq5HuLvviIxeF-CtFg.jpeg)

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

![](https://cdn-images-1.medium.com/max/1024/1*7Pkornk0xARTOuqcDu_ACQ.jpeg)

![](https://cdn-images-1.medium.com/max/1024/1*A1-5UrbLow2PblFwm6zdgw.jpeg)

![](https://cdn-images-1.medium.com/max/1024/1*RKzfDH547kOxkZJWx0FAug.jpeg)

![](https://cdn-images-1.medium.com/max/1024/1*bf8ZBlTkKiLNxCMD5-Y5vg.jpeg)

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 :

![](https://cdn-images-1.medium.com/max/963/1*zrE-mBGLen_CvS81i6zPzw.jpeg)

![](https://cdn-images-1.medium.com/max/1024/1*NeXDhl6AcGpqa75i7bMXBA.jpeg)

![](https://cdn-images-1.medium.com/max/1024/1*-k9w8AI6BsoGeHKqx7LGFg.jpeg)

accompagné du monitoring :

![](https://cdn-images-1.medium.com/max/1024/1*PIQ00q9iHrV6xwqgrO8X2w.jpeg)

![](https://cdn-images-1.medium.com/max/1024/1*riEy4FDsXahbWWQUZd1lFw.jpeg)

![](https://cdn-images-1.medium.com/max/1024/1*LoudQC9SHSC4K5ALUhpVow.jpeg)

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

![](https://cdn-images-1.medium.com/max/1024/1*T7C3WtiwNzMjJ1I-Q9QTeA.jpeg)

![](https://cdn-images-1.medium.com/max/1024/1*E639oM9vwq0KvXVW7nWRHA.jpeg)

![](https://cdn-images-1.medium.com/max/1024/1*4C0R0chrxwdjuwNTKYAEBA.jpeg)

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
```

- [kontena/akrobateo](https://github.com/kontena/akrobateo)
- [Test rapide de Kontena Akrobateo, un simple opérateur Kubernetes pour exposer les services…](https://medium.com/@abenahmed1/test-rapide-de-kontena-akrobateo-un-simple-op%C3%A9rateur-kubernetes-pour-exposer-les-services-e4080cf42eb4)
- [Kontena Universal Loadbalancer · Kontena Pharos](https://pharos.sh/docs/addons/kontena-universal-lb.html)

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

![](https://cdn-images-1.medium.com/max/1024/1*qYq-OR9p-2d24aZJLPD1hw.jpeg)

![](https://cdn-images-1.medium.com/max/1024/1*3vaOteMJdmWL9zkKNesE2w.png)

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

![](https://cdn-images-1.medium.com/max/800/1*zSAemz8hrPeBAf8MAJnhLw.png)

et avec toujours Kontena Lens :

![](https://cdn-images-1.medium.com/max/1024/1*C-whNjy1DbnKn9iixh3e6A.jpeg)

![](https://cdn-images-1.medium.com/max/1024/1*pKbdlD982ByM5yUnZiClRQ.jpeg)

![](https://cdn-images-1.medium.com/max/1024/1*N8n3jaESNV5iadlJJYNnUQ.jpeg)

A suivre ! …

![](https://cdn-images-1.medium.com/max/430/0*Zpfjs_HI7x2Rt2d7.jpg)