Table des matières
Introduction
Dans le monde dynamique de la gestion des conteneurs et de l’orchestration, choisir la bonne pile de technologies est crucial pour une mise à l’échelle réussie en entreprise. Rancher, une plateforme de gestion de clusters Kubernetes, s’est imposée comme un choix populaire pour les organisations cherchant à simplifier et à optimiser leur infrastructure. Quand il est déployé avec RKE2, une distribution Kubernetes légère mais robuste, Rancher offre une solution complète pour les besoins les plus exigeants en matière de déploiement de conteneurs.
Cependant, la mise à l’échelle de cette infrastructure ne se limite pas à la simple orchestration de conteneurs. La gestion efficace de la répartition de charge (Load Balancing) est un élément clé pour garantir des performances optimales et une haute disponibilité. Dans cet article, nous explorerons comment déployer Rancher sur un cluster RKE2 et configurer une solution de répartition de charge adaptée aux besoins des entreprises modernes.
Que vous soyez un architecte de solutions cherchant à déployer Kubernetes à grande échelle ou un administrateur système curieux de savoir comment Rancher et RKE2 peuvent résoudre vos problèmes de répartition de charge, cet article est fait pour vous.
Utilisation de RKE2
RKE2, également connu sous le nom de Rancher Kubernetes Engine 2, est la deuxième génération du Rancher Kubernetes Engine (RKE), un produit de Rancher Labs. RKE2 est conçu comme une distribution Kubernetes légère, sécurisée et facile à installer. Il est spécialement conçu pour répondre aux besoins des organisations qui cherchent à adopter Kubernetes dans des environnements de production.
Caractéristiques Principales de RKE2
- Sécurité renforcée: RKE2 est conforme aux normes de sécurité comme la spécification CIS (Center for Internet Security).
- Facilité d’Installation: Il offre une installation simplifiée avec moins d’étapes et moins de complexité.
- Intégration avec Rancher: RKE2 est étroitement intégré avec la plateforme de gestion de clusters Rancher, facilitant ainsi la gestion et le monitoring.
- Prise en charge de plusieurs runtimes: RKE2 supporte à la fois containerd et Docker comme runtimes de conteneurs.
- Haute Disponibilité: Il est conçu pour supporter des architectures en haute disponibilité.
Comment ça fonctionne ?
RKE2 supprime certains composants souvent déployés en tant qu’addons dans un cluster Kubernetes standard pour les intégrer directement dans le binaire RKE2. Cela inclut notamment les projets comme CoreDNS, Helm Controller, et bien d’autres.
Installation et Configuration
L’installation de RKE2 est relativement simple. Vous pouvez le faire en utilisant un simple script d’installation ou en téléchargeant les binaires directement. La configuration peut être faite via des fichiers de configuration YAML ou des variables d’environnement.
Utilisation avec Rancher
RKE2 peut être facilement intégré à la plateforme Rancher pour une expérience de gestion unifiée. Vous pouvez utiliser Rancher pour déployer, gérer et surveiller vos clusters RKE2.
Pourquoi choisir RKE2 ?
Si vous êtes à la recherche d’une solution Kubernetes qui est à la fois facile à installer, hautement sécurisée et intégrée avec des outils de gestion puissants, RKE2 pourrait être le bon choix pour vous.
Prérequis
- Un ou plusieurs nœuds sous Linux (Ubuntu, CentOS, RHEL, etc.).
- Utilisateur avec des privilèges sudo.
- Service NTP installé et configuré
Architecture Hautement Disponible (HA)
Dans une architecture HA, vous aurez généralement au moins 3 nœuds de contrôle pour éviter le partitionnement du réseau (split-brain). Ces nœuds de contrôle hébergeront les composants du plan de contrôle de Kubernetes, tels que l’API Server, le contrôleur manager, et l’ordonnanceur (scheduler).
Dans un cluster Kubernetes, les nœuds jouent différents rôles en fonction de leurs responsabilités et des composants qu’ils exécutent. De manière générale, un cluster Kubernetes est composé de deux types de nœuds : les nœuds serveurs (aussi appelés « nœuds maîtres » ou « control plane nodes ») et les nœuds de travail (ou « nœuds workers »).
Nœud Serveur (Control Plane Node)
Un nœud serveur est responsable de la gestion globale du cluster. Il exécute des composants qui sont nécessaires pour le contrôle et l’orchestration du cluster, notamment :
- API Server: Point d’entrée pour toutes les commandes et requêtes sur le cluster.
- Etcd: Base de données distribuée qui stocke toutes les configurations et les états du cluster.
- Controller Manager: Exécute les contrôleurs qui régissent divers aspects du cluster.
- Scheduler: Responsable de l’ordonnancement des Pods sur les nœuds de travail.
Les nœuds serveurs sont essentiels pour le fonctionnement du cluster, et il est généralement recommandé d’en avoir plusieurs pour des raisons de haute disponibilité.
Nœud de Travail (Worker Node)
Un nœud de travail est là où les conteneurs (Pods) sont effectivement exécutés. Il est responsable de l’exécution des tâches assignées par le nœud serveur. Un nœud de travail exécute les composants suivants :
- Kubelet: Agent qui s’assure que les conteneurs sont en cours d’exécution dans les Pods.
- Kube-proxy: Gère les règles de réseau sur les nœuds pour acheminer le trafic vers les Pods.
- Container Runtime: Logiciel pour exécuter des conteneurs (comme Docker ou containerd).
Résumé
- Nœud Serveur: Gère et contrôle l’état global du cluster.
- Nœud de Travail: Exécute les applications et les services dans des conteneurs.
Dans certains cas, notamment pour des petits environnements ou des déploiements de test, les mêmes nœuds peuvent jouer les deux rôles, mais cela n’est généralement pas recommandé pour les environnements de production pour des raisons de sécurité et de performance.
Installation du premier nœud serveur
On lance la commande d’installation :
curl -sfL https://get.rke2.io | sh -
Si vous voulez installer une version spécifique, vous pouvez passer des paramètres à l’installeur :
curl -sfL https://get.rke2.io | INSTALL_RKE2_CHANNEL=v1.20 sh -
Activez et démarrez le service RKE2 :
systemctl enable rke2-server.service systemctl start rke2-server.service
Vérifiez que RKE2 est en cours d’exécution :
systemctl status rke2-server.service
Récupérez le jeton du serveur :
cat /var/lib/rancher/rke2/server/node-token
Conservez ce jeton car il sera nécessaire pour ajouter des nœuds au cluster.
Pour voir les logs :
journalctl -u rke2-server -f
Installation des 2 autres nœuds serveurs
Il suffit de créer le fichier de configuration dans /etc/rancher/rke2.
On va déjà créer le répertoire :
mkdir -p /etc/rancher/rke2/
Puis on va indiquer la configuration afin que le nouveau noeud serveur s’interface avec le serveur déjà installé :
server: https://server1.domain.com:9345 token: my-shared-secret tls-san: - my-kubernetes-domain.com - another-kubernetes-domain.com
my-shared-secret est le jeton que vous aurez récupéré au préalable sur le serveur (server1.domain.com) via la commande :cat /var/lib/rancher/rke2/server/node-token
Il ne reste plus qu’à lancer la commande :
curl -sfL https://get.rke2.io | sh - systemctl enable rke2-server.service systemctl start rke2-server.service
Installation des 2 noeuds de travail
Worker Linux
Lancement de l’installation :
curl -sfL https://get.rke2.io | INSTALL_RKE2_TYPE="agent" sh -
Activez le service RKE2 agent :
systemctl enable rke2-agent.service
On configure alors le service pour s’intégrer aux autres noeuds :
mkdir -p /etc/rancher/rke2/ vim /etc/rancher/rke2/config.yaml
Contenu du fichier :
server: https://server1.domain.com:9345 token: my-shared-secret
On démarre le service :
systemctl start rke2-agent.service
Pour voir les logs :
journalctl -u rke2-agent -f
Worker Windows
L’ajout de nœuds de travail (workers) Windows à un cluster RKE2 est une opération plus complexe que pour les nœuds Linux. RKE2 lui-même est principalement conçu pour les environnements Linux. Cependant, il est possible d’intégrer des nœuds Windows dans un cluster Kubernetes géré par RKE2, mais cela nécessite quelques étapes supplémentaires et des précautions particulières.
Points à Considérer :
- Version de Windows: Assurez-vous d’utiliser une version de Windows Server compatible avec la version de Kubernetes que vous utilisez.
- Fonctionnalités Windows: Vous devrez activer certaines fonctionnalités Windows, comme les conteneurs, avant d’installer les composants de Kubernetes.
- Réseau: Le réseau doit être correctement configuré pour permettre la communication entre les nœuds Windows et Linux.
Étapes de Base :
- Préparation du Nœud Windows: Installez les fonctionnalités nécessaires et préparez le nœud pour rejoindre le cluster. Pour ce faire, sous Powershell :
Install-WindowsFeature -Name OpenSSH.Server, Containers
- Installation de Docker: Docker est généralement utilisé comme runtime de conteneur sur les nœuds Windows. Vous pouvez utiliser chocolatey pour cela.
choco install docker-desktop choco install kubernetes-cli
- Rejoindre le Cluster: Utilisez
kubeadmou un autre outil similaire pour rejoindre le nœud Windows au cluster. Vous aurez besoin du jeton du cluster et de l’adresse IP du nœud principal.
kubeadm join --token=<JETON_DU_CLUSTER> <IP_DU_SERVEUR_PRINCIPAL>:<PORT>
- Vérification: Une fois le nœud ajouté, vous pouvez vérifier son statut à l’aide de
kubectl get nodes. - Déploiement des Pods: Vous pouvez maintenant déployer des pods sur le nœud Windows en utilisant des fichiers de manifeste YAML spécifiques à Windows.
Limitations et Précautions :
- Les nœuds Windows ne peuvent exécuter que des conteneurs Windows.
- Certaines fonctionnalités de Kubernetes ne sont pas disponibles sur les nœuds Windows.
- Le dépannage peut être plus complexe en raison des différences entre les environnements Windows et Linux.
Pour une intégration réussie, il est fortement recommandé de suivre la documentation officielle de Kubernetes sur les clusters Windows.
Cas d’un proxy
Si vous avez un proxy d’entreprise, vous aurez besoin de l’indiquer dans vos variables d’environnement.
Dans /etc/environnement :
export http_proxy=http://proxy.in.domain.com:8080 export https_proxy=http://proxy.in.domain.com:8080 export ftp_proxy=http://proxy.in.domain.com:8080 export HTTP_PROXY=http://proxy.in.domain.com:8080 export HTTPS_PROXY=http://proxy.in.domain.com:8080 export FTP_PROXY=http://proxy.in.domain.com:8080 export NO_PROXY="localhost,127.0.0.1,localaddress,localdomain.com,in.domain.com,in.domain.com,172.XX.XXX.XX/28" export no_proxy="localhost,127.0.0.1,localaddress,localdomain.com,in.domain.com,in.domain.com,172.XX.XXX.XX/28"
Dans notre configuration, nous avions aussi indiqué dans le fichier /etc/default/rke2-server :
HTTP_PROXY=http://proxy.in.domain.com:8080 HTTPS_PROXY=http://proxy.in.domain.com:8080 NO_PROXY=localhost,127.0.0.1,localaddress,localdomain.com,in.domain.com,127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.svc,.cluster.local http_proxy=http://proxy.in.domain.com:8080 https_proxy=http://proxy.in.domain.com:8080 no_proxy=localhost,127.0.0.1,localaddress,localdomain.com,in.domain.com,127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.svc,.cluster.local
Ajout des binaires dans le path
RKE2 déploie les utilitaires essentiels (kubectl, crictl et ctr) dans le répertoire /var/lib/rancher/rke2/bin/.
On va ajouter ces binaires dans /etc/environment :
sudo nano /etc/environment
Ajoutez le chemin à la fin de la ligne PATH :
PATH="...:/var/lib/rancher/rke2/bin"
Note : Remplacez ... par les autres répertoires déjà présents dans le PATH.
Redémarrez le système ou la session utilisateur pour appliquer les changements.
Installation de helm
Vous avez toute la procédure sur le site officiel : Helm | Installing Helm
La commande principale en fonction de la version est :
curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash
Après l’installation, vous pouvez vérifier que Helm est correctement installé en exécutant :
helm versionInstallation de cert-manager (en fonction)
Dans le cas où vous avez votre propre certificat, le plus simple étant un wildcard, vous n’avez alors pas besoin de déployer cert-manager.
Vous devriez passer cette étape si vous apportez vos propres fichiers de certificat (option ingress.tls.source=secret), ou si vous utilisez la terminaison TLS sur un équilibreur de charge externe.
Cette étape n’est requise que pour utiliser des certificats délivrés par l’autorité de certification générée par Rancher (ingress.tls.source=rancher) ou pour demander des certificats émis par Let’s Encrypt (ingress.tls.source=letsEncrypt).
Étapes d’Installation
Créez un espace de noms pour cert-manager. Cet espace de noms hébergera les ressources de cert-manager :
kubectl create namespace cert-manager
Ajoutez le dépôt Helm de Jetstack, qui héberge le chart de cert-manager :
helm repo add jetstack https://charts.jetstack.io helm repo update
Installez les CustomResourceDefinitions (CRD) pour cert-manager. Ces CRD sont nécessaires pour que cert-manager fonctionne correctement :
kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v1.13.0/cert-manager.crds.yaml
Note: Remplacez v1.13.0 par la version de cert-manager que vous souhaitez installer, si différente.
Installez cert-manager en utilisant Helm :
helm install cert-manager jetstack/cert-manager \ --namespace cert-manager \ --version v1.13.0
Note: Remplacez v1.13.0 par la version de cert-manager que vous souhaitez installer, si différente.
Après l’installation, vous pouvez vérifier que les pods de cert-manager sont en cours d’exécution :
kubectl get pods --namespace cert-manager
Vous devriez voir trois pods : cert-manager, cert-manager-cainjector, et cert-manager-webhook, tous en état de fonctionnement.
Configuration Load Balancer et DNS (si besoin)
Sur le cloud
Cette documentation ne couvre pas vraiment l’usage des outils cloud des fournisseurs mondiaux principaux. C’est donc un aparté pour configurer facilement l’accès à vos nœuds si vous êtes dans ce cas.
Sur des outils en ligne comme google cloud, AWS ou azure, vous avez des loads balancers intégrés.
Google Cloud (GCP)
- Répartiteur de charge : Google Cloud propose des répartiteurs de charge HTTP(S) (Layer 7) et TCP/SSL (Layer 4). GCP fournit des contrôleurs d’Ingress intégrés qui automatisent la configuration des répartiteurs de charge HTTP(S) et TCP/SSL. Vous pouvez définir des ressources d’Ingress dans votre cluster Kubernetes, et le contrôleur GCP s’occupe du reste.
- DNS : Google Cloud DNS permet de configurer des enregistrements DNS comme A ou CNAME. Avec Vous pouvez automatiser la gestion des enregistrements DNS en utilisant des annotations ou des Operators spécifiques à Kubernetes.
Amazon Web Services (AWS)
- Répartiteur de charge : AWS propose Elastic Load Balancing avec des options pour les répartiteurs de charge de couche 7 (Application Load Balancer) et de couche 4 (Network Load Balancer). AWS propose des contrôleurs d’Ingress comme le AWS Load Balancer Controller qui automatise la création et la gestion des Application Load Balancers (ALB) et Network Load Balancers (NLB).
- DNS : Amazon Route 53 est le service DNS qui permet de créer des enregistrements A ou CNAME. Amazon Route 53 peut être intégré avec des services comme ExternalDNS pour automatiser la création d’enregistrements DNS basés sur des ressources d’Ingress ou des Services dans Kubernetes.
Microsoft Azure
- Répartiteur de charge : Azure propose des répartiteurs de charge Standard et Basic qui peuvent être configurés pour la répartition de charge de couche 4. Il existe aussi Azure Application Gateway pour la répartition de charge de couche 7. Azure propose l’Azure Kubernetes Load Balancer qui est créé automatiquement avec l’Azure Kubernetes Service (AKS). Il peut aussi être géré via des ressources d’Ingress en utilisant des annotations spécifiques à Azure.
- DNS : Azure DNS permet de configurer des enregistrements DNS comme A ou CNAME. Azure DNS peut être intégré avec Kubernetes via des solutions comme ExternalDNS, qui peut automatiquement créer des enregistrements DNS basés sur des ressources d’Ingress ou des Services.
Méthode très basique : le round robin DNS (à des fins de test)
Si vous n’utilisez pas de répartiteur de charge, vous pouvez utiliser un DNS en mode « Round Robin » pour répartir le trafic entre vos nœuds. Cependant, il faut noter que cette méthode est beaucoup moins sophistiquée qu’un répartiteur de charge et ne prend pas en compte la santé des nœuds ou d’autres métriques plus avancées pour le routage du trafic.
Si vous avez vos 3 nœuds maîtres ayant les IP 192.168.1.1, 192.168.1.2 et 192.168.1.3, vous pouvez créer un enregistrement wildcard de ce type :
*.example.com pointe vers 192.168.1.1, 192.168.1.2 et 192.168.1.3
Ainsi vous pouvez déployer vos applications via ingress et comme le DNS répondra en round robin sur vos 3 serveurs, vous pourrez publier facilement vos applications.
Pas de vérification de la santé des nœuds : Le DNS en mode « Round Robin » ne vérifie pas si un nœud est en panne. Si un nœud tombe en panne, le DNS continuera à y diriger le trafic jusqu’à ce que vous mettiez à jour les enregistrements DNS.
Configuration d’une solution de Load Balancing locale type F5 ou HAProxy
HAProxy
Prérequis
- HAProxy installé sur une machine dédiée dans la bonne zone pour pouvoir attaquer les noeuds
- DNS configuré en wildcard sur votre domaine pour attaquer HAProxy
L’utilisation de HAProxy comme répartiteur de charge pour un cluster Rancher RKE2 est une option robuste et fiable. Voici comment configurer HAProxy pour répartir la charge.
Ouvrez le fichier de configuration HAProxy, généralement situé à /etc/haproxy/haproxy.cfg, dans un éditeur de texte.
sudo nano /etc/haproxy/haproxy.cfg
Ajoutez ou modifiez la section frontend pour écouter sur les ports 80 (HTTP) et 443 (HTTPS).
frontend http_front
bind *:80
mode tcp
default_backend http_back
frontend https_front
bind *:443 ssl crt /etc/haproxy/certs/my-cert.pem # Remplacez par votre propre certificat
mode tcp
default_backend https_back
Dans cet exemple, nous utilisons un certificat SSL (my-cert.pem) pour le HTTPS. Remplacez cela par votre propre certificat.
Ajoutez ou modifiez la section backend pour inclure vos nœuds master et de travail :
backend http_back
mode tcp
balance leastconn
server master1 192.168.1.1:80 check port 6443 check-ssl verify none
server master2 192.168.1.2:80 check port 6443 check-ssl verify none
server master3 192.168.1.3:80 check port 6443 check-ssl verify none
backend https_back
mode tcp
balance leastconn
option ssl-hello-chk
server master1 192.168.1.1:443 check port 6443 check-ssl verify none
server master2 192.168.1.2:443 check port 6443 check-ssl verify none
server master3 192.168.1.3:443 check port 6443 check-ssl verify none
Ici, nous utilisons l’algorithme de répartition de charge leastconn (mais il existe roundrobin, source, first, etc.).
Après avoir effectué ces modifications, validez la configuration d’HAProxy et redémarrez le service :
sudo haproxy -c -f /etc/haproxy/haproxy.cfg sudo systemctl restart haproxy
Assurez-vous que votre enregistrement DNS pour Rancher pointe vers l’adresse IP de votre répartiteur de charge HAProxy. C’est à dire faire pointer votre wildcard DNS vers HAProxy. Par exemple si le serveur HAProxy est sur l’adresse 192.168.1.253 :
* IN A 192.168.1.253
BIGIP F5
Prérequis
- BIGIP F5 installé sur une ou plusieurs machines dédiées dans la bonne zone pour pouvoir attaquer les nœuds
- DNS configuré en wildcard sur votre domaine pour attaquer le ou les serveurs F5
Configuration de la pool
On fait un check sur le port 6443 (kubernetes apiserver) :
Onglet « Members »
Faire de même pour le port 80.
Configuration du Virtual Server
Pour le port 443 :
Onglet « Resources »
Faire de même pour le port 80.
Installation de MetalLB
MetalLB est une solution d’équilibrage de charge pour les clusters Kubernetes qui ne disposent pas d’un équilibrage de charge natif ou qui sont déployés sur des infrastructures bare-metal.
Comme vous le savez, parmi les fonctionnalités offertes par Kubernetes, il y a la possibilité de créer des services, qui sont des abstractions pour exposer des pods à l’extérieur du cluster. Il existe différents types de services, dont le plus courant est le ClusterIP, qui expose un service sur une adresse IP interne au cluster. Mais il y a aussi le NodePort, qui expose un service sur un port spécifique de chaque nœud du cluster, et le LoadBalancer, qui expose un service sur une adresse IP externe au cluster, en utilisant un équilibreur de charge (loadbalancer) physique ou virtuel.
Toutefois, le type de service LoadBalancer n’est pas disponible sur tous les environnements Kubernetes. Il nécessite en effet que le fournisseur d’infrastructure (cloud ou on-premise) dispose d’un équilibreur de charge compatible avec Kubernetes. C’est le cas des services Kubernetes managés dans le cloud, comme GCP ou AWS, qui utilisent leurs propres équilibreurs de charge intégrés à leurs plateformes. Mais ce n’est pas le cas des clusters Kubernetes déployés sur des machines virtuelles ou bare metal, qui ne disposent pas d’un équilibreur de charge natif.
C’est là qu’intervient MetalLB, une solution open source qui permet de créer des services de type LoadBalancer sur des clusters Kubernetes sans équilibreur de charge natif. MetalLB se charge d’attribuer une adresse IP externe à chaque service LoadBalancer et de router le trafic vers les pods correspondants.
Installer MetalLB en mode layer 2 est probablement la meilleure option. Ce mode est le plus simple à configurer et est souvent suffisant pour les besoins de base en équilibrage de charge dans un cluster Kubernetes. MetalLB en mode layer 2 attribuera une adresse IP à partir d’un pool défini à chaque service Kubernetes de type LoadBalancer que vous créez.
Configuration du réseau
- Plage d’adresses IP: Assurez-vous que la plage d’adresses IP que vous avez réservée pour MetalLB ne soit pas en conflit avec d’autres dispositifs sur votre réseau. Cette plage doit être une sous-partie de votre réseau local, mais elle ne doit pas être gérée par DHCP ou attribuée à d’autres dispositifs.
- Routeur/Gateways: Configurez votre routeur ou votre gateway pour que le trafic destiné à la plage d’adresses IP de MetalLB soit acheminé vers le réseau où se trouvent vos nœuds Kubernetes. Cela peut généralement être fait en ajoutant une route statique.
- Règles de pare-feu: Si vous avez un pare-feu, assurez-vous qu’il est configuré pour permettre le trafic entrant vers la plage d’adresses IP de MetalLB et vers les nœuds de votre cluster Kubernetes.
Étape 1 : Ajouter le repo Helm de MetalLB
helm repo add metallb https://metallb.github.io/metallb helm repo update
Étape 2 : Créer un fichier de configuration
Créez un fichier YAML appelé metallb-values.yaml avec le contenu suivant :
configInline:
address-pools:
- name: default
protocol: layer2
addresses:
- 192.168.1.50-192.168.1.59
Ce fichier configure MetalLB pour utiliser le mode layer2 et définit le pool d’adresses IP à utiliser (à adapter à votre configuration, là nous n’avons que 10 adresses Ip de disponibles pour déclarer des services dans notre cluster).
Étape 3 : Installer MetalLB avec Helm
Utilisez Helm pour installer MetalLB en utilisant le fichier de configuration que vous venez de créer :
helm install metallb metallb/metallb -f metallb-values.yaml --namespace metallb-system --create-namespace
Cette commande installe MetalLB dans le namespace metallb-system (et crée le namespace si nécessaire) en utilisant les valeurs spécifiées dans metallb-values.yaml.
Pour vérifier que tout a bien fonctionné, vous pouvez lister les pods dans le namespace metallb-system :
kubectl get pods -n metallb-system
Installation de Rancher
Helm utilise un dépôt de paquets pour distribuer les charts, qui sont les packages Helm.
On s’appuie donc sur helm pour ajouter la chart pour Rancher :
helm repo add rancher-stable https://releases.rancher.com/server-charts/stable
Mettez à jour les informations du dépôt Helm pour vous assurer que vous installez la dernière version :
helm repo update
Créer un espace de noms pour Rancher
kubectl create namespace cattle-system
Utilisation de votre propre certificat (si besoin)
Dans le cas où vous avez votre propre certificat, le plus simple étant un wildcard, vous n’avez alors pas besoin de déployer cert-manager.
Pour installer le certificat, il vous faudra le .crt en format PEM et la clef non encryptée en extension .key (généré pour la création du certificat). Puis vous connecter sur un des nœuds maîtres, copier le .crt et le .key dans le répertoire courant.
Par exemple pour les 2 fichiers tls.crt et tls.key, il faut lancer la commande :
kubectl -n cattle-system create secret tls tls-rancher-ingress --cert=tls.crt --key=tls.key --dry-run --save-config -o yaml | kubectl apply -f -
Installation du client UI
helm install rancher rancher-stable/rancher --namespace cattle-system --set hostname=rancher.your-domain.com --set replicas=3
Note: Remplacez rancher.your-domain.com par le nom de domaine que vous avez configuré pour pointer vers votre cluster.
Options spécifiques si proxy
helm install rancher rancher-stable/rancher \ --namespace cattle-system \ --set hostname=rancher.your-domain.com \ --set proxy="http://your-proxy-here:port" \ --set noProxy="127.0.0.0/8\,10.0.0.0/8\,cattle-system.svc\,172.16.0.0/12\,192.168.0.0/16\,.svc\,.cluster.local"
Vérifier l’installation
kubectl -n cattle-system rollout status deploy/rancher
Vous devriez voir un message indiquant que le déploiement a réussi.
Accès à l’interface utilisateur de Rancher
Après l’installation, vous devriez être capable d’accéder à Rancher en utilisant le nom de domaine que vous avez configuré (rancher.your-domain.com dans cet exemple). Vous pouvez naviguer vers ce domaine dans votre navigateur web, où vous serez accueilli par l’interface utilisateur de Rancher.
