Rancher 2 : Trois Méthodes d'Installation

15 Juin 2020 • 9 min

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 : architecture Rancher 2

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 !

rancher-rke

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 :

cluster-old-version

Sur la page suivante, on me propose un wizard qui génère une ligne de commande Docker :

wizard

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 :

node registered

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 : cluster import

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 : rancher-kube

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 !

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 :

404

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

rancher helm

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!