🥇Pilnvērtīgs Kubernetes no nulles uz Raspberry Pi

Ļoti nesen viena pazīstama kompānija paziņoja, ka pāriet uz ARM arhitektūru saviem klēpjdatoru modeļiem. Dzirdot šo ziņu, es atcerējos, ka, apskatot cenas EC2 AWS, pievērsu uzmanību Graviton’iem ar ļoti pievilcīgu cenu. Proti, grūtība, kā zināms, bija tajā, ka tas ir ARM. Toreiz man nemaz nenāca prātā, ka ARM ir diezgan nopietni...

Man šī arhitektūra vienmēr ir šķitusi kā mobilās ierīces un citas IoT rīku pārziņa. "Īstie" serveri uz ARM ir kā neparasti, pat kaut kā dīvaini... Tomēr jaunā doma man iešāvās prātā, tāpēc vienā no brīvdienām nolēmu pārbaudīt, ko vispār var palaist uz ARM šodien. Un tam nolēmu sākt ar tuvāko un pazīstamāko – Kubernetes klasteri. Turklāt ne tikai kādu nosacītu "klasteri", bet pilnu versiju, lai tas būtu maksimāli līdzīgs tam, kā esmu pieradis to redzēt ražošanā.

Manā iecerē klasterim jāpiekļūst no interneta, tajā jādarbojas kādam tīmekļa lietotnei un tam jānodrošina vismaz uzraudzība. Lai realizētu šo ideju, būs nepieciešami daži (vai vairāk) Raspberry Pi ne zemāki par 3B+ modeli. Eksperimentu platforma varētu būt arī AWS, bet mani interesēja tieši "maliņas" (kuras tāpat stāvēja bez darba). Tātad, mēs izveidosim uz tiem Kubernetes klasteri ar Ingress, Prometheus un Grafana.

„Maliņu” sagatavošana

Operētājsistēmas un SSH instalēšana

Ar operētājsistēmas izvēli es īpaši neizšķirojos: vienkārši paņēmu visjaunāko Raspberry Pi OS Lite no oficiālās vietnes. Tur arī pieejama instalācijas dokumentācija, visas darbības, kuras jāveic visos nākamā klastera mezglos. Tālāk būs jāveic sekojošas manipulācijas (tām arī visiem mezgliem).

Pievienojot monitoru un tastatūru, ir jāveic sākotnējās tīkla un SSH iestatīšanas procedūras:

Klastera darbībai uz mātes mezgla obligāti jābūt statiskai IP adresei, bet darba mezglos – pēc izvēles. Es izvēlējos statiskas adreses visur ērtības dēļ.
Statisko adresi var konfigurēt operētājsistēmā (failā /etc/dhcpcd.conf ir piemērs) vai, fiksējot lease DHCP serverī, kas tiek izmantots (manā gadījumā – mājas) maršrutētājā.
ssh-server var vienkārši ieslēgt raspi-config (interfacing options → ssh).

Pēc tam jau var piereģistrēties pa SSH (pēc noklusējuma lietotājvārds – pi, un parole – raspberry vai tas, uz kuru mainījāt) un turpinām iestatījumus.

Citi iestatījumi

Iestatīsim hosta vārdu. Manā piemērā tiks izmantots pi-control un pi-worker.
Pārbaudīsim, vai failu sistēma ir paplašināta visam diskam (df -h /). Ja nepieciešams, to var paplašināt, izmantojot raspi-config.
Mainīsim noklusējuma lietotāja paroli raspi-config.
Izslēgsim swap failu (tāds ir Kubernetes prasība; ja interesē šī tēma, sk. issue #53533):
```
dphys-swapfile swapoff
systemctl disable dphys-swapfile
```
Atjaunināsim pakotnes uz jaunākajām versijām:
```
apt-get update && apt-get dist-upgrade -y
```

Instalēsim Docker un papildu pakotnes:

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

Instalācijas laikā iptables-persistent būs nepieciešams saglabāt iptables iestatījumus ipv4, kā arī failā /etc/iptables/rules.v4 — pievienot noteikumus ķēdei FORWARD, tāpat:

# 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

Viss, kas paliek, ir restartēties.

Tagad viss ir gatavs Kubernetes klastera instalācijai.

Kubernetes instalācija

Šajā posmā es speciāli atliktu visus savus un mūsu uzņēmuma izstrādājumus automatizācijai klastera K8s uzstādīšanai un konfigurēšanai. Tā vietā izmantosim oficiālo dokumentāciju no kubernetes.io (vieglāk papildinātu ar komentāriem un saīsinājumiem).

Pievienosim Kubernetes repozitoriju:

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

Tālāk dokumentācijā tiek ieteikts uzstādīt CRI (container runtime interface). Ņemot vērā, ka Docker jau ir uzstādīts, virzāmies tālāk un instalējam galvenās sastāvdaļas:

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

Galveno komponentu uzstādīšanas posmā es uzreiz pievienoju kubernetes-cni, kas ir nepieciešams klastera darbībai. Šeit ir svarīgs brīdis: pakotne kubernetes-cni kādēļ prasības dēļ neizveido noklusējuma direktoriju CNI interfeisiem, tādēļ man bija jāizveido tā manuāli:

mkdir -p /etc/cni/net.d

Lai nodrošinātu tīkla aizmugurē, par kuru tiks runāts tālāk, ir nepieciešams uzstādīt CNI spraudni. Es izvēlējos sev pazīstamu un saprotamu spraudni portmap (pilnu sarakstu skat. dokumentācijā):

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 konfigurācija

Kontrolējošais plāns

Paša klastera uzstādīšana ir ļoti vienkārša. Lai paātrinātu šo procesu un pārbaudītu, vai Kubernetes attēli ir pieejami, var iepriekš izpildīt:

kubeadm config images pull

Tagad veiksim pašu instalāciju — inicializēsim klastera control plane:

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

Lūdzu, ņemiet vērā, ka pakalpojumu un pod'iem paredzētajām apakšnetēm nedrīkst pārklāties savā starpā vai ar esošajām tīkla konfigurācijām.

Beigās mums parādīs paziņojumu, ka viss ir kārtībā, un arī norādīs, kā pievienot darba mezglus control plane:

Jūsu Kubernetes control-plane ir veiksmīgi inicializēts!
Lai sāktu izmantot savu klasteri, jums jādara sekojošais kā parastam lietotājam:
 mkdir -p $HOME/.kube
 sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
 sudo chown $(id -u):$(id -g) $HOME/.kube/config
Tagad jums vajadzētu ieviest pod tīklu klasterī.
Izmantojiet "kubectl apply -f [podnetwork].yaml" ar vienu no iespēju, kas norādīta:
 https://kubernetes.io/docs/concepts/cluster-administration/addons/
Tagad varat pievienot jebkuru skaitu control-plane mezglu, izpildot sekojošo komandu katrā no tiem kā root:
 kubeadm join 192.168.88.30:6443 --token a485vl.xjgvzzr2g0xbtbs4 
   --discovery-token-ca-cert-hash sha256:9da6b05aaa5364a9ec59adcc67b3988b9c1b94c15e81300560220acb1779b050 
   --contrl-plane --certificate-key 72a3c0a14c627d6d7fdade1f4c8d7a41b0fac31b1faf0d8fdf9678d74d7d2403
Lūdzu, ņemiet vērā, ka certificate-key sniedz piekļuvi klastera sensitīviem datiem, glabājiet to slepeni!
Kā drošības pasākums, augšupielādētie certifikāti tiks dzēsti divu stundu laikā; Ja nepieciešams, varat izmantot
"kubeadm init phase upload-certs --upload-certs" lai pēc tam atkārtoti ielādētu certifikātus.
Tad varat pievienot jebkuru skaitu darba mezglu, izpildot sekojošo katrā no tiem kā root:
kubeadm join 192.168.88.30:6443 --token a485vl.xjgvzzr2g0xbtbs4 
   --discovery-token-ca-cert-hash sha256:9da6b05aaa5364a9ec59adcc67b3988b9c1b94c15e81300560220acb1779b050

Izpildīsim ieteikumus par konfigurācijas pievienošanu lietotājam. Un arī ieteiktu tūlīt pievienot automātisko pabeigšanu kubectl:

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

Šajā posmā jau var redzēt pirmo mezglu klasterī (protams, tas vēl nav gatavs):

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

Tīklošanas konfigurācija

Tālāk, kā tika teikts paziņojumā pēc instalācijas, būs nepieciešams uzstādīt tīklu klasterī. Dokumentācijā piedāvā izvēli no Calico, Cilium, contiv-vpp, Kube-router un Weave Net… Šeit es atkāpos no oficiālās instrukcijas un izvēlējos man pazīstamāku un saprotamāku variantu: flannel host-gw režīmā (vairāk par pieejamajiem backend’iem skat. projekta dokumentācijā).

To uzstādīt klasterī ir diezgan vienkārši. Vispirms — lejupielādējam manifestus:

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

Tad mainām iestatījumos tipu no vxlan uz host-gw:

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

… un pod’iem paredzēto apakšneti — no noklusējuma vērtības uz to, kas norādīta klastera inicializēšanas laikā:

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

Pēc tam izveidojam resursus:

kubectl create -f kube-flannel.yml

Gatavs! Pēc kāda laika pirmais K8s mezgls pāries statusā Gatavs:

VĀRDS         STATUSS   ROLI    VECUMS   VERSIJA
pi-control   Gatavs    galvenais   2m    v1.18.6

Darba mezgla pievienošana

Tagad var pievienot darbinieku. Lai to izdarītu, uz tā — pēc Kubernetes instalēšanas atbilstoši iepriekš aprakstītajam scenārijam — vienkārši izpildiet iepriekš iegūto komandu:

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

Uzskatām, ka klasteris ir gatavs:

root@pi-control:~# kubectl get no
VĀRDS         STATUSS   ROLI    VECUMS    VERSIJA
pi-control   Gatavs    galvenais   28m    v1.18.6
pi-worker    Gatavs       2m8s   v1.18.6

Manā rīcībā bija tikai divas Raspberry Pi, tāpēc nevēlējos atdot vienu no tām tikai kontroles līmenim. Tāpēc es noņēmu automātiski uzstādīto tainted ar komandu:

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

… un izdzēsu rindu:

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

Klastera piepildīšana ar nepieciešamo minimumu

Vispirms mums būs nepieciešams Helm. Protams, visu var izdarīt arī bez tā, bet Helm ļauj burtiski bez failu rediģēšanas konfigurēt dažas sastāvdaļas pēc saviem ieskatiem. Un patiesībā tas ir vienkārši izpildāms fails, kas «maizi neprasa».

Tātad, ieejam helm.sh dokumentācijas/uzstādīšanas sadaļā un izpildām komandu no turienes:

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

Pēc tam pievienojam chartu repozitoriju:

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

Tagad instalēsim infrastruktūras sastāvdaļas saskaņā ar plānu:

Ingress kontrolieris;
Prometheus;
Grafana;
cert-manager.

Ingress kontrolieris

Pirmais komponents — Ingress kontrolieris — tiek uzstādīts diezgan viegli un ir gatavs lietošanai «no kastes». Lai to izdarītu, pietiek ieiet bare-metal sadaļā mājaslapā un izpildīt instalācijas komandu no turienes:

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

Tomēr šajā brīdī «maliņa» sāka saspringt un iestigt diska IOPS. Problēma ir tāda, ka kopā ar Ingress kontrolieri tiek uzstādīts liels daudzums resursu, tiek izpildīti daudzi pieprasījumi API, un līdz ar to daudz datu tiek pierakstīti etcd. Kopumā vai nu atmiņas karte 10. klases nav ļoti izturīga, vai nu SD kartes vienkārši nav pietiekami, lai izturētu šo slodzi. Tomēr pēc apmēram 5 minūtēm viss tika palaists.

Tika izveidots nosaukumu telpa un tajā parādījās kontrolieris un viss nepieciešamais:

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

Šos divus komponentus diezgan vienkārši var instalēt, izmantojot Helm no chart repo.

Atrodam Prometheus, izveidojam namespace un instalējam tajā:

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

Pēc noklusējuma Prometheus pieprasa 2 diskus: vienu pašam Prometheus datiem un otru AlertManager datiem. Tā kā klasterī nav izveidots storage class, diski netiks pasūtīti un pod'i nesāks darboties. Bare metal Kubernetes instalācijām parasti izmantojam Ceph rbd, tomēr Raspberry Pi gadījumā tas ir pārmērīgi.

Tāpēc izveidosim vienkāršu local storage uz hostpath. PV (persistent volume) manifesti prometheus-server un prometheus-alertmanager ir apvienoti failā prometheus-pv.yaml par Git repozitoriji ar piemēriem šim rakstam. PV direktorija ir jā iepriekš izveido uz diska tā mezgla, pie kura vēlamies piesaistīt Prometheus: piemērā ir norādīts nodeAffinity pēc hostname pi-worker un uz tā ir izveidotas direktorijas /data/localstorage/prometheus-server un /data/localstorage/prometheus-alertmanager.

Lejupielādējam (klonējam) manifestu un pievienojam to Kubernetes:

kubectl create -f prometheus-pv.yaml

Šajā posmā es pirmo reizi sastapos ar ARM arhitektūras problēmu. Kube-state-metrics, kas pēc noklusējuma tiek instalēts Prometheus chartā, atteicās startēt. Tas izsniedza kļūdu:

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"

Problēma ir tajā, ka kube-state-metrics izmanto CoreOS projekta attēlu, kas nav kompilēts ARM iestatījumiem:

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

Man nācās nedaudz googlēt un atrast, piemēram, šo attēlu. Lai to izmantotu, atjaunināsim izlaidi, norādot, kuru attēlu izmantot kube-state-metrics:

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

Pārbaudām, vai viss ir iedarbināts:

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

Lai izveidotu grafikus un vadības paneļus, instalējam Grafana:

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

Izvades beigās tiks parādīts, kā iegūt paroli piekļuvei:

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

Lai pasūtītu sertifikātus, instalējam cert-manager. Lai to instalētu, piesaistāmies dokumentācijā, kas piedāvā atbilstošas komandas Helm:

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

Pašparakstītiem sertifikātiem mājas lietošanai tas ir pilnīgi pietiekami. Ja nepieciešams saņemt to pašu Let’s Encrypt, tad jāiestata arī cluster issuer. Sīkāku informāciju var atrast mūsu rakstā «SSL sertifikāti no Let’s Encrypt ar cert-manager Kubernetes».

Es izvēlējos variantu no piemēra dokumentācijā, nolēmis, ka LE staging variants būs pietiekams. Mainām piemēra e-pastu, saglabājam failā un pievienojam klasterim (cert-manager-cluster-issuer.yaml):

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

Tagad varam pasūtīt sertifikātu, piemēram, Grafana. Tam būs nepieciešams domēns un piekļuve klasterim no ārpuses. Man ir domēns, un esmu konfigurējis portu 80 un 443 pāradresāciju manā mājas maršrutētājā saskaņā ar izveidoto ingress-controller pakalpojumu:

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

80. porta gadījumā šis tiek pārraidīts uz 31303, bet 443 – uz 30498. (Porti tiek ģenerēti nejauši, tāpēc jums tie būs citi.)

Šeit ir sertifikāta piemērs (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

Pievienojam to klasterim:

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

Pēc tam parādīsies Ingress resurss, caur kuru notiks Let’s Encrypt validācija:

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

Pēc tam, kad validācija tiks veikta, mēs redzēsim, ka resurss certificate ir gatavs, un iepriekš minētajā slepenībā grafana-tls ir sertifikāts un atslēga. Varam uzreiz pārbaudīt, kas ir izsniedzis sertifikātu:

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

Atgriezīsimies pie Grafana. Mums būs nepieciešams nedaudz koriģēt tās Helm izlaidumu, mainot iestatījumus TLS saskaņā ar izveidoto sertifikātu.

Tādēļ lejupielādējam chart, labojam un atjauninām to no lokālās direktorijas:

helm pull --untar stable/grafana

Rediģējam failā grafana/values.yaml TLS parametrus:

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

Šeit varam uzreiz konfigurēt uzstādīto Prometheus kā datasource:

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

Tagad no lokālās direktorijas atjauninām Grafana chart:

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

Pārbaudām, vai Ingress grafana ir pievienots 443 ports un ir pieejams pa 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

Lai demonstrētu Grafana darbībā, varat lejupielādēt un pievienot dashboard par kube-state-metrics. Šādi tas izskatās:

Vēl ieteiktu pievienot dashboard par node exporter: tas detalizēti parādīs, kas notiek ar „jaudām” (CPU slodze, atmiņas, tīkla, diska utt. izmantošana).

Pēc tam uzskatu, ka klasteris ir gatavs uzņemt un palaist lietojumprogrammas!

Piezīme par komplektu

Lai izstrādātu lietotnes ARM arhitektūrai, ir vismaz divas iespējas. Pirmkārt, var izstrādāt tieši uz ARM ierīces. Tomēr, apskatot divu Raspberry Pi pašreizējo noslodzi, es sapratu, ka uz tām apstrāde vairs nenotiks. Tāpēc pasūtīju jaunu Raspberry Pi 4 (tā ir jaudīgāka un tajā ir 4 GB atmiņas) — plānoju veikt izstrādi uz tās.

Otrā iespēja — izveidot multiarhitektūras Docker attēlu uz jaudīgākas mašīnas. Tam ir nepieciešams paplašinājums docker buildx. Ja lietotne ir kompilējama valodā, būs nepieciešama krustpasta kompilācija ARM. Visas iestatīšanas detaļas šādam ceļam neaprakstīšu, jo tas prasa atsevišķu rakstu. Realizējot šādu pieeju, var sasniegt "universālos" attēlus: Docker, kas darbojas uz ARM mašīnas, automātiski lejupielādēs attiecīgo arhitektūrai paredzēto attēlu.

Secinājums

Veiktā eksperiments pārsniedza visas manas cerības: [vismaz] "vanilīšu" Kubernetes ar nepieciešamo bāzi jūtas labi ARM, un tā konfigurācijā radās tikai pāris nianses.

Paši Raspberry Pi 3B+ iztur slodzi uz CPU, tomēr to SD kartes ir acīmredzams pudeļu kakls. Kolēģi paziņoja, ka dažās versijās ir iespēja startēt no USB, uz kuru var pieslēgt SSD: tad situācija, iespējams, uzlabosies.

Šeit ir piemērs CPU slodzei, instalējot Grafana:

Eksperimentiem un "pārbaudei" manā skatījumā Kubernetes klasteris uz "maliņām" daudz labāk parāda pieredzi izpildē nekā tas pats Minikube, jo visi klastera komponenti tiek instalēti un darbojas "nopietni".

Nākotnē ir ideja pievienot klasterim visu CI/CD ciklu, pilnībā īstenotu uz Raspberry Pi. Un es būšu priecīgs, ja kāds padalīsies ar savu pieredzi K8s iestatīšanā AWS Graviton'os.

P.S. Jā, "produkcija" var būt tuvāk, nekā es domāju: