Des clusters Kubernetes imbriqués avec Ignite, Firecracker, Containerd, Kind et Rancher …

Karim
10 min readSep 16, 2019

--

J’avais déjà parlé dans un précédent article de Weave Ignite et Footloose qui continuent de se développer :

Une nouvelle version d’Ignite permet maintenant de s’affranchir de l’utilisation du moteur Docker avec Containerd et CNI :

Focus sur cette nouvelle version avec pour commencer le lancement d’une instance Bare Metal de type C2L dans Scaleway sur laquelle tourne Ubuntu 18.04 LTS :

A noter que Scaleway permet également de faire tourner en version Beta des serveurs de la gamme Dedibox et facturés comme les instances classiques à l’heure :

Je profite du second disque de 250 Go pour créer un point de montage dédié au moteur Containerd. L’extension virtualisation nécessaire à Ignite est active :

Sur cette instance de Scaleway, j’installe les dépendances nécessaires à Ignite :

$ apt-get update && apt-get install -y --no-install-recommends containerd dmsetup openssh-client git binutils

Puis les binaires nécessaires à CNI :

$ export CNI_VERSION=v0.8.2
$ export ARCH=$([ $(uname -m) = "x86_64" ] && echo amd64 || echo arm64)
$ mkdir -p /opt/cni/bin
$ curl -sSL https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/cni-plugins-linux-${ARCH}-${CNI_VERSION}.tgz | tar -xz -C /opt/cni/bin

suivi d’Ignite :

$ for binary in ignite ignited; do
echo "Installing ${binary}..."
curl -sfLo ${binary} https://github.com/weaveworks/ignite/releases/download/${VERSION}/${binary}-${GOARCH}
chmod +x ${binary}
mv ${binary} /usr/bin
done

Weave Ignite est un gestionnaire de machine virtuelle (VM) open source avec un conteneur UX et une gestion GitOps intégrée. Ignite combine les MicroVM Firecracker avec les images Docker / OCI pour unifier containers et machines virtuelles. Ignite peut gérer les VMs de manière déclarative et automatique comme Kubernetes et Terraform.

Pour rappel, Firecracker est une implémentation KVM open source d’AWS optimisée pour une haute sécurité, une isolation, une vitesse et une faible consommation de ressources. AWS l’utilise comme base pour ses offres serverless (AWS Lambda et Fargate) qui doivent être chargées presque instantanément tout en maintenant les utilisateurs isolés (multilocation). Firecracker a prouvé sa capacité à faire fonctionner 4000 microVMs sur le même hôte ! …

Je vais utiliser une image Ubuntu fournie par Weaveworks dans le Docker Hub pour lancer une première microVM mais sans Docker (avec uniquement Ignite, Containerd et CNI plugins) :

$ ignite run weaveworks/ignite-ubuntu \
--cpus 2 \
--memory 8GB \
--ssh \
--size 50GB \
--name k8s1

Je peux m’y connecter via SSH directement :

Je mets les bonnes entrées DNS (en utilisant par exemple celui de Google) dans le fichier /etc/resolv.conf :

Et dans l’optique de l’installation de Kind (Kubernetes in Docker), j’installe dans cette microVM le moteur Docker :

$ curl -fsSL https://get.docker.com -o get-docker.sh; sh get-docker.sh; systemctl enable docker; systemctl start docker

et le déployer …

Kind (Kubernetes IN Docker) est un outil permettant d’exécuter des clusters Kubernetes locaux à l’aide de “nœuds” sous la forme de containers Docker. Kind a été à l’origine principalement conçu pour tester les versions Kubernetes 1.11 et ultérieures, en ciblant notamment les tests de conformité.

Pour rappel :

  • Kind prend en charge les clusters multi-nœuds (y compris HA)
  • Kind supporte les builds de Kubernetes à partir des sources
    pour make / bash / docker, ou bazel, en plus des builds pré-publiées.
  • Kind est écrit en Go, peut être utilisé comme bibliothèque et a des versions stables
  • Kind supporte Windows en plus de MacOS et Linux
  • Et Kind est un installer Kubernetes certifié conforme par la CNCF

Je vais créer avec Kind un cluster à trois noeuds (1 noeud Maître et deux noeuds Workers) à partir de ce fichier de configuration en YAML :

config.yaml
$ kind create cluster --config config.yaml

Le cluster est actif et j’installe le client Kubectl pour interagir avec lui:

$ curl -LO https://storage.googleapis.com/kubernetes-release/release/v1.15.3/bin/linux/amd64/kubectl; chmod +rwx kubectl; mv kubectl /usr/bin$ export KUBECONFIG="$(kind get kubeconfig-path --name="kind")"

Déploiement de MetalLB avec Kind nécessaire à mon premier test :

$ kubectl apply -f https://raw.githubusercontent.com/google/metallb/v0.8.1/manifests/metallb.yaml

avec cette configuration utilisant ce plan d’adressage interne 172.17.0.0/16 :

l2.yaml

Je peux procéder au désormais traditionnel démonstrateur FC :

deployment.yml

Une adresse IP m’a été attribuée par MetalLB pour le démonstrateur FC :

Réutilisation de Gobetween, un Load Balancer et proxy inverse libre, open-source et minimaliste dans le cluster Kind :

$ curl -s https://api.github.com/repos/yyyar/gobetween/releases | grep browser_download_url | grep linux_amd64 | cut -d '"' -f 4 | head -n 1 | wget -i -

Il va servir à me permettre d’accéder en externe au démonstrateur via l’adresse IP interne attribuée par MetalLB. Pour cela, je me base sur cette configuration en TOML pour Gobetween :

gobetween.toml

Je peux lancer Gotbetween avec cette configuration :

$ gobetween -c config/gobetween.toml

J’avais également liée cette microVM à un réseau ZeroTier ce qui me permet d’accéder au démonstrateur depuis mon navigateur :

Gobetween peut activer son API Restful pour plus d’infos :

Lancement d’une seconde microVM qui va servir à porter un second cluster Kubernetes avec Kind :

à trois noeuds (1 noeud maître et deux noeuds workers) :

config.yaml

avec encore une fois MetalLB :

et cette fois-çi le déploiement du deuxième démonstrateur FC :

deployment.yml

Une adresse IP interne est fournie par MetalLB pour l’accès au démonstrateur :

Je réutilise comme précédemment Gobetween avec cette microVM liée à ZeroTier :

avec cette configuration en TOML (très proche de la précédente) :

gobetween.toml

Ce second démonstrateur est accessible depuis mon navigateur via une adresse du réseau configurée en amont dans ZeroTier :

Lancement d’une dernière microVM qui va me servir à héberger un serveur Rancher :

Installation du moteur Docker et du serveur Rancher :

$ curl -fsSL https://get.docker.com -o get-docker.sh; sh get-docker.sh; systemctl enable docker; systemctl start docker; docker run -d --restart=unless-stopped -p 80:80 -p 443:443 -v /opt/rancher:/var/lib/rancher rancher/rancher:latest

Je peux alors importer mes deux clusters Kubernetes construits avec l’aide de Kind dans Rancher. Importation du premier cluster k8s1 :

Puis du second cluster nommé k8s2 :

Tous les clusters sont importés dans Rancher :

Sur le serveur hôte C2L j’effectue la liaison avec ZeroTier :

Obtention au final de cette configuration schématique :

et je réutilise une dernière fois Gobetween avec cette configuration en TOML qui reprend les adresses IP des microVMs dans ZeroTier :

gobetween.toml

Ici j’ai utilisé des poids dans Gobetween pour simuler une sorte d’A/B Testing avec deux versions différentes du démonstrateur FC accessibles avec l’adresse IP publique du serveur C2L dans Scaleway :

Le monitoring des deux clusters Kubernetes est assurée par le serveur Rancher via Prometheus et Grafana :

--

--