Pak të fundit, një kompani e njohur njoftoi se po kalon linjën e laptopëve të saj në arkitekturën ARM. Pas dëgjimit të kësaj lajmi, kujtova: duke kontrolluar për herë të pestë çmimet në EC2 në AWS, vura re Graviton që kishin një çmim shumë të pëlqyeshëm. Sidoqoftë, kishte një kapje, që ishte ARM. Në atë kohë, nuk mund të më shpinte mendja se ARM është diçka serioze...
PĂ«r mua, kjo arkitekturĂ« gjithmonĂ« ka qenĂ« diçka pĂ«r pajisjet mobile dhe IoT tĂ« tjera. "ServerĂ«t e 'vĂ«rtetĂ«' nĂ« ARM â Ă«shtĂ« ndryshe, nĂ« njĂ«farĂ« mĂ«nyre edhe çfarĂ« e çuditshme... MegjithatĂ«, njĂ« mendim i ri mĂ« mbeti nĂ« kokĂ«, prandaj njĂ« fundjavĂ« vendosa tĂ« kontrolloj se çfarĂ« mund tĂ« nisim sot nĂ« ARM. Dhe pĂ«r kĂ«tĂ«, vendosa tĂ« filloj me atĂ« qĂ« mĂ« Ă«shtĂ« afĂ«r dhe mĂ« i njohur â njĂ« klaster Kubernetes. Jo thjesht ndonjĂ« "klaster" tĂ« zakonshĂ«m, por krejt "pĂ«r tĂ« rritur", qĂ« tĂ« jetĂ« sa mĂ« i ngjashĂ«m me atĂ« qĂ« jam mĂ«suar ta shoh nĂ« prodhim.
Sipas planit tim, klasteri duhet të jetë i aksesueshëm nga interneti, aty duhet të vendoset një aplikacion web dhe gjithashtu të ketë të paktën monitorim. Për realizimin e kësaj ideje do të nevojiten disa (ose më shumë) Raspberry Pi jo më të dobët se modeli 3B+. Si platformë për eksperimente mund të ishte AWS, por më interesonin pikërisht "mali" (të cilat përndryshe ishin duke pritur pa punë). Pra, ne do të vendosim në to një klaster Kubernetes me Ingress, Prometheus dhe Grafana.
Pregatitja e "mali"
Instalimi i OS dhe SSH
Për zgjedhjen e OS për instalim nuk u shqetësova shumë: thjesht mora Raspberry Pi OS Lite më të freskët me . Aty është në dispozicion , të gjitha veprimet e të cilit duhet të bëhen në të gjitha nyjet e klasterit të ardhshëm. Më pas, nevojiten këto manovra të tjera (edhe në të gjitha nyjet).
Duke lidhur monitorin dhe tastierën, fillimisht duhet të konfigurojmë rrjetin dhe SSH:
- PĂ«r funksionimin e klasterit, master-i patjetĂ«r duhet tĂ« ketĂ« njĂ« adresĂ« IP statike, ndĂ«rsa nĂ« nyjet e punĂ«s â sipas dĂ«shirĂ«s. UnĂ« preferova adresa statike gjithandej pĂ«r arsye tĂ« ThjeshtĂ«sisĂ« nĂ« konfigurim.
- Adresa statike mund të konfigurohet në OS (në skedarin
/etc/dhcpcd.confka njĂ« shembull tĂ« pĂ«rshtatshĂ«m) ose duke fiksoi lease nĂ« serverin DHCP tĂ« router-it tĂ« pĂ«rdorur (nĂ« rastin tim â shtĂ«piak). - ssh-server thjesht aktivizohet nĂ« raspi-config (opsionet e ndĂ«rfaqĂ«sit â ssh).
Pas kësaj, mund të logohesh nëpërmjet SSH (nga default, identifikimi është pi, dhe fjalëkalimi është raspberry ose ai që u ndryshua) dhe të vazhdoj me konfigurimet.
Konfigurime të tjera
- Do të vendosim emrin e host-it. Në shembullin tim do të përdoren
pi-controldhepi-worker. - Le të verifikojmë që sistemi i skedarëve është zgjeruar në të gjithë diskun (
df -h /). Nëse është e nevojshme, mund ta zgjeroni atë duke përdorur raspi-config. - Do të ndryshojmë fjalëkalimin e përdoruesit të paracaktuar në raspi-config.
- Do të fikim skedarin swap (kjo është kërkesë e Kubernetes; nëse jeni të interesuar për detaje mbi këtë temë, shihni ):
dphys-swapfile swapoff systemctl disable dphys-swapfile - Do të përditësojmë paketat në versionet më të fundit:
apt-get update && apt-get dist-upgrade -y - Do të instalojmë Docker dhe paketa shtesë:
apt-get install -y docker docker.io apt-transport-https curl bridge-utils iptables-persistentGjatë instalimit
iptables-persistentdo tĂ« kĂ«rkohet tĂ« ruajmĂ« konfigurimet e iptables pĂ«r ipv4, dhe nĂ« skedarin/etc/iptables/rules.v4â shtoni rregullat nĂ« zinxhirinFORWARD, ndryshe kĂ«shtu:# 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 - Tani vetĂ«m duhet tĂ« rinisni.
Tani gjithçka është gati për instalimin e klasterit Kubernetes.
Instalimi i Kubernetes
Në këtë fazë, qëllimisht e kam vonuar të gjithë përvojën time dhe të punonjësve tanë për automatizimin e instalimit dhe konfigurimit të klasterit K8s. Në vend të kësaj, do të përdorim dokumentacionin zyrtar nga (paksa të plotësuar me komente dhe përmbledhje).
Do të shtojmë depot e Kubernetes:
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 updateMë pas dokumentacioni sugjeron të instaloni CRI (container runtime interface). Duke qenë se Docker është instaluar tashmë, kalojmë përpara dhe instalojmë komponentët bazë:
sudo apt-get install -y kubelet kubeadm kubectl kubernetes-cni Në hapin e instalimit të komponentëve bazë kam shtuar kubernetes-cni, i cili është i nevojshëm për funksionimin e klasterit. Në këtë rast, ka një çështje të rëndësishme: paketa kubernetes-cni për ndonjë arsye nuk krijon direktorinë me default për konfigurimet e CNI interface-ve, kështu që më duhej ta krijoja atë manualisht:
mkdir -p /etc/cni/net.dPër të punuar me network-backend-in, për të cilin do të flasim më poshtë, është e nevojshme të instaloni plugin-in për CNI. Kam zgjedhur plugin-in e njohur dhe të qartë për mua portmap (lista e plotë e tyre mund të shihet në ):
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/ ./portmapKonfigurimi i Kubernetes
Nod-i me control plane
Instalimi i klasterit është mjaft i thjeshtë. Dhe për të përshpejtuar këtë proces dhe për të kontrolluar që imazhet e Kubernetes janë të disponueshme, mund të ekzekutojmë paraprakisht:
kubeadm config images pullTani kryejmĂ« vetĂ« instalimin â inicializojmĂ« control plane tĂ« klasterit:
kubeadm init --pod-network-cidr=10.1.0.0/16 --service-cidr=10.2.0.0/16 --upload-certsKujdesi se qĂ« subnetet pĂ«r shĂ«rbimet dhe podâĂ«t nuk duhet tĂ« ndĂ«rhyjnĂ« midis tyre dhe me rrjetet ekzistuese.
Në fund do të na shfaqet një mesazh që gjithçka është mirë, dhe gjithashtu do të na udhëzojnë se si të lidhim nyjat e punës me planin e kontrollit:
Kontrolli juaj i Kubernetes ka filluar me sukses! Për të filluar përdorimin e klasterit tuaj, duhet të ekzekutoni atë që vijon si një përdorues normal:
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
Tani duhet të vendosni një rrjet pod në klaster.
Ekzekutoni "kubectl apply -f [podnetwork].yaml" me një nga opsionet e listuara në:
https://kubernetes.io/docs/concepts/cluster-administration/addons/
Tani mund të bashkoni çdo numër të nyjeve të planit të kontrollit që ekzekutojnë komandën e mëposhtme në secilin si root:
kubeadm join 192.168.88.30:6443 --token a485vl.xjgvzzr2g0xbtbs4
--discovery-token-ca-cert-hash sha256:9da6b05aaa5364a9ec59adcc67b3988b9c1b94c15e81300560220acb1779b050
--contrl-plane --certificate-key 72a3c0a14c627d6d7fdade1f4c8d7a41b0fac31b1faf0d8fdf9678d74d7d2403
Kujdesi se që çelësi i certifikatës jep akses në të dhëna delikate të klasterit, mbajeni sekret!
Si një masë siguruese, certifikat e ngarkuara do të fshihen pas dy orëve; Nëse është e nevojshme, mund të përdorni
"kubeadm init phase upload-certs --upload-certs" për të ngarkuar përsëri certifikatat më vonë.
Pastaj mund të bashkoni çdo numër të nyjeve të punës duke ekzekutuar të mëposhtmen në secilin si root:
kubeadm join 192.168.88.30:6443 --token a485vl.xjgvzzr2g0xbtbs4
--discovery-token-ca-cert-hash sha256:9da6b05aaa5364a9ec59adcc67b3988b9c1b94c15e81300560220acb1779b050Le të realizojmë rekomandimet për shtimin e konfigurimit për përdoruesin. Dhe gjithashtu rekomandoj që menjëherë të shtojmë auto-dhënien për kubectl:
kubectl completion bash > ~$HOME/.kube/completion.bash.inc
printf "
# Kubectl dhënia e paqartë në terminal
source '$HOME/.kube/completion.bash.inc'
" >> $HOME/.bash_profile
source $HOME/.bash_profileNë këtë fazë tani mund të shihni nyjën e parë në klaster (pavarësisht se ajo ende nuk është gati):
root@pi-control:~# kubectl get no
NAME STATUS ROLES AGE VERSION
pi-control NotReady master 29s v1.18.6Konfigurimi i rrjetit
Më pas, siç u tha në mesazhin pas instalimit, do të kërkohet të vendosni një rrjet në klaster. Dokumentacioni ofron një zgjedhje nga Calico, Cilium, contiv-vpp, Kube-router dhe Weave Net⊠Këtu kam devijuar nga instruksionet zyrtare dhe zgjodha një variant më të njohur dhe të kuptueshëm për mua: në modin host-gw (më shumë mbi backendet e disponueshme shih në ).
Ta vendosësh atë në klaster është mjaft e thjeshtë. Në fillim - shkarko manifestet:
wget https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml Më pas ndërroni në cilësime llojin nga vxlan në host-gw:
sed -i 's/vxlan/host-gw/' kube-flannel.yml⊠dhe subneti i podâĂ«ve - nga vlera e paracaktuar nĂ« atĂ« qĂ« Ă«shtĂ« e specifikuar pas fillimit tĂ« klasterit:
sed -i 's#10.244.0.0/16#10.1.0.0/16#' kube-flannel.ymlPasi të keni përfunduar, krijoni burimet:
kubectl create -f kube-flannel.yml E bërë! Pas pak kohësh, nyja e parë K8s do të kalojë në statusin Gati:
NAME STATUS ROLES AGE VERSION
pi-control Ready master 2m v1.18.6Shtimi i nyjës së punës
Tani tani mund të shtoni një punëtor. Për këtë, pas instalimit të Kubernetes sipas skenarit të përshkruar më lart, thjesht duhet të ekzekutoni komandën që keni marrë më parë:
kubeadm join 192.168.88.30:6443 --token a485vl.xjgvzzr2g0xbtbs4
--discovery-token-ca-cert-hash sha256:9da6b05aaa5364a9ec59adcc67b3988b9c1b94c15e81300560220acb1779b050Kështu mund të konsiderohet se klasteri është i gatshëm:
root@pi-control:~# kubectl get no
EMRI STATUSI ROLLET MOSHA VERSIONI
pi-control Gatshëm master 28m v1.18.6
pi-worker Gatshëm 2m8s v1.18.6Isha me dy Raspberry Pi, prandaj nuk doja ta jepja një nga ato të për planin e kontrollit. Prandaj, hoqa taint-in e instaluar automatikisht nga nyja pi-control duke ekzekutuar:
root@pi-control:~# kubectl edit node pi-control⊠dhe fshiva rreshtat:
- efekt: NoSchedule
çelësi: node-role.kubernetes.io/masterPlotësimi i klasterit me minimumin e nevojshëm
Fillimisht, do të na nevojitet Helm. Sigurisht, mund ta bëni gjithçka edhe pa të, por Helm lejon që disa komponentë të konfigurohen sipas dëshirës pa pasur nevojë të editoni skedarët. Dhe në fakt, është thjesht një skedar binar që "nuk kërkon bukë".
Pra, hyjmë në në seksionin docs/installation dhe ekzekutojmë komandën nga atje:
curl -s https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 | bashPas kësaj, shtojmë repository-n e chart-eve:
helm repo add stable https://kubernetes-charts.storage.googleapis.com/Tani do të installojmë komponentët infrastrukturore sipas planit:
- Kontrolluesi Ingress;
- Prometheus;
- Grafana;
- cert-manager.
Kontrolluesi Ingress
Komponenti i parĂ« â Kontrolluesi Ingress â instalohet mjaft lehtĂ« dhe Ă«shtĂ« gati pĂ«r t'u pĂ«rdorur "nga kutia". Mjafton tĂ« hyni nĂ« dhe tĂ« ekzekutoni komandĂ«n e instalimit nga atje:
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v0.34.1/deploy/static/provider/baremetal/deploy.yamlMegjithatë, në këtë moment "mali" filloi të lodhet dhe të hasë në IOPS të diskut. Kjo është për shkak se me instalimin e kontrolluesit Ingress instalohet një sasi e madhe burimesh, bëhen shumë kërkesa në API dhe, për rrjedhojë, shkruhen shumë të dhëna në etcd. Në përgjithësi, ose karta e memories e klasës 10 nuk është shumë e efektshme, ose SD-kartat thjesht nuk janë të mjaftueshme për një ngarkesë të tillë. Megjithatë, pas rreth 5 minutash gjithçka filloi.
U krijua një namespace dhe atje u shfaq kontrolluesi dhe të gjitha gjërat e nevojshme për të:
root@pi-control:~# kubectl -n ingress-nginx get pod
EMRI GATSHĂM STATUSI RINOVIMET MOSHA
-ingress-nginx-admission-create-2hwdx 0/1 PĂ«rfunduar 0 31s
-ingress-nginx-admission-patch-cp55c 0/1 PĂ«rfunduar 0 31s
-ingress-nginx-controller-7fd7d8df56-68qp5 1/1 Duke funksionuar 0 48sPrometheus
Dy komponentët e mëposhtëm janë mjaft të lehtë për t'u instaluar përmes Helm nga depoja e chart.
Gjejmë Prometheus, krijojmë një namespace dhe e instalojmë atë në të:
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"}Me default, Prometheus kërkon 2 disqe: për të dhënat e Prometheus dhe për të dhënat e AlertManager. Duke qenë se në klaster nuk është krijuar një klase storage, disqet nuk do të kërkohen dhe pod'ët nuk do të fillojnë. Për instalime bare metal të Kubernetes, zakonisht përdorim Ceph rbd, por në rastin e Raspberry Pi, kjo është e tepruar.
Prandaj, ne do të krijojmë një storage lokal të thjeshtë në hostpath. Manifestet e PV (volume të qëndrueshëm) për prometheus-server dhe prometheus-alertmanager janë të bashkuara në skedarin prometheus-pv.yaml në . Drejtoria për PV duhet të krijohet paraprakisht në diskun e nodit, të cilit duam t'i lidhim Prometheus: në shembullin e përmendur nodeAffinity për hostname pi-worker dhe në të janë krijuar drejtoritë /data/localstorage/prometheus-server dhe /data/localstorage/prometheus-alertmanager.
Shkarkojmë (klonojmë) manifestin dhe e shtojmë në Kubernetes:
kubectl create -f prometheus-pv.yamlNë këtë fazë, u përballa për herë të parë me problemin e arkitekturës ARM. Kube-state-metrics, i cili instalohet si default në chart-in e Prometheus, refuzoi të fillonte. Ai jepte një gabim:
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"Problemi është se për kube-state-metrics përdoret imazhi i projektit CoreOS, i cili nuk kompilohet pë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.7Më duhej të kërkoja pak në Google dhe të gjeta, për shembull, . Për ta përdorur atë, do të azhurnojmë lëshimin, duke treguar se cili imazh do të përdoret pë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.6Kontrollojmë se gjithçka është nisur:
root@pi-control:~# kubectl -n monitoring get po
EMRI GATI STATUS RIKTHIMET MOSHA
prometheus-alertmanager-df65d99d4-6d27g 2/2 Duke u ekzekutuar 0 5m56s
prometheus-kube-state-metrics-5dc5fd89c6-ztmqr 1/1 Duke u ekzekutuar 0 5m56s
prometheus-node-exporter-49zll 1/1 Duke u ekzekutuar 0 5m51s
prometheus-node-exporter-vwl44 1/1 Duke u ekzekutuar 0 4m20s
prometheus-pushgateway-c547cfc87-k28qx 1/1 Duke u ekzekutuar 0 5m56s
prometheus-server-85666fd794-z9qnc 2/2 Duke u ekzekutuar 0 4m52sGrafana dhe cert-manager
PĂ«r grafikat dhe dashboardâĂ«t vendosim NĂ«se tashmĂ« e dini se çfarĂ« Ă«shtĂ« analiza e grupeve dhe se si ta bĂ«ni nĂ« SQL, kaloni menjĂ«herĂ« nĂ« seksionin e fundit.:
helm install grafana --namespace monitoring stable/grafana --set ingress.enabled=true --set ingress.hosts={"grafana.home.pi"}Në fund të daljes do të tregohet si të merrni passwordin për qasje:
kubectl get secret --namespace monitoring grafana -o jsonpath="{.data.admin-password}" | base64 --decode ; echoPër të porositur certifikatat do të instalojmë cert-manager. Për instalimin e tij do të referohemi në , e cila ofron komandat pë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=truePĂ«r certifikatat e vetĂ«-nĂ«nshkruara pĂ«r pĂ«rdorim shtĂ«piak, kjo Ă«shtĂ« mjaft e mjaftueshme. NĂ«se nevojitet tĂ« merrni tĂ« njĂ«jtin Letâs Encrypt, atĂ«herĂ« duhet tĂ« konfiguroni gjithashtu cluster issuer. Detaje rreth kĂ«saj mund tĂ« gjeni nĂ« artikullin tonĂ« "».
Unë ndalesha në variantin nga , duke vendosur se varianti staging i LE do të ishte mjaft. Ndryshojmë në shembull email-in, e ruajmë në skedarin dhe e shtojmë në klaster ():
kubectl create -f cert-manager-cluster-issuer.yamlTani është e mundur të porositni një certifikatë, për shembull, për Grafana. Për këtë kërkohet një domain dhe akses në klaster nga jashtë. Unë kam një domain dhe trafikun e kam konfiguruar me kalimin e porteve 80 dhe 443 në router-in tim shtëpiak në përputhje me shërbimin e krijuar të ingress-controller:
kubectl -n ingress-nginx get svc
EMRI LLOJI CLUSTER-IP EXTERNAL-IP PORT(S) MOSHA
ingress-nginx-controller NodePort 10.2.206.61 80:31303/TCP,443:30498/TCP 23dPorti 80 nĂ« kĂ«tĂ« rast transmetohet nĂ« 31303, ndĂ«rsa 443 â nĂ« 30498. (Poret gjenerohen rastĂ«sisht, kĂ«shtu qĂ« ju do t'i keni ndryshe.)
Ja një shembull i certifikatës ():
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-stagingE shtojmë atë në klaster:
kubectl create -f cert-manager-grafana-certificate.yamlPas kĂ«saj do tĂ« shfaqet njĂ« burim Ingress, pĂ«rmes tĂ« cilit do tĂ« realizohet validimi nga Letâs Encrypt:
root@pi-control:~# kubectl -n monitoring get ing
EMRI KLASA HOSTS ADRESA PORTET MOSHA
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 Pas kalimit tĂ« validimit, do tĂ« shohim se burimi certifikata Ă«shtĂ« gati, dhe nĂ« sekretin e pĂ«rmendur mĂ« sipĂ«r grafana-tls â certifikata dhe çelĂ«si. Mund tĂ« kontrolloni menjĂ«herĂ« se kush e lĂ«shoi certifikatĂ«n:
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 X1Le të kthehemi te Grafana. Na nevojitet të ndryshojmë pak Helm-release-n e saj, duke modifikuar cilësimet për TLS në përputhje me certifikatin e krijuar.
Për këtë, shkarkojmë chart-in, e redaktojmë dhe e përditësojmë nga direktoria lokale:
helm pull --untar stable/grafana Editojmë në skedarin grafana/values.yaml cilet e TLS:
tls:
- secretName: grafana-tls
hosts:
- grafana.home.pi Në këtë pikë, mund të konfiguroni gjithashtu Prometheus-in e instaluar si datasource:
datasources:
datasources.yaml:
apiVersion: 1
datasources:
- name: Prometheus
type: prometheus
url: http://prometheus-server:80
access: proxy
isDefault: trueTani nga direktoria lokale përditësojmë chart-in e Grafana-s:
helm upgrade grafana --namespace monitoring ./grafana --set ingress.enabled=true --set ingress.hosts={"grafana.home.pi"} Verifikojmë se në Ingress grafana ka shtuar portin 443 dhe ka qasje përmes 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; includeSubDomainsPër të demonstruar Grafana-n në veprim, mund të shkarkoni dhe shtoni . Këtu si duket:
Gjithashtu rekomandoj të shtoni një dashboard për node exporter: ai do të tregojë në detaje se çfarë po ndodh me "malinat" (ngarkesa e CPU-së, përdorimi i memories, rrjetit, diskut, etj.).
Pas kësaj, e konsideroj se klastri është gati për të pranuar dhe për të ekzekutuar aplikacione!
Shënim mbi ndërtimin
Për ndërtimin e aplikacioneve për arkitekturën ARM, ka të paktën dy opsione. Së pari, mund të ndërtojmë në një pajisje ARM. Megjithatë, duke e parë aktualizimin e dy Raspberry Pi-ve, kuptova se as ndërtimin nuk do ta përballonin. Prandaj, porosa një Raspberry Pi 4 të re (ajo është më e fuqishme dhe ka 4 GB memorie) - planifikoj të ndërtosh aty.
Opsioni i dytë është ndërtimi i një imazhi Docker me shumë arkitekturë në një makinë më të fuqishme. Për këtë ka . Nëse aplikacioni është në një gjuhë të kompilueshme, do të nevojitet një ndërkompilim për ARM. Nuk do të përshkruaj të gjitha parametrat për një rrugë të tillë, pasi kjo do të kërkonte një artikull të veçantë. Duke realizuar një qasje të tillë, është e mundur të arrijmë imazhe "universale": Docker, i nisur në një makinë ARM, do të ngarkojë automatikisht imazhin përkatës për arkitekturën.
PĂ«rfundim
Eksperimenti i kryer tejkaloi të gjitha pritshmëritë e mia: [të paktën] Kubernetes-i "vanilje" me bazën e nevojshme performon mirë në ARM, dhe gjatë konfigurimit të tij u shfaqën vetëm disa nuanca.
Raspberry Pi 3B+ e mban ngarkesën në CPU, megjithatë kartat e tyre SD janë një ngushticë e qartë. Kolegët sugjeruan se në disa versione ekziston mundësia për të nisur nga USB, ku mund të lidhet një SSD: atëherë situata ndoshta do të përmirësohej.
Ja një shembull i ngarkesës së CPU gjatë instalimit të Grafana:
Për eksperimente dhe "për të provuar", sipas mendimit tim, një klastri Kubernetes në "mali" përcjell ndjesi më të mira nga përdorimi sesa Minikube i njëjtë, sepse të gjitha komponentët e klastri instalohet dhe punojnë "në mënyrë të plotë".
Në të ardhmen, ka një ide për të shtuar në klastri të gjithë ciklin CI/CD, i realizuar plotësisht në Raspberry Pi. Po ashtu, do të isha i gatshëm, nëse dikush do të ndante përvojën e tij për konfigurimin e K8s në AWS Gravitons.
P.S. Po, "prodhimi" mund të jetë më afër se ç'mendoja:
P.P.S.
Lexoni gjithashtu në blogun tonë:
- «».
Burimi: habr.com
