Si vous êtes à l’affût d’une solution pratique pour tenir les rênes de Kubernetes, ou bien, si vous êtes un utilisateur actif de Rancher 1.6, ce blogpost sur Rancher 2 peut vous intéresser.
Qu’est-ce que Rancher 2 ?
Si on ne jette qu’un rapide coup d’œil à Rancher, on pourrait croire qu’il ne s’agit “que” d’une simple interface graphique et se demander quelle est la différence avec le dashboard officiel de Kubernetes. Il y a pourtant un monde entre les deux, puisque Rancher gère aussi :
- l’installation et la maintenance de cluster
- l’identification (authentication) des utilisateurs
- le trafic HTTP entrant (ce qu’on appelle les ingress dans Kubernetes)
- une métrologie intégrée, avec Prometheus et Grafana
Le diagramme ci-dessous donne une bonne idée de l’ensemble des fonctionnalités offertes :
Il s’agit donc bel et bien d’une distribution Kubernetes, qui intègre des briques indispensables à une utilisation réaliste en production ; au même titre que des produits concurrents comme OpenShift ou Ksphere, par exemple. On appréciera l’approche Open-Source !
Avant de poursuivre, je vais préciser que chez Enix, même si on travaille beaucoup avec Rancher (qu’on utilise depuis les premières versions, qui étaient basées sur Docker), on peut vous accompagner dans votre déploiement Kubernetes quel que soit votre modèle de déploiement. Voilà c’est dit, revenons maintenant à nos moutons … Ou à nos vaches, puisque c’est la mascotte de Rancher !
Introduction - Modus operandi
Au travers de ce blogpost, je vous propose de faire le tour des trois méthodes d’installation possibles pour Rancher 2 :
- Option A : je cherche à simplifier (voire masquer) la gestion de Kubernetes.
- Option B : je garde un contrôle total sur Kubernetes, mais je complète en fonctionnalités.
- Option C : Rancher installé sur le cluster lui-même, sans stockage persistent.
Chacun aura sa préférence, j’utilise personnellement les trois options en fonction de l’objectif.
Afin d’éviter un blogpost à rallonge, je fais l’impasse totale sur la Haute-Disponibilité de Rancher (qui est possible dans les trois cas), et j’y reviendrai probablement dans un autre billet de blog.
Je ne fais pas appel aux fonctionnalités des Cloud Providers (type LoadBalancer) afin d’être le plus générique possible.
Enfin, je me base sur Rancher 2.4.4, mais les concepts vus plus bas seront probablement valables pour la plupart des versions à venir.
Option A : Installation auto-guidée
Bienvenue dans le monde confortable de l’installation tout inclus avec Rancher 2, vous ne souffrirez plus de la complexité de Kubernetes !
L’opération se passe en deux étapes :
- Installation de Rancher 2
- Création d’un cluster Kubernetes de façon automatisée
Option A étape 1 : Rancher
Rancher 2 est installé dans son propre environnement, par exemple sur une simple VM faisant déjà tourner Docker :
docker run -d --restart=unless-stopped \
-p 80:80 -p 443:443 rancher/rancher:latest
ou avec quelques options et la récupération d’un certificat via let’s encrypt :
docker run -d --restart=unless-stopped \
-p 80:80 -p 443:443 --name=rancher-2.4.4 \
-v /opt/rancher:/var/lib/rancher \
rancher/rancher:v2.4.4 --acme-domain rancher-rke.blogpost.enix.io
En moins d’une minute vous devriez pouvoir joindre Rancher 2 sur l’IP de la machine, et en HTTPS !
Option A étape 2 : Kubernetes
Nous allons donc ajouter un cluster en mode automatique, là plusieurs choix nous interpellent :
- Sur des machines virtuelles d’un cloud provider (Amazon, Azure, OVH, DigitalOcean, …)
- Ou bien via les offres Kubernetes de cloud provider (Amazon, Azure et Google)
- Ou encore From existing nodes (Custom), c’est l’option que je vais utiliser !
Je nomme donc mon cluster rancher-rke puisque notre approche s’appuie sur la brique rke pour installer Kubernetes. Je sélectionne ensuite une ancienne version (volontairement) de Kubernetes et je laisse tout le reste par défaut :
Sur la page suivante, on me propose un wizard qui génère une ligne de commande Docker :
Je lance donc mon premier master node en sélectionnant etcd et Control Plane et j’applique la ligne de commande résultante sur une nouvelle machine virtuelle :
docker run -d --privileged --restart=unless-stopped --net=host -v /etc/kubernetes:/etc/kubernetes -v /var/run:/var/run rancher/rancher-agent:v2.4.4 --server https://rancher-rke.blogpost.enix.io --token <caviardé> --etcd --controlplane
Sans changer de page web je devrais voir apparaître un magnifique :
Rebelote sur une nouvelle VM en sélectionnant Worker uniquement … et … tada !
Faites péter les Pods !
Pour conclure cette première étape, je vous laisse la surprise d’aller éditer le cluster afin de sélectionner la dernière version de Kubernetes et voir la magie opérer. Entre temps, je synthétise mon avis sur cette première option :
pros
- L’approche la plus simple
- Avec la maintenance la moins coûteuse
- Totalement dans l’esprit Rancher 1.6
cons
- Les intégrations avec une infrastructure existante (notamment réseau) sont peu évidentes
- Difficile d’aller activer des fonctionnalités alpha
- Ne comptez pas profiter des tutoriels autour de
kubeadm!
Option B : Je garde la main sur Kubernetes
Pas touche à mon Kubernetes
Nous retrouvons deux étapes et un prérequis pour accomplir cette deuxième mission :
- Avoir un cluster Kubernetes déjà installé
- Installer Rancher 2
- Importer le cluster sur Rancher
Option B étape 1
La première étape est identique à l’option A
Option B étape 2
Lors de la création du cluster sur Rancher 2, j’utilise l’option Import an existing cluster :
Rancher me propose alors d’appliquer des specifications Kubernetes afin d’importer le cluster :
root@rancher-blog-kube-1:~# kubectl apply -f https://rancher-kube.blogpost.enix.io/v3/import/<caviardé>.yaml
clusterrole.rbac.authorization.k8s.io/proxy-clusterrole-kubeapiserver created
clusterrolebinding.rbac.authorization.k8s.io/proxy-role-binding-kubernetes-master created
namespace/cattle-system created
serviceaccount/cattle created
clusterrolebinding.rbac.authorization.k8s.io/cattle-admin-binding created
secret/cattle-credentials-c6e77ac created
clusterrole.rbac.authorization.k8s.io/cattle-admin created
deployment.apps/cattle-cluster-agent created
daemonset.apps/cattle-node-agent created
Le résultat ne se fait pas trop attendre :
Je prends le temps de regarder ce qui vient de se passer :
root@rancher-blog-kube-1:~# kubectl get namespaces
NAME STATUS AGE
cattle-system Active 2m52s
default Active 16m
kube-node-lease Active 16m
kube-public Active 16m
kube-system Active 17m
root@rancher-blog-kube-1:~# kubectl get all --namespace cattle-system
NAME READY STATUS RESTARTS AGE
pod/cattle-cluster-agent-545fff6958-nk5qv 1/1 Running 0 4m24s
pod/cattle-node-agent-k9xxs 1/1 Running 0 4m11s
pod/cattle-node-agent-vtbb5 1/1 Running 0 4m7s
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
daemonset.apps/cattle-node-agent 2 2 2 2 2 <none> 4m39s
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/cattle-cluster-agent 1/1 1 1 4m39s
NAME DESIRED CURRENT READY AGE
replicaset.apps/cattle-cluster-agent-545fff6958 1 1 1 4m24s
replicaset.apps/cattle-cluster-agent-6fc8f7fc65 0 0 0 4m39s
Ok, j’ai donc un agent Rancher qui tourne sur chacun de mes nœuds dans le namespace cattle-system !
Quelques remarques :
pros
- Cette approche est extrêmement rapide à mettre en place
- Je garde une totale liberté d’action sur mon cluster Kubernetes
- Je peux toutefois bénéficier de la plupart des fonctionnalités de Rancher 2 en sus
cons
- La maintenance du cluster Kubernetes n’est pas négligeable
- L’ingress préinstallé par Rancher dans l’option A, doit ici être ajouté dans un deuxième temps, via les applications
Option C : Inception
On n’est pas là pour rigoler avec cette approche tout-en-un
Dans cette dernière stratégie, je combine deux problématiques :
- Éviter de consommer des ressources en-dehors du cluster Kubernetes.
- Rappelez-vous que dans les options A et B, j’utilise une machine virtuelle pour Rancher 2.
- Industrialiser ma façon d’installer Rancher 2 via l’outil
Helm!- Si vous souhaitez creuser Helm 3, Julien vous propose un debrief complet sur Helm 3.
Cette fois-ci, la procédure d’installation est un peu plus compliquée : Rancher 2 tourne à l’intérieur du cluster, la WebUI de Rancher 2 ne sera donc pas accessible de l’extérieur sans une configuration ad-hoc.
J’y vois deux difficultés :
- Exposer les ports 80 et 443
- Mettre en place ce qu’il faut pour obtenir un certificat x509 automatiquement
Option C Etape 1 : Installation d’un ingress
Vous pouvez passer cette étape si l’un des ingress controller connu (nginx, traefik, haproxy, …) ou inconnu tourne déjà sur votre cluster.
Kubernetes permet d’aiguiller le trafic HTTP entrant via l’utilisation de ressources ingress. J’installe donc un ingress controller afin d’exposer correctement mon service Rancher 2.
Bonne nouvelle, Kubernetes propose un ingress controller par défaut, avec un Helm chart, et la documentation ici.
Dans l’esprit générique de ce billet de blog, j’ajoute quelques options afin d’utiliser les ports 80 et 443 de mes worker nodes.
kubectl create namespace ingress-system
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm install blog-enix-rancher ingress-nginx/ingress-nginx \
--namespace ingress-system \
--set controller.hostPort.enabled=true \
--set controller.kind=DaemonSet
root@rancher-helm-1:~# kubectl get pods --namespace ingress-system
NAME READY STATUS RESTARTS AGE
blog-enix-rancher-ingress-nginx-controller-ctz5g 1/1 Running 0 30m
En me connectant en http sur l’ip du noeud, j’obtiens :
Pour une fois, c’est normal ! L'Ingress controller ne sait pas où orienter le trafic.
Option C Etape 2 : Installation de cert-manager
La documentation Rancher 2 m’indique que l’obtention d’un certificat se fera au travers de cert-manager.
Ca tombe bien, j’utilise cet outil très souvent, et je le conseille d’ailleurs vivement !
C’est re-parti pour 2 minutes de Helm :
kubectl create namespace cert-manager
helm repo add jetstack https://charts.jetstack.io
helm install cert-manager jetstack/cert-manager \
--namespace cert-manager \
--version v0.15.1 \
--set installCRDs=true
root@rancher-helm-1:~# kubectl -n cert-manager get pods
NAME READY STATUS RESTARTS AGE
cert-manager-7747db9d88-fxzlm 1/1 Running 0 14s
cert-manager-cainjector-87c85c6ff-jbwqt 1/1 Running 0 14s
cert-manager-webhook-64dc9fff44-mqxdn 1/1 Running 0 14s
A ce stade, je suis fin prêt pour lancher Rancher !
Option C Etape 3 : Rancher
On m’avait promis une installation en une ligne … la les voici !
kubectl create namespace cattle-system
helm install rancher rancher-latest/rancher \
--namespace cattle-system \
--set hostname=rancher-helm.blogpost.enix.io \
--set ingress.tls.source=letsEncrypt \
--set letsEncrypt.email=<caviardé>
Un peu de patience et vous aurez accès à votre instance en HTTPS :
Le cluster sous-jacent est utilisable immédiatement dans Rancher 2. Vous pouvez toutefois désactiver cet ajout via l’option addLocal du Helm chart à mettre à false.
Ouf, on a terminé !
Regardons dans le détail ce qui tourne sur le cluster :
root@rancher-helm-1:~# kubectl get namespace
NAME STATUS AGE
cattle-global-data Active 2m12s
cattle-global-nt Active 2m11s
cattle-system Active 3m17s
cert-manager Active 4m26s
default Active 14m
ingress-system Active 7m22s
kube-node-lease Active 14m
kube-public Active 14m
kube-system Active 14m
local Active 2m12s
p-6g7hh Active 2m12s
p-mv6gz Active 2m12s
Ca fait beaucoup de namespaces … notez local qui correspond à la configuration Rancher de ce cluster Kubernetes, les p-* qui correspondent aux projets Rancher, il y a aussi pas loin de 68 CustomResourcesDefinitions installées dans Kubernetes.
Rancher utilise en fait l'API de Kubernetes pour stocker toutes ses données, on peut donc parler d’une application stateless (si on est très ouvert d’esprit …).
pros
- Pas de ressources hors cluster Kubernetes
- Pas de stockage persistent dédié à mettre en place
- Installation de Rancher comme n’importe quelle autre application sur un cluster
cons
- En tant qu'Ops, il faut composer avec toutes ces ressources spécifiques
- Rancher rajoute de la charge sur l’API Kubernetes
- La désintallation n’est pas triviale
Conclusion
Rancher 2 est une distribution Kubernetes extrêmement flexible et mérite que vous tentiez l’aventure !
Les cas d’usages sont nombreux, les mises à jour fréquentes, et la communauté d’utilisateurs est gigantesque.
Nous organisons un workshop (gratuit) le 23 juin 2020 en collaboration avec la Cloud Native Computing Foundation et Rancher. Vous pourrez travailler en ligne avec un formateur, et découvrir l’ensemble des fonctionnalités de Rancher 2. Plus d’information ici
Ne ratez pas nos prochains articles DevOps et Cloud Native! Suivez Enix sur Twitter!