🎂 ☣️ 🧔🏿 Beende Kubernetes von Grund auf auf Raspberry Pi 🆔 📙 💰

In jüngerer Zeit gab ein bekanntes Unternehmen bekannt, dass es seine Laptop-Linie auf die ARM-Architektur überträgt. Als ich diese Nachricht hörte, erinnerte ich mich: Als ich noch einmal die Preise für EC2 in AWS durchgesehen hatte, bemerkte ich Gravitons mit einem sehr leckeren Preis. Der Haken war natürlich, dass es ARM ist. Mir ist damals noch nicht einmal in den Sinn gekommen, dass ARM ziemlich ernst ist ...

Für mich war diese Architektur schon immer eine Menge mobiler und anderer IoT-Dinge. "Echte" Server auf ARM sind irgendwie ungewöhnlich, in gewisser Weise sogar wild ... Ein neuer Gedanke steckte jedoch in meinem Kopf, und so beschloss ich an einem Wochenende zu prüfen, was heute auf ARM gestartet werden könnte. Und dafür habe ich mich entschlossen, mit einem engen und lieben zu beginnen - einem Kubernetes-Cluster. Und nicht nur ein bedingter "Cluster", sondern alles "auf erwachsene Weise", damit es so gut wie möglich so ist, wie ich es gewohnt bin, es in der Produktion zu sehen.

Meiner Idee nach sollte der Cluster über das Internet zugänglich sein, einige Webanwendungen sollten darin ausgeführt werden und es sollte zumindest eine Überwachung erfolgen. Um diese Idee umzusetzen, benötigen Sie ein Paar (oder mehr) Raspberry Pi Modell 3B + oder höher. AWS hätte eine Plattform für Experimente werden können, aber es waren die "Himbeeren", die für mich interessant waren (die noch untätig waren). Daher werden wir einen Kubernetes-Cluster mit Ingress, Prometheus und Grafana bereitstellen.

Zubereitung von "Himbeeren"

Installieren des Betriebssystems und von SSH

Ich habe mich nicht viel mit der Wahl des Betriebssystems für die Installation beschäftigt: Ich habe gerade das neueste Raspberry Pi OS Lite von der offiziellen Website genommen . Dort ist auch die Installationsdokumentation verfügbar , von der aus alle Schritte auf allen Knoten des zukünftigen Clusters ausgeführt werden müssen. Als Nächstes müssen Sie die folgenden Manipulationen durchführen (auch auf allen Knoten).

Nach dem Anschließen von Monitor und Tastatur müssen Sie zuerst das Netzwerk und SSH konfigurieren:

Damit der Cluster funktioniert, muss der Master eine statische IP-Adresse haben und die Arbeitsknoten müssen eine statische IP-Adresse haben. Ich habe überall statische Adressen bevorzugt, um die Einrichtung zu vereinfachen.
Eine statische Adresse kann im Betriebssystem konfiguriert werden ( /etc/dhcpcd.confes gibt ein geeignetes Beispiel in der Datei ) oder durch Festlegen der Lease auf dem DHCP-Server des verwendeten Routers (in meinem Fall zu Hause).
ssh-server ist nur in raspi-config enthalten ( Schnittstellenoptionen -> ssh ).

Danach können Sie sich bereits über SSH anmelden (standardmäßig ist die Anmeldung piund das Kennwort ist das raspberry, in das Sie geändert haben) und die Einstellungen fortsetzen.

Andere Einstellungen

Legen wir den Hostnamen fest. In meinem Beispiel pi-controlund wird verwendet pi-worker.
Lassen Sie uns überprüfen, ob das Dateisystem auf die gesamte Festplatte erweitert ist ( df -h /). Es kann bei Bedarf mit raspi-config erweitert werden.
Ändern Sie das Standardbenutzerkennwort in raspi-config.
Deaktivieren Sie die Auslagerungsdatei (dies ist die Kubernetes-Anforderung; wenn Sie an Details zu diesem Thema interessiert sind, lesen Sie Ausgabe 53533 ):
```
dphys-swapfile swapoff
systemctl disable dphys-swapfile
```
Lassen Sie uns die Pakete auf die neuesten Versionen aktualisieren:
```
apt-get update && apt-get dist-upgrade -y
```
Installieren Sie Docker und zusätzliche Pakete:
```
apt-get install -y docker docker.io apt-transport-https curl bridge-utils iptables-persistent
```
Während der Installation müssen Sie iptables-persistentdie iptables-Einstellungen für ipv4 speichern und /etc/iptables/rules.v4die Regeln wie folgt zur Kette in der Datei hinzufügen FORWARD:
```
# Generated by xtables-save v1.8.2 on Sun Jul 19 00:27:43 2020
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A FORWARD -s 10.1.0.0/16  -j ACCEPT
-A FORWARD -d 10.1.0.0/16  -j ACCEPT
COMMIT
```
Es bleibt nur ein Neustart.

Sie können jetzt Ihren Kubernetes-Cluster installieren.

Kubernetes installieren

Zu diesem Zeitpunkt habe ich alle meine und unsere Unternehmensentwicklungen zur Automatisierung der Installation und Konfiguration des K8s-Clusters bewusst verschoben. Stattdessen verwenden wir die offizielle Dokumentation von kubernetes.io (leicht ergänzt mit Kommentaren und Abkürzungen).

Fügen Sie das Kubernetes-Repository hinzu:

curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
cat <<EOF | sudo tee /etc/apt/sources.list.d/kubernetes.list
deb https://apt.kubernetes.io/ kubernetes-xenial main
EOF
sudo apt-get update

Weiter in der Dokumentation wird vorgeschlagen, CRI (Container Runtime Interface) zu installieren. Da Docker bereits installiert ist, fahren wir fort und installieren die Hauptkomponenten:

sudo apt-get install -y kubelet kubeadm kubectl kubernetes-cni

Bei der Installation der Hauptkomponenten habe ich sofort hinzugefügt, kubernetes-cniwas für die Funktion des Clusters erforderlich ist. Und hier gibt es einen wichtigen Punkt: Aus kubernetes-cniirgendeinem Grund erstellt das Paket kein Standardverzeichnis für die CNI-Schnittstelleneinstellungen, daher musste ich es manuell erstellen:

mkdir -p /etc/cni/net.d

Damit das Netzwerk-Backend funktioniert, das weiter unten erläutert wird, müssen Sie das Plugin für CNI installieren. Ich habe das Portmap-Plugin ausgewählt, das mir vertraut und klar ist ( eine vollständige Liste finden Sie in der Dokumentation ):

curl -sL https://github.com/containernetworking/plugins/releases/download/v0.7.5/cni-plugins-arm-v0.7.5.tgz | tar zxvf - -C /opt/cni/bin/ ./portmap

Kubernetes konfigurieren

Steuerebenenknoten

Das Einrichten des Clusters selbst ist ziemlich einfach. Um diesen Vorgang zu beschleunigen und zu überprüfen, ob Kubernetes-Images verfügbar sind, können Sie zunächst Folgendes ausführen:

kubeadm config images pull

Jetzt führen wir die Installation selbst durch - wir initialisieren die Steuerebene des Clusters:

kubeadm init --pod-network-cidr=10.1.0.0/16 --service-cidr=10.2.0.0/16 --upload-certs

Bitte beachten Sie, dass sich Subnetze für Dienste und Pods nicht miteinander oder mit vorhandenen Netzwerken überschneiden sollten.

Am Ende wird eine Meldung angezeigt, die besagt, dass alles in Ordnung ist, und gleichzeitig erfahren Sie, wie Sie Arbeitsknoten an die Steuerebene anschließen:

Your Kubernetes control-plane has initialized successfully!
To start using your cluster, you need to run the following as a regular user:
 mkdir -p $HOME/.kube
 sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
 sudo chown $(id -u):$(id -g) $HOME/.kube/config
You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
 https://kubernetes.io/docs/concepts/cluster-administration/addons/
You can now join any number of the control-plane node running the following command on each as root:
 kubeadm join 192.168.88.30:6443 --token a485vl.xjgvzzr2g0xbtbs4 \
   --discovery-token-ca-cert-hash sha256:9da6b05aaa5364a9ec59adcc67b3988b9c1b94c15e81300560220acb1779b050 \
   --contrl-plane --certificate-key 72a3c0a14c627d6d7fdade1f4c8d7a41b0fac31b1faf0d8fdf9678d74d7d2403
Please note that the certificate-key gives access to cluster sensitive data, keep it secret!
As a safeguard, uploaded-certs will be deleted in two hours; If necessary, you can use
"kubeadm init phase upload-certs --upload-certs" to reload certs afterward.
Then you can join any number of worker nodes by running the following on each as root:
kubeadm join 192.168.88.30:6443 --token a485vl.xjgvzzr2g0xbtbs4 \
   --discovery-token-ca-cert-hash sha256:9da6b05aaa5364a9ec59adcc67b3988b9c1b94c15e81300560220acb1779b050

Folgen wir den Empfehlungen zum Hinzufügen einer Konfiguration für den Benutzer. Gleichzeitig empfehle ich, die automatische Vervollständigung für kubectl sofort hinzuzufügen:

 kubectl completion bash > ~/.kube/completion.bash.inc
 printf "
 # Kubectl shell completion
 source '$HOME/.kube/completion.bash.inc'
 " >> $HOME/.bash_profile
 source $HOME/.bash_profile

Zu diesem Zeitpunkt können Sie bereits den ersten Knoten im Cluster sehen (obwohl er noch nicht fertig ist):

root@pi-control:~# kubectl get no
NAME         STATUS     ROLES    AGE   VERSION
pi-control   NotReady   master   29s   v1.18.6

Netzwerkkonfiguration

Wie in der Meldung nach der Installation angegeben, müssen Sie das Netzwerk im Cluster installieren. Die Dokumentation bietet eine Auswahl an Calico, Cilium, Contiv-Vpp, Kube-Router und Weave Net ... Hier habe ich von den offiziellen Anweisungen abgewichen und eine für mich bekanntere und verständlichere Option gewählt: Flanell im Host-GW-Modus (weitere Informationen zu verfügbaren Backends finden Sie in der Dokumentation Projekt ).

Die Installation in einem Cluster ist ziemlich einfach. Laden Sie zunächst die Manifeste herunter:

wget https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

Ändern Sie vxlandann in den Einstellungen den Typ von bis host-gw:

sed -i 's/vxlan/host-gw/' kube-flannel.yml

... und das Pod-Subnetz - vom Standardwert bis zu dem bei der Clusterinitialisierung angegebenen Wert:

sed -i 's#10.244.0.0/16#10.1.0.0/16#' kube-flannel.yml

Danach erstellen wir Ressourcen:

kubectl create -f kube-flannel.yml

Erledigt! Nach einer Weile erhält der erste K8-Knoten den Status Ready:

NAME         STATUS   ROLES    AGE   VERSION
pi-control   Ready    master   2m    v1.18.6

Hinzufügen eines Worker-Knotens

Jetzt können Sie einen Worker hinzufügen. Dazu müssen Sie nach der Installation von Kubernetes selbst gemäß dem oben beschriebenen Szenario nur den zuvor empfangenen Befehl ausführen:

kubeadm join 192.168.88.30:6443 --token a485vl.xjgvzzr2g0xbtbs4 \
    --discovery-token-ca-cert-hash sha256:9da6b05aaa5364a9ec59adcc67b3988b9c1b94c15e81300560220acb1779b050

In diesem Zusammenhang können wir davon ausgehen, dass der Cluster bereit ist:

root@pi-control:~# kubectl get no
NAME         STATUS   ROLES    AGE    VERSION
pi-control   Ready    master   28m    v1.18.6
pi-worker    Ready    <none>   2m8s   v1.18.6

Ich hatte nur zwei Raspberry Pi zur Hand, also wollte ich keinen davon nur unter der Kontrollebene geben. Also habe ich den automatisch installierten Taint vom Pi-Control-Knoten entfernt, indem ich Folgendes ausgeführt habe:

root@pi-control:~# kubectl edit node pi-control

... und die Zeilen entfernen:

 - effect: NoSchedule
   key: node-role.kubernetes.io/master

Füllen Sie den Cluster mit dem erforderlichen Minimum

Zuerst brauchen wir Helm . Natürlich können Sie alles ohne es tun, aber mit Helm können Sie einige Komponenten nach Belieben konfigurieren, ohne Dateien zu bearbeiten. Und tatsächlich ist es nur eine Binärdatei, die "nicht nach Brot fragt".

Gehen Sie also zu helm.sh im Abschnitt docs / installation und führen Sie den Befehl von dort aus:

curl -s https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 | bash

Fügen Sie danach das Diagramm-Repository hinzu:

helm repo add stable https://kubernetes-charts.storage.googleapis.com/

Lassen Sie uns nun die Infrastrukturkomponenten gemäß der Idee installieren:

Ingress Controller;
Prometheus;
Grafana;
Cert-Manager.

Ingress Controller

Die erste Komponente, der Ingress-Controller , ist einfach zu installieren und sofort einsatzbereit. Gehen Sie dazu einfach zum Bare-Metal-Bereich auf der Site und führen Sie von dort aus den Installationsbefehl aus:

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v0.34.1/deploy/static/provider/baremetal/deploy.yaml

In diesem Moment begann die "Himbeere" jedoch zu belasten und auf Festplatten-IOPS zu stoßen. Tatsache ist, dass zusammen mit dem Ingress-Controller eine große Anzahl von Ressourcen installiert wird, viele API-Anforderungen gestellt werden und dementsprechend viele Daten in etcd geschrieben werden. Im Allgemeinen ist entweder eine Speicherkarte der Klasse 10 nicht sehr produktiv, oder eine SD-Karte reicht für eine solche Belastung im Grunde nicht aus. Trotzdem fing nach 5 Minuten alles an.

Ein Namespace wurde erstellt und ein Controller wurde darin angezeigt und alles, was er benötigt:

root@pi-control:~# kubectl -n ingress-nginx get pod
NAME                                        READY   STATUS      RESTARTS   AGE
ingress-nginx-admission-create-2hwdx        0/1     Completed   0          31s
ingress-nginx-admission-patch-cp55c         0/1     Completed   0          31s
ingress-nginx-controller-7fd7d8df56-68qp5   1/1     Running     0          48s

Prometheus

Die nächsten beiden Komponenten sind relativ einfach über Helm aus dem Chart-Repo zu installieren.

Suchen Sie Prometheus , erstellen Sie einen Namespace und installieren Sie ihn:

helm search repo stable | grep prometheus
kubectl create ns monitoring
helm install prometheus --namespace monitoring stable/prometheus --set server.ingress.enabled=True --set server.ingress.hosts={"prometheus.home.pi"}

Standardmäßig bestellt Prometheus 2 Festplatten: für die Daten des Prometheus selbst und für die Daten des AlertManager. Da im Cluster keine Speicherklasse erstellt wurde, werden keine Festplatten bestellt und keine Pods gestartet. Für Bare-Metal-Kubernetes-Installationen verwenden wir normalerweise Ceph rbd, aber im Fall des Raspberry Pi ist dies ein Overkill.

Erstellen wir also einen einfachen lokalen Speicher auf dem Hostpfad. Die PV-Manifeste (Persistent Volume) für prometheus-server und prometheus-alertmanager werden in einer Datei prometheus-pv.yamlim Git-Repository mit Beispielen für den Artikel zusammengeführt . Das Verzeichnis für PV muss in erstellt vorab auf der Platte des Knotens , zu dem wir Prometheus wollen binden: Im Beispiel nodeAffinitywird der Hostname angegeben pi-workerund die Verzeichnisse /data/localstorage/prometheus-serverund sind darauf angelegt /data/localstorage/prometheus-alertmanager.

Laden Sie das Manifest herunter (klonen Sie es) und fügen Sie es Kubernetes hinzu:

kubectl create -f prometheus-pv.yaml

Zu diesem Zeitpunkt stieß ich zum ersten Mal auf das Problem der ARM-Architektur. Kube-State-Metriken, die standardmäßig im Prometheus-Diagramm festgelegt sind, konnten nicht gestartet werden. Es gab einen Fehler:

root@pi-control:~# kubectl -n monitoring logs prometheus-kube-state-metrics-c65b87574-l66d8
standard_init_linux.go:207: exec user process caused "exec format error"

Tatsache ist, dass für Kube-State-Metriken das Image des CoreOS-Projekts verwendet wird, das nicht für ARM kompiliert wurde:

kubectl -n monitoring get deployments.apps prometheus-kube-state-metrics -o=jsonpath={.spec.template.spec.containers[].image}
quay.io/coreos/kube-state-metrics:v1.9.7

Ich musste ein wenig googeln und zum Beispiel dieses Bild finden . Um dies zu nutzen, aktualisieren wir die Version und geben an, welches Image für Kube-State-Metriken verwendet werden soll:

helm upgrade prometheus --namespace monitoring stable/prometheus --set server.ingress.enabled=True --set server.ingress.hosts={"prometheus.home.pi"} --set kube-state-metrics.image.repository=carlosedp/kube-state-metrics --set kube-state-metrics.image.tag=v1.9.6

Wir überprüfen, ob alles begonnen hat:

root@pi-control:~# kubectl -n monitoring get po
NAME                                             READY   STATUS              RESTARTS   AGE
prometheus-alertmanager-df65d99d4-6d27g          2/2     Running             0          5m56s
prometheus-kube-state-metrics-5dc5fd89c6-ztmqr   1/1     Running             0          5m56s
prometheus-node-exporter-49zll                   1/1     Running             0          5m51s
prometheus-node-exporter-vwl44                   1/1     Running             0          4m20s
prometheus-pushgateway-c547cfc87-k28qx           1/1     Running             0          5m56s
prometheus-server-85666fd794-z9qnc               2/2     Running             0          4m52s

Grafana und Cert-Manager

Installieren Sie Grafana für Diagramme und Dashboards :

helm install grafana --namespace monitoring stable/grafana  --set ingress.enabled=true --set ingress.hosts={"grafana.home.pi"}

Am Ende der Ausgabe wird gezeigt, wie Sie das Passwort für den Zugriff erhalten:

kubectl get secret --namespace monitoring grafana -o jsonpath="{.data.admin-password}" | base64 --decode ; echo

Installieren Sie den Zertifikatsmanager, um Zertifikate zu bestellen . Informationen zur Installation finden Sie in der Dokumentation , die die entsprechenden Befehle für Helm enthält:

helm repo add jetstack https://charts.jetstack.io

helm install \
  cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --version v0.16.0 \
  --set installCRDs=true

Für selbstsignierte Zertifikate für den Heimgebrauch ist dies ausreichend. Wenn Sie dasselbe Let's Encrypt erhalten möchten , müssen Sie einen anderen Cluster-Aussteller konfigurieren. Weitere Details finden Sie in unserem Artikel " SSL-Zertifikate von Let's Encrypt with cert-manager on Kubernetes ".

Ich selbst habe mich für eine Variante aus dem Beispiel in der Dokumentation entschieden und entschieden, dass die Staging-LE-Variante ausreichen würde. Ändern Sie die E-Mail im Beispiel, speichern Sie sie in einer Datei und fügen Sie sie dem Cluster hinzu ( cert-manager-cluster-issuer.yaml ):

kubectl create -f cert-manager-cluster-issuer.yaml

Jetzt können Sie beispielsweise für Grafana ein Zertifikat bestellen. Dies erfordert eine Domäne und externen Zugriff auf den Cluster. Ich habe eine Domäne und habe den Datenverkehr konfiguriert, indem ich die Ports 80 und 443 auf meinem Heimrouter gemäß dem erstellten Ingress-Controller-Dienst weitergeleitet habe:

kubectl -n ingress-nginx get svc
NAME                                 TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)                      AGE
ingress-nginx-controller             NodePort    10.2.206.61    <none>        80:31303/TCP,443:30498/TCP   23d

Der 80. Port wird in diesem Fall in 31303 und 443 in 30498 übersetzt. (Die Ports werden zufällig generiert, sodass Sie unterschiedliche haben.)

Hier ist ein Beispielzertifikat ( cert-manager-grafana-certificate.yaml ):

apiVersion: cert-manager.io/v1alpha2
kind: Certificate
metadata:
  name: grafana
  namespace: monitoring
spec:
  dnsNames:
    - grafana.home.pi
  secretName: grafana-tls
  issuerRef:
    kind: ClusterIssuer
    name: letsencrypt-staging

Fügen Sie es dem Cluster hinzu:

kubectl create -f cert-manager-grafana-certificate.yaml

Danach wird die Ingress-Ressource angezeigt, über die die Validierung von Let's Encrypt erfolgt:

root@pi-control:~# kubectl -n monitoring get ing
NAME                        CLASS    HOSTS                        ADDRESS         PORTS   AGE
cm-acme-http-solver-rkf8l   <none>   grafana.home.pi      192.168.88.31   80      72s
grafana                     <none>   grafana.home.pi      192.168.88.31   80      6d17h
prometheus-server           <none>   prometheus.home.pi   192.168.88.31   80      8d

Nachdem die Validierung bestanden wurde, werden wir sehen, dass die Ressource certificatebereit ist und das obige Geheimnis das grafana-tlsZertifikat und den Schlüssel enthält. Sie können sofort überprüfen, wer das Zertifikat ausgestellt hat:

root@pi-control:~# kubectl -n monitoring get certificate
NAME      READY   SECRET        AGE
grafana   True    grafana-tls   13m

root@pi-control:~# kubectl -n monitoring get secrets grafana-tls -ojsonpath="{.data['tls\.crt']}" | base64 -d | openssl x509 -issuer -noout
issuer=CN = Fake LE Intermediate X1

Gehen wir zurück zu Grafana. Wir müssen die Helm-Version ein wenig korrigieren und die Einstellungen für TLS entsprechend dem generierten Zertifikat ändern.

Laden Sie dazu das Diagramm herunter, bearbeiten und aktualisieren Sie es aus dem lokalen Verzeichnis:

helm pull --untar stable/grafana

Bearbeiten Sie die grafana/values.yaml TLS-Parameter in der Datei :

  tls:
    - secretName: grafana-tls
      hosts:
        - grafana.home.pi

Hier können Sie den installierten Prometheus sofort wie folgt konfigurieren datasource:

datasources:
  datasources.yaml:
    apiVersion: 1
    datasources:
    - name: Prometheus
      type: prometheus
      url: http://prometheus-server:80
      access: proxy
      isDefault: true

Aktualisieren Sie nun das Grafana-Diagramm aus dem lokalen Verzeichnis:

helm upgrade grafana --namespace monitoring ./grafana  --set ingress.enabled=true --set ingress.hosts={"grafana.home.pi"}

Wir überprüfen, ob grafanaPort 443 zu Ingress hinzugefügt wurde und ob über HTTPS Zugriff besteht:

root@pi-control:~# kubectl -n monitoring get ing grafana
NAME      CLASS    HOSTS                     ADDRESS         PORTS     AGE
grafana   <none>   grafana.home.pi           192.168.88.31   80, 443   63m

root@pi-control:~# curl -kI https://grafana.home.pi
HTTP/2 302
server: nginx/1.19.1
date: Tue, 28 Jul 2020 19:01:31 GMT
content-type: text/html; charset=utf-8
cache-control: no-cache
expires: -1
location: /login
pragma: no-cache
set-cookie: redirect_to=%2F; Path=/; HttpOnly; SameSite=Lax
x-frame-options: deny
strict-transport-security: max-age=15724800; includeSubDomains

Um Grafana in Aktion zu demonstrieren, können Sie ein Dashboard für Kube-State-Metriken herunterladen und hinzufügen . So sieht es aus: Ich

empfehle außerdem, ein Dashboard für den Knotenexporter hinzuzufügen: Es zeigt detailliert, was mit den "Himbeeren" passiert (CPU-Auslastung, Speicher, Netzwerk, Festplattennutzung usw.).

Danach glaube ich, dass der Cluster bereit ist, Anwendungen zu empfangen und auszuführen!

Montagehinweis

Es gibt mindestens zwei Optionen zum Erstellen von Anwendungen für die ARM-Architektur. Zunächst können Sie auf einem ARM-Gerät aufbauen. Nachdem ich mir die aktuelle Entsorgung der beiden Raspberry Pi angesehen hatte, wurde mir klar, dass sie die Montage auch nicht überleben würden. Deshalb habe ich mir einen neuen Raspberry Pi 4 bestellt (er ist leistungsstärker und verfügt über 4 GB Speicher) - ich habe vor, ihn darauf aufzubauen.

Die zweite Option besteht darin, ein Docker-Image mit mehreren Architekturen auf einem leistungsstärkeren Computer zu erstellen. Hierfür gibt es eine Erweiterung Docker Buildx . Wenn die Anwendung in einer kompilierten Sprache vorliegt, ist eine Kreuzkompilierung für ARM erforderlich. Ich werde nicht alle Einstellungen für diesen Pfad beschreiben, weil Dies führt zu einem separaten Artikel. Bei der Implementierung dieses Ansatzes können Sie "universelle" Images erzielen: Docker, das auf einem ARM-Computer ausgeführt wird, lädt automatisch das der Architektur entsprechende Image.

Fazit

Das durchgeführte Experiment hat alle meine Erwartungen übertroffen: [zumindest] "Vanille" Kubernetes mit der notwendigen Basis fühlt sich auf ARM gut an, und mit seiner Konfiguration entstanden nur ein paar Nuancen.

Die Raspberry Pi 3B + selbst halten die CPU beschäftigt, aber ihre SD-Karten sind ein klarer Engpass. Die Kollegen schlugen vor, dass es in einigen Versionen möglich ist, von USB zu booten, wo Sie eine SSD anschließen können. Dann wird sich die Situation höchstwahrscheinlich verbessern.

Hier ist ein Beispiel für die CPU-Auslastung bei der Installation von Grafana:

Für Experimente und "zum Ausprobieren" vermittelt der Kubernetes-Cluster auf "Himbeeren" meiner Meinung nach die Betriebsempfindungen viel besser als der gleiche Minikube, da alle Komponenten des Clusters installiert sind und funktionieren "Auf erwachsene Weise."

In Zukunft besteht die Idee, den gesamten CI / CD-Zyklus, der vollständig auf dem Raspberry Pi implementiert ist, zum Cluster hinzuzufügen. Und ich würde mich auch freuen, wenn jemand seine Erfahrungen beim Einrichten von K8s auf AWS Gravitons teilt.

PS Ja, "Produktion" kann näher sein als ich dachte:

PPS

Lesen Sie auch in unserem Blog:

" Abenteuer mit einem Heim-Kubernetes-Cluster ."

Beende Kubernetes von Grund auf auf Raspberry Pi