Kontena Pharos 2.4
Karim
Posted on August 24, 2019
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 :
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) :
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 :
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 :
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) :
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 :
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 :
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
- kontena/akrobateo
- Test rapide de Kontena Akrobateo, un simple opérateur Kubernetes pour exposer les services…
- Kontena Universal Loadbalancer · Kontena Pharos
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) :
et avec toujours Kontena Lens :
A suivre ! …
Posted on August 24, 2019
Join Our Newsletter. No Spam, Only the good stuff.
Sign up to receive the latest update from our blog.