Maintenant qu’on a vu ce qu’était K8s, on va pouvoir commencer à déployer le cluster.
L’installation de K8s n’est pas simple si on veut la faire manuellement mais de nombreux outils commencent à émerger afin de nous faciliter la vie ! Ayant déjà utilisé Rancher dans ses version précédentes (avec plus ou moins de succès!), on a voulu utiliser la dernière mouture qui est entièrement basée sur K8s.
La documentation de Rancher est assez sommaire pour le moment en ce qui concerne la version 2.0 néanmoins le quick start est assez bien fait, il nous permet d’avoir un cluster Kubernetes fonctionnel.
Pour l’installation, nous avons 2 possibilités:
- Rancher Single Node
- Rancher HA (High Availability) via RKE
Dans le premier cas, nous aurons 1 serveur Rancher qui va tourner dans un docker sur un des serveurs. Celui-ci va nous servir dans un premier temps à créer un ou plusieurs clusters Kubernetes puis ensuite de les gérer. A noter qu’il est déconseillé d’inclure dans le cluster Kubernetes le serveur Rancher car Rancher utilise les ports 80 et 443 et ils seront utilisés également dans le cluster pour faire de l’Ingress sur nos applications.
Dans le deuxième cas, nous utiliserons RKE, un outils de Rancher qui permet de provisionner une cluster Kubernetes (avec ou sans Rancher) dans lequel on va déployer Rancher comme une application “standard” via Kubernetes. Avec cette méthode, Rancher est déployé en Haute dispo et sera accessible via l’ingress de Kubernetes.
A noter que pour l’instant, la version maximale de docker supportée par Rancher est la 17.03 mais j’ai fait les tests avec la version 18.03 sans souci jusqu’à maintenant.
Rancher Single Node
Pour lancer Rancher en “Single Node”, rien de plus simple, on lance une simple commande :
L’option acme-domain permet d’obtenir les certificats ssl depuis let’s encrypt et le fait de mapper le volume /var/lib/rancher sur disque permet de conserver la configuration de Rancher, ainsi, si on supprime le docker Rancher et qu’on relance cette commande, on n’aura rien perdu et les clusters provisionnés seront toujours présents dans Rancher.
L’interface de Rancher est disponible via l’url mondomaine.com (en https s’il vous plait!) et nous sommes invités à modifier le mot de passe de l’admin.
Création du cluster Kubernetes
La création d’un cluster Kubernetes se fait depuis l’interface, il est possible d’instancier directement des serveurs chez la plupart des Cloud provider (Google, AWS, OpenStack, …) ou même d’importer un cluster Kubernetes existant.
Dans notre cas, j’ai choisi l’option “Custom” puisque nous avons déjà les serveurs. Ensuite il suffit de donner un petit nom à notre cluster, ici “test”, et on peut cliquer sur “Next” !
Sur l’écran suivant, Rancher nous génère la commande qu’il faudra lancer sur les serveurs qu’on souhaite ajouter au cluster.
En fonction des cases qu’on a coché (etc, control et woker), Rancher génère la commande qu’on devra lancer sur le serveur concerné.
Sur chacun des serveur on lance la commande générée (Attention à modifier les paramètres –address et –internal-address pour chacun des serveurs) et ajouter/supprimer –etcd –controlplane –worker en fonction du type de serveur que vous souhaitez instancier.
Normalement en moins de 5 minutes on a un cluster Kubernetes fonctionnel ! Et une jolie interface qui nous montre la charge CPU et mémoire du cluster ainsi que le nombre de pods déployés.
Rancher HA (High Availability) via RKE
Documentation officielle : https://github.com/rancher/rke/wiki/Quick-Start-Guide
Comme je l’ai dit, Rancher Single Node c’est bien, c’est simple, mais on veut quand même s’assurer qu’il soit toujours disponible ^^. En plus on va avoir un cluster Kubernetes, ce truc dont tout le monde parle pour gérer automatiquement nos déploiements, pourquoi ne pas l’utiliser pour gérer le déploiement de Rancher et s’assurer qu’il soit toujours up !
Pour cela on va utiliser un outil de Rancher, RKE.
RKE est un outil en ligne de commande qui permet de provisionner un cluster Kubernetes à partir d’un fichier de configuration (qu’on va même pouvoir générer via RKE lui même !).
Prérequis
Paramétrage du firewall
Pour pouvoir discuter entre eux, les noeuds ont besoin que le port 6443 soit ouvert sur les ip internes. Pour firewalld ça se passe comme ça :
Paramétrage du ssh
Pour réaliser l’installation, RKE va créer un tunnel ssh entre la machine sur laquelle on lance rke et les machines sur lesquelles il va installer K8s. Pour cela, votre configuration SSH doit permettre le tunneling.
Sur la machine sur laquelle rke est installé et utilisé, il faut ajouter (ou décommenter) la ligne suivante dans le fichier /etc/ssh/sshd_config
Si vous rencontrez un problème de connexion ssh, il faut upgrader la version ssh à la version 7.4 (https://github.com/rancher/rke/issues/93)
Installation de RKE en local
Là encore, un simple exécutable à télécharger :
Maintenant que RKE est installé sur notre machine, on est prêt à provisionner notre cluster, il ne reste qu’à lui donner le fichier de configuration. Pour ça, soit on créé un fichier cluster.yml et on le rempli à la main (on pourra ensuite le modifier pour updater noter cluster) soit on demande à RKE de le générer.
Création du fichier de configuration
Si on est un peu fainéant alors peut passer par RKE pour générer le fichier de configuration, quitte à customiser le fichier par la suite. (ou sinon, vous pouvez copier coller mon fichier de configuration un peu plus bas ^^)
Là il va nous poser pas mal de questions, notamment les ip, user, port SSH des hosts, il suffit de répondre et on aura notre fichier cluster.yml créé dans le dossier où on a lancé la commande (pas d’inquiétude si vous vous êtes trompé, il suffira d’éditer le fichier avec de provisionner les serveurs)
Ce fichier de configuration comprend 3 parties principales:
- Déclaration des serveurs
- Spécification des images docker pour les services internes à K8s
- Déclaration des Addons (optionnel)
Les addons sont des ressources Kubernetes déclarées en yaml que RKE va instancier.
Les addons_include sont des url depuis lesquelles RKE va pouvoir télécharger les fichiers de déclaration de ressources yaml et instancier les ressources.
On pourrait par exemple déclarer les addons Rancher directement dans ce fichier de configuration et rke déploierait Rancher. Cependant, il nous manque encore quelques briques (pour gérer les certificats notamment), nous aurions donc Rancher avec des certificats auto-signés qu’il faudra mettre à jour ensuite avec les vrais certificats qu’on génèrera avec Lets Encrypt.
Voici les addons pour déployer Rancher (pour information mais nous préfèrerons déployer Rancher ensuite, via Helm.
Déploiement
Ci-dessous, vous trouverez le fichier généré, dans lequel j’ai customisé les partie kubelet et kube-api pour y ajouter des “extra-args” qui nous seront utiles ensuite lorsque nous déploierons Rook (pour le stockage distribué) ou utiliserons Stash (pour les backups).
Par défaut, rke va chercher un fichier cluster.yml dans le répertoire ou est lancée la commande rke mais il est possible de nommer ce fichier différemment et le passer en paramètre
C’est parti! Notre fichier de config est près, on peut lancer la création du cluster !
Ceci va durer quelques minutes, et installer toutes les briques propres à Kubernetes.
Une fois terminé, rke génère un fichier (toujours dans le répertoire courant) kube_config_<nom_du_fichier_conf>.yml (dans notre cas kube_config_cluster.yml).
Ce fichier est le fichier de configuration de kubectl, l’outil permettant d’interagir avec le cluster. Il contient l’url du cluster et les certificats pour s’y connecter ! ⇒ donc à garder précieusement
RKE a maintenant installé un cluster Kubernetes “vierge”, c’est un vrai cluster K8s, il n’y a pas encore de notion de Rancher à ce stade. Si vous ne souhaitez pas utiliser Rancher, vous auriez ici un cluster entièrement fonctionnel que vous pourriez utiliser avec les outils standard de K8s.
En cas de FORWARD policy à DROP, lancer les commandes suivantes :
Taints
Les “Taints” sont le moyen de Kubernetes de mettre des tags particuliers sur les nœuds qui seront utilisés par le scheduler pour savoir s’il est autorisé à déployer ou non certains Pods sur le nœud.
La version 0.1.8 de rke déclare des Taints empêchant de déployer les applications sur les master mais pas les versions antérieurs. Si vous avez utilisé une version antérieurs, vous pourrez ajouter les Taints avec les commandes
Limiter les ressources
Kubernetes a la possibilité de limiter les ressources pour un conteneur, pour un Namespace ou pour un noeud.
https://kubernetes.io/docs/concepts/policy/resource-quotas/
Il est ainsi possible de limiter le CPU, la mémoire, le nombre de pod pour un noeud ou pour un Namespace.
Il est également possible de définir des limites par défaut aux conteneurs dans un Namespace. (https://kubernetes.io/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)
Suppression du cluster
Si vous souhaitez supprimer le cluster (pour libérer les machines ou parce qu’il y a eu un souci), vous pouvez lancer la commande:
Il faut ensuite “nettoyer” la machine, surtout si vous souhaitez recommencer l’installation car sinon Kubernetes va essayer de reprendre certaines choses existante et il est très probable que cela ne fonctionne pas.
Vous noterez qu’on supprime des répertoires (rook et openebs) qui ne sont pas présents pour le moment mais le seront lorsque nous aurons déployé ces outils.
Bonjour,
Es il possible d’avoir les versions texte et non images de la configuration rke s’il vous plait? se sera plus pratique pour copier 😀
Bonjour,
Tout d’abord désolé du temps de réponse.
Vous pouvez récupérer le fichier à cette adresse : https://drive.google.com/file/d/1ncUeW7uTo9kGu9Zc8Gq3kDMoLwSxDopA/view?usp=sharing
Bien à vous.