K3s bietet Kubernetes mit kleinerem Footprint, aber ein Node reicht nicht für Production-HA. Bei Embedded etcd muss das Server-/Control-Plane-Design Quorum berücksichtigen; Worker-Kapazität separat planen.
Laut K3s-Dokumentation nutzt ein HA-Cluster mit Embedded etcd drei oder mehr Server-Nodes. Agent/Worker-Nodes können für Workloads ergänzt werden. Eine feste Registration-/LB-Adresse vereinfacht den Betrieb.
Ein externer Load Balancer oder eine feste Registration-Adresse zeigt auf Server-Nodes. Worker treten über die API bei; Pod-Traffic läuft über Service/Ingress.
Embedded etcd speichert Cluster-State auf Server-Nodes. Bei externer DB werden Control Plane und Datastore getrennt; Netzwerklatenz und Backup bleiben kritisch.
Embedded-etcd-HA benötigt Server-zu-Server-Zugriff auf 2379/2380. Metrics Server braucht 10250; je CNI kommen weitere Ports hinzu.
Control Plane, Nodes, Pods und Snapshots regelmäßig prüfen.
sudo k3s kubectl get nodes -o widesudo k3s kubectl get pods -Asudo k3s kubectl get events -A --sort-by=.lastTimestamp | tail -n 30sudo k3s etcd-snapshot lssystemctl status k3s --no-pagerVor Cluster-Erweiterung Persistent Storage, DNS, Ingress und Backups inventarisieren.
K3s ist eine leichte Kubernetes-Distribution mit Kubernetes API und Kern-Orchestrierung.
Nicht bei Embedded etcd HA; offiziell sind drei oder mehr Server-Nodes nötig. External Datastore ist anders.
Es schützt Cluster-State; persistente App-Daten brauchen zusätzlich Storage-/DB-Backups.
Teilen Sie Node-Anzahl, Stateful Apps, Storage und Uptime-Ziel; Single Node, HA Embedded etcd oder External DB auswählen.