cilium-kubernetes

Ce rôle Ansible installe le réseau Cilium sur un cluster Kubernetes. En coulisses, il utilise le Helm chart officiel. Actuellement, des procédures telles que l'installation, la mise à niveau et la suppression du déploiement Cilium sont prises en charge.

Versions

Je tague chaque version et j'essaie de respecter le versionnement sémantique. Si vous souhaitez utiliser le rôle, je vous recommande de vérifier le dernier tag. La branche master est essentiellement pour le développement, tandis que les tags marquent les versions stables. Un tag 13.0.0+1.15.3 signifie qu'il s'agit de la version 13.0.0 de ce rôle et qu'il contient la version du chart Cilium 1.15.3. Si le rôle change, la partie avant + augmentera. Si la version du chart Cilium change, la partie après + augmentera aussi. Cela permet de taguer les corrections de bogues et les nouvelles versions majeures du rôle tout en développant pour une version spécifique de Cilium.

Exigences

Vous devez avoir le binaire Helm 3 installé sur l'hôte où ansible-playbook est exécuté ou sur celui où vous avez délégué les playbooks (par exemple, en utilisant la variable cilium_delegate_to). Vous pouvez soit :

• utiliser votre gestionnaire de paquets préféré si votre distribution inclut helm dans son dépôt (par exemple, pour Archlinux utilisez sudo pacman -S helm)
• ou utiliser l'un des rôles Ansible Helm (par exemple, helm - qui est aussi installé si vous utilisez ansible-galaxy role install -vr requirements.yml)
• ou télécharger directement le binaire depuis Helm releases et le placer dans le répertoire /usr/local/bin/.

Un KUBECONFIG correctement configuré est également nécessaire (qui se trouve par défaut à ${HOME}/.kube/config). Normalement, si kubectl fonctionne avec votre cluster, alors tout devrait être en ordre à ce niveau.

De plus, la collection Ansible kubernetes.core doit être installée. Cela peut se faire en utilisant le fichier collections.yml inclus dans ce rôle : ansible-galaxy install -r collections.yml.

Et bien sûr, vous avez besoin d'un cluster Kubernetes ;-)

Installation

• Téléchargez directement depuis Github (pensez à changer dans le répertoire des rôles Ansible avant de cloner. Vous pouvez connaître le chemin du rôle en utilisant la commande ansible-config dump | grep DEFAULT_ROLES_PATH) : git clone https://github.com/githubixx/ansible-role-cilium-kubernetes.git githubixx.cilium_kubernetes

• Via la commande ansible-galaxy et téléchargez directement depuis Ansible Galaxy : ansible-galaxy install role githubixx.cilium_kubernetes

• Créez un fichier requirements.yml avec le contenu suivant (cela téléchargera le rôle depuis Github) et installez-le avec ansible-galaxy role install -r requirements.yml (changez version si nécessaire) :

---
roles:
  - name: githubixx.cilium_kubernetes
    src: https://github.com/githubixx/ansible-role-cilium-kubernetes.git
    version: 13.0.0+1.15.3

Journal des modifications

Historique des modifications :

Voir le CHANGELOG.md complet

Modifications récentes :

13.0.0+1.15.3

Modifications majeures

• modifications dans templates/cilium_values_default.yml.j2 :
  • ajout de kubeProxyReplacement, nodePort et socketLB (nécessaire car BPF masquerade nécessite NodePort)

Mise à jour

• mise à niveau vers Cilium v1.15.3

Molecule

• remplacement des boîtes Vagrant generic/ubuntu2204 par alvistack/ubuntu-22.04

12.0.0+1.15.0

• mise à niveau vers Cilium v1.15.0
• refonte de la configuration Molecule
• introduction de la variable cilium_chart_values_directory

Variables de rôle

# Version du chart Helm
cilium_chart_version: "1.15.3"

# Nom du chart Helm
cilium_chart_name: "cilium"

# URL du chart Helm
cilium_chart_url: "https://helm.cilium.io/"

# Espace de noms Kubernetes où les ressources Cilium doivent être installées
cilium_namespace: "cilium"

# Répertoire qui contient le fichier de valeurs du chart Helm. Ansible tentera de localiser
# un fichier appelé "values.yml.j2" ou "values.yaml.j2" dans le répertoire spécifié
# (".j2" car vous pouvez utiliser les habituelles fonctionnalités de template Jinja2).
# S'il n'est pas trouvé, le "templates/cilium_values_default.yml.j2" par défaut sera
# utilisé (qui peut d'ailleurs servir de template). Le contenu de ce fichier
# sera fourni à la commande "helm install/template" en tant que fichier de valeurs.
cilium_chart_values_directory: "/tmp/cilium/helm"

# paramètres etcd. Si la variable "cilium_etcd_enabled" est définie et réglée sur "true",
# les paramètres etcd de Cilium sont générés et déployés. Sinon, tous les paramètres suivants
# "cilium_etcd_*" sont ignorés.
cilium_etcd_enabled: "true"

# Interface sur laquelle les démons etcd écoutent. Si les démons etcd sont associés à
# une interface WireGuard, ce paramètre doit être "wg0" (par défaut) par exemple.
# Vous pouvez également utiliser une variable comme "{{ etcd_interface }}" si vous avez utilisé
# mon rôle etcd (https://github.com/githubixx/ansible-role-etcd)
cilium_etcd_interface: "eth0"

# Port sur lequel les démons etcd écoutent
cilium_etcd_client_port: 2379

# Groupe d'hôtes Ansible pour etcd dans le fichier "hosts" d'Ansible. Cette valeur est utilisée dans
# le template "templates/cilium_values_default.yml.j2" pour déterminer les adresses IP
# des hôtes où les démons etcd écoutent.
cilium_etcd_nodes_group: "k8s_etcd"

# Si cette variable est définie, un secret Kubernetes sera installé contenant les fichiers de certificat
# définis dans "cilium_etcd_cafile", "cilium_etcd_certfile" et "cilium_etcd_keyfile"
#
# Cela entraîne l'établissement d'une connexion sécurisée (https) à etcd.
# Cela nécessite bien sûr qu'etcd soit configuré pour utiliser SSL/TLS.
#
# Si cette valeur n'est pas définie (par exemple, commentée), le reste des paramètres "cilium_etcd_*"
# ci-dessous est ignoré et la connexion à etcd sera établie
# de manière non sécurisée via "http".
cilium_etcd_secrets_name: "cilium-etcd-secrets"

# Où trouver les fichiers de certificat définis ci-dessous. Si vous avez utilisé mon
# rôle d'Autorité de Certification Kubernetes (https://github.com/githubixx/ansible-role-kubernetes-ca)
# vous avez peut-être déjà défini la variable "k8s_ca_conf_directory" que vous
# pouvez réutiliser ici. Ce rôle génère également les fichiers de certificat qui peuvent
# être utilisés pour les variables ci-dessous.
# Par défaut, ce sera "$HOME/k8s/certs" de l'utilisateur actuel qui exécute
# la commande "ansible-playbook".
cilium_etcd_cert_directory: "{{ '~/k8s/certs' | expanduser }}"

# fichier d'autorité de certification etcd (le fichier sera récupéré dans "cilium_etcd_cert_directory")
cilium_etcd_cafile: "ca-etcd.pem"

# fichier de certificat etcd (le fichier sera récupéré dans "cilium_etcd_cert_directory")
# Assurez-vous que le certificat contient les adresses IP dans le "Nom alternatif
# du sujet" (SAN) des interfaces où les démons etcd écoutent
# (ce sont les adresses IP des interfaces définies dans "cilium_etcd_interface").
# Cela est déjà géré par mon rôle d'Autorité de Certification Kubernetes
# (https://github.com/githubixx/ansible-role-kubernetes-ca) si vous l'avez utilisé.
cilium_etcd_certfile: "cert-cilium.pem"

# fichier de clé du certificat etcd (le fichier sera récupéré dans "cilium_etcd_cert_directory")
cilium_etcd_keyfile: "cert-cilium-key.pem"

# Par défaut, toutes les tâches qui doivent communiquer avec le cluster Kubernetes
# sont exécutées sur votre hôte local (127.0.0.1). Mais si celui-ci
# n'a pas de connexion directe à ce cluster ou si cela doit être exécuté
# ailleurs, cette variable peut être modifiée en conséquence.
cilium_delegate_to: 127.0.0.1

# Montre la commande "helm" qui a été exécutée si une tâche utilise Helm pour
# installer, mettre à jour/améliorer ou supprimer une telle ressource.
cilium_helm_show_commands: false

# Sans la variable "cilium_action" définie, ce rôle ne fera que rendre un fichier
# avec toutes les ressources qui seront installées ou mises à niveau. Le fichier
# rendu avec les ressources s'appellera "template.yml" et sera
# placé dans le répertoire spécifié ci-dessous.
cilium_template_output_directory: "{{ '~/cilium/template' | expanduser }}"

Utilisation

La première chose à faire est de vérifier templates/cilium_values_default.yml.j2. Ce fichier contient les valeurs/réglages pour le chart Helm Cilium qui sont différents des valeurs par défaut qui se trouvent ici. Les valeurs par défaut de ce rôle Ansible utilisent un cluster etcd activé TLS. Si vous avez un cluster Kubernetes auto-hébergé/sur matériel, il y a de fortes chances qu'un cluster etcd soit déjà en cours d'exécution pour le serveur API Kubernetes, ce qui est mon cas. J'utilise mon rôle Ansible etcd pour installer un tel cluster etcd et mon rôle Kubernetes Certificate Authority pour générer les certificats. Donc, si vous avez utilisé mes rôles, vous pouvez utiliser ce rôle Cilium tel quel.

Le template templates/cilium_values_default.yml.j2 contient également certaines clauses if pour utiliser un cluster etcd qui n'est pas activé TLS. Consultez defaults/main.yml pour vérifier quelles valeurs peuvent être modifiées. Vous pouvez également introduire vos propres variables. Pour utiliser vos propres valeurs, créez un fichier nommé values.yml.j2 ou values.yaml.j2 et placez-le dans le répertoire spécifié par cilium_chart_values_directory. Ce rôle utilisera alors ce fichier pour rendre les valeurs Helm.

Après que le fichier de valeurs soit en place et que les valeurs de defaults/main.yml aient été vérifiées, le rôle peut être installé. La plupart des tâches du rôle sont exécutées localement par défaut car plusieurs tâches doivent communiquer avec le serveur API Kubernetes ou exécuter des commandes Helm. Mais vous pouvez déléguer ce type de tâches à un autre hôte en utilisant la variable cilium_delegate_to (voir ci-dessus). Assurez-vous simplement que l'hôte à qui vous déléguez ce genre de tâches a une connexion au serveur API Kubernetes et que l'utilisateur a un fichier KUBECONFIG valide.

L'action par défaut consiste à simplement rendre le fichier YAML des ressources Kubernetes après avoir remplacé toutes les variables et choses de Jinja2. Dans la section Exemple de Playbook ci-dessous, il y a un Exemple 2 (attribuer un tag au rôle). Le rôle githubixx.cilium_kubernetes a un tag role-cilium-kubernetes attribué. En supposant que les valeurs pour le chart Helm doivent être rendues (rien ne sera installé dans ce cas) et que le playbook est appelé k8s.yml, exécutez la commande suivante :

ansible-playbook --tags=role-cilium-kubernetes k8s.yml

Pour rendre le template dans un répertoire différent, utilisez la variable cilium_template_output_directory par exemple :

ansible-playbook --tags=role-cilium-kubernetes --extra-vars cilium_template_output_directory="/tmp/cilium" k8s.yml

Si vous souhaitez voir les commandes helm et les paramètres qui ont été exécutés dans les logs, vous pouvez spécifier --extra-vars cilium_helm_show_commands=true.

Une des dernières tâches est appelée TASK [githubixx.cilium_kubernetes : Écrire des templates dans un fichier]. Cela rend le template avec les ressources qui seront créées dans le répertoire spécifié par cilium_template_output_directory. Le fichier s'appellera template.yml. Le répertoire/le fichier sera placé sur votre machine locale pour que vous puissiez l'inspecter.

Si la sortie rendue contient tout ce dont vous avez besoin, le rôle peut être installé, ce qui déploie enfin Cilium :

ansible-playbook --tags=role-cilium-kubernetes --extra-vars cilium_action=install k8s.yml

Pour vérifier si tout a été déployé, utilisez les commandes habituelles kubectl comme kubectl -n <cilium_namespace> get pods -o wide.

Étant donné que Cilium publie des mises à jour tous les quelques semaines/mois, le rôle peut également effectuer des mises à niveau. Le rôle exécute essentiellement ce qui est décrit dans le guide de mise à niveau de Cilium. Cela signifie que la vérification pré-vol de Cilium sera installée et que certaines vérifications sont effectuées avant que la mise à jour n'ait effectivement lieu. Consultez tasks/upgrade.yml pour voir ce qui se passe avant, pendant et après la mise à niveau. Évidemment, vous devriez consulter le guide de mise à niveau de Cilium en général pour vérifier les changements majeurs avant de mettre à niveau. Assurez-vous également de consulter les Notes de mise à niveau !

En cas d'échec d'une mise à niveau, un Retour arrière vers une version précédente peut être initié en changeant simplement la variable cilium_chart_version. Mais vous devriez absolument lire le guide de retour arrière de Cilium. Le passage d'une version mineure à une autre n'est généralement pas un problème, mais passer d'une version majeure à une précédente peut ne pas être aussi simple.

Vérifiez également templates/cilium_values_default_pre_flight_check.yml.j2. Si vous devez ajuster les valeurs pour la vérification pré-vol, vous pouvez soit modifier ce fichier, soit créer un fichier templates/cilium_values_user_pre_flight_check.yml.j2 avec vos propres valeurs.

Avant de faire la mise à niveau, il vous suffit de modifier la variable cilium_chart_version par exemple, de 1.13.4 à 1.14.5 pour passer de 1.13.4 à 1.14.5. Pour effectuer la mise à jour, exécutez :

ansible-playbook --tags=role-cilium-kubernetes --extra-vars cilium_action=upgrade k8s.yml

Comme déjà mentionné, le rôle comprend déjà certaines vérifications pour s'assurer que la mise à niveau se déroule bien, mais vous devriez à nouveau vérifier avec kubectl si tout fonctionne comme prévu après la mise à niveau.

Enfin, si vous voulez vous débarrasser de Cilium, vous pouvez supprimer toutes les ressources à nouveau :

ansible-playbook --tags=role-cilium-kubernetes --extra-vars cilium_action=delete k8s.yml

Si vous n'avez pas de plugins CNI configurés, cela entraînera des erreurs CNI sur le processus kubelet sur les nœuds de travail Kubernetes de temps en temps, car il n'y a plus de choses liées au CNI et bien sûr, la connectivité entre les pods sur différents hôtes sera perdue avec toutes les politiques réseau et autres.

Exemple de Playbook

Exemple 1 (sans tag de rôle) :

- hosts: k8s_worker
  roles:
    - githubixx.cilium_kubernetes

Exemple 2 (attribuer un tag au rôle) :

-
  hosts: k8s_worker
  roles:
    -
      role: githubixx.cilium_kubernetes
      tags: role-cilium-kubernetes

Tests

Ce rôle dispose d'une petite configuration de test créée à l'aide de Molecule, libvirt (vagrant-libvirt) et QEMU/KVM. Veuillez consulter mon article de blog Tester les rôles Ansible avec Molecule, libvirt (vagrant-libvirt) et QEMU/KVM pour savoir comment configurer. La configuration de test se trouve ici.

Ensuite, molecule peut être exécuté. La commande suivante effectuera une configuration de base et créera un template des ressources (action par défaut, voir ci-dessus) qui seront créées :

molecule converge

Installer Cilium et les ressources requises. Cela mettra en place quelques machines virtuelles (MV) et installera un cluster Kubernetes. Ce paramétrage sera utilisé pour installer Cilium en utilisant ce rôle.

molecule converge -- --extra-vars cilium_action=install

La commande suivante peut être utilisée pour installer CoreDNS pour les besoins DNS de Kubernetes et étiqueter les nœuds de contrôleur afin d'exécuter uniquement les pods Cilium :

molecule converge -- --extra-vars cilium_setup_networking=install

Mise à niveau de Cilium ou modification des paramètres :

molecule converge -- --extra-vars cilium_action=upgrade

Suppression de Cilium et de ses ressources :

molecule converge -- --extra-vars cilium_action=delete

Pour exécuter quelques tests, utilisez (ajoutez optionnellement -v pour obtenir plus de détails) :

molecule verify

Pour nettoyer, exécutez :

molecule destroy

Licence

LICENCE PUBLIQUE GÉNÉRALE GNU Version 3

Informations sur l'auteur

http://www.tauceti.blog