cilium-kubernetes

Diese Ansible-Rolle installiert das Cilium Netzwerk auf einem Kubernetes-Cluster. Intern verwendet sie das offizielle Helm-Chart. Momentan werden Verfahren wie Installieren, Aktualisieren und Löschen der Cilium-Bereitstellung unterstützt.

Versionen

Ich kennzeichne jede Version und versuche, bei semantischer Versionierung zu bleiben. Wenn Sie die Rolle verwenden möchten, empfehle ich, den neuesten Tag zu verwenden. Der Master-Zweig ist hauptsächlich für die Entwicklung, während die Tags stabile Versionen markieren. Ein Tag 13.0.0+1.15.3 bedeutet, dass dies die Version 13.0.0 dieser Rolle ist und sie die Cilium-Chart-Version 1.15.3 enthält. Wenn sich die Rolle selbst ändert, wird X.Y.Z vor dem + erhöht. Wenn sich die Cilium-Chart-Version ändert, wird X.Y.Z nach dem + ebenfalls erhöht. Dadurch können Fehlerbehebungen und neue Hauptversionen der Rolle getaggt werden, während sie weiterhin für eine bestimmte Cilium-Version entwickelt wird.

Anforderungen

Sie müssen die Binary Helm 3 auf dem Host installiert haben, auf dem ansible-playbook ausgeführt wird, oder auf dem Host, auf den die Playbooks delegiert wurden (z.B. durch die Verwendung der cilium_delegate_to-Variable). Sie können entweder

• Ihren bevorzugten Paketmanager verwenden, wenn Ihre Distribution helm in ihrem Repository hat (z.B. für Archlinux sudo pacman -S helm verwenden)
• oder eine der Ansible Helm-Rollen verwenden (z.B. helm - die auch installiert wird, wenn Sie ansible-galaxy role install -vr requirements.yml verwenden)
• oder die Binary direkt von Helm Releases herunterladen und in das Verzeichnis /usr/local/bin/ legen.

Ein korrekt konfiguriertes KUBECONFIG ist ebenfalls erforderlich (standardmäßig befindet es sich bei ${HOME}/.kube/config). Wenn kubectl normalerweise mit Ihrem Cluster funktioniert, sollte dies in dieser Hinsicht bereits in Ordnung sein.

Zusätzlich muss die Ansible kubernetes.core-Kollektion installiert sein. Dies kann mit der im Paket enthaltenen collections.yml-Datei erfolgen: ansible-galaxy install -r collections.yml.

Und natürlich benötigen Sie einen Kubernetes-Cluster ;-)

Installation

• Direkt von GitHub herunterladen (wechseln Sie in das Verzeichnis der Ansible-Rollen, bevor Sie klonen. Sie können den Rollenpfad herausfinden, indem Sie den Befehl ansible-config dump | grep DEFAULT_ROLES_PATH verwenden): git clone https://github.com/githubixx/ansible-role-cilium-kubernetes.git githubixx.cilium_kubernetes

• Über den ansible-galaxy-Befehl und direkt von Ansible Galaxy herunterladen: ansible-galaxy install role githubixx.cilium_kubernetes

• Erstellen Sie eine requirements.yml-Datei mit dem folgenden Inhalt (dies wird die Rolle von GitHub herunterladen) und installieren Sie sie mit ansible-galaxy role install -r requirements.yml (ändern Sie version, wenn nötig):

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

Änderungsprotokoll

Änderungshistorie:

Siehe das vollständige CHANGELOG.md

Neueste Änderungen:

13.0.0+1.15.3

Brechend

• Änderungen in templates/cilium_values_default.yml.j2:
  • Hinzugefügt: kubeProxyReplacement, nodePort und socketLB (dies ist erforderlich, da BPF-Masquerade NodePort benötigt)

Aktualisierung

• Upgrade auf Cilium v1.15.3

Molecule

• Vagrant generic/ubuntu2204-Boxes durch alvistack/ubuntu-22.04 ersetzt

12.0.0+1.15.0

• Upgrade auf Cilium v1.15.0
• Neuordnung der Molecule-Einrichtung
• Einführung der cilium_chart_values_directory-Variable

Rollenvariablen

# Helm-Chart-Version
cilium_chart_version: "1.15.3"

# Helm-Chart-Name
cilium_chart_name: "cilium"

# Helm-Chart-URL
cilium_chart_url: "https://helm.cilium.io/"

# Kubernetes-Namespace, in dem Cilium-Ressourcen installiert werden sollen
cilium_namespace: "cilium"

# Verzeichnis, das die Helm-Chart-Werte-Datei enthält. Ansible versucht, eine 
# Datei mit dem Namen "values.yml.j2" oder "values.yaml.j2" im angegebenen 
# Verzeichnis zu finden (".j2", weil Sie dort die üblichen Jinja2-Vorlage-Dinge 
# nutzen können).
# Wenn nicht gefunden, wird die Standarddatei "templates/cilium_values_default.yml.j2" 
# verwendet (die übrigens auch als Vorlage verwendet werden kann). Der Inhalt dieser Datei
# wird dem Befehl "helm install/template" als Werte-Datei bereitgestellt.
cilium_chart_values_directory: "/tmp/cilium/helm"

# etcd-Einstellungen. Wenn die Variable "cilium_etcd_enabled" definiert und auf "true" 
# gesetzt ist, werden die etcd-Einstellungen für Cilium generiert und bereitgestellt. 
# Andernfalls werden alle folgenden "cilium_etcd_*"-Einstellungen ignoriert.
cilium_etcd_enabled: "true"

# Schnittstelle, auf der die etcd-Daemons lauschen. Wenn die etcd-Daemons an 
# einer WireGuard-Schnittstelle gebunden sind, sollte diese Einstellung "wg0" (standardmäßig) 
# sein.
# Sie können auch eine Variable wie "{{ etcd_interface }}" verwenden, 
# wenn Sie meine etcd-Rolle verwendet haben (https://github.com/githubixx/ansible-role-etcd)
cilium_etcd_interface: "eth0"

# Port, auf dem die etcd-Daemons lauschen
cilium_etcd_client_port: 2379

# Ansible etcd-Hostgruppe in der Ansible "hosts"-Datei. Dieser Wert wird in 
# der Vorlage "templates/cilium_values_default.yml.j2" verwendet, um die IP-Adressen 
# der Hosts zu bestimmen, auf denen die etcd-Daemons lauschen.
cilium_etcd_nodes_group: "k8s_etcd"

# Wenn diese Variable definiert ist, wird ein Kubernetes-Geheimnis installiert, das 
# die Zertifikatdateien enthält, die in "cilium_etcd_cafile", "cilium_etcd_certfile" 
# und "cilium_etcd_keyfile" definiert sind.
# Dies sorgt dafür, dass eine sichere Verbindung (https) zu etcd hergestellt wird.
# Dies erfordert natürlich, dass etcd so konfiguriert ist, dass SSL/TLS verwendet wird.
# Wenn dieser Wert nicht definiert ist (z.B. kommentiert), werden die restlichen 
# "cilium_etcd_*"-Einstellungen ignoriert und die Verbindung zu etcd wird unsicher 
# über "http" hergestellt.
cilium_etcd_secrets_name: "cilium-etcd-secrets"

# Wo die Zertifikatdateien, die unten definiert sind, gefunden werden können. 
# Wenn Sie meine Kubernetes-Zertifizierungsstelle (https://github.com/githubixx/ansible-role-kubernetes-ca) verwendet haben, 
# haben Sie möglicherweise bereits die Variable "k8s_ca_conf_directory" definiert, 
# die Sie hier wiederverwenden können. Diese Rolle generiert auch die Zertifikatdateien, 
# die für die unten definierten Variablen verwendet werden können.
# Standardmäßig wird dies "$HOME/k8s/certs" des aktuellen Benutzers sein, der den 
# Befehl "ansible-playbook" ausführt.
cilium_etcd_cert_directory: "{{ '~/k8s/certs' | expanduser }}"

# etcd-Zertifizierungsstellen-Datei (die Datei wird im 
# "cilium_etcd_cert_directory" abgerufen)
cilium_etcd_cafile: "ca-etcd.pem"

# etcd-Zertifikat-Datei (die Datei wird im 
# "cilium_etcd_cert_directory" abgerufen)
# Stellen Sie sicher, dass das Zertifikat die IP-Adressen im "Subject
# Alternative Name" (SAN) der Schnittstellen, auf denen die etcd-Daemons lauschen, 
# enthält (das sind die IP-Adressen der in "cilium_etcd_interface" definierten 
# Schnittstellen). 
# Dies wird bereits von meiner Kubernetes-Zertifizierungsstelle (https://github.com/githubixx/ansible-role-kubernetes-ca) 
# behandelt, wenn Sie diese verwendet haben.
cilium_etcd_certfile: "cert-cilium.pem"

# etcd-Zertifikat-Schlüssel-Datei (die Datei wird im 
# "cilium_etcd_cert_directory" abgerufen)
cilium_etcd_keyfile: "cert-cilium-key.pem"

# Standardmäßig werden alle Aufgaben, die mit dem Kubernetes-Cluster kommunizieren 
# müssen, auf Ihrem lokalen Host (127.0.0.1) ausgeführt. Wenn dieser keine 
# direkte Verbindung zu diesem Cluster hat oder andernorts ausgeführt werden soll, 
# kann diese Variable entsprechend geändert werden.
cilium_delegate_to: 127.0.0.1

# Zeigt den "helm"-Befehl, der ausgeführt wurde, wenn eine Aufgabe Helm 
# verwendet, um eine solche Ressource zu installieren, zu aktualisieren/upgraden oder zu löschen.
cilium_helm_show_commands: false

# Wenn die Variable "cilium_action" nicht definiert ist, wird diese Rolle 
# nur eine Datei mit allen Ressourcen rendern, die installiert oder aktualisiert 
# werden. Die gerenderte Datei mit den Ressourcen wird "template.yml" genannt 
# und wird im unten angegebenen Verzeichnis platziert.
cilium_template_output_directory: "{{ '~/cilium/template' | expanduser }}"

Nutzung

Der erste Schritt besteht darin, die Datei templates/cilium_values_default.yml.j2 zu überprüfen. Diese Datei enthält die Werte/Einstellungen für das Cilium-Helm-Chart, die sich von den Standardwerten unterscheiden, die hier zu finden sind. Die Standardwerte dieser Ansible-Rolle verwenden einen TLS-aktivierten etcd-Cluster. Wenn Sie einen selbst gehosteten/baren Kubernetes-Cluster haben, besteht eine hohe Wahrscheinlichkeit, dass bereits ein etcd-Cluster für den Kubernetes-API-Server ausgeführt wird, was in meinem Fall der Fall ist. Ich verwende meine Ansible etcd-Rolle, um einen solchen etcd-Cluster zu installieren, und meine Kubernetes-Zertifizierungsstelle-Rolle, um die Zertifikate zu generieren. Wenn Sie meine Rollen verwendet haben, können Sie diese Cilium-Rolle im Grunde so verwenden, wie sie ist.

Die Vorlage templates/cilium_values_default.yml.j2 enthält auch einige if-Klauseln, um einen etcd-Cluster zu verwenden, der nicht TLS-aktiviert ist. Siehe defaults/main.yml, um zu überprüfen, welche Werte geändert werden können. Sie können auch Ihre eigenen Variablen einführen. Um Ihre eigenen Werte zu verwenden, erstellen Sie einfach eine Datei mit dem Namen values.yml.j2 oder values.yaml.j2 und legen Sie sie in das im cilium_chart_values_directory angegebene Verzeichnis. Dann wird diese Rolle diese Datei verwenden, um die Helm-Werte zu rendern.

Nachdem die Werte-Datei an ihrem Platz ist und die Werte in defaults/main.yml überprüft wurden, kann die Rolle installiert werden. Die meisten Aufgaben der Rolle werden standardmäßig lokal ausgeführt, da viele Aufgaben mit dem Kubernetes-API-Server oder beim Ausführen von Helm-Befehlen kommunizieren müssen. Aber Sie können diese Art von Aufgaben an einen anderen Host delegieren, indem Sie die cilium_delegate_to-Variable verwenden (siehe oben). Stellen Sie nur sicher, dass der Host, an den Sie diese Aufgaben delegieren, eine Verbindung zum Kubernetes-API-Server hat und der Benutzer eine gültige KUBECONFIG-Datei hat.

Die Standardaktion besteht darin, die YAML-Datei der Kubernetes-Ressourcen zu rendern, nachdem alle Jinja2-Variablen und solche Dinge ersetzt wurden. Im Abschnitt Beispiel-Playbook unten gibt es ein Beispiel 2 (Tag der Rolle zuweisen). Der Rolle githubixx.cilium_kubernetes wurde das Tag role-cilium-kubernetes zugewiesen. Angenommen, die Werte für das Helm-Chart sollen gerendert werden (in diesem Fall wird nichts installiert), und das Playbook wird k8s.yml genannt, führen Sie den folgenden Befehl aus:

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

Um die Vorlage in ein anderes Verzeichnis zu rendern, verwenden Sie die Variable cilium_template_output_directory, z.B.:

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

Wenn Sie die helm-Befehle und die Parameter, die in den Protokollen ausgeführt wurden, sehen möchten, können Sie auch --extra-vars cilium_helm_show_commands=true angeben.

Eine der letzten Aufgaben heißt TASK [githubixx.cilium_kubernetes : Schreibe Vorlagen in Datei]. Dies rendert die Vorlage mit den Ressourcen, die im Verzeichnis spezifiziert in cilium_template_output_directory erstellt werden. Die Datei wird template.yml genannt. Das Verzeichnis/ die Datei wird auf Ihrem lokalen Computer platziert, um es zu inspizieren.

Wenn die gerenderte Ausgabe alles enthält, was Sie benötigen, kann die Rolle installiert werden, was schließlich Cilium bereitstellt:

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

Um zu überprüfen, ob alles bereitgestellt wurde, verwenden Sie die üblichen kubectl-Befehle wie kubectl -n <cilium_namespace> get pods -o wide.

Da Cilium alle paar Wochen/Monate Updates/Aktualisierungen herausgibt, kann die Rolle auch Aktualisierungen durchführen. Die Rolle führt im Wesentlichen aus, was im Cilium Upgrade-Leitfaden beschrieben ist. Das bedeutet, dass die Cilium-Vorflugkontrolle installiert wird und einige Prüfungen durchgeführt werden, bevor das Update tatsächlich erfolgt. Werfen Sie einen Blick auf tasks/upgrade.yml, um zu sehen, was vor, während und nach dem Update passiert. Natürlich sollten Sie den Cilium Upgrade-Leitfaden im Allgemeinen konsultieren, um nach größeren Änderungen und ähnlichem zu suchen, bevor Sie aktualisieren. Stellen Sie auch sicher, dass Sie die Upgrade-Hinweise überprüfen!

Wenn ein Upgrade nicht erfolgreich war, kann ein Rollback auf eine frühere Version im Grunde durch Ändern der Variablen cilium_chart_version initiiert werden. Aber Sie sollten auf jeden Fall den Cilium Rollback-Leitfaden lesen. Der Wechsel zwischen Minor-Versionen ist normalerweise kein Problem, aber der Wechsel von einer Hauptversion zu einer vorherigen kann möglicherweise nicht so einfach sein.

Überprüfen Sie auch templates/cilium_values_default_pre_flight_check.yml.j2. Wenn Sie Werte für die Pre-Flight-Überprüfung anpassen müssen, können Sie entweder diese Datei ändern oder eine Datei templates/cilium_values_user_pre_flight_check.yml.j2 mit Ihren eigenen Werten erstellen.

Bevor Sie das Upgrade durchführen, müssen Sie im Grunde nur die Variable cilium_chart_version ändern, z.B. von 1.13.4 auf 1.14.5, um von 1.13.4 auf 1.14.5 zu aktualisieren. Führen Sie also den Befehl aus

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

Wie bereits erwähnt, beinhaltet die Rolle bereits einige Prüfungen, um sicherzustellen, dass das Upgrade glatt verläuft, aber Sie sollten erneut mit kubectl überprüfen, ob alles nach dem Upgrade wie erwartet funktioniert.

Und schließlich, wenn Sie Cilium loswerden möchten, können Sie alle Ressourcen wieder löschen:

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

Wenn Sie keine CNI-Plugins konfiguriert haben, wird dies dazu führen, dass der kubelet-Prozess auf den Kubernetes-Worker-Knoten von Zeit zu Zeit CNI-Fehler ausgibt, da es keine CNI-bezogenen Dinge mehr gibt und natürlich die Konnektivität zwischen Pods auf verschiedenen Hosts zusammen mit Netzwerkrichtlinien und ähnlichen Dingen verloren gehen wird.

Beispiel-Playbook

Beispiel 1 (ohne Rollentag):

- hosts: k8s_worker
  roles:
    - githubixx.cilium_kubernetes

Beispiel 2 (Tag zur Rolle zuweisen):

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

Tests

Diese Rolle hat ein kleines Testsetup, das mit Molecule, libvirt (vagrant-libvirt) und QEMU/KVM erstellt wurde. Bitte lesen Sie meinen Blog-Beitrag Testing Ansible roles with Molecule, libvirt (vagrant-libvirt) and QEMU/KVM über das Setup. Die Testkonfiguration ist hier.

Danach kann Molecule ausgeführt werden. Der folgende Befehl erstellt eine grundlegende Einrichtung und erstellt eine Vorlage der Ressourcen (Standardaktion siehe oben), die erstellt werden:

molecule converge

Installieren Sie Cilium und die erforderlichen Ressourcen. Dies richtet einige virtuelle Maschinen (VM) ein und installiert einen Kubernetes-Cluster. Dieses Setup wird verwendet, um Cilium mit dieser Rolle zu installieren.

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

Der folgende Befehl kann verwendet werden, um CoreDNS für Kubernetes-DNS-Sachen zu installieren und Controller-Knoten so zu kennzeichnen, dass sie nur Cilium-Pods ausführen:

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

Upgrade von Cilium oder Ändern der Parameter:

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

Löschen von Cilium und seinen Ressourcen:

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

Um einige Tests durchzuführen, verwenden Sie (optinal -v für mehr Ausgabe hinzufügen):

molecule verify

Um aufzuräumen, führen Sie aus

molecule destroy

Lizenz

GNU GENERAL PUBLIC LICENSE Version 3

Autor Informationen

http://www.tauceti.blog