Full Kubernetes fra bunnen av på Raspberry Pi

Nylig kunngjorde et kjent selskap at de flytter linjen sin med bærbare datamaskiner til ARM-arkitektur. Da jeg hørte denne nyheten, kom jeg på at jeg, igjen mens jeg så på prisene for EC2 i AWS, la merke til Graviton-er med en veldig fristende pris. Selvfølgelig var det en hake ved det, for dette er ARM. Den gangen hadde jeg ikke i tankene at ARM er ganske seriøst ...

For meg har denne arkitekturen alltid vært forbeholdt mobile enheter og annet IoT-stæsj. «Ekte» servere på ARM virker heller uvanlig, til og med litt sprø ... Men en ny tanke festet seg, så en helg bestemte jeg meg for å sjekke hva som faktisk kan kjøres på ARM i dag. Og for dette ville jeg begynne med noe nært og kjært — et Kubernetes-kluster. Og ikke bare et hvilket som helst «kluster», men litt «voksent», slik at det ville være så likt som jeg er vant til å se det i produksjon.

I mitt hode skulle klusteret være tilgjengelig fra internett, det skulle kjøre en eller annen webapplikasjon, og det skulle være minst overvåkning. For å realisere denne ideen trengs det et par (eller flere) Raspberry Pi-modeller ikke lavere enn 3B+. Eksperimenteringsstedet kunne også vært AWS, men jeg var spesielt interessert i «bringebær» (som uansett stod ubrukt). Så, vi skal sette opp et Kubernetes-kluster med Ingress, Prometheus og Grafana på dem.

Forberedelse av «bringebær»

Installasjon av OS og SSH

Jeg stresset ikke med valg av OS for installasjon: jeg tok bare den nyeste Raspberry Pi OS Lite med den offisielle nettsiden. Der finnes også dokumentasjonen for installasjon, alle handlingene som må utføres på alle noder i det fremtidige klustret. Deretter må følgende manipulasjoner utføres (også på alle noder).

Når man har koblet til en skjerm og et tastatur, må man først konfigurere nettverket og SSH:

1. For at klusteret skal fungere må masteren ha en statisk IP-adresse, mens på arbeidsnoder kan det være valgfritt. Jeg foretrakk statiske adresser overalt av hensyn til enkelheten i konfigurasjonen.
2. En statisk adresse kan konfigureres i OS (i filen /etc/dhcpcd.conf finnes et passende eksempel) eller ved å fikse lease i DHCP-serveren til den brukte (i mitt tilfelle — hjemme) ruteren.
3. ssh-server aktiveres enkelt i raspi-config (grensesnittalternativer → ssh).

Etter dette kan man logge inn via SSH (standard innlogging er pi, og passordet er raspberry eller det man har endret til) og fortsette konfigurasjonen.

Andre innstillinger

1. Vi setter vertsnavnet. I mitt eksempel vil det bli brukt pi-control og pi-worker.
2. Vi sjekker at filsystemet er utvidet til hele disken (df -h /). Om nødvendig kan den utvides ved hjelp av raspi-config.
3. Vi endrer det forhåndsinstallerte brukernavnet i raspi-config.
4. Vi deaktiverer swap-filen (dette er et krav fra Kubernetes; hvis du er interessert i detaljer om dette, se issue #53533):

   dphys-swapfile swapoff
   systemctl disable dphys-swapfile

5. Vi oppdaterer pakkene til de nyeste versjonene:

   apt-get update && apt-get dist-upgrade -y

6. Vi installerer Docker og tilleggsprogrammer:

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

   Ved installasjon iptables-persistent må vi lagre iptables-innstillingene for ipv4, og i filen /etc/iptables/rules.v4 — legge til regler i kjeden FORWARD, slik:

   # 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

7. Det gjenstår bare å starte på nytt.

Nå er alt klart for installasjon av Kubernetes-klyngen.

Installasjon av Kubernetes

I dette trinnet har jeg bevisst utsatt alt arbeidet fra våre egne og våre bedrifts automatiseringer for installasjon og konfigurasjon av K8s-klyngen. I stedet vil vi bruke den offisielle dokumentasjonen med kubernetes.io (litt supplert med kommentarer og forkortelser).

La oss legge til 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

Videre anbefales det i dokumentasjonen å installere CRI (container runtime interface). Siden Docker allerede er installert, går vi videre og installerer de grunnleggende komponentene:

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

I trinnet for installasjon av de grunnleggende komponentene la jeg umiddelbart til kubernetes-cni, som er nødvendig for at klyngen skal fungere. Og her er det et viktig punkt: pakken kubernetes-cni av en eller annen grunn ikke oppretter standardkatalogen for CNI-innstillinger, så jeg måtte opprette den manuelt:

mkdir -p /etc/cni/net.d

For å få network-backend til å fungere, som omtales nedenfor, er det nødvendig å installere en CNI-plugin. Jeg valgte den kjente og forståelige plugin portmap (for en fullstendig liste, se dokumentasjonen):

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

Installasjonen av selve klyngen gjøres ganske enkelt. For å fremskynde denne prosessen og sjekke at Kubernetes-bildene er tilgjengelige, kan vi først utføre:

kubeadm config images pull

Nå gjennomfører vi selve installasjonen — vi initialiserer control plane i klyngen:

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

Vær oppmerksom på at subnett for tjenester og pod'er ikke skal overlappe hverandre eller eksisterende nettverk.

Til slutt vil vi se en melding som bekrefter at alt er i orden, og samtidig gi oss instruksjoner om hvordan vi kan koble til arbeidsnoder til kontrollplanet:

Kontrollplanet ditt for Kubernetes har blitt initialisert vellykket!
For å begynne å bruke klyngen din, må du kjøre følgende som en vanlig bruker:
 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 nå distribuere et pod-nettverk til klyngen.
Kjør "kubectl apply -f [podnetwork].yaml" med ett av alternativene som er oppført på:
 https://kubernetes.io/docs/concepts/cluster-administration/addons/
Du kan nå koble til et hvilket som helst antall kontrollsenter-noder ved å kjøre følgende kommando på hver som root:
 kubeadm join 192.168.88.30:6443 --token a485vl.xjgvzzr2g0xbtbs4 
   --discovery-token-ca-cert-hash sha256:9da6b05aaa5364a9ec59adcc67b3988b9c1b94c15e81300560220acb1779b050 
   --contrl-plane --certificate-key 72a3c0a14c627d6d7fdade1f4c8d7a41b0fac31b1faf0d8fdf9678d74d7d2403
Vær oppmerksom på at sertifikattasten gir tilgang til sensitive data i klyngen, hold den hemmelig!
Som en sikkerhetsforanstaltning vil opplastede sertifikater bli slettet om to timer; hvis nødvendig kan du bruke
"kubeadm init phase upload-certs --upload-certs" for å laste opp sertifikater på nytt etterpå.
Deretter kan du koble til et hvilket som helst antall arbeidsnoder ved å kjøre følgende på hver som root:
kubeadm join 192.168.88.30:6443 --token a485vl.xjgvzzr2g0xbtbs4 
   --discovery-token-ca-cert-hash sha256:9da6b05aaa5364a9ec59adcc67b3988b9c1b94c15e81300560220acb1779b050

La oss følge anbefalingene for å legge til konfigurasjonen for brukeren. Og samtidig er det lurt å legge til autofullføring for 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

På dette punktet kan vi allerede se den første noden i klyngen (selv om den ennå ikke er klar):

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

Nettverkskonfigurasjon

Som nevnt i meldingen etter installasjonen, må vi deretter sette opp nettverksløsning i klyngen. Dokumentasjonen tilbyr valg mellom Calico, Cilium, contiv-vpp, Kube-router og Weave Net… Her avviker jeg fra den offisielle instruksjonen og velger en mer kjent og forståelig løsning for meg: flannel i host-gw-modus (les mer om tilgjengelige bakender i projektets dokumentation).

Å installere det i klyngen er ganske enkelt. Først - last ned manifestene:

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

Deretter endrer vi innstillingen fra vxlan En funksjon har blitt host-gw:

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

… og subnettet for pod'er - fra standardverdien til den som ble angitt under initialiseringen av klyngen:

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

Etter dette oppretter vi ressursene:

kubectl create -f kube-flannel.yml

Klar! Etter en stund vil den første K8s-noden endre status til Klar:

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

Legge til en arbeidsnode

Nå kan du legge til en worker. For dette, på den — etter å ha installert Kubernetes i henhold til scenariet beskrevet ovenfor — må du bare kjøre den tidligere mottatte kommandoen:

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

Nå kan vi si at klyngen er klar:

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

Jeg hadde bare to Raspberry Pi tilgjengelig, så jeg ønsket ikke å gi bort en av dem kun til kontrollplanet. Derfor fjernet jeg den automatisk installerte tainten fra noden pi-control ved å kjøre:

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

… og fjernet linjene:

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

Fylling av klyngen med minimum nødvendige komponenter

Først trenger vi Helm. Selvfølgelig kan man gjøre alt uten det, men Helm tillater deg å konfigurere noen komponenter uten å redigere filer. Og det er faktisk bare en binær fil som "ikke krever noe".

Så, vi går til helm.sh i seksjonen docs/installation og utfører kommandoen derfra:

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

Etter dette legger vi til chart-repositoriet:

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

Nå vil vi installere infrastrukturkomponentene i henhold til planen:

• Ingress-kontroller;
• Prometheus;
• Grafana;
• cert-manager.

Ingress-kontroller

Den første komponenten — Ingress-kontroller — installeres ganske enkelt og er klar til bruk "rett ut av esken". For dette må du bare gå til seksjonen bare-metal på nettstedet og utføre installasjonskommandoen derfra:

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

Men på dette tidspunktet begynte "malinen" å slite og stange mot diskens IOPS. Det viser seg at sammen med Ingress-kontrolleren installeres det mange ressurser, mange forespørselene går til API, og som et resultat skrives det mye data til etcd. Generelt, enten er minnekortet i klasse 10 ikke veldig effektivt, eller SD-kortene er generelt utilstrekkelige for så høy belastning. Likevel, etter omtrent 5 minutter startet alt.

Et namespace ble opprettet, og i det dukket det opp en kontroller og alt det trenger:

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 neste to komponentene er ganske enkle å installere via Helm fra chart repo.

Vi finner Prometheus, vi oppretter namespace og installerer 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 bestiller Prometheus 2 disker: en for dataene til selve Prometheus og en for dataene til AlertManager. Siden det ikke er opprettet en storage class i klyngen, vil diskene ikke bli bestilt og pod’ene vil ikke starte. For bare metal-installasjoner av Kubernetes bruker vi vanligvis Ceph rbd, men i tilfelle av Raspberry Pi er det åpenbart overkill.

Derfor skal vi opprette en enkel local storage på hostpath. Manifestene for PV (persistent volume) for prometheus-server og prometheus-alertmanager er slått sammen i filen prometheus-pv.yaml i Git-repositorier med eksempler til artikkelen. Katalogen for PV må opprettes på forhånd på disken til den noden vi ønsker å binde Prometheus til: i eksemplet er det angitt nodeAffinity etter hostname pi-worker og det er opprettet kataloger på den /data/localstorage/prometheus-server og /data/localstorage/prometheus-alertmanager.

Vi laster ned (kloner) manifestet og legger det til Kubernetes:

kubectl create -f prometheus-pv.yaml

På dette stadiet møtte jeg for første gang problemet med ARM-arkitektur. Kube-state-metrics, som standard installeres med Prometheus-chartet, nektet å starte. Den ga feilmeldingen:

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"

Poenget er at kube-state-metrics bruker bildet fra prosjektet CoreOS, som ikke bygges for 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

Jeg måtte google litt og finne for eksempel dette bildet. For å bruke det, oppdaterer vi utgivelsen og angir hvilket bilde som skal brukes for 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 sjekker at alt har startet:

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

For grafer og dashboards installerer vi Grafana:

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

På slutten av utdataene vil vi se hvordan vi får passordet for tilgang:

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

For å bestille sertifikater installerer vi cert-manager. For installasjonen henviser vi til dokumentasjonen, som tilbyr passende kommandoer for 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

For selvsignerte sertifikater for hjemmebruk er dette mer enn tilstrekkelig. Hvis man derimot ønsker å få samme Let’s Encrypt, må man sette opp en cluster issuer. Detaljer om dette kan man finne i vår artikkel «SSL-sertifikater fra Let’s Encrypt med cert-manager i Kubernetes».

Selv valgte jeg alternativet fra eksempelet i dokumentasjonen, og bestemte meg for at staging-alternativet fra LE ville være tilstrekkelig. Vi endrer e-posten i eksempelet, lagrer det i fil og legger det til i klyngen (cert-manager-cluster-issuer.yaml):

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

Nå kan vi bestille sertifikatet, for eksempel for Grafana. For dette trenger vi et domene og ekstern tilgang til klyngen. Jeg har domenet, og trafikken er satt opp ved å videresende porter 80 og 443 på hjemme-ruteren i henhold til den opprettede ingress-controller-tjenesten:

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

Port 80 omdirigeres i dette tilfellet til 31303, og 443 til 30498. (Porter genereres tilfeldig, så de vil være forskjellige for deg.)

Her er et eksempel på sertifikatet (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 legger det til i klyngen:

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

Etter dette vil det opprettes en Ingress-ressurs, gjennom hvilken valideringen skjer med 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

Etter at valideringen er fullført, vil vi se at ressursen certificate er klar, og i den angitte hemmeligheten grafana-tls er sertifikat og nøkkel. Man kan umiddelbart sjekke hvem som utstedte sertifikatet:

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

La oss gå tilbake til Grafana. Vi må gjøre noen justeringer i Helm-utgivelsen vår, og endre innstillingene for TLS i samsvar med det opprettede sertifikatet.

For å gjøre dette laster vi ned diagrammet, redigerer og oppdaterer fra den lokale katalogen:

helm pull --untar stable/grafana

Vi redigerer i filen grafana/values.yaml TLS-parametrene:

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

Her kan vi også konfigurere den installerte Prometheus som datasource:

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

Nå oppdaterer vi Grafana-diagrammet fra den lokale katalogen:

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

Vi sjekker at Ingress grafana har fått port 443 og har tilgang 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

For å demonstrere Grafana i aksjon kan du laste ned og legge til dashboard for kube-state-metrics. Slik ser det ut:

Jeg anbefaler også å legge til dashboard for node exporter: det vil gi en detaljert oversikt over hva som skjer med «malinen» (CPU-belastning, minnebruk, nettverk, disk osv.).

Etter dette mener jeg at klusteret er klart til å ta imot og kjøre applikasjoner!

Merk om bygging

For å bygge applikasjoner for ARM-arkitektur er det minst to alternativer. For det første kan man bygge på en ARM-enhet. Men etter å ha sett på den nåværende bruken av to Raspberry Pi, innså jeg at de ikke hadde kapasitet til å håndtere byggingen heller. Så jeg bestilte en ny Raspberry Pi 4 (den er kraftigere og har så mye som 4 GB minne) — jeg planlegger å bygge på den.

Det andre alternativet er å bygge et multi-arkitektur Docker-bilde på en kraftigere maskin. For dette finnes det utvidelsen docker buildx. Dersom appen er skrevet i et kompilert språk, vil det være nødvendig med krysskompilering for ARM. Jeg vil ikke beskrive alle innstillingene for en slik tilnærming, da det ville blitt en egen artikkel. Ved å implementere en slik tilnærming kan man oppnå "universelle" bilder: Docker, som kjører på ARM-maskinen, vil automatisk laste ned det riktige bildet for arkitekturen.

Konklusjon

Eksperimentet overgikk alle mine forventninger: [minst] "vanilje" Kubernetes med nødvendig database fungerer ganske bra på ARM, og det oppsto bare et par små problemer under konfigurasjonen.

Selv Raspberry Pi 3B+ håndterer belastningen på CPU, men SD-kortene deres er et klart flaskehals. Kollegaene mine har gitt tips om at det i visse versjoner er mulig å boote fra USB, hvor man kan tilkoble SSD: da vil situasjonen trolig bli bedre.

Her er et eksempel på CPU-lasten under installasjonen av Grafana:

For eksperimentering og "for moro skyld" mener jeg at Kubernetes-klusteret på "små datamaskiner" gir en mye bedre opplevelse enn det samme Minikube, fordi alle klusterkomponenter installeres og fungerer "som en proff".

Det er en fremtidig idé om å legge hele CI/CD-syklusen til klusteret, fullt implementert på Raspberry Pi. Jeg vil også sette pris på hvis noen deler sin erfaring med å sette opp K8s på AWS Graviton.

P.S. Ja, "produksjon" kan være nærmere enn jeg trodde:

P.P.S.

Also read in our blog:

• «Eventyrene med hjemme-Kubernetes-klusteret».

Kilde: habr.com