Loading search data...

Installer un cluster Kubernetes avec sa version ultra-light K3S de Rancher

Publié le : 7 octobre 2019 | Mis à jour le : 1 mars 2023

logo kubernetes

K3s est une version ultra-light de Kubernetes développée par Rancher. Il ne nécessite que 40MB d’espace disque et 512MB de RAM pour démarrer, car il se destine avant tout pour les équipements légers comme ceux de l’IoT, des serveurs de transports edge, des RaspberryPi entre autre.

Que contient cette distribution ?

  • Tous les composants Kubernetes (kube-apiserver, kube-controller-manager, kube-scheduler, kubelet, kube-proxy
  • Docker est remplacé par containerd
  • Pour le réseau on retrouve Flannel, CoreDNS
  • Pour la gestion d’Ingress Traefik accompagné d’un simple loadBalancer
  • Par contre les plugins des cloud providers et de stockage ont été enlevés.
  • Sqlite3 remplace etcd.

Tester K3S sur un cluster de VM Ubuntu

Pour ce test je vais utiliser une machine hôte Ubuntu sur laquelle je vais provisionner 3 VM (1 master + 2 workers) avec vagrant et libvirt. Personnellement je l’utilise sur 2 mini pc: 1 KODLIX GN41 équipé d’un céléron N41000 et un autre d’un Atom Z8350

En premier lieu, il faut installer vagrant et ansible. Je vous renvoie à mes billets d’introduction sur vagrant et ansible pour cela.

Il faut ensuite cloner mon projet :

git clone git@github.com:stephrobert/k3sSandbox.git

Ensuite provisionnons nos 3 VM (pour le serveur plus sage de mettre 1GB de Ram) :

vagrant up

Installons k3s sur tous les nodes :

vagrant push

Au bout de quelques minutes, vous devriez avoir accès à votre cluster k3s.

Un petit contrôle de l’état des nodes du cluster :

ssh master1
kubectl get nodes
NAME      STATUS   ROLES                  AGE   VERSION
master1   Ready    control-plane,master   11m   v1.22.5+k3s1
worker2   Ready    <none>                 10m   v1.22.5+k3s1
worker1   Ready    <none>                 10m   v1.22.5+k3s1

Maintenant vous pouvez utiliser les commandes classiques de kubectl :

kubectl get pod -A
NAMESPACE     NAME                                     READY   STATUS      RESTARTS   AGE
kube-system   local-path-provisioner-64ffb68fd-5r6hf   1/1     Running     0          12m
kube-system   coredns-85cb69466-sgk22                  1/1     Running     0          12m
kube-system   metrics-server-9cf544f65-5qx25           1/1     Running     0          12m
kube-system   helm-install-traefik-crd--1-4cwxn        0/1     Completed   0          12m
kube-system   helm-install-traefik--1-6txdj            0/1     Completed   1          12m
kube-system   svclb-traefik-skffv                      2/2     Running     0          11m
kube-system   svclb-traefik-tn6xk                      2/2     Running     0          11m
kube-system   svclb-traefik-m65p5                      2/2     Running     0          11m
kube-system   traefik-786ff64748-dm5qp                 1/1     Running     0          11m

Destruction des VM

Il suffit de lancer la commande :

vagrant destroy -f
==> worker2: Removing domain...
==> worker2: Deleting the machine folder
==> worker1: Removing domain...
==> worker1: Deleting the machine folder
==> master1: Removing domain...
==> master1: Deleting the machine folder

Après un destroy il ne faut pas oublier de nettoyer le fichier /etc/hosts des machines master1, worker1 à n

Quelques explications sur le provisioning

Voici le fichier Vagrantfile :

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure(2) do |config|

  base_ip_str = "10.240.0.1"
  cpu_master = 1
  mem_master = 1792
  number_workers = 2 # Number of workers nodes kubernetes
  cpu_worker = 1
  mem_worker = 1024
  config.vm.box = "generic/ubuntu2004" # Image for all installations
  kubectl_version = "1.23.1-00"

  nodes = []
  (0..number_workers).each do |i|
    case i
      when 0
        nodes[i] = {
          "name" => "master#{i + 1}",
          "ip" => "#{base_ip_str}#{i}"
        }
      when 1..number_workers
        nodes[i] = {
          "name" => "worker#{i }",
          "ip" => "#{base_ip_str}#{i}"
        }
    end
  end

# Provision VM
  nodes.each do |node|
    config.vm.define node["name"] do |machine|
      machine.vm.hostname = node["name"]
      machine.vm.provider "libvirt" do |lv|
        if (node["name"] =~ /master/)
          lv.cpus = cpu_master
          lv.memory = mem_master
        else
          lv.cpus = cpu_worker
          lv.memory = mem_worker
        end
      end
      machine.vm.synced_folder '.', '/vagrant', disabled: true
      machine.vm.network "private_network", ip: node["ip"]
      machine.vm.provision "ansible" do |ansible|
        ansible.playbook = "provision.yml"
        ansible.groups = {
          "master" => ["master1"],
          "workers" => ["worker[1:#{number_workers}]"],
          "kubernetes:children" => ["masters", "workers"],
          "all:vars" => {
            "base_ip_str" => "#{base_ip_str}",
            "kubectl_version" => "#{kubectl_version}"
          }
        }
      end
    end
  end
  config.push.define "local-exec" do |push|
    push.inline = <<-SCRIPT
      ansible-playbook -i .vagrant/provisioners/ansible/inventory/vagrant_ansible_inventory master.yml
      ansible-playbook -i .vagrant/provisioners/ansible/inventory/vagrant_ansible_inventory slave.yml
    SCRIPT
  end
end

Après l’initialisation des variables et du tableau contenant tous les nodes, nous entrons dans une boucle each qui va permettre d’adapter la configuration des nodes en fonction des paramètres tirés du tableau node. Cela permet de configurer des nodes master et workers avec des ressources mem et cpu différentes.

Après cette boucle nous retrouvons une commande que j’utilise pour la première fois. La commande push permet de lancer des scripts depuis le noeud local. Pourquoi avoir choisi cette option plutôt que de tout intégrer dans le playbook lancé dans la boucle. Tout simplement que dans la boucle les playbooks ne sont pas lancé une fois, mais à chaque qu’un node devient disponible. Du coup le playbook des workers nodes se lance avant même que le token du master soit créé. Cela a comme bénéfice de pouvoir simplifier l’écriture du playbook.

Pour lancer la configuration des nodes il suffit de lancer la commande vagrant push.

Mots clés :

kubernetes k3s devops

Si vous avez apprécié cet article de blog, vous pouvez m'encourager à produire plus de contenu en m'offrant un café sur  Ko-Fi. Vous pouvez aussi passer votre prochaine commande sur amazon, sans que cela ne vous coûte plus cher, via  ce lien . Vous pouvez aussi partager le lien sur twitter ou Linkedin via les boutons ci-dessous. Je vous remercie pour votre soutien.

Autres Articles


Commentaires: