🥇Volledig Kubernetes vanaf nul op Raspberry Pi

Onlangs heeft een bekende onderneming aangekondigd dat het zijn lijn laptops overstapt naar ARM-architectuur. Toen ik dit nieuws hoorde, herinnerde ik me dat ik bij het bekijken van de prijzen voor EC2 op AWS, oog viel op de Graviton-servers met een zeer aantrekkelijke prijs. De catch was echter dat dit ARM was. Toen had ik nog niet in gedachten dat ARM iets serieus was...

Voor mij was deze architectuur altijd het domein van mobiele apparaten en andere IoT-dingetjes. ‘Echte’ servers op ARM is toch wel ongebruikelijk, zelfs op een bepaalde manier vreemd... Maar een nieuwe gedachte kwam bij me op, dus besloot ik op een van de weekenden te checken wat je tegenwoordig op ARM kunt draaien. En om dit te doen, besloot ik te beginnen met het vertrouwde - een Kubernetes-cluster. En niet zomaar een 'cluster', maar echt 'professional', zodat het zo dicht mogelijk bij de productie komt.

Volgens mijn plan moet het cluster toegankelijk zijn vanuit het internet, er moet een bepaalde webapplicatie draaien en er moet minimaal monitoring zijn. Voor de uitvoering van dit idee heb je een paar (of meer) Raspberry Pi's nodig, niet lager dan model 3B+. AWS zou een plek voor experimenten kunnen zijn, maar ik was vooral geïnteresseerd in de ‘frambozen’ (die toch stil lagen). Dus gaan we een Kubernetes-cluster opzetten met Ingress, Prometheus en Grafana.

Voorbereiding van de ‘frambozen’

Installatie van het besturingssysteem en SSH

Bij het kiezen van het besturingssysteem voor installatie heb ik me niet te veel zorgen gemaakt: ik heb gewoon de nieuwste Raspberry Pi OS Lite genomen met de officiële website. Daar is ook de installatiedocumentatie beschikbaar, alle handelingen die uitgevoerd moeten worden op alle knooppunten van het toekomstige cluster. Vervolgens moeten de volgende handelingen worden uitgevoerd (ook op alle knooppunten).

Met een monitor en toetsenbord aangesloten, moet je eerst het netwerk en SSH configureren:

Voor het functioneren van het cluster moet de master een statisch IP-adres hebben, en op de werkknopen is dat naar keuze. Ik geef de voorkeur aan statische adressen overal uit het oogpunt van gebruiksgemak bij de configuratie.
Een statisch adres kan worden geconfigureerd in het besturingssysteem (in het bestand /etc/dhcpcd.conf is er een geschikt voorbeeld) of door het lease in de DHCP-server van de gebruikte (in mijn geval de thuis) router te fixeren.
ssh-server wordt gewoon ingeschakeld in raspi-config (interfacing options → ssh).

Daarna kun je inloggen via SSH (standaard inlognaam is pi, en het wachtwoord is framboos of de waarop je bent overgestapt) en ga verder met de instellingen.

Andere instellingen

We stellen de hostnaam in. In mijn voorbeeld worden de volgende namen gebruikt pi-control en pi-worker.
Laten we controleren of het bestandssysteem is vergroot naar de volledige schijf (df -h /). Indien nodig kan het worden vergroot met raspi-config.
We wijzigen het standaard wachtwoord van de gebruiker in raspi-config.
We schakelen het swapbestand uit (dit is een vereiste van Kubernetes; als je meer details over dit onderwerp wilt, zie issue #53533):
```
dphys-swapfile swapoff
systemctl disable dphys-swapfile
```
We updaten de pakketten naar de laatste versies:
```
apt-get update && apt-get dist-upgrade -y
```

We installeren Docker en aanvullende pakketten:

apt-get install -y docker docker.io apt-transport-https curl bridge-utils iptables-persistent

Bij de installatie van iptables-persistent moet je de iptables-instellingen voor ipv4 opslaan, en in het bestand /etc/iptables/rules.v4 moet je regels toevoegen aan de keten FORWARD, zo:

# 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

Het enige dat nog rest, is opnieuw opstarten.

Nu is alles klaar voor de installatie van het Kubernetes-cluster.

Kubernetes installatie

In deze fase heb ik opzettelijk al mijn en onze bedrijfsaanpassingen voor het automatiseren van de installatie en configuratie van het K8s-cluster uitgesteld. In plaats daarvan gebruiken we de officiële documentatie met kubernetes.io (licht aangevuld met opmerkingen en inkortingen).

Laten we de Kubernetes-repository toevoegen:

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

Vervolgens wordt in de documentatie voorgesteld om de CRI (container runtime interface) te installeren. Aangezien Docker al is geïnstalleerd, gaan we verder en installeren we de belangrijkste componenten:

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

Bij de installatie van de belangrijkste componenten heb ik meteen kubernetes-cnitoegevoegd, dat nodig is voor het functioneren van het cluster. En hier is een belangrijk punt: het pakket kubernetes-cni maakt om de een of andere reden niet standaard een map aan voor de CNI-interface-instellingen, dus ik moest deze handmatig aanmaken:

mkdir -p /etc/cni/net.d

Voor de werking van de network-backend, waar we het hieronder over zullen hebben, moet de plugin voor CNI worden geïnstalleerd. Ik heb de vertrouwde en begrijpelijke plugin portmap gekozen (de volledige lijst hiervan zie in de documentatie):

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-instellingen

Node met control plane

De installatie van het cluster zelf is vrij eenvoudig. En om dit proces te versnellen en te controleren of de Kubernetes-images beschikbaar zijn, kunnen we vooraf uitvoeren:

kubeadm config images pull

Nu gaan we door met de installatie — we initialiseren de control plane van het cluster:

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

Let op, de subnetten voor services en pods mogen niet overlappen met elkaar en met bestaande netwerken.

Aan het einde zien we een bericht dat alles goed is gegaan, en we krijgen tegelijkertijd advies over hoe we werkknopen aan het control plane kunnen toevoegen:

Je Kubernetes control-plane is succesvol geïnitieerd! 
Om je cluster te gaan gebruiken, moet je het volgende uitvoeren als een gewone gebruiker: 
 mkdir -p $HOME/.kube 
 sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config 
 sudo chown $(id -u):$(id -g) $HOME/.kube/config 
Je moet nu een pod-netwerk naar de cluster implementeren. 
Voer "kubectl apply -f [podnetwork].yaml" uit met een van de opties die je vindt op: 
 https://kubernetes.io/docs/concepts/cluster-administration/addons/ 
Je kunt nu een onbeperkt aantal control-plane knooppunten aansluiten door het volgende commando als root op elk uit te voeren: 
 kubeadm join 192.168.88.30:6443 --token a485vl.xjgvzzr2g0xbtbs4 
   --discovery-token-ca-cert-hash sha256:9da6b05aaa5364a9ec59adcc67b3988b9c1b94c15e81300560220acb1779b050 
   --contrl-plane --certificate-key 72a3c0a14c627d6d7fdade1f4c8d7a41b0fac31b1faf0d8fdf9678d74d7d2403 
Let op dat de certificate-key toegang geeft tot gevoelige gegevens in de cluster, houd deze geheim! 
Als veiligheidsmaatregel worden de geüploadde certificaten binnen twee uur verwijderd; Indien nodig kun je 
"kubeadm init phase upload-certs --upload-certs" gebruiken om later opnieuw certificaten te uploaden. 
Daarna kun je een onbeperkt aantal werkknopen verbinden door het volgende als root op elk uit te voeren: 
kubeadm join 192.168.88.30:6443 --token a485vl.xjgvzzr2g0xbtbs4 
   --discovery-token-ca-cert-hash sha256:9da6b05aaa5364a9ec59adcc67b3988b9c1b94c15e81300560220acb1779b050

Laten we de aanbevelingen opvolgen om de configuratie voor de gebruiker toe te voegen. Ik raad ook aan om meteen autocompletion voor kubectl toe te voegen:

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

Op dit moment is het al mogelijk om de eerste node in de cluster te zien (hoewel deze nog niet klaar is):

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

Netwerkconfiguratie

Vervolgens, zoals vermeld in het bericht na de installatie, moet er een netwerk in de cluster worden geïnstalleerd. In de documentatie worden Calico, Cilium, contiv-vpp, Kube-router en Weave Net als opties aangeboden... Hier ben ik afgeweken van de officiële instructies en heb ik een meer vertrouwde en begrijpelijke optie gekozen: flannel in host-gw modus (meer informatie over beschikbare backends zie in de projectdocumentatie).

Het is vrij eenvoudig om het in de cluster te installeren. Om te beginnen — download de manifesten:

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

Vervolgens veranderen we in de instellingen het type van vxlan en een werkende opdracht krijgen. host-gw:

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

… en de pod-subnet — van de standaardwaarde naar de waarde die tijdens de initialisatie van de cluster is opgegeven:

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

Daarna maken we de resources aan:

kubectl create -f kube-flannel.yml

Klaar! Na enige tijd zal de eerste K8s-node naar de status gaan Klaar:

NAAM         STATUS   ROLEN    LEEFTIJD   VERSIE
pi-control   Klaar    master   2m    v1.18.6

Een werknode toevoegen

Nu kan een worker worden toegevoegd. Hiervoor moet je gewoon de eerder ontvangen opdracht uitvoeren op de node, nadat Kubernetes is geïnstalleerd volgens het bovenstaande scenario:

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

Hiermee kunnen we concluderen dat de cluster klaar is:

root@pi-control:~# kubectl get no
NAAM         STATUS   ROLEN    LEEFTIJD    VERSIE
pi-control   Klaar    master   28m    v1.18.6
pi-worker    Klaar       2m8s   v1.18.6

Ik had slechts twee Raspberry Pi's tot mijn beschikking, dus ik wilde er geen van hen aan het control plane toewijzen. van Daarom heb ik de automatisch toegekende taint van de node pi-control verwijderd door:

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

… en de regels te verwijderen:

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

De cluster vullen met de noodzakelijke minimums

In de eerste plaats hebben we nodig Helm. Natuurlijk kan alles ook zonder gedaan worden, maar Helm maakt het mogelijk om verschillende componenten naar eigen inzicht in te stellen zonder bestanden te bewerken. En eigenlijk is het gewoon een binaire bestand dat "geen brood vraagt".

Dus, laten we naar helm.sh gaan in de sectie docs/installation en de opdracht van daar uitvoeren:

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

Daarna voegen we de chartrepository toe:

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

Laten we nu de infrastructuurcomponenten installeren volgens het plan:

Ingress controller;
Prometheus;
Grafana;
cert-manager.

Ingress controller

De eerste component — Ingress controller — wordt vrij eenvoudig geïnstalleerd en is 'uit de doos' klaar voor gebruik. Hiervoor hoef je alleen maar naar de sectie bare-metal op de website te gaan en de installatiopdracht daar uit te voeren:

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

Echter, op dat moment begon de 'framboos' te stressen en te worstelen met de schijf IOPS. Het probleem is dat samen met de Ingress-controller een groot aantal bronnen wordt geïnstalleerd, veel verzoeken naar de API worden gedaan en dus veel gegevens in etcd worden geschreven. Kortom, of de 10 klasse SD-kaart is niet erg efficiënt, of er is gewoon niet genoeg capaciteit voor deze belasting. Desondanks startte alles na ongeveer 5 minuten.

Er werd een namespace aangemaakt en daarin verscheen de controller met alles wat hij nodig had:

root@pi-control:~# kubectl -n ingress-nginx get pod
Naam                                        Klaar   Status      Herstarts   Leeftijd
ingress-nginx-admission-create-2hwdx        0/1     Voltooid   0          31s
ingress-nginx-admission-patch-cp55c         0/1     Voltooid   0          31s
ingress-nginx-controller-7fd7d8df56-68qp5   1/1     Draait     0          48s

Prometheus

De volgende twee componenten zijn vrij eenvoudig te installeren via Helm vanuit de chart repo.

Zoek Prometheus, we maken een namespace en installeren deze:

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"}

Standaard vraagt Prometheus om 2 schijven: voor de gegevens van Prometheus zelf en voor de gegevens van AlertManager. Aangezien er in het cluster geen storage class is gemaakt, worden de schijven niet aangevraagd en zullen de pods niet starten. Voor bare metal-installaties van Kubernetes gebruiken we meestal Ceph rbd, maar in het geval van Raspberry Pi is dat duidelijk overkill.

Daarom maken we eenvoudige lokale opslag aan op hostpath. De manifesten voor de PV (persistent volume) voor prometheus-server en prometheus-alertmanager zijn samengevoegd in het bestand prometheus-pv.yaml in Git-repositories met voorbeelden voor het artikel. De directory voor de PV moet van tevoren worden aangemaakt op de schijf van de node waaraan we Prometheus willen koppelen: in het voorbeeld staat nodeAffinity op hostname pi-worker en daar zijn de directory's aangemaakt /data/localstorage/prometheus-server en /data/localstorage/prometheus-alertmanager.

We downloaden (klonen) het manifest en voegen het toe aan Kubernetes:

kubectl create -f prometheus-pv.yaml

In dit stadium kwam ik voor het eerst een probleem met de ARM-architectuur tegen. Kube-state-metrics, dat standaard wordt geïnstalleerd in de Prometheus-chart, weigerde te starten. Het gaf de foutmelding:

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"

Het probleem is dat voor kube-state-metrics een afbeelding van het CoreOS-project wordt gebruikt, die niet voor ARM wordt gebuild:

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

Ik moest wat googelen en vond bijvoorbeeld deze afbeelding. Om hiervan gebruik te maken, updaten we de release en geven we aan welke afbeelding we voor kube-state-metrics willen gebruiken:

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

We controleren of alles is opgestart:

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 en cert-manager

Voor grafieken en dashboards installeren we Grafana:

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

Aan het einde van de uitvoer laten ze ons zien hoe we het wachtwoord voor toegang kunnen krijgen:

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

Voor het aanvragen van certificaten installeren we cert-manager. Voor de installatie verwijzen we naar de documentatie, die de bijbehorende commando's voor Helm aanbiedt:

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

Voor zelfondertekende certificaten voor thuisgebruik is dit ruim voldoende. Als je echter hetzelfde wilt ontvangen Let’s Encrypt, moet je ook de cluster issuer instellen. Details hierover kun je vinden in ons artikel "SSL-certificaten van Let’s Encrypt met cert-manager in Kubernetes».

Ik heb zelf gekozen voor de optie uit het voorbeeld in de documentatie, ervan overtuigd dat de staging-versie van LE voldoende zou zijn. We passen in het voorbeeld het e-mailadres aan, slaan het op in een bestand en voegen het toe aan de cluster (cert-manager-cluster-issuer.yaml):

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

Nu kunnen we een certificaat aanvragen, bijvoorbeeld voor Grafana. Hiervoor zijn een domein en toegang tot de cluster van buitenaf nodig. Ik heb een domein en heb het verkeer ingesteld door poorten 80 en 443 op mijn thuisrouter door te sturen zoals gespecificeerd in de gemaakte service van de ingress-controller:

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

De 80e poort wordt in dit geval doorgegeven naar 31303, en 443 naar 30498. (Poorten worden willekeurig gegenereerd, dus jouw poorten kunnen anders zijn.)

Hier is een voorbeeld van een certificaat (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

We voegen het toe aan de cluster:

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

Daarna verschijnt de Ingress resource, waarmee de validatie door Let’s Encrypt zal plaatsvinden:

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

Na het passeren van de validatie, zullen we zien dat de resource certificate klaar is, en in de eerder genoemde secret grafana-tls — het certificaat en de sleutel. We kunnen meteen controleren wie het certificaat heeft uitgegeven:

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

Laten we terugkeren naar Grafana. We moeten een paar wijzigingen aanbrengen in de Helm-release, waarbij we de instellingen voor TLS aanpassen aan het gemaakte certificaat.

Hiervoor downloaden we de chart, passen deze aan en updaten we vanuit de lokale directory:

helm pull --untar stable/grafana

We bewerken het bestand grafana/values.yaml TLS-parameters:

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

Hier kunnen we ook Prometheus instellen als datasource:

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

Nu updaten we de Grafana chart vanuit de lokale directory:

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

We controleren of de Ingress grafana poort 443 heeft toegevoegd en of er toegang is via HTTPS:

root@pi-control:~# kubectl -n monitoring get ing grafana
NAME CLASS HOSTS ADDRESS PORTS AGE
grafana  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=; Path=/; HttpOnly; SameSite=Lax
x-frame-options: deny
strict-transport-security: max-age=15724800; includeSubDomains

Om Grafana in actie te demonstreren, kun je een dashboard voor kube-state-metrics. Dit is hoe het eruit ziet:

Ik raad ook aan een dashboard voor node exporter toe te voegen: het zal gedetailleerd laten zien wat er met de 'frambozen' gebeurt (CPU-belasting, geheugengebruik, netwerk, schijf, enz.).

Na dit alles denk ik dat de cluster klaar is om applicaties te ontvangen en te draaien!

Opmerking over de build

Voor het bouwen van applicaties voor de ARM-architectuur zijn er minstens twee opties. Ten eerste kun je bouwen op een ARM-apparaat. Toen ik echter naar het huidige gebruik van twee Raspberry Pi's keek, besefte ik dat ze het bouwen zelf ook niet zullen volhouden. Daarom heb ik een nieuwe Raspberry Pi 4 besteld (die is krachtiger en heeft maar liefst 4 GB geheugen) — ik ben van plan om daar op te bouwen.

De tweede optie is om een multi-architectuur Docker-image te bouwen op een krachtiger machine. Hiervoor is er de extensie docker buildx. Als de applicatie in een compileertaal is geschreven, is cross-compilatie voor ARM vereist. Ik zal niet alle instellingen voor die benadering beschrijven, omdat dat een apart artikel zou vergen. Met deze aanpak kunnen 'universele' images worden bereikt: Docker, dat draait op een ARM-machine, zal automatisch het corresponderende architecture-image downloaden.

Conclusie

Het uitgevoerde experiment overtrof al mijn verwachtingen: [minstens] 'vanilla' Kubernetes met de benodigde basis presteert uitstekend op ARM, en tijdens de configuratie stuitte ik op slechts een paar nuances.

De Raspberry Pi 3B+ houdt de CPU-last goed vol, maar hun SD-kaarten zijn een duidelijke bottleneck. Collega's hebben gesuggereerd dat in sommige versies de mogelijkheid bestaat om op USB te booten, waar je een SSD op kunt aansluiten: dan zal de situatie waarschijnlijk verbeteren.

Hier is een voorbeeld van de CPU-belasting tijdens de installatie van Grafana:

Voor experimenten en 'om te proberen', vind ik dat een Kubernetes-cluster op 'raspberries' veel beter aanvoelt voor gebruik dan dezelfde Minikube, omdat alle componenten van het cluster daadwerkelijk worden geïnstalleerd en werken 'volwassen'.

In de toekomst is het idee om de volledige CI/CD-cyclus toe te voegen aan het cluster, volledig gerealiseerd op Raspberry Pi. En ik zou blij zijn als iemand zijn ervaring met de configuratie van K8s op AWS Graviton wil delen.

P.S. Ja, 'productie' kan dichterbij zijn dan ik dacht: