ProHoster > Blogi > Haldamine > TĂ€ielik Kubernetes nullist Raspberry Pi-l

TĂ€ielik Kubernetes nullist Raspberry Pi-l

TĂ€ielik Kubernetes nullist Raspberry Pi-l

Paar nĂ€dalat tagasi teatas ĂŒks tuntud ettevĂ”te, et nad viivad oma sĂŒlearvutite tooteportfelli ARM-arkitektuurile. Seda uudist kuuldes meenutasin, et kui jĂ€llegi AWS-i EC2 hindu sirvisin, siis mĂ€rkasin Graviton'e, mille hind oli tĂ”eliselt ahvatlev. Probleem oli muidugi selles, et see on ARM. Siis polnud mul veel pĂ€he tulnud, et ARM on tegelikult ĂŒsna tĂ”sine...

Minu jaoks on see arhitektuur alati olnud mobiilsete ja teiste IoT-vidinate pĂ€rusmaa. „TĂ”elised“ serverid ARM-il - see tundus kuidagi ebatavaline, isegi kummaline... Kuid uus mĂ”te jĂ€i mu pĂ€he, seega otsustasin ĂŒhel nĂ€dalavahetusel uurida, mida tĂ€na ARM-il tĂ”eliselt kĂ€ivitada saab. Otsustasin alustada lĂ€hedasest ja tuntud - Kubernetes klastrist. Ja mitte lihtsalt mingist tinglikust „klastrist“, vaid kogu „pĂ€ris“ moodi, et see oleks vĂ”imalikult sarnane sellele, millega olen harjunud tootmises.

Minu plaanis peaks klaster olema Internetis ligipÀÀsetav, seal peaks tööle hakkama mĂ”ni veebirakendus ja seal peab olema vĂ€hemalt ka monitooring. Selle idee elluviimiseks peab olema paar (vĂ”i rohkem) Raspberry Pi-d, mis ei ole madalamad mudelist 3B+. Katseteks vĂ”iks platvormiks olla ka AWS, kuid mind huvitavad just „maliinid“ (mis nagunii seisavad tegemata). Nii et me seadistame nendele Kubernetes klastriga, mis sisaldab Ingressi, Prometheust ja Grafanat.

„Maliinide“ ettevalmistamine

OS-i ja SSH installimine

OperatsioonisĂŒsteemi valimisega ma vĂ€ga vaeva ei nĂ€inud: lihtsalt vĂ”tsin kĂ”ige vĂ€rskema Raspberry Pi OS Lite, milles on ametlikult veebisaidilt. Seal on ka saadaval installatsioonidokumentatsioon, mida tuleb jĂ€rgida kĂ”ikides tulevase klastrite sĂ”lmedes. Edasi peame tegelema jĂ€rgmiste toimingutega (samuti kĂ”ikides sĂ”lmedes).

Monitori ja klaviatuuri ĂŒhendamisel tuleb eelnevalt seadistada vĂ”rk ja SSH:

  1. Klastri töötamiseks peab meistris olema kindlasti staatiline IP-aadress, töötavates sÔlmedes - vastavalt soovile. Mina eelistasin kÔikjal staatilisi aadresse, et seadistamine oleks mugavam.
  2. Staatilise aadressi saab seadistada operatsioonisĂŒsteemis (failis /etc/dhcpcd.conf on sobiv nĂ€ide) vĂ”i fikseerides lease'i DHCP-serveris (minu juhul - kodus) ruuteris.
  3. ssh-serveri saab lihtsalt sisse lĂŒlitada raspi-configis (interfacing options → ssh).

PÀrast seda saab juba SSH-sse sisse logida (vaikimisi on kasutajanimi - pi, ja parool - raspberry vÔi see, mille peale vahetati) ja jÀtkata seadistamist.

Teised seadistused

  1. Seadame hostinime. Minu nÀites kasutatakse pi-control ja pi-worker.
  2. Kontrollime, et failisĂŒsteem oleks laienenud kogu kettale (df -h /). Vajadusel saab seda laiendada, kasutades raspi-config'i.
  3. Muudame vaikimisi kasutaja parooli raspi-config'is.
  4. KĂŒljendame swap-faili vĂ€lja (see on Kubernetes'e nĂ”ue; kui teid huvitavad detailid selle teema kohta, vt. issue #53533):
    dphys-swapfile swapoff
systemctl disable dphys-swapfile
  5. Uuendame paketid uusimale versioonile:
    apt-get update && apt-get dist-upgrade -y
  6. Paigaldame Dockeri ja lisapaketid:
    apt-get install -y docker docker.io apt-transport-https curl bridge-utils iptables-persistent

    Paigaldamisel iptables-persistent peame salvestama iptables'i seadistused ipv4 jaoks, ja faili /etc/iptables/rules.v4 — lisama reeglid ahelasse FORWARD, nii:

    # 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. JÀetakse vaid taaskÀivitamine.

NĂŒĂŒd on kĂ”ik valmis Kubernetes'e klastri paigaldamiseks.

Kubernetes'e paigaldamine

Selles etapis jĂ€tsin teadlikult kĂ”rvale kĂ”ik minu ja meie ettevĂ”tte automatiseerimise arendused Kubernetes'e klastri paigaldamiseks ja seadistamiseks. Selle asemel kasutame ametlikku dokumentatsiooni, kubernetes.io (veidi tĂ€iendatud kommentaaride ja lĂŒhenditega).

Lisame Kubernetes'e hoidla:

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

JÀtkame dokumentatsioonis soovitatud CRI (container runtime interface) paigaldamisega. Kuna Docker on juba paigaldatud, liigume edasi ja paigaldame pÔhikomponendid:

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

PÔhikomponentide paigaldamise etapil lisasin kohe kubernetes-cni, mis on vajalik klastri tööks. Oluline mÀrk: pakett kubernetes-cni mingitel pÔhjustel ei loo vaikimisi kausta CNI-liideste seadistuste jaoks, seega pidin selle kÀsitsi looma:

mkdir -p /etc/cni/net.d

Network-bÀkkendi tööks, millest rÀÀgime allpool, on vajalik CNI lisandi paigaldamine. Valisin tuttava ja arusaadava lisandi portmap (tÀielikku nimekirja vt. dokumentatsioon):

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'e seadistamine

Kontrollplaani sÔlm

Klastri paigaldamine toimub ĂŒsna lihtsalt. Selle protsessi kiirendamiseks ja kontrollimiseks, et Kubernetes'e pildid on kĂ€tte saadavad, vĂ”ib eelnevalt teostada:

kubeadm config images pull

NĂŒĂŒd teeme ise paigalduse — initsialiseerime klastri kontrollplaani:

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

Pange tĂ€hele, et teenuste ja pod'ide alavĂ”rgud ei tohi ĂŒksteisega ning olemasolevate vĂ”rkudega kattuda.

LĂ”pus nĂ€idatakse meile sĂ”numit, et kĂ”ik on hĂ€sti, ja antakse ka nĂ”u, kuidas ĂŒhendada töökohti juhtimislennukiga:

Teie Kubernetes'i juhtimislennuk on edukalt algatatud! 
Klastri kasutamiseks peate regulaarse kasutajana kÀivitama jÀrgmised kÀsud: 
 mkdir -p $HOME/.kube
 sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
 sudo chown $(id -u):$(id -g) $HOME/.kube/config
NĂŒĂŒd peaksite klastrisse juurutama pod-vĂ”rgu. 
KĂ€ivitage "kubectl apply -f [podnetwork].yaml" ĂŒhe valiku abil, mis on loetletud aadressil: 
 https://kubernetes.io/docs/concepts/cluster-administration/addons/ 
NĂŒĂŒd saate ĂŒhendada mis tahes arvu juhtimislennukeid, kĂ€ivitades igaĂŒhe peal jĂ€rgmise kĂ€su: 
 kubeadm join 192.168.88.30:6443 --token a485vl.xjgvzzr2g0xbtbs4 
 --discovery-token-ca-cert-hash sha256:9da6b05aaa5364a9ec59adcc67b3988b9c1b94c15e81300560220acb1779b050 
 --contrl-plane --certificate-key 72a3c0a14c627d6d7fdade1f4c8d7a41b0fac31b1faf0d8fdf9678d74d7d2403 
Palun pange tÀhele, et sertifikaadi vÔtme abil pÀÀsete juurde klastri tundlikule teabele, hoidke see saladuses! 
Kaitseks kustutatakse ĂŒleslaaditud sertifikaadid kahe tunni pĂ€rast; Vajadusel vĂ”ite kasutada 
"kubeadm init phase upload-certs --upload-certs" sertifikaatide uuesti laadimiseks hiljem. 
SeejĂ€rel vĂ”ite ĂŒhendada mis tahes arvu töökohti, kĂ€ivitades igaĂŒhe peal jĂ€rgmise kĂ€su: 
kubeadm join 192.168.88.30:6443 --token a485vl.xjgvzzr2g0xbtbs4 
 --discovery-token-ca-cert-hash sha256:9da6b05aaa5364a9ec59adcc67b3988b9c1b94c15e81300560220acb1779b050

JÀrgime soovitusi kasutaja konfigureerimise lisamiseks. Lisaks soovitan kohe lisada automaatse tÀiendamise kubectl jaoks:

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

Sellel etapil on juba vÔimalik nÀha esimest sÔlme klastris (kuigi see pole veel valmis):

root@pi-control:~# kubectl get no
NIMI        OLEK      ROLLID    VANUS  VERSION
pi-control  NotReady  master    29s   v1.18.6

VÔrgu konfigureerimine

SeejĂ€rel, nagu öeldi paigaldamise jĂ€rel, on vaja klastrisse vĂ”rgu installimist. Dokumentatsioon pakub valikut Calico, Cilium, contiv-vpp, Kube-router ja Weave Net... Siin kĂ”rvaldasin ametlikest juhenditest ja valisin enda jaoks tuttavama ja arusaadavama variandi: flannel host-gw reĆŸiimis (lisainfot saadaval olevate tagaplaanide kohta vt projekti dokumentatsioonis).

Klastrisse paigaldamine on ĂŒsna lihtne. Esiteks - laeme mĂ€rke:

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

SeejĂ€rel muudame seadistustes tĂŒĂŒbi vxlan . Tundub, et host-gw:

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


ja pod'ide alavĂ”rk — muuda vaikevÀÀrtust sellest, mis mÀÀrati klastrit algatades:

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

PĂ€rast seda loome ressursid:

kubectl create -f kube-flannel.yml

Valmis! MÔne aja pÀrast muutub esimene K8s sÔlm olekusse Valmis:

NIMI        OLEK    ROLLID    VANUS  VERSION
pi-control  Ready   master    2m    v1.18.6

Töökoha sÔlme lisamine

NĂŒĂŒd saab lisada worker'i. Selleks tuleb pĂ€rast Kubernetes'i paigaldamist eelmises osas kirjeldatud stsenaariumi jĂ€rgi lihtsalt kĂ€ivitada varasemalt saadud kĂ€sk:

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

Sellega vÔib arvata, et klooster on valmis:

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

Mul oli kĂ€epĂ€rast vaid kaks Raspberry Pi, seega ei tahtnud ma ĂŒhte neist anda seda kontrollplaanile. SeetĂ”ttu eemaldasin automaatselt seadistatud taint'i sĂ”lmele pi-control, kĂ€ivitades:

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


 ja kustutades read:

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

Klastri tÀitmine vajaliku miinimummiga

Esiteks vajame me Helm. Loomulikult on kÔike vÔimalik teha ka ilma selleta, kuid Helm vÔimaldab paigaldada mÔningaid komponente tÀpselt vastavalt oma soovile ilma failide muutmata. Ja tegelikult on see lihtsalt binaarfail, mis "leiba ei palu".

Nii et logime sisse helm.sh ja lÀheme jaotisse docs/installation ning kÀivitame sealt kÀsu:

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

PĂ€rast seda lisame chartide hoidla:

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

NĂŒĂŒd paigaldame infrastruktuuri komponendid vastavalt plaanile:

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

Ingress kontroller

Esimene komponent — Ingress kontroller — paigaldatakse suhteliselt lihtsalt ja on "kastist vĂ€lja" kasutamiseks valmis. Selleks piisab, kui minna jaotisse bare-metal veebisaidil ja kĂ€ivitada sealt paigaldamiskĂ€sk:

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

Kuid sel hetkel hakkas "maliina" pingutama ja jÀÀma diskio IOPS-i taha. Asi on selles, et koos Ingress-kontrolleriga paigaldatakse suur hulk ressursse, esitatakse palju pĂ€ringuid API-le ja seega salvestatakse palju andmeid etcd-sse. ÜhesĂ”naga, kas 10. klassi mĂ€lukaart ei ole eriti jĂ”udne vĂ”i SD-kaarte on selle koormuse jaoks lihtsalt vĂ€he. Siiski, umbes 5 minuti pĂ€rast kĂ”ik kĂ€ivitus.

Loodi namespace ja sinna ilmus kontroller ja kÔik, mis tal vajalik oli:

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

JĂ€rgmised kaks komponenti on ĂŒsna lihtne installida Helm'i kaudu chart repository'st.

Leidke Prometheus, looge namespace ja installige see sinna:

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

Vaikimisi tellib Prometheus 2 ketast: ĂŒhe Prometheuse andmete jaoks ja teise AlertManageri andmete jaoks. Kuna klastris pole loodud storage class'i, ei tellita kettaid ja pod'id ei kĂ€ivitu. Bare metal'i Kubernetes installatsioonide jaoks kasutame tavaliselt Ceph rbd, kuid Raspberry Pi puhul on see ilmselgelt liialdus.

SeetÔttu loome lihtsa kohaliku salvestuse hostpath'il. PV (persistent volume) mansiifid prometheus-server'i ja prometheus-alertmanager'i jaoks on koondatud failis prometheus-pv.yaml ja Git-repositorid artikli nÀidiste jaoks. PV jaoks vajalik kataloog tuleb enne valmis loo diskil, millele soovime Prometheust siduda: nÀites on mÀÀratud nodeAffinity hostname'i kaudu pi-worker ja sellel on loodud kataloogid /data/localstorage/prometheus-server ja /data/localstorage/prometheus-alertmanager.

Laadige (kloneerige) mansiif ja lisage see Kubernetesesse:

kubectl create -f prometheus-pv.yaml

Sellel etapil seisime esmakordselt silmitsi ARM-arhitektuuri probleemiga. Kube-state-metrics, mis installitakse vaikimisi Prometheuse chart'iga, keeldus tööle hakkamast. See andis vea:

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"

Asi on selles, et kube-state-metrics'i jaoks kasutatakse CoreOS projekti pilti, mida ARM-i jaoks ei lÔhuta:

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

Pidin veidi googeldama ja leidma nÀiteks selle pildi. Selleks, et seda kasutada, uuendame vÀljaande, nÀidates, millist pilti kasutada kube-state-metrics'i jaoks:

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

Kontrollime, et kÔik oleks kÀivitunud:

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

Graafikute ja dashboard'ide jaoks paigaldame Grafana:

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

LÔpus nÀidatakse meile, kuidas saada juurdepÀÀsuks parool:

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

Sertifikaatide tellimiseks paigaldame cert-manager. Selle paigaldamiseks pöördume dokumentatsioon, mis pakub vastavaid kÀske Helmi jaoks:

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

Koduses kasutuses isesigneeritud sertifikaatide jaoks on sellest tĂ€iesti piisav. Kui aga soovite saada sama Let’s Encrypt, tuleb seadistada ka cluster issuer. TĂ€iendavad ĂŒksikasjad leiate meie artiklist „SSL-sertifikaadid Let’s Encrypti kaudu cert-manageri abil Kuberneteses».

Otsustasin peatuda dokumentatsioonis oleva nÀite variandi peal , arvates, et staging-variant LE jaoks on piisav. Muudame nÀites e-posti, salvestame faili ja lisame klastrisse (cert-manager-cluster-issuer.yamlkubectl create -f cert-manager-cluster-issuer.yaml):

NĂŒĂŒd saab tellida sertifikaadi, nĂ€iteks Grafana jaoks. Selleks on vajalik domeen ja juurdepÀÀs Đșластрisse vĂ€ljastpoolt. Mul on domeen, ja olen seadistanud portide 80 ja 443 edastamise kodu ruuteris vastavalt loodud ingress-controller’i teenusele:

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. port edastatakse sel juhul 31303-sse ja 443 30498-sse.

(Pordid genereeritakse juhuslikult, seega on teil need teised.) Siin on nÀidis sertifikaadist (

cert-manager-grafana-certificate.yamlapiVersion: 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):

Lisame selle klastrisse:

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

PĂ€rast seda ilmub ressursse Ingress, mille kaudu toimub Let’s Encrypt'i valideerimine:

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Àrast valideerimisprotsessi nÀeme, et ressurss

sertifikaat on valmis ja ĂŒlaltoodud salajasus grafana-tls on sertifikaat ja vĂ”ti. Saame kohe kontrollida, kes sertifikaadi vĂ€lja andis: — sertifikaat ja vĂ”ti. Saate kohe kontrollida, kes on sertifikaadi vĂ€lja andnud:

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

Naasime tagasi Grafana juurde. Meil on vaja veidi muuta tema Helm-vÀljalaskmist, kohandades TLS-i seadeid vastavalt loodud sertifikaadile.

Selleks laadime alla chart'i, muuda ja uuendame kohalikust kataloogist:

helm pull --untar stable/grafana

Muudame failis grafana/values.yaml TLS-i seadeid:

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

Siin saab kohe mÀÀrata ka paigaldatud Prometheuse kui andmeallika:

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

NĂŒĂŒd uuendame kohalikust kataloogist Grafana chart'i:

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

Kontrollime, et Ingress grafana oleks lisatud 443 port ning HTTPS-ile juurdepÀÀs oleks olemas:

root@pi-control:~# kubectl -n monitoring get ing grafana
NIMI KLASS HOSTID AADRESS PORTID VANUS
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

Grafana tegevuse demonstreerimiseks saab alla laadida ja lisada kube-state-metrics dashboard'i. Nii see vÀlja nÀeb:

TĂ€ielik Kubernetes nullist Raspberry Pi-l

Soovitan ka lisada node exporter dashboard'i: see nĂ€itab ĂŒksikasjalikult, mis toimub «maliinidega» (CPU koormus, mĂ€lu, vĂ”rgu, ketta kasutus jne).

PÀrast seda arvan, et klaster on valmis rakenduste vastuvÔtmiseks ja kÀitamiseks!

MĂ€rkused kogumise kohta

Rakenduste koostamiseks ARM-arhitektuuril on vĂ€hemalt kaks vĂ”imalust. Esiteks, saab koostada ARM-seadmest. Kuid vaatamata kahe Raspberry Pi praegusele kasutusele, sain aru, et nad ei suuda isegi koostet taluda. SeetĂ”ttu tellisin endale uue Raspberry Pi 4 (see on tugevam ja selles on lausa 4 GB mĂ€lu) — plaanin sellel koostada.

Teine variant on koostada multiarhitektuuriline Docker-pilt vĂ”imsamal masinal. Selleks on olemas docker buildx laiendusKui rakendus on kompileeritav, on ARM-i jaoks vajalik ristkompileerimine. Kirjeldan kĂ”iki seadeid sellise tee kohta eraldi artiklis, sest see vĂ”taks liiga palju aega. Sellise lĂ€henemise rakendamisel on vĂ”imalik saavutada "ĂŒlikĂ”rgetasemel" kujutised: Docker, mis töötab ARM-masinal, laadib automaatselt alla arhitektuurile vastava kujutise.

KokkuvÔte

Tehtud katse ĂŒletas kĂ”ik minu ootused: [vĂ€hemalt] "vanilli" Kubernetes vajaliku andmebaasiga tunneb ARM-is end hĂ€sti ja selle seadistamisel tekkis vaid paar nĂŒanssi.

Raspberry Pi 3B+ esitab koormuse CPU-le, kuid nende SD-kaardid on selge pudelikael. Kollegid ĂŒtlesid, et mĂ”nedes versioonides on vĂ”imalik kĂ€ivituda USB-st, kuhu saab ĂŒhendada SSD: siis on olukord tĂ”enĂ€oliselt parem.

Siin on nÀide CPU koormusest Grafana installimisel:

TĂ€ielik Kubernetes nullist Raspberry Pi-l

Eksperimentide ja "katsetamiseks" arvan, et Kubernetes-klasstri kasutamine "maliinidel" toob rohkem reaalset kogemust kui sama Minikube, sest kÔik klasstri komponendid seadistatakse ja töötavad "professionaalselt".

Tulevikus on plaan lisada klasstrisse kogu CI/CD protsess, mis rakendatakse tÀielikult Raspberry Pi-l. Samuti oleksin rÔÔmus, kui keegi jagaks oma kogemusi K8s seadistamise kohta AWS Gravitonitel.

P.S. Jah, "produktion" vÔib olla lÀhemal, kui ma arvasin:

TĂ€ielik Kubernetes nullist Raspberry Pi-l

P.P.S.

Lugege ka meie blogist:

Allikas: habr.com

Osta usaldusvÀÀrne hostimine veebilehtede jaoks DDoS-i kaitsega, VPS VDS serverid đŸ”„ Osta usaldusvÀÀrne hostimine veebilehtede jaoks DDoS-i kaitsega, VPS VDS serverid | ProHoster