SĂ« fundmi, njĂ« kompani e njohur shpalli se po kalon serinĂ« e laptopĂ«ve tĂ« saj nĂ« arkitekturĂ«n ARM. Kur dĂ«gjova kĂ«tĂ« lajm, mĂ« erdhi nĂ« mendje: duke shikuar pĂ«r herĂ« tĂ« katĂ«rt çmimet e EC2 nĂ« AWS, vura re GravitonâĂ«t me njĂ« çmim shumĂ« tĂ«rheqĂ«s. Sigurisht, kishte njĂ« kurth, pasi kjo ishte ARM. NĂ« atĂ« kohĂ«, nuk mendoja se ARM ishte njĂ« çështje serioze...
PĂ«r mua, kjo arkitekturĂ« gjithmonĂ« ka qenĂ« nĂ« fushĂ«n e mobileve dhe gjĂ«rave tjera IoT. âServerĂ«t e vĂ«rtetĂ«â nĂ« ARM - ishte diçka e pazakontĂ«, madje e çuditshme... MegjithatĂ«, njĂ« mendim i ri mĂ« ka mbetur nĂ« kokĂ«, prandaj nĂ« njĂ« nga fundjavĂ«t vendosa tĂ« kontrolloj çfarĂ« mund tĂ« filloj sot nĂ« ARM. Dhe pĂ«r kĂ«tĂ«, vendosa tĂ« filloj me diçka tĂ« njohur - njĂ« grup Kubernetes. Dhe jo thjesht njĂ« âgrupâ tĂ« zakonshĂ«m, por gjithçka âsiç duhetâ, qĂ« tĂ« ishte sa mĂ« e ngjashme me atĂ« qĂ« kam mĂ«suar ta shoh nĂ« prodhim.
Sipas planit tim, klasteri duhet të jetë i aksesueshëm nga interneti, duhet të ketë një aplikacion web dhe gjithashtu duhet të ketë të paktën monitorim. Për realizimin e kësaj ideje do të nevojiten disa (ose më shumë) Raspberry Pi jo më poshtë se modeli 3B+. Një platformë eksperimentimi mund të ishte AWS, por mua më interesonin pikërisht «mali» (të cilat gjithsesi ishin të papërdorura). Kështu, ne do të vendosim një klaster Kubernetes me Ingress, Prometheus dhe Grafana në to.
Përgatitja e «mali»
Instalimi i OS dhe SSH
Për zgjedhjen e OS për instalim nuk u mundova shumë: thjesht mora Raspberry Pi OS Lite më të fundit me . Atje gjithashtu është e disponueshme , të gjitha veprimet e të cilave duhet të kryhen në të gjitha nyjat e klasterit të ardhshëm. Më pas, do të nevojitet të kryhen manipulasione të mëtejshme (po ashtu në të gjitha nyjat).
Duke lidhur monitorin dhe tastierën, është e nevojshme të konfiguroni paraprakisht rrjetin dhe SSH:
- Për funksionimin e klasterit në master duhet patjetër të ketë një adresë IP statike, ndërsa në nyjat punuese - sipas dëshirës. Unë preferova adresa statike kudo nga pikëpamja e lehtësisë së konfigurimit.
- Adresa statike mund të konfigurohet në OS (në skedarin
/etc/dhcpcd.confka njĂ« shembull tĂ« pĂ«rshtatshĂ«m) ose pĂ«rmes fiksimit tĂ« lease nĂ« serverin DHCP tĂ« routerit tĂ« pĂ«rdorur (nĂ« rastin tim â routeri i shtĂ«pisĂ«). - ssh-server thjesht aktivizohet nĂ« raspi-config (opsionet e interfacing â ssh).
Pas kësaj, mund të kyçeni përmes SSH (emri i përdoruesit për default është pi, dhe password-i është raspberry ose ai që keni ndryshuar) dhe të vazhdoni me konfigurimin.
Konfigurime të tjera
- Do të vendosim emrin e host-it. Në shembullin tim do të përdoren
pi-controldhepi-worker. - Të kontrollojmë nëse sistemi i skedave është zgjeruar në të gjithë diskun (
df -h /). Në rast nevoje, mund ta zgjeroni me ndihmën e raspi-config. - Do të ndryshojmë fjalëkalimin e përdoruesit për default në raspi-config.
- Do të çaktivizojmë 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 të tjera:
apt-get install -y docker docker.io apt-transport-https curl bridge-utils iptables-persistentGjatë instalimit
iptables-persistentdo tĂ« kĂ«rkojĂ« tĂ« ruani konfigurimet e iptables pĂ«r ipv4, dhe nĂ« skedarin/etc/iptables/rules.v4â shtoni rregullat nĂ« zinxhirinFORWARD, 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 mbetet vetĂ«m tĂ« riaktivizoni.
Tani gjithçka është gati për instalimin e klasterit Kubernetes.
Instalimi i Kubernetes
Në këtë fazë, kam vendosur që të lë mënjanë të gjitha zhvillimet e mia dhe të kompanisë për automatizimin e instalimit dhe konfigurimit të klasterit K8s. Në vend të kësaj, do të përdorim dokumentacionin zyrtar nga (pak e plotësuar me komente dhe shkurtimet).
Të shtojmë depozitat 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 në dokumentacion propozoheshe të instalonim CRI (interface e kohës së funksionimit të konteinerit). Që Docker është tashmë i instaluar, kalojmë përpara dhe instalojmë komponentët kryesorë:
sudo apt-get install -y kubelet kubeadm kubectl kubernetes-cni Në hapin e instalimit të komponentëve kryesorë, unë menjëherë e shtova kubernetes-cni, i cili është i nevojshëm për funksionimin e klasterit. Dhe këtu ka një pikë të rëndësishme: pako kubernetes-cni për arsye të caktuara nuk krijon automatikisht një direktor për configurimet e CNI-së, prandaj më duhej ta krijoja atë manualisht:
mkdir -p /etc/cni/net.dPër funksionimin e backend-it të rrjetit, për të cilin do të flasim më poshtë, është e nevojshme të instaloni një plugin për CNI. Kam zgjedhur plugin-in portmap, që më është i njohur dhe i kuptueshëm (shihni listën e plotë 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 me kontroll
Instalimi i vetë klastra bëhet mjaft lehtë. Për të përshpejtuar këtë proces dhe për të verifikuar që imazhet Kubernetes janë të aksesueshme, mund të ekzekutoni paraprakisht:
kubeadm config images pullTani kryejmĂ« instalimin e vetĂ« â nĂ« fillojmĂ« kontrollin e planit tĂ« klastra:
kubeadm init --pod-network-cidr=10.1.0.0/16 --service-cidr=10.2.0.0/16 --upload-certsKujdes, subnetet pĂ«r shĂ«rbimet dhe podâĂ«t nuk duhet tĂ« pĂ«rçohen me njĂ«ra-tjetrĂ«n dhe me rrjetet ekzistuese.
Në fund do na shfaqet një mesazh që gjithçka është në rregull dhe na sugjeron se si të bashkëngjitni nodet e punës në planin e kontrollit:
Plani i kontrollit të Kubernetes është inicializuar me sukses!
Për të filluar përdorimin e klasterit tuaj, duhet të ekzekutoni sa vijon si një përdorues i zakonshëm:
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 podesh 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ë bashkoheni me çdo numër të pikave të kontrollit duke ekzekutuar 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
Ju lutemi vini re se çelësi i certifikatës jep qasje në të dhëna të ndjeshme të klasterit, mbajeni të fshehtë!
Si një masë mbrojtëse, certifikatat e ngarkuara do të fshihen pas dy orësh; Nëse është e nevojshme, mund të përdorni
"kubeadm init phase upload-certs --upload-certs" për të riparuar certifikatat më pas.
Pastaj mund të bashkoheni me çdo numër të nodave punues 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:9da6b05aaa5364a9ec59adcc67b3988b9c1b94c15e81300560220acb1779b050Të zbatojmë rekomandimet për shtimin e konfigurimit për përdoruesin. Po ashtu rekomandoj të shtoni menjëherë plotësimin automatik për kubectl:
kubectl completion bash > ~/.kube/completion.bash.inc
printf "
# Plotësimi i shell-it të Kubectl
source '$HOME/.kube/completion.bash.inc'
" >> $HOME/.bash_profile
source $HOME/.bash_profileNë këtë fazë tashmë mund të shihni nyjën e parë në klaster (në fakt, ajo nuk është ende 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ë nevojitet të vendosni rrjetin në klaster. Dokumentacioni ofron një zgjedhje nga Calico, Cilium, contiv-vpp, Kube-router dhe Weave Net⊠Këtu kam devijuar nga udhëzimet zyrtare dhe kam zgjedhur një variant më të njohur dhe më të qartë për mua: në modalitetin host-gw (më shumë për backend-et e disponueshëm shih në ).
Instalimi i tij në klaster është mjaft i thjeshtë. Së pari - shkarkoni manifestet:
wget https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml Pastaj ndryshojmë në konfigurim llojin nga vxlan në host-gw:
sed -i 's/vxlan/host-gw/' kube-flannel.yml⊠dhe subnetin e pod-ëve - nga vlera e paracaktuar në atë që është specifikuar gjatë inicializimit të klasterit:
sed -i 's#10.244.0.0/16#10.1.0.0/16#' kube-flannel.ymlPas kësaj krijojmë burimet:
kubectl create -f kube-flannel.yml Këtu! Pas disa kohësh, nodi i parë K8s do të kalojë në statusin Gati:
NAME STATUS ROLES AGE VERSION
pi-control Ready master 2m v1.18.6Shtimi i nodit të punës
Tani mund të shtoni një worker. Për këtë, në të - pas instalimit të Kubernetes sipas skenarit të përshkruar më sipër - thjesht duhet të shkoni te komandës që keni marrë më parë:
kubeadm join 192.168.88.30:6443 --token a485vl.xjgvzzr2g0xbtbs4
--discovery-token-ca-cert-hash sha256:9da6b05aaa5364a9ec59adcc67b3988b9c1b94c15e81300560220acb1779b050Me këtë mund të konsiderohet se klasteri është gati:
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.6Kisha vetëm dy Raspberry Pi pranë meje, kështu që nuk doja të dija një prej tyre vetëm për planin e kontrollit. Prandaj, hoqa taint-in e instaluar automatikisht nga nodi pi-control duke ekzekutuar:
root@pi-control:~# kubectl edit node pi-control⊠dhe hoqa rreshtat:
- effect: NoSchedule
key: node-role.kubernetes.io/masterPlotësimi i klasterit me minimumin e nevojshëm
Së pari, do të na nevojitet Helm. Sigurisht, është e mundur të bëhet gjithçka pa të, por Helm lejon të konfigurohen disa komponente sipas dëshirës pa modifikuar skedarët. Dhe në fakt, ky është thjesht një skedar binar që "nuk kërkon bukë".
Pra, shkoni në në seksionin docs/installation dhe ekzekutoni komandën nga aty:
curl -s https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 | bashPas kësaj, shtojmë depozitën e chart-eve:
helm repo add stable https://kubernetes-charts.storage.googleapis.com/Tani do të instalojmë komponentët infrastrukturore sipas planit:
- Ingress controller;
- Prometheus;
- Grafana;
- cert-manager.
Ingress controller
Komponenti i parĂ« â Ingress controller â instalohet lehtĂ«sisht dhe Ă«shtĂ« gati pĂ«r t'u pĂ«rdorur "nga kutia". Mjafton tĂ« hysh nĂ« dhe tĂ« ekzekutosh komandĂ«n e instalimit nga aty:
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v0.34.1/deploy/static/provider/baremetal/deploy.yamlMegjithatë, në atë moment "malina" filloi të tensionohej dhe të përballej me IOPS-in e diskut. Arsyeja është se, përveç Ingress-controller-it, instalohet një numër i madh burimesh, ekzekutohen shumë kërkesa për API dhe, për pasojë, shumë të dhëna shkruhen në etcd. Në thelb, ose karta e memories 10 është jo shumë e fuqishme, ose SD kartat në përgjithësi nuk mjaftojnë për një ngarkesë të tillë. Megjithatë, pas pesë minutash gjithçka u aktivizua.
U krijua një namespace dhe në të shfaqej kontrolle dhe gjithçka e nevojshme për të:
root@pi-control:~# kubectl -n ingress-nginx get pod
EMRI GATI STATUS RIKTHIMET 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 Po funksionon 0 48sPrometheus
Dy komponentët e ardhshëm janë mjaft të lehtë për t'u instaluar përmes Helm nga repo chart.
Gjejmë Prometheus, krijojmë namespace dhe e instalojmë atje:
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"}Së default, Prometheus kërkon 2 disqe: një për të dhënat e Prometheus dhe një për të dhënat e AlertManager. Duke qenë se nuk është krijuar një storage class në klaster, disqet nuk do të kërkohen dhe pod-të nuk do të nisin. Për instalimet bare metal të Kubernetes zakonisht përdorim Ceph rbd, megjithatë në rastin e Raspberry Pi kjo është një tepricë e qartë.
Prandaj, le të krijojmë një storage lokal të thjeshtë në hostpath. Manifestet PV (persistent volume) për prometheus-server dhe prometheus-alertmanager janë të bashkuara në skedarin prometheus-pv.yaml në . Drejtoria për PV duhet të krijohet më parë në diskun e atij nodi, të cilit dëshirojmë t'i lidhim Prometheus: në shembull është e caktuar nodeAffinity pi-worker sipër hostname /data/localstorage/prometheus-server dhe /data/localstorage/prometheus-alertmanager.
dhe në të janë krijuar direktoriume
Shkarkojmë (klonojmë) manifestin dhe e shtojmë në Kubernetes:kubectl create -f prometheus-pv.yaml
Në këtë fazë, përballesha për herë të parë me problemin e arkitekturës ARM. Kube-state-metrics, i cili instalohet si default në chartin Prometheus, refuzoi të niste. Ai dha gabimin: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"
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.7Duhej të kërkoja pak dhe të gjeja, për shembull, . Për ta përdorur, do të përmirësojmë lëshimin duke treguar se cili imazh të përdorim 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ë që gjithçka të ketë nisur:
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 4m52sGrafana dhe cert-manager
Për grafikët dhe dashboard-et instalojmë Grafana:
helm install grafana --namespace monitoring stable/grafana --set ingress.enabled=true --set ingress.hosts={"grafana.home.pi"}Në fund të daljes na tregohet se si ta marrim fjalëkalimin për akses:
kubectl get secret --namespace monitoring grafana -o jsonpath="{.data.admin-password}" | base64 --decode ; echoPër të porositur certifikatat, do të vendosim cert-manager. Për instalimin e tij do t'i referohemi , e cila ofron komandat përkatëse 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Ă«shkruara, ky Ă«shtĂ« mjaft i pĂ«rshtatshĂ«m pĂ«r pĂ«rdorim nĂ« shtĂ«pi. NĂ«se duhen marrĂ« po ato Letâs Encrypt, atĂ«herĂ« duhet tĂ« konfigurohet edhe cluster issuer. Detajet mbi kĂ«tĂ« mund tĂ« gjenden nĂ« artikullin tonĂ« «».
Unë vendosa për opsionin nga , duke vendosur se opsioni staging i LE do të ishte i mjaftueshëm. Ndryshojmë në shembull email-in, e ruajmë në skedar dhe e shtojmë në klasër ():
kubectl create -f cert-manager-cluster-issuer.yamlTani mund të porositim një certifikat, për shembull, për Grafana. Për këtë, nevojitet një domen dhe akses në klasër nga jashtë. Unë kam një domen, dhe trafiku e kam konfigurur duke kaluar portet 80 dhe 443 në router-in tim të shtëpisë në përputhje me shërbimin e krijuar të 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 23dPorti 80 në këtë rast përkthehet në 31303 dhe 443 në 30498. (Portat gjenerohen rastësisht, prandaj do të keni numra të ndryshëm.)
Ja një shembull certifikate ():
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ë në klaster:
kubectl create -f cert-manager-grafana-certificate.yamlPas kĂ«saj do tĂ« shfaqet burimi Ingress, pĂ«rmes tĂ« cilit do tĂ« bĂ«het validimi nga 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 Pas kalimit të validimit, do të shohim se burimi certificate është gati, dhe në sekretin e përmendur më sipër grafana-tls ndodhet certifikata dhe çelësi. Mund ta verifikoni 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 X1Të kthehemi te Grafana. Na nevojitet të bëjmë disa ndryshime në release-in e saj Helm, duke rregulluar parametrat për TLS në përputhje me certifikatën e krijuar.
Për këtë, shkarkojmë chart-in, e rregullojmë dhe përditësojmë nga direktoria lokale:
helm pull --untar stable/grafana Editojmë në skedarin grafana/values.yaml parametrat TLS:
tls:
- secretName: grafana-tls
hosts:
- grafana.home.pi Po ashtu, mund të konfigurojmë Prometheus-in e instaluar si burimi i të dhënave:
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:
helm upgrade grafana --namespace monitoring ./grafana --set ingress.enabled=true --set ingress.hosts={"grafana.home.pi"} Kontrollojmë se në Ingress grafana është shtuar porta 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ë veprim, mund të shkarkoni dhe shtoni . Ja si duket:
Po ashtu, rekomandoj të shtoni një dashboard për node exporter: ky do të tregojë në detaje çfarë po ndodh me "mali" (ngarkesa e CPU, përdorimi i memories, rrjeti, disku etj.).
Pas kësaj, mendoj se klastri është gati të pranojë dhe të nisë aplikacionet!
Shënim mbi ndërtim
PĂ«r ndĂ«rtimin e aplikacioneve pĂ«r arkitekturĂ«n ARM, ka tĂ« paktĂ«n dy mundĂ«si. SĂ« pari, mund tĂ« ndĂ«rtohet nĂ« njĂ« pajisje ARM. MegjithatĂ«, pasi pashĂ« aktualizimin e dy Raspberry Pi, kuptova se nuk do tâi pĂ«rballonin as ndĂ«rtimet. Prandaj, kam porositur njĂ« Raspberry Pi 4 tĂ« re (ajo Ă«shtĂ« mĂ« e fuqishme dhe ka madje 4 GB memorie) â planifikoj ta ndĂ«rtoj atje.
Opsioni i dytĂ« â ndĂ«rtimi i njĂ« imazhi Docker me shumĂ« arkitektura nĂ« njĂ« makinĂ« mĂ« tĂ« fuqishme. PĂ«r kĂ«tĂ« ka . NĂ«se aplikacioni Ă«shtĂ« nĂ« njĂ« gjuhĂ« tĂ« kompiluar, do tĂ« nevojitet njĂ« pĂ«rpilim i kryqĂ«zuar pĂ«r ARM. Nuk do tĂ« pĂ«rshkruaj tĂ« gjitha cilĂ«simet pĂ«r kĂ«tĂ« rrugĂ«, pasi do tĂ« duhej njĂ« artikull i veçantĂ«. Me implementimin e kĂ«tij qasjeje, mund tĂ« arrihen imazhe "universale": Docker, i cilĂ«suar nĂ« njĂ« makinĂ« ARM, do tĂ« ngarkojĂ« automatikisht imazhin pĂ«rkatĂ«s pĂ«r arkitekturĂ«n.
PĂ«rfundimi
Eksperimenti i kryer kaloi të gjitha pritjet e mia: [të paktën] Kubernetes-i "vanilje" me bazën e nevojshme punon mirë në ARM, dhe gjatë konfigurimit të tij vetëm disa detaje u shfaqën.
Raspberry Pi 3B+ e mbajnë ngarkesën e CPU-së, por kartat e tyre SD janë një ngushticë e dukshme. Kollegët sugjeruan se në disa versione ka mundësi të ngarkohet nga USB, ku mund të lidhet një SSD: atëherë situata do të përmirësohet ndjeshëm.
Ja një shembull i ngarkesës së CPU-së gjatë instalimit të Grafana:
Për eksperimente dhe për "të provuar", sipas mendimit tim, një klaster Kubernetes në "mali" përcjell ndjesitë nga shfrytëzimi shumë më mirë se Minikube i njëjtë, sepse të gjitha komponentët e klasterit instalohen dhe funksionojnë "si profesionistë".
NĂ« perspektivĂ«, ka njĂ« ide pĂ«r tĂ« shtuar nĂ« klasterin e plotĂ« ciklin CI/CD, tĂ« realizuar plotĂ«sisht nĂ« Raspberry Pi. Po ashtu, do tĂ« isha i lumtur nĂ«se dikush do tĂ« ndante pĂ«rvojĂ«n e tij nĂ« konfigurimin e K8s nĂ« AWS GravitonâĂ«t.
P.S. Po, «production» mund të jetë më afër se sa mendoja:
P.P.S.
Lexoni gjithashtu në blogun tonë:
- «».
Burimi: habr.com
