In unserem neu übersetzten Artikel geben wir einen schnellen Überblick über die neue Kubernetes-Distribution. Wir hoffen, dass der Artikel für die Leser von Habr interessant sein wird.
Vor ein paar Tagen erzählte mir ein Freund von einer neuen Kubernetes-Distribution von Mirantis namens k0s . Wir alle kennen und lieben K8s, oder? Wir waren auch fasziniert von K3s , einem leichten Kubernetes, das von Rancher Labs entwickelt und vor einiger Zeit an CNCF übergeben wurde. Es ist Zeit, die neue k0s-Distribution zu entdecken!
Nach einer kurzen Einführung in k0s erstellen wir einen Cluster mit drei Knoten, indem wir die folgenden Schritte ausführen:
- Vorbereiten von drei virtuellen Maschinen ( Multipass in Aktion)
- Installieren von k0s auf jedem von ihnen
- Einrichten einer einfachen k0s-Cluster-Konfigurationsdatei
- Cluster-Initialisierung
- Zugriff auf den Cluster erhalten
- Hinzufügen von Worker-Knoten
- Nutzer hinzufügen
Was ist k0s?
k0s ist die neueste Kubernetes-Distribution. Die aktuelle Version ist 0.8.0. Es wurde im Dezember 2020 veröffentlicht und das erste Commit des gesamten Projekts fand im Juni 2020 statt.
k0s wird als einzelne Binärdatei ohne Betriebssystemabhängigkeiten ausgeliefert. Somit ist es als eine Kubernetes-Distribution mit reibungsfreien / Null-Abhängigkeiten / Null-Kosten- Eigenschaften definiert (einfache Konfiguration / keine Abhängigkeiten / frei).
Neueste Version von k0s:
- Liefert zertifiziert (Internet Security Center zertifiziert) Kubernetes 1.19
- Verwendet Containerd als Standard-Container-Laufzeit
- Unterstützt Intel (x86-64) und ARM (ARM64) Architekturen
- Verwendet Intra-Cluster etcd
- Verwendet standardmäßig das Calico- Netzwerk-Plugin (wodurch Netzwerkrichtlinien aktiviert werden).
- Beinhaltet Pod Security Policy Access Controller
- Verwendet DNS mit CoreDNS
- Bietet Cluster-Metriken über Metrics Server
- Aktiviert die horizontale Pod-Autoscale (HPA).
Viele coole Funktionen werden in zukünftigen Versionen verfügbar sein, darunter:
- Kompakte VM-Laufzeit (Ich freue mich sehr darauf, diese Funktion zu testen)
- Cluster-Upgrade ohne Ausfallzeit
- Cluster-Sicherung und Wiederherstellung
Beeindruckend, nicht wahr? Als Nächstes sehen wir uns an, wie Sie mit k0s einen 3-Knoten-Cluster bereitstellen.
Virtuelle Maschinen vorbereiten
Zunächst erstellen wir drei virtuelle Maschinen, von denen jede ein Knoten in unserem Cluster ist. In diesem Artikel gehe ich schnell und einfach vor und verwende das hervorragende Multipass- Tool (ich liebe es), um lokale virtuelle Maschinen unter MacOS vorzubereiten.
Die folgenden Befehle erstellen drei Instanzen von Ubuntu auf xhyve. Jede virtuelle Maschine verfügt über 5 GB Festplatte, 2 GB RAM und 2 virtuelle Prozessoren (vCPU):
for i in 1 2 3; do multipass launch -n node$i -c 2 -m 2G done
Anschließend können wir eine Liste der virtuellen Maschinen anzeigen, um sicherzustellen, dass alle ordnungsgemäß funktionieren:
$ multipass list Name State IPv4 Image node1 Running 192.168.64.11 Ubuntu 20.04 LTS node2 Running 192.168.64.12 Ubuntu 20.04 LTS node3 Running 192.168.64.13 Ubuntu 20.04 LTS
Als nächstes werden wir k0s auf jedem dieser Knoten installieren.
Installation der neuesten k0s-Version
Die neueste Version von k0s kann aus dem GitHub-Repository heruntergeladen werden .
Es hat ein praktisches Installationsskript:
curl -sSLf get.k0s.sh | sudo sh
Wir verwenden dieses Skript, um k0s auf allen unseren Knoten zu installieren:
for i in 1 2 3; do multipass exec node$i --bash -c "curl -sSLf get.k0s.sh | sudo sh" done
Das obige Skript installiert k0s in / user / bin / k0 . Um alle verfügbaren Befehle abzurufen, führen Sie die Binärdatei ohne Argumente aus.
Verfügbare k0s-Befehle Wir
können die aktuelle Version überprüfen:
$ k0s version v0.8.0
Wir werden einige der Befehle in den nächsten Schritten verwenden.
Konfigurationsdatei erstellen
Zunächst müssen Sie eine Konfigurationsdatei definieren, die die Informationen enthält, die k0s zum Erstellen eines Clusters benötigt. Auf Knoten 1 können wir den Befehl default-config ausführen, um die vollständige Standardkonfiguration abzurufen. Auf diese Weise können wir unter anderem Folgendes bestimmen:
ubuntu@node1:~$ k0s default-config
apiVersion: k0s.k0sproject.io/v1beta1
kind: Cluster
metadata:
name: k0s
spec:
api:
address: 192.168.64.11
sans:
- 192.168.64.11
- 192.168.64.11
extraArgs: {}
controllerManager:
extraArgs: {}
scheduler:
extraArgs: {}
storage:
type: etcd
kine: null
etcd:
peerAddress: 192.168.64.11
network:
podCIDR: 10.244.0.0/16
serviceCIDR: 10.96.0.0/12
provider: calico
calico:
mode: vxlan
vxlanPort: 4789
vxlanVNI: 4096
mtu: 1450
wireguard: false
podSecurityPolicy:
defaultPolicy: 00-k0s-privileged
workerProfiles: []
extensions: null
images:
konnectivity:
image: us.gcr.io/k8s-artifacts-prod/kas-network-proxy/proxy-agent
version: v0.0.13
metricsserver:
image: gcr.io/k8s-staging-metrics-server/metrics-server
version: v0.3.7
kubeproxy:
image: k8s.gcr.io/kube-proxy
version: v1.19.4
coredns:
image: docker.io/coredns/coredns
version: 1.7.0
calico:
cni:
image: calico/cni
version: v3.16.2
flexvolume:
image: calico/pod2daemon-flexvol
version: v3.16.2
node:
image: calico/node
version: v3.16.2
kubecontrollers:
image: calico/kube-controllers
version: v3.16.2
repository: ""
telemetry:
interval: 10m0s
enabled: true
- Startoptionen für API-Server, Controller-Manager und Scheduler
- Speicher, der zum Speichern von Clusterinformationen ( etcd ) verwendet werden kann
- Netzwerk-Plugin und seine Konfiguration ( Calico )
- Version von Container-Images mit Verwaltungskomponenten
- Einige zusätzliche Verwaltungsschemata, die beim Starten eines Clusters bereitgestellt werden sollen
Wir könnten diese Konfiguration in einer Datei speichern und an unsere Bedürfnisse anpassen. In diesem Artikel verwenden wir jedoch eine sehr einfache Konfiguration und speichern sie in /etc/k0s/k0s.yaml . Hinweis : Da wir die Cluster auf initialisieren node1 , dieser Knoten wird die API - Server dienen. Die IP-Adresse dieses Knotens wird in api.address und api.sans (alternative Betreffnamen ) in der obigen Konfigurationsdatei verwendet. Wenn wir zusätzliche Masterknoten und einen Load Balancer darüber hätten, würden wir in den Einstellungen auch api.sans verwenden
apiVersion: k0s.k0sproject.io/v1beta1
kind: Cluster
metadata:
name: k0s
spec:
api:
address: 192.168.64.11
sans:
- 192.168.64.11
network:
podCIDR: 10.244.0.0/16
serviceCIDR: 10.96.0.0/12
Die IP-Adresse jedes Hosts und Load Balancers (oder des entsprechenden Domänennamens).
Cluster-Initialisierung
Zuerst erstellen wir eine systemd-Einheit auf Knoten1 , um k0s zu verwalten.
[Unit] Description="k0s server" After=network-online.target Wants=network-online.target [Service] Type=simple ExecStart=/usr/bin/k0s server -c /etc/k0s/k0s.yaml --enable-worker Restart=always
Der Hauptbefehl ist hier in ExecStart aufgeführt . Der k0s-Server wird mit der Konfiguration gestartet, die wir im vorherigen Schritt in unserer Datei gespeichert haben. Wir geben auch den Parameter --enable-worker an , damit dieser erste Masterknoten auch als Worker fungiert.
Anschließend kopieren wir diese Datei nach /lib/systemd/system/k0s.service , starten systemd neu und starten den neu erstellten Dienst.
ubuntu@node1:~$ sudo systemctl daemon-reload ubuntu@node1:~$ sudo systemctl start k0s.service
Aus Neugier können Sie die vom k0s-Server gestarteten Prozesse überprüfen:
ubuntu@node1:~$ sudo ps aux | awk ‘{print $11}’ | grep k0s /usr/bin/k0s /var/lib/k0s/bin/etcd /var/lib/k0s/bin/konnectivity-server /var/lib/k0s/bin/kube-controller-manager /var/lib/k0s/bin/kube-scheduler /var/lib/k0s/bin/kube-apiserver /var/lib/k0s/bin/containerd /var/lib/k0s/bin/kubelet
Aus der obigen Ausgabe können wir ersehen , dass alle Hauptkomponenten ausgeführt werden ( kube-apiserver , kube-controller-manager , kube-scheduler usw.) sowie Komponenten, die Master- und Worker-Knoten gemeinsam haben ( Containerd , Kubelet ). k0s ist für die Verwaltung all dieser Komponenten verantwortlich.
Jetzt haben wir einen Cluster von 1 Knoten. Im nächsten Schritt werden wir sehen, wie Sie darauf zugreifen können.
Zugriff auf den Cluster erhalten
Zuerst müssen wir die kubeconfig- Datei erhalten, die während der Erstellung des Clusters generiert wird. Es wurde auf Knoten 1 unter /var/lib/k0s/pki/admin.conf erstellt . Diese Datei sollte verwendet werden, um kubectl auf dem lokalen Computer zu konfigurieren .
Zuerst erhalten wir die Kubeconfig des Clusters von Knoten1 :
# Get kubeconfig file $ multipass exec node1 cat /var/lib/k0s/pki/admin.conf > k0s.cfg
Als nächstes ersetzen wir die interne IP-Adresse durch den externen IP- Adressknoten1 :
# Replace IP address $ NODE1_IP=$(multipass info node1 | grep IP | awk '{print $2}') sed -i '' "s/localhost/$NODE1_IP/" k0s.cfg
Anschließend konfigurieren wir unseren lokalen kubectl-Client für die Kommunikation mit dem k0s-API-Server:
export KUBECONFIG=$PWD/k0s.cfg
Sicherlich ist einer der ersten Befehle, die wir ausführen, wenn wir einen neuen Cluster betreten, derjenige, der eine Liste aller verfügbaren Knoten anzeigt - versuchen wir Folgendes:
$ kubectl get no NAME STATUS ROLES AGE VERSION node1 Ready <none> 78s v1.19.4
Hier ist nichts überraschend. Schließlich ist Knoten1 nicht nur der Hauptknoten, sondern auch der Arbeitsknoten unseres ersten Clusters, dank des Flags --enable-worker , das wir im Befehl start angegeben haben. Ohne dieses Flag würde Knoten1 nur funktionieren und nicht in der Liste der Knoten hier erscheinen.
Hinzufügen von Worker-Knoten
Um Knoten2 und Knoten3 zum Cluster hinzuzufügen , müssen wir zuerst ein Verbindungstoken aus Knoten1 erstellen (dies ist ein ziemlich häufiger Schritt, da er in mit kubeadm erstellten Docker Swarm- und Kubernetes-Clustern verwendet wird).
$ TOKEN=$(k0s token create --role=worker)
Der obige Befehl generiert ein langes (sehr langes) Token. Damit können wir Knoten2 und Knoten3 mit dem Cluster verbinden :
ubuntu@node2:~$ k0s worker $TOKEN ubuntu@node3:~$ k0s worker $TOKEN
Hinweis: In einem realen Cluster würden wir systemd (oder einen anderen Supervisor) verwenden, um die k0s-Prozesse für die Worker-Knoten zu verwalten, wie wir es für den Master-Knoten getan haben.
Unser Cluster mit drei Knoten ist betriebsbereit, wie wir überprüfen können, indem wir die Liste der Knoten anzeigen und die Knoten erneut auflisten:
$ kubectl get no NAME STATUS ROLES AGE VERSION node1 Ready <none> 30m v1.19.4 node2 Ready <none> 35s v1.19.4 node3 Ready <none> 32s v1.19.4
Wir können auch die Pods überprüfen, die in allen Namespaces ausgeführt werden:
Liste der Pods, die im Cluster in allen Namespaces ausgeführt werden.
Hier sind einige Dinge zu beachten:
- Wie üblich sehen wir die kube- Proxy- Pods, die Netzwerk-Plugin-Pods (basierend auf Calico) sowie die CoreDNS-Pods.
- api-server, scheduler controller-manager , , .
K0s Version 0.8.0 enthält den Unterbefehl user . Auf diese Weise können Sie eine Kubeconfig für einen zusätzlichen Benutzer / eine zusätzliche Gruppe erstellen . Mit dem folgenden Befehl wird beispielsweise eine kubeconfig- Datei namens demo für einen neuen Benutzer erstellt , die sich in einer imaginären Gruppe namens development befindet .
Hinweis: In Kubernetes werden Benutzer und Gruppen von einem Administrator außerhalb des Clusters verwaltet, dh in K8s gibt es keine Benutzer-Nicht-Gruppen-Ressource.
$ sudo k0s user create demo --groups development > demo.kubeconfig
Zum besseren Verständnis extrahieren wir das Client-Zertifikat aus dieser kubeconfig- Datei und dekodieren es aus der base64-Darstellung:
$ cat demo.kubeconfig | grep client-certificate-data | awk '{print $2}' | base64 --decode > demo.crt
Dann verwenden wir den Befehl openssl , um den Inhalt des Zertifikats abzurufen :
ubuntu@node1:~$ openssl x509 -in demo.crt -noout -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
71:8b:a4:4d:be:76:70:8a:...:07:60:67:c1:2d:51:94
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN = kubernetes-ca
Validity
Not Before: Dec 2 13:50:00 2020 GMT
Not After : Dec 2 13:50:00 2021 GMT
Subject: O = development, CN = demo
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
00:be:87:dd:15:46:91:98:eb:b8:38:34:77:a4:99:
da:4b:d6:ca:09:92:f3:29:28:2d:db:7a:0b:9f:91:
65:f3:11:bb:6c:88:b1:8f:46:6e:38:71:97:b7:b5:
9b:8d:32:86:1f:0b:f8:4e:57:4f:1c:5f:9f:c5:ee:
40:23:80:99:a1:77:30:a3:46:c1:5b:3e:1c:fa:5c:
- Die Emittenteneigenschaft ist kubernetes-ca , die Zertifizierungsstelle für unseren k0s-Cluster.
- Thema ist O = Entwicklung, CN = Demo ; Dieser Teil ist wichtig, da hier der Name und die Gruppe des Benutzers eingehen. Da das Zertifikat von der Cluster-Zertifizierungsstelle signiert ist, kann das Plugin auf dem API-Server den Benutzer / die Gruppe anhand des allgemeinen Namens (CN) und der Organisation (O) im Betreff des Zertifikats authentifizieren.
Zuerst weisen wir kubectl an, den in dieser neuen kubeconfig- Datei definierten Kontext zu verwenden :
$ export KUBECONFIG=$PWD/demo.kubeconfig
Dann zeigen wir noch einmal die Liste der Knoten an und listen die Clusterknoten auf:
$ kubectl get no Error from server (Forbidden): nodes is forbidden: User “demo” cannot list resource “nodes” in API group “” at the cluster scope
Diese Fehlermeldung wurde erwartet. Selbst wenn
api-server
der Benutzer identifiziert wird (das mit der Benutzeranforderung gesendete Zertifikat wurde von der Cluster-Zertifizierungsstelle signiert), darf er keine Aktionen für den Cluster ausführen.
Zusätzliche Berechtigungen können einfach hinzugefügt werden,
Role/ClusterRole
indem sie erstellt und einem Benutzer
RoleBinding/ClusterRoleBinding
zugewiesen werden. Ich überlasse diese Aufgabe jedoch dem Leser als Übung.
Fazit
k0s ist definitiv eine Überlegung wert. Dieser Ansatz ist sehr interessant, wenn eine einzelne Binärdatei alle Prozesse verwaltet.
Dieser Artikel bietet nur einen kurzen Überblick über k0s, aber ich werde auf jeden Fall seine Entwicklung verfolgen und zukünftige Artikel dieser neuen und vielversprechenden Kubernetes-Distribution widmen. Einige der zukünftigen Funktionen scheinen wirklich vielversprechend zu sein, und ich freue mich darauf, sie zu testen.