Featured image of post J'ai testé pour vous : k8s The Easier Way (k8s-tew)

J'ai testé pour vous : k8s The Easier Way (k8s-tew)

Ecrit par ~ zwindler ~

Tu ne faisais pas un livre sur Kubernetes, toi ?

Oui ! Mais pour l’instant, je ne peux pas trop en parler :-p. Mais promis dès que je le peux, je communiquerai.

Cependant, je peux quand même dire que la rédaction de ce livre m’a amené à tester BEAUCOUP de tools pour installer Kubernetes. Et comme je l’ai déjà fait précédemment sur ce blog, je vais vous présenter un des tools que j’ai testé et qui s’appelle : Kubernetes The Easier Way, ou k8s-tew.

Les plus cultivés d’entre vous auront certainement reconnus une référence au projet Kubernetes the hard way, de Kelsey Hightower. C’est assumé :

Kubernetes is a fairly complex project. For a newbie it is hard to understand and also to use. While Kelsey Hightower’s Kubernetes The Hard Way, on which this project is based, helps a lot to understand Kubernetes, it is optimized for the use with Google Cloud Platform.

k8s-tew est une CLI qui va nous installer pour nous tous les prérequis pour obtenir un k8s opérationnel en quelques commandes, ainsi que tout un tas de logiciels tiers.

Le projet supporte plusieurs modes de déploiement :

  • sur l’hôte local (mais nécessite les ports 80 et 443 disponibles)
  • sur une machine unique distante
  • sur plusieurs machines distantes
  • control plane HA ou non

Prérequis

Le projet k8s-tew a été développé en golang. En théorie, il est possible de le compiler pour macOS, Windows ou Linux ARM à partir des sources.

Pour le fun, on va donc faire ça.

Cependant, si vous êtes sur machine Linux AMD64, le binaire précompilé disponibles sur le dépôt github de k8s-tew.

curl -s https://api.github.com/repos/darxkies/k8s-tew/releases/latest \
  | grep "browser_download_url" | cut -d : -f 2,3 | tr -d \" | sudo wget \
  -O /usr/local/bin/k8s-tew -qi -

sudo chmod a+x /usr/local/bin/k8s-tew

Compiler les sources

Merci le Golang, il n’y a pas grand-chose à faire d’autre que de cloner le dépôt :

git clone https://github.com/darxkies/k8s-tew.git

cd k8s-tew
make build-binaries
> CGO_ENABLED=0 go build -ldflags "-X github.com/darxkies/k8s-tew/pkg/version.Version=2.4.12-4-g25cfcb40 -s -w" -o k8s-tew github.com/darxkies/k8s-tew/cmd/k8s-tew 

file ./k8s-tew
./k8s-tew: Mach-O 64-bit executable arm64

./k8s-tew 
Version: 2.4.12-4-g25cfcb40
OS: /

Kubernetes - The Easier Way
[...]

Configuration

Une fois la CLI installée (que vous l’ayez compilée ou téléchargée), on va pouvoir s’attaquer au vrai morceau.

Je vous propose la version “multi-node simple” (sans HA pour le control plane) à l’aide de 3 machines virtuelles que j’ai créés sur un cloud provider.

Note : le worflow est différent selon qu’on exécute la CLI en mode “local” ou non. Le workflow à suivre est le suivant :

  • initialize –> configure –> generate –> deploy

La commande ./k8s-tew initialize va nous permettre de générer un fichier de configuration assets/etc/k8s-tew/config.yaml.

./k8s-tew initialize
INFO[0000] Saved config                                 
INFO[0000] Done

Ce fichier contient toutes les options de configuration pour notre cluster, que ce soit pour Kubernetes lui-même ou pour les composants qui seront installés a posteriori.

Parmi les composants choisis par le développeur de k8s-tew, on retrouve calico (CNI plugin), metalLB (pour avoir les Services de type LoadBalancer), Ceph et Minio (stockage), Velero (sauvegarde) :

version: 2.4.0
cluster-id: 0df51ff0-3bae-4a33-b41f-66fb97bd3704
cluster-name: k8s-tew
email: k8s-tew@gmail.com
[...]
kube-state-metrics-count: 1
drain-grace-period-seconds: 0
versions:
  etcd: quay.io/coreos/etcd:v3.5.21
  kubernetes: v1.32.3
[...]
  containerd: 2.0.5
[...]
  velero: docker.io/velero/velero:v1.9.0
[...]
  minio-server: docker.io/minio/minio:RELEASE.2021-03-12T00-00-47Z
  minio-client: docker.io/minio/mc:RELEASE.2021-03-12T03-36-59Z
[...]
  metallb-controller: quay.io/metallb/controller:v0.9.5
  metallb-speaker: quay.io/metallb/speaker:v0.9.5
  ceph: quay.io/ceph/ceph:v19.2.2
[...]
nodes: {}

Je n’ai mis que quelques lignes, mais si vous ouvrez le fichier, vous remarquerez que la liste des composants préinstallés est TRÈS (trop) longue, avec même une instance wordpress+mysql.

La deuxième chose qu’on peut noter est que pour l’instant, la liste des Nodes est vide.

On va donc ajouter des Nodes avec la commande k8s-tew node-add :

➜  ~ k8s-tew node-add -n tew1 -i 203.0.113.97 -l controller,node,storage,worker
  INFO[0000] Node added index=0 ip=203.0.113.97 
  labels="[controller node storage]" name=tew1 storage-index=0
  INFO[0000] Saved config

➜  ~ k8s-tew node-add -n tew2 -i 203.0.113.49 -l controller,node,storage,worker
  [...]

➜  ~ k8s-tew node-add -n tew3 -i 203.0.113.43 -l controller,node,storage,worker
  [...]

Note : dans cet exemple, les Nodes tew1, tew2 et tew3 disposent tous les trois de tous les rôles (control plane, worker et membre du cluster de stockage Ceph). Dans un contexte de production, cette configuration serait probablement peu recommandée, une séparation propre des rôles serait préférable.

À partir de là, la section nodes: du fichier de configuration doit maintenant contenir ceci :

[...]
nodes:
  tew1:
    ip: 203.0.113.97
    index: 0
    storage-index: 0
    labels:
    - controller
    - node
    - storage
    - worker
  tew2:
    ip: 203.0.113.49
    index: 1
    storage-index: 1
    labels:
    - controller
    - node
    - storage
    - worker
  tew3:
    ip: 203.0.113.43
    index: 2
    storage-index: 2
    labels:
    - controller
    - node
    - storage
    - worker

Générer les fichiers qui vont nous permettre de réaliser l’installation (binaires pour les composants, certificats, etc) :

k8s-tew generate
INFO[0000] Generated config entries                     
INFO[0000] Saved config                                 
INFO[0000] Copied                                        name=k8s-tew
INFO[0000] Downloading                                   name=etcd-v3.5.21-linux-amd64.tar.gz
INFO[0010] Installed                                     name=etcdctl
[...]
INFO[0027] Generated                 name=kube-scheduler-tew1.yaml
INFO[0027] Generated                 name=kube-scheduler-tew2.yaml
INFO[0027] Generated                 name=kube-scheduler-tew3.yaml
INFO[0027] Generated                 name=kube-proxy-tew1.yaml
INFO[0027] Generated                 name=kube-proxy-tew2.yaml
INFO[0027] Generated                 name=kube-proxy-tew3.yaml
INFO[0027] Done 

Déploiement

À partir de maintenant, tous les fichiers de configuration nécessaires à k8s-tew sont générés. Il ne reste donc plus qu’à déployer tout ça avec la commande k8s-tew.

Et là c’est le drame…

./k8s-tew deploy
INFO[0000] Executing remote command                      name=create-directories node=tew1
ERRO[0000] Failed deploying                              error="open /Users/zwindler/.ssh/id_rsa: no such file or directory"

Note 1 : k8s-tew n’utilise pas votre agent ssh, mais ouvre un fichier de clé présent sur votre machine pour se connecter aux machines distantes. De plus, il ne supporte que les clés de type RSA. Enfin, l’utilisation du compte root est obligatoire (pas possibilité de passer par un utilisateur classique avec sudo).

Note 2 : si vous avez compilé le binaire comme moi pour MacOS, vous allez retrouver avec une mauvaise blague. Le binaire est aussi utilisé pour installer sur les serveurs distants (Linux/amd64 dans mon cas) et l’installation échouera lamentablement (et silencieusement). On peut tricher / contourner le problème en téléchargeant le binaire pour Linux et en déposant au chemin ./assets/opt/k8s-tew/bin/k8s-tew :

curl -s https://api.github.com/repos/darxkies/k8s-tew/releases/latest \
  | grep "browser_download_url" | cut -d : -f 2,3 | tr -d \" | sudo wget \
  -O ./assets/opt/k8s-tew/bin/k8s-tew -qi -

Une fois cette configuration modifiée sur mes machines virtuelles, j’ai relancé le processus :

./k8s-tew deploy
INFO[0000] Executing remote command  name=create-directories node=tew1
INFO[0000] Executing remote command  name=get-checksums node=tew1
INFO[0000] Executing remote command  name=stop-service node=tew1
INFO[0001] Deploying                 name=k8s-tew.service node=tew1
[...]
NFO[0032] Configuring taint                             node=tew1
INFO[0040] Configuring taint                             node=tew2
INFO[0041] Configuring taint                             node=tew3
INFO[0045] Applying manifest                             name=kubelet-setup
INFO[0045] Applying manifest                             name=admin-user-setup
INFO[0045] Applying manifest                             name=calico-setup
INFO[0045] Applying manifest                             name=metallb-setup
INFO[0045] Applying manifest                             name=coredns-setup
[...]
INFO[0117] Applying manifest                             name=velero-setup
INFO[0124] Applying manifest                             name=wordpress-setup
INFO[0190] Done  

A l’issue du processus (environ 3 minutes), le cluster Kubernetes complet avec de nombreux composants devrait être opérationnel. On peut récupérer une série de variables qui vont faciliter l’usage de notre cluster (notamment la variable KUBECONFIG, mais aussi CONTAINER_RUNTIME_ENDPOINT et CONTAINERD_NAMESPACE si on est en mode local) :

➜  ~ kubectl get nodes
NAME   STATUS   ROLES                       AGE     VERSION
tew1   Ready    controller,storage,worker   9m16s   v1.32.3
tew2   Ready    controller,storage,worker   9m7s    v1.32.3
tew3   Ready    controller,storage,worker   9m3s    v1.32.3

Aller plus loin

k8s-tew permet d’installer un cluster Kubernetes disposant déjà d’un grand nombre de composants tiers, permettant d’immédiatement commencer à l’utiliser.

Toutes ces options de configuration sont décrites sur la documentation officielle (darxkies.github.io/k8s-tew/_build/html/usage.html#configuration).

Cependant, k8s-tew n’est pour l’instant pas très flexibles sur l’accès SSH pour réaliser l’installation (pas possible de séparer les IPs internes des IPs externes, compte root obligatoire, pas de sudo), ce qui limite son intérêt dans beaucoup de scenario.

Avantages et Inconvénients

Les plusLes moins
➕ un cluster complet avec énormément de composants préinstallés (trop)➖ compte root + clé RSA obligatoire, pas de sudo, pas de ed25519
➕ code go open source➖ client golang qui pourrait être multiplateformes, mais en réalité compatible linux amd64 uniquement (hors bidouilles)
➖ trop de composants préinstallés, consomme trop de ressources (mais c’est paramétrable)
➖ impossible de distinguer IP externe et IP interne dans le cas de déploiements sur un cloud provider avec firewalling
➖ pas de gestion des règles de firewalling
Licensed under CC BY-SA 4.0
Dernière mise à jour le 26 May 2025 20:00 CEST

Vous aimez ce blog ou cet article ? Partagez-le avec vos amis !   Twitter Linkedin email Facebook

Vous pouvez également vous abonner à la mailing list des articles ici

L'intégralité du contenu appartenant à Denis Germain (alias zwindler) présent sur ce blog, incluant les textes, le code, les images, les schémas et les supports de talks de conf, sont distribués sous la licence CC BY-SA 4.0.

Les autres contenus (thème du blog, police de caractères, logos d'entreprises, articles invités...) restent soumis à leur propre licence ou à défaut, au droit d'auteur. Plus d'informations dans les Mentions Légales

Généré avec Hugo
Thème Stack conçu par Jimmy