Ansible Konfiguration für k3s-prod

Ansible Konfiguration für k3s-prod

#

Aufgabe und Rolle

#

Ansible ist hier für die Ebene unterhalb von Kubernetes zuständig: k3s auf den Knoten installieren, die Basis-Manifeste anwenden, den Cluster geordnet herunter- und wieder hochfahren. Alles, was danach im Cluster läuft, kommt über ArgoCD aus dem Verzeichnis apps/.

Herkunft und Anpassung

#

Die Grundlage ist die Collection k3s-io/k3s-ansible, eingebunden über requirements.yml im Wurzelverzeichnis. Die Playbooks hier rufen deren k3s.orchestration.site auf und ergänzen, was darüber hinaus gebraucht wird.

Verzeichnisstruktur

#

Nutzung

#

Beispiel: Cluster initialisieren/aktualisieren

#

1ansible-playbook -i ansible/inventory.yaml ansible/deploy.yaml

deploy.yaml macht zwei Dinge nacheinander: Es importiert das Playbook der Collection, das k3s auf allen Knoten des Inventars installiert und verbindet, und wendet danach apps/k3s an, die virtuelle IP des API-Servers. Die Standard-StorageClass kommt nicht mehr von hier, sondern von Longhorn; das k3s-Addon local-storage ist abgeschaltet, siehe apps/k3s/README.md.

Das Cluster-Token in inventory.yaml ist mit Ansible Vault verschlüsselt. Ohne das Vault-Passwort läuft kein Playbook.

Nur k3s installieren, ohne den anschließenden Kustomize-Schritt — dafür lässt sich das Playbook der Collection auch direkt aufrufen:

1ansible-playbook k3s.orchestration.site -i ansible/inventory.yaml -u root

Benutzer anlegen

#

1ansible-playbook ansible/create_user.yaml

Fragt Benutzer- und Gruppenname interaktiv ab und legt die fertige kubeconfig unter user_configs/<name>/config ab.

Herunterfahren und Wiederanfahren

#

1ansible-playbook -i ansible/inventory.yaml ansible/shutdown_cluster.yaml
2ansible-playbook -i ansible/inventory.yaml ansible/startup_cluster.yaml

Die Reihenfolge ist nicht beliebig. Longhorn repliziert Volumes synchron über mehrere Knoten; werden die Knoten einfach abgeschaltet, können Volumes inkonsistent zurückbleiben. Zugleich muss ArgoCD ausgesetzt werden, damit es während der Wartung nicht selbständig alles wieder hochzieht.

Beides erledigen die Playbooks — die Begründung im Einzelnen steht in shutdown-startup.md. Diesen Text vor dem ersten Einsatz lesen.

Abhängigkeiten

#

• Ansible in einer aktuellen stabilen Version, dazu ein passendes Python auf dem Controller
• Die Collections aus requirements.yml im Wurzelverzeichnis
• Root-Zugang per SSH auf alle Knoten des Inventars. Den Schlüssel sinnvoll über einen ssh-agent bereitstellen, statt ihn je Aufruf anzugeben
• Das Ansible-Vault-Passwort
• kubectl und helm auf dem Controller, für den Kustomize-Schritt

Weiterführende Dokumentation

#

Einzelheiten zur k3s-Installation und zu den Playbooks der Collection stehen in der k3s-ansible-Dokumentation.