🥇Fullständigt Kubernetes från grunden på Raspberry Pi

Nyligen meddelade ett välkänt företag att de övergår till ARM-arkitektur för sin serie bärbara datorer. När jag hörde denna nyhet kom jag att tänka på att jag vid ett flertal tillfällen hade kikat på priserna för EC2 i AWS och la märke till Graviton-processorerna med ett väldigt attraktivt pris. Problemet var givetvis att det var ARM. Då hade jag ingen aning om att ARM faktiskt är ganska respektingivande...

För mig har denna arkitektur alltid varit förknippad med mobil- och andra IoT-prylar. ''Riktiga'' servrar på ARM känns lite ovanligt, ja till och med bisarrt... Men en ny tanke satte sig i huvudet, så jag bestämde mig en weekend för att kolla vad som faktiskt går att köra på ARM idag. Jag ville börja med det som kändes mest bekant — ett Kubernetes-kluster. Och inte bara något slags ''kluster'', utan verkligen en riktig installation, så att det skulle bli så likt produktion som möjligt.

Enligt min plan skulle klustret vara tillgängligt från internet, köra en viss webapplikation och ha minst någon form av övervakning. För att förverkliga denna idé behövs ett par (eller fler) Raspberry Pi, minst i modellen 3B+. Plattformen för experimenten skulle kunna vara AWS, men jag var mer intresserad av just ''hallonen'' (som ändå stod oanvända). Så vi kommer att sätta upp ett Kubernetes-kluster på dem med Ingress, Prometheus och Grafana.

Förberedelse av ''hallonen''

Installation av OS och SSH

Jag lät mig inte överdrivet plågas av valet av operativsystem: jag tog helt enkelt den senaste Raspberry Pi OS Lite med den officiella sidan. Där finns även installationsdokumentation, alla åtgärder därifrån måste utföras på alla noder i det framtida klustret. Vidare behövs följande manövrer (också på alla noder).

Efter att ha anslutit en monitor och tangentbord, måste nätverket och SSH konfigureras först:

För att klustret ska fungera krävs en statisk IP-adress på master-noden, medan arbetande noder kan få adresser på valfritt sätt. Jag valde att använda statiska adresser överallt för att förenkla konfigurationen.
En statisk adress kan konfigureras i operativsystemet (i filen /etc/dhcpcd.conf finns ett lämpligt exempel) eller genom att fästa lease i DHCP-servern på den använda (i mitt fall — hemman) routern.
ssh-server aktiveras enkelt via raspi-config (interfacing options → ssh).

Efter detta kan du logga in via SSH (standardinloggning — pi, och lösenordet — raspberry eller det som ändrades) och fortsätta konfigurationerna.

Övriga inställningar

Vi ställer in värdnamnet. I mitt exempel kommer vi att använda pi-control och pi-worker.
Vi kontrollerar att filsystemet har utökats till hela disken (df -h /). Vid behov kan det utökas med hjälp av raspi-config.
Vi ändrar det förinställda lösenordet för användaren i raspi-config.
Vi stänger av swap-filen (detta är ett krav från Kubernetes; om du är intresserad av detaljer om detta, se issue #53533):
```
dphys-swapfile swapoff
systemctl disable dphys-swapfile
```
Vi uppdaterar paketen till de senaste versionerna:
```
apt-get update && apt-get dist-upgrade -y
```

Vi installerar Docker och ytterligare paket:

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

Vid installation iptables-persistent måste konfigureras för att spara iptables-inställningarna för ipv4, och i filen /etc/iptables/rules.v4 — lägg till regler i kedjan FORWARD, så här:

# 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

Det är bara att starta om.

Nu är allt klart för installationen av Kubernetes-klustret.

Installation av Kubernetes

Vid detta stadie har jag medvetet skjutit upp alla mina och våra företagslösningar för automatisk installation och konfiguration av K8s-kluster. Istället kommer vi att använda den officiella dokumentationen med kubernetes.io (lite kompletterad med kommentarer och förkortningar).

Vi lägger till Kubernetes-repositoriet:

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

Vidare föreslår dokumentationen att installera CRI (container runtime interface). Eftersom Docker redan är installerat, går vi vidare och installerar huvudkomponenterna:

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

Vid installationen av huvudkomponenterna lade jag också till kubernetes-cni, som är nödvändig för klustrets funktion. Här finns en viktig punkt: paketet kubernetes-cni skapar av någon anledning inte en standardkatalog för inställningarna för CNI-gränssnitten, så jag måste skapa den manuellt:

mkdir -p /etc/cni/net.d

För att fungera korrekt med nätverksbackend som kommer att diskuteras nedan, måste vi installera en plugin för CNI. Jag valde den bekväma och välkända portmap-plugin (se hela listan i dokumentationen):

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

Konfigurering av Kubernetes

Noden med control plane

Installationen av själva klustret görs ganska enkelt. För att påskynda denna process och kontrollera att Kubernetes-bilderna är tillgängliga kan vi först köra:

kubeadm config images pull

Nu genomför vi själva installationen — initierar klustrets control plane:

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

Observera att subnät för tjänster och poddar inte får överlappa varandra eller med befintliga nätverk.

I slutet kommer vi att se ett meddelande om att allt är okej, och vi får också råd om hur man ansluter arbetsnoder till kontrollplanet:

Ditt Kubernetes kontrollplan har initierats framgångsrikt!
För att börja använda din kluster måste du köra följande som en vanlig användare:
 mkdir -p $HOME/.kube
 sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
 sudo chown $(id -u):$(id -g) $HOME/.kube/config
Du bör nu distribuera ett pod-nätverk till klustret.
Kör "kubectl apply -f [podnetwork].yaml" med ett av alternativen som anges på:
 https://kubernetes.io/docs/concepts/cluster-administration/addons/
Du kan nu ansluta valfritt antal kontrollplane-noder genom att köra följande kommando på varje som root:
 kubeadm join 192.168.88.30:6443 --token a485vl.xjgvzzr2g0xbtbs4 
   --discovery-token-ca-cert-hash sha256:9da6b05aaa5364a9ec59adcc67b3988b9c1b94c15e81300560220acb1779b050 
   --contrl-plane --certificate-key 72a3c0a14c627d6d7fdade1f4c8d7a41b0fac31b1faf0d8fdf9678d74d7d2403
Observera att certificate-key ger åtkomst till klusterets känsliga data, håll det hemligt!
Som en säkerhetsåtgärd kommer uppladdade certifikat att raderas om två timmar; Om nödvändigt kan du använda
"kubeadm init phase upload-certs --upload-certs" för att ladda om certifikat i efterhand.
Sedan kan du ansluta valfritt antal arbetsnoder genom att köra följande på varje som root:
kubeadm join 192.168.88.30:6443 --token a485vl.xjgvzzr2g0xbtbs4 
   --discovery-token-ca-cert-hash sha256:9da6b05aaa5364a9ec59adcc67b3988b9c1b94c15e81300560220acb1779b050

Vi kommer att följa rekommendationerna för att lägga till konfigurationen för användaren. Jag rekommenderar också att du direkt lägger till autocompletions för kubectl:

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

Vid det här laget kan vi redan se den första noden i klustret (även om den inte är redo än):

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

Nätverkskonfiguration

Vidare, som nämnts i meddelandet efter installationen, kommer vi att behöva installera ett nätverk i klustret. Dokumentationen erbjuder val mellan Calico, Cilium, contiv-vpp, Kube-router och Weave Net… Här avvek jag från den officiella instruktionen och valde ett mer bekant och förståeligt alternativ: flannel i host-gw-läge (mer information om tillgängliga backendar finns i projektets dokumentation).

Att installera det i klustret är ganska enkelt. Först — ladda ner manifesten:

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

Därefter ändrar vi inställningarna så att typen blir vxlan till host-gw:

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

… och poddarnas subnät — från standardvärdet till det som angavs vid initiering av klustret:

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

Efter det skapar vi resurser:

kubectl create -f kube-flannel.yml

Klart! Efter en stund kommer den första K8s-noden att byta status Redo:

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

Lägg till en arbetsnod

Nu kan du lägga till en worker. För detta, efter att ha installerat Kubernetes enligt det ovan beskrivna scenariot, behöver du bara köra det tidigare erhållna kommandot:

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

Därmed kan vi säga att klustret är klart:

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

Jag hade bara två Raspberry Pi tillgängliga, så jag ville inte ge bort en av dem bara till kontrollplanet. Därför tog jag bort den automatiskt installerade tainten från noden pi-control genom att köra:

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

… och tog bort raderna:

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

Fyllning av klustret med minimikrav

Först och främst behöver vi Helm. Självklart kan man göra allt utan det, men Helm låter dig bokstavligen konfigurera vissa komponenter utan att redigera filer. Och i själva verket är det bara en binär fil som "inte ber om bröd".

Så, vi besöker helm.sh i avsnittet docs/installation och kör kommandot därifrån:

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

Efter detta lägger vi till chart-repositoriet:

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

Nu installerar vi infrastrukturkomponenterna enligt plan:

Ingress controller;
Prometheus;
Grafana;
cert-manager.

Ingress controller

Den första komponenten — Ingress controller — installeras ganska enkelt och är redo att användas direkt. För detta räcker det med att gå till avsnittet bare-metal på webbplatsen och köra installationskommandot därifrån:

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

Men vid detta tillfälle började "hallonen" att strula och kämpa med diskens IOPS. Poängen är att många resurser installeras tillsammans med Ingress-kontrollern, många API-förfrågningar görs, och därmed skrivs mycket data till etcd. Sammanfattningsvis, antingen är minneskortet av klass 10 inte särskilt effektivt, eller så saknas det allmänt SD-kort för en sådan belastning. Trots allt startade det efter ungefär 5 minuter.

Ett namespace skapades och där dök kontrollern och allt som behövdes upp:

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

De följande två komponenterna är ganska enkla att installera via Helm från chart-repot.

Vi hittar Prometheus, skapar vi ett namespace och installerar i det:

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

Som standard beställer Prometheus två diskar: för data från Prometheus själv och för data från AlertManager. Eftersom det inte skapades en storage class i klustret, kommer diskarna inte att beställas och pod'arna kan inte startas. För bare metal-installationer av Kubernetes använder vi vanligtvis Ceph rbd, men i fallet med Raspberry Pi är det uppenbarligen överdrivet.

Därför skapar vi en enkel local storage på hostpath. Manifesten för PV (persistent volume) för prometheus-server och prometheus-alertmanager har sammanställts i filen prometheus-pv.yaml på Git-repositories med exempel för artikeln. Katalogen för PV måste skapats i förväg på disken för den nod som vi vill binda Prometheus till: i exemplet har vi angett nodeAffinity utifrån hostname pi-worker och där har mappar skapats /data/localstorage/prometheus-server och /data/localstorage/prometheus-alertmanager.

Vi laddar ner (klonar) manifestet och lägger till det i Kubernetes:

kubectl create -f prometheus-pv.yaml

Vid det här steget stötte jag första gången på problemet med ARM-arkitekturen. Kube-state-metrics, som som standard installeras i Prometheus-chartet, vägrade att starta. Den gav ett felmeddelande:

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"

Problemet är att kube-state-metrics använder en bild från CoreOS-projektet, som inte byggs för ARM:

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

Jag var tvungen att googla lite och hitta, till exempel, denna bild. För att använda den uppdaterar vi releasen och anger vilken bild som ska användas för 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

Vi kontrollerar att allt har startat:

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

För diagram och dashboards installerar vi Grafana:

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

I slutet av utdata kommer vi att visa hur man får ett lösenord för åtkomst:

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

För att beställa certifikat installerar vi cert-manager. För installationen vänder vi oss till dokumentationen, som erbjuder motsvarande kommandon för 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

För självsignerade certifikat för hemmet är detta helt tillräckligt. Om du istället behöver få samma Let's Encrypt, måste du även konfigurera en cluster issuer. Mer information om detta finns i vår artikel “SSL-certifikat från Let’s Encrypt med cert-manager i Kubernetes».

Jag valde själv alternativet från exemplet i dokumentationen, och beslöt att staging-alternativet från LE skulle vara tillräckligt. Vi ändrar e-posten i exemplet, sparar det i en fil och lägger till det i klustret (cert-manager-cluster-issuer.yaml):

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

Nu kan man beställa ett certifikat, till exempel för Grafana. För detta krävs en domän och åtkomst till klustret utifrån. Jag har en domän, och jag har konfigurerat portarna 80 och 443 genom att vidarebefordra dem på min hemrouter enligt den skapade tjänsten 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

I det här fallet vidarebefordras port 80 till 31303 och 443 till 30498. (Portarna genereras slumpmässigt, så ni kommer att ha andra.)

Här är ett exempel på ett certifikat (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

Vi lägger till det i klustret:

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

Efter detta kommer det att dyka upp en Ingress-resurs genom vilken valideringen kommer att genomföras av Let’s Encrypt:

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

När valideringen har genomförts kommer vi att se att resursen certificate är klar, och i den angivna hemligheten grafana-tls finns certifikatet och nyckeln. Du kan genast kontrollera vem som utfärdade certifikatet:

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

Låt oss gå tillbaka till Grafana. Vi behöver göra några justeringar av dess Helm-release, genom att ändra inställningar för TLS enligt det skapade certifikatet.

För detta hämtar vi diagrammet, justerar det och uppdaterar från den lokala katalogen:

helm pull --untar stable/grafana

Redigerar i filen grafana/values.yaml TLS-parametrar:

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

Här kan vi också direkt konfigurera den installerade Prometheus som datasource:

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

Nu uppdaterar vi Grafana-diagrammet från den lokala katalogen:

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

Vi kontrollerar att Ingress grafana har fått port 443 och har tillgång över 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

För att demonstrera Grafana i aktion kan du hämta och lägga till dashboard för kube-state-metrics. Så här ser det ut:

Jag rekommenderar också att lägga till en dashboard för node exporter: den visar noggrant vad som händer med "malinerna" (CPU-belastning, minnesanvändning, nätverk, disk, etc.).

Efter detta anser jag att klustret är redo att ta emot och köra applikationer!

Observera angående byggnation

För att bygga applikationer för ARM-arkitektur finns det minst två alternativ. För det första kan du bygga på en ARM-enhet. Men efter att ha tittat på de nuvarande lasten på två Raspberry Pi insåg jag att de knappt klarar av byggen. Därför beställde jag en ny Raspberry Pi 4 (den är kraftfullare och har hela 4 GB minne) – jag planerar att bygga på den.

Det andra alternativet är att bygga en multi-arkitektur Docker-image på en kraftfullare maskin. För det har vi tillägget docker buildx. Om applikationen är skriven i ett kompilert språk, behöver du krosskompilering för ARM. Jag kommer inte att beskriva alla inställningar för denna väg, eftersom det skulle kräva en separat artikel. Genom att implementera detta tillvägagångssätt kan man uppnå "universella" bilder: Docker, som körs på en ARM-maskin, kommer automatiskt att ladda ner den bild som passar arkitekturen.

Slutsats

Det genomförda experimentet överträffade alla mina förväntningar: [minst] "vanilj" Kubernetes med nödvändig bas fungerar bra på ARM, och när det konfigurerades uppstod det endast några få nyanser.

Själva Raspberry Pi 3B+ klarar CPU-belastningen, men deras SD-kort är en tydlig flaskhals. Mina kollegor föreslog att det i vissa versioner finns möjlighet att starta från USB, där man kan koppla in ett SSD: då troligtvis kommer situationen att förbättras.

Här är ett exempel på CPU-belastningen vid installation av Grafana:

För experiment och "att prova", tycker jag att en Kubernetes-kluster på "hallon" ger en mycket bättre känsla av drift än till exempel Minikube, eftersom alla klusterkomponenter både installeras och fungerar "på riktigt".

Framtidsvisionen är att lägga till hela CI/CD-cykeln till klustret, helt genomfört på Raspberry Pi. Jag skulle också vara glad om någon delar med sig av sin erfarenhet av att konfigurera K8s på AWS Graviton.

P.S. Ja, "produktion" kan vara närmare än jag trott: