🚔 🥔 🧖🏽 أكمل Kubernetes من البداية على Raspberry Pi 👏 👨🏿‍🚒 👶🏼

في الآونة الأخيرة ، أعلنت شركة معروفة أنها بصدد نقل خطها من أجهزة الكمبيوتر المحمولة إلى هندسة ARM. عند سماع هذا الخبر ، تذكرت: أثناء البحث في أسعار EC2 في AWS مرة أخرى ، لاحظت أن Gravitons بسعر لذيذ جدًا. المهم ، بالطبع ، أنه ARM. لم يخطر ببالي حتى ذلك الحين أن ARM كانت جادة جدًا ...

بالنسبة لي ، كانت هذه الهندسة دائمًا الكثير من الأشياء المحمولة وغيرها من إنترنت الأشياء. تعد الخوادم "الحقيقية" على ARM غير عادية إلى حد ما ، بل وحشية من بعض النواحي ... ومع ذلك ، بقيت فكرة جديدة في رأسي ، لذلك قررت في أحد أيام الأسبوع التحقق مما يمكن إطلاقه في ARM اليوم. ولهذا قررت أن أبدأ بمجموعة قريبة وعزيزة - مجموعة Kubernetes. وليس فقط بعض "الكتلة" الشرطية ، ولكن كل شيء "بطريقة البالغين" بحيث يكون قدر الإمكان هو نفسه الذي اعتدت رؤيته في الإنتاج.

وفقًا لفكرتي ، يجب أن يكون الوصول إلى الكتلة متاحًا من الإنترنت ، ويجب تشغيل بعض تطبيقات الويب فيه ويجب أن يكون هناك على الأقل مراقبة. لتنفيذ هذه الفكرة ، ستحتاج إلى زوج (أو أكثر) طراز Raspberry Pi 3B + أو أعلى. كان من الممكن أن تصبح AWS منصة للتجارب ، لكن "التوت" كان مثيرًا للاهتمام بالنسبة لي (والذي كان لا يزال خاملاً). لذلك ، سنقوم بنشر مجموعة Kubernetes مع Ingress و Prometheus و Grafana عليها.

تحضير "التوت"

تثبيت نظام التشغيل و SSH

لم أزعجني كثيرًا باختيار نظام التشغيل للتثبيت: لقد أخذت للتو أحدث إصدار من Raspberry Pi OS Lite من الموقع الرسمي . تتوفر أيضًا وثائق التثبيت هناك ، ويجب تنفيذ جميع الإجراءات من خلالها على جميع عقد المجموعة المستقبلية. بعد ذلك ، تحتاج إلى إجراء المعالجات التالية (أيضًا على جميع العقد).

بعد توصيل الشاشة ولوحة المفاتيح ، يجب عليك أولاً تكوين الشبكة و SSH:

لكي تعمل الكتلة ، يجب أن يكون للسيد عنوان IP ثابت ، ويجب أن يكون للعقد العاملة عنوان IP ثابت. فضلت العناوين الثابتة في كل مكان لسهولة الإعداد.
يمكن تكوين عنوان ثابت في نظام التشغيل ( /etc/dhcpcd.confيوجد مثال مناسب في الملف ) أو عن طريق تحديد عقد الإيجار في خادم DHCP لجهاز التوجيه المستخدم (في حالتي ، المنزل).
تم تضمين خادم ssh فقط في تكوين raspi ( خيارات الواجهة -> ssh ).

بعد ذلك ، يمكنك بالفعل تسجيل الدخول عبر SSH (بشكل افتراضي ، تسجيل الدخول هو pi، وكلمة المرور هي raspberryالتي غيرت إليها) ومتابعة الإعدادات.

اعدادات اخرى

لنقم بتعيين اسم المضيف. في بلدي على سبيل المثال، pi-controlو سيتم استخدامها pi-worker.
دعنا نتحقق من توسيع نظام الملفات ليشمل القرص بأكمله ( df -h /). يمكن تمديده إذا لزم الأمر باستخدام raspi-config.
قم بتغيير كلمة مرور المستخدم الافتراضية في raspi-config.
قم بإيقاف تشغيل ملف المبادلة (هذا هو مطلب Kubernetes ؛ إذا كنت مهتمًا بالتفاصيل حول هذا الموضوع ، فراجع المشكلة رقم 53533 ):
```
dphys-swapfile swapoff
systemctl disable dphys-swapfile
```
لنقم بتحديث الحزم إلى أحدث الإصدارات:
```
apt-get update && apt-get dist-upgrade -y
```
تثبيت Docker والحزم الإضافية:
```
apt-get install -y docker docker.io apt-transport-https curl bridge-utils iptables-persistent
```
أثناء التثبيت ، iptables-persistentستحتاج إلى حفظ إعدادات iptables لـ ipv4 ، /etc/iptables/rules.v4وإضافة القواعد إلى السلسلة في الملف FORWARD، مثل هذا:
```
# 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
```
يبقى فقط لإعادة التشغيل.

أنت الآن جاهز لتثبيت مجموعة Kubernetes الخاصة بك.

تثبيت برنامج Kubernetes

في هذه المرحلة ، قمت بتأجيل جميع عمليات التطوير الخاصة بي وتطورات الشركة الخاصة بنا فيما يتعلق بأتمتة تثبيت وتكوين مجموعة K8s. بدلاً من ذلك ، سنستخدم الوثائق الرسمية من kubernetes.io (مع استكمالها قليلاً بالتعليقات والاختصارات).

أضف مستودع 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 update

علاوة على ذلك في الوثائق ، يُقترح تثبيت CRI (واجهة وقت تشغيل الحاوية). نظرًا لأنه تم تثبيت Docker بالفعل ، فلننتقل إلى المكونات الرئيسية ونثبتها:

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

في خطوة تثبيت المكونات الرئيسية ، أضفت على الفور kubernetes-cniما هو مطلوب حتى تعمل الكتلة. وهنا توجد نقطة مهمة: kubernetes-cniلسبب ما ، لا تنشئ الحزمة دليلًا افتراضيًا لإعدادات واجهة CNI ، لذلك كان عليّ إنشائها يدويًا:

mkdir -p /etc/cni/net.d

لكي تعمل الواجهة الخلفية للشبكة ، والتي سيتم مناقشتها أدناه ، تحتاج إلى تثبيت المكون الإضافي لـ CNI. اخترت المكون الإضافي portmap ، وهو مألوف وواضح بالنسبة لي (راجع الوثائق للحصول على قائمة كاملة ):

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

عقدة مستوى التحكم

يعد إنشاء الكتلة نفسها أمرًا بسيطًا إلى حد ما. ولتسريع هذه العملية والتحقق من توفر صور Kubernetes ، يمكنك أولاً تشغيل:

kubeadm config images pull

الآن نقوم بتنفيذ التثبيت نفسه - نقوم بتهيئة مستوى التحكم في الكتلة:

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

يرجى ملاحظة أن الشبكات الفرعية للخدمات والبودات يجب ألا تتداخل مع بعضها البعض أو مع الشبكات الموجودة.

في النهاية ، ستظهر لنا رسالة تفيد بأن كل شيء على ما يرام ، وفي نفس الوقت سيعلمونك بكيفية إرفاق عقد العمل بمستوى التحكم:

Your Kubernetes control-plane has initialized successfully!
To start using your cluster, you need to run the following as a regular user:
 mkdir -p $HOME/.kube
 sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
 sudo chown $(id -u):$(id -g) $HOME/.kube/config
You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
 https://kubernetes.io/docs/concepts/cluster-administration/addons/
You can now join any number of the control-plane node running the following command on each as root:
 kubeadm join 192.168.88.30:6443 --token a485vl.xjgvzzr2g0xbtbs4 \
   --discovery-token-ca-cert-hash sha256:9da6b05aaa5364a9ec59adcc67b3988b9c1b94c15e81300560220acb1779b050 \
   --contrl-plane --certificate-key 72a3c0a14c627d6d7fdade1f4c8d7a41b0fac31b1faf0d8fdf9678d74d7d2403
Please note that the certificate-key gives access to cluster sensitive data, keep it secret!
As a safeguard, uploaded-certs will be deleted in two hours; If necessary, you can use
"kubeadm init phase upload-certs --upload-certs" to reload certs afterward.
Then you can join any number of worker nodes by running the following on each as root:
kubeadm join 192.168.88.30:6443 --token a485vl.xjgvzzr2g0xbtbs4 \
   --discovery-token-ca-cert-hash sha256:9da6b05aaa5364a9ec59adcc67b3988b9c1b94c15e81300560220acb1779b050

دعنا نتبع التوصيات الخاصة بإضافة تهيئة للمستخدم. وفي الوقت نفسه ، أوصي بإضافة الإكمال التلقائي لـ 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

في هذه المرحلة ، يمكنك بالفعل رؤية العقدة الأولى في الكتلة (على الرغم من أنها ليست جاهزة بعد):

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

تكوين شبكة

علاوة على ذلك ، كما قيل في الرسالة بعد التثبيت ، ستحتاج إلى تثبيت الشبكة في الكتلة. توفر الوثائق خيارًا من Calico و Cilium و contiv-vpp و Kube-router و Weave Net ... هنا انحرفت عن الإرشادات الرسمية واخترت خيارًا أكثر دراية ومفهومًا بالنسبة لي: الفانيلا في وضع host-gw (لمزيد من المعلومات حول الخلفيات المتاحة ، راجع الوثائق مشروع ).

تثبيته في كتلة بسيط للغاية. أولاً ، قم بتنزيل المانيفست:

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

ثم قم بتغيير النوع من vxlanإلى في الإعدادات host-gw:

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

... والشبكة الفرعية pod - من القيمة الافتراضية إلى القيمة المحددة أثناء تهيئة الكتلة:

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

بعد ذلك ، نقوم بإنشاء الموارد:

kubectl create -f kube-flannel.yml

منجز! بعد فترة ، ستنتقل عقدة K8s الأولى إلى الحالة Ready:

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

إضافة عقدة عاملة

الآن يمكنك إضافة عامل. للقيام بذلك ، عليه - بعد تثبيت Kubernetes نفسه وفقًا للسيناريو الموضح أعلاه - ما عليك سوى تنفيذ الأمر الذي تم استلامه مسبقًا:

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

في هذا يمكننا أن نفترض أن الكتلة جاهزة:

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

لم يكن لدي سوى اثنين من Raspberry Pi في متناول اليد ، لذلك لم أرغب في إعطاء واحد منهم فقط تحت طائرة التحكم. لذلك قمت بإزالة التلوث المثبت تلقائيًا من عقدة التحكم في pi عن طريق تشغيل:

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

.. وإزالة الخطوط:

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

ملء الكتلة بالحد الأدنى المطلوب

بادئ ذي بدء ، نحتاج إلى هيلم . بالطبع ، يمكنك القيام بكل شيء بدونه ، لكن Helm يسمح لك بتهيئة بعض المكونات كما تراه مناسبًا ، حرفيًا دون تحرير الملفات. وفي الحقيقة هو مجرد ملف ثنائي "لا يطلب الخبز".

لذلك ، انتقل إلى helm.sh في قسم المستندات / التثبيت وقم بتنفيذ الأمر من هناك:

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

بعد ذلك أضف مستودع الرسم البياني:

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

لنقم الآن بتثبيت مكونات البنية التحتية وفقًا للفكرة:

تحكم الدخول
بروميثيوس.
جرافانا.
مدير الشهادات.

تحكم الدخول

المكون الأول ، وحدة التحكم في الدخول ، سهل التركيب وجاهز للاستخدام خارج الصندوق. للقيام بذلك ، ما عليك سوى الانتقال إلى قسم bare-metal في الموقع وتنفيذ أمر التثبيت من هناك:

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

ومع ذلك ، في هذه اللحظة ، بدأ "التوت" بالتوتر والركض إلى قرص IOPS. الحقيقة هي أنه مع وحدة التحكم في الدخول ، يتم تثبيت عدد كبير من الموارد ، ويتم إجراء العديد من طلبات واجهة برمجة التطبيقات ، وبالتالي ، تتم كتابة الكثير من البيانات إلى إلخ. بشكل عام ، إما أن بطاقة الذاكرة من الفئة 10 ليست منتجة للغاية ، أو أن بطاقة SD غير كافية بشكل أساسي لمثل هذا الحمل. ومع ذلك ، بعد 5 دقائق بدأ كل شيء.

تم إنشاء مساحة اسم وظهرت فيها وحدة تحكم وكل ما تحتاجه:

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

بروميثيوس

من السهل تثبيت المكونين التاليين عبر Helm من مخطط إعادة الشراء.

ابحث عن Prometheus ، وأنشئ مساحة اسم وقم بتثبيتها فيه:

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

بشكل افتراضي ، يطلب Prometheus قرصين: لبيانات بروميثيوس نفسه وبيانات AlertManager. نظرًا لعدم إنشاء فئة تخزين في الكتلة ، لن يتم طلب الأقراص ولن تبدأ البودات. بالنسبة لتركيبات Kubernetes المعدنية العارية ، نستخدم عادةً Ceph rbd ، ولكن في حالة Raspberry Pi ، يعد هذا مبالغة.

لذلك دعونا ننشئ تخزينًا محليًا بسيطًا على مسار المضيف. يتم دمج ملفات PV (المجلد الدائم) لخادم Prometheus و prometheus-alertmanager في ملف prometheus-pv.yamlفي مستودع Git مع أمثلة للمقالة . يجب إنشاء دليل PV مسبقًا على قرص العقدة التي نريد ربط Prometheus بها: في المثال nodeAffinity، يتم تحديد اسم المضيف pi-workerوالدلائل /data/localstorage/prometheus-serverويتم إنشاؤها عليه /data/localstorage/prometheus-alertmanager.

تنزيل (استنساخ) البيان وإضافته إلى Kubernetes:

kubectl create -f prometheus-pv.yaml

في هذه المرحلة ، واجهت مشكلة هندسة ARM لأول مرة. Kube-state-metrics ، التي تم تعيينها افتراضيًا في مخطط Prometheus ، رفضت البدء. كان يعطي خطأ:

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"

الحقيقة هي أنه بالنسبة لمقاييس kube-state-metrics ، يتم استخدام صورة مشروع CoreOS ، والتي لم يتم تجميعها لـ 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

اضطررت إلى البحث في google قليلاً والعثور ، على سبيل المثال ، على هذه الصورة . للاستفادة منها ، دعنا نحدّث الإصدار ، مع تحديد الصورة التي يجب استخدامها لمقاييس 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

نتحقق من أن كل شيء قد بدأ:

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 :

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

في نهاية الإخراج ، سوف نوضح كيفية الحصول على كلمة المرور للوصول:

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

لطلب الشهادات ، قم بتثبيت مدير الشهادات . لتثبيته ، راجع الوثائق التي تقدم الأوامر المناسبة لـ 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

بالنسبة للشهادات الموقعة ذاتيًا في الاستخدام المنزلي ، فهذا يكفي. إذا كنت بحاجة إلى تلقي نفس Let's Encrypt ، فأنت بحاجة إلى تكوين جهة إصدار مجموعة أخرى. يمكن العثور على مزيد من التفاصيل في مقالتنا " شهادات SSL من Let's Encrypt with cert-manager على Kubernetes ".

لقد استقرت بنفسي على الإصدار من المثال الموجود في الوثائق ، وقررت أن النسخة التدريجية من LE ستكون كافية. قم بتغيير البريد الإلكتروني في المثال ، واحفظه في ملف وأضفه إلى المجموعة ( cert-manager-cluster-issuer.yaml ):

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

يمكنك الآن طلب شهادة ، على سبيل المثال ، لـ Grafana. سيتطلب هذا المجال والوصول الخارجي إلى الكتلة. لدي مجال ، وقمت بتكوين حركة المرور عن طريق إعادة توجيه المنفذين 80 و 443 على جهاز التوجيه المنزلي الخاص بي وفقًا لخدمة وحدة التحكم التي تم إنشاؤها:

kubectl -n ingress-nginx get svc
NAME                                 TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)                      AGE
ingress-nginx-controller             NodePort    10.2.206.61    <none>        80:31303/TCP,443:30498/TCP   23d

في هذه الحالة ، يتم ترجمة المنفذ 80 إلى 31303 ، ومن 443 إلى 30498. (يتم إنشاء المنافذ عشوائيًا ، لذلك سيكون لديك منافذ مختلفة.)

إليك مثال على الشهادة ( 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

أضفه إلى الكتلة:

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

بعد ذلك ، سيظهر مورد الدخول ، والذي سيتم من خلاله التحقق من صحة Let's Encrypt:

root@pi-control:~# kubectl -n monitoring get ing
NAME                        CLASS    HOSTS                        ADDRESS         PORTS   AGE
cm-acme-http-solver-rkf8l   <none>   grafana.home.pi      192.168.88.31   80      72s
grafana                     <none>   grafana.home.pi      192.168.88.31   80      6d17h
prometheus-server           <none>   prometheus.home.pi   192.168.88.31   80      8d

بعد اجتياز التحقق من الصحة ، سنرى أن المورد certificateجاهز ، وأن السر أعلاه يحتوي على grafana-tlsالشهادة والمفتاح. يمكنك التحقق فورًا من مصدر الشهادة:

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

دعنا نعود إلى جرافانا. نحتاج إلى إصلاح إصدار Helm قليلاً ، وتغيير إعدادات TLS وفقًا للشهادة التي تم إنشاؤها.

للقيام بذلك ، قم بتنزيل المخطط وتعديله وتحديثه من الدليل المحلي:

helm pull --untar stable/grafana

تحرير grafana/values.yaml معلمات TLS في الملف :

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

هنا يمكنك تكوين برنامج Prometheus المثبت على الفور على النحو التالي datasource:

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

الآن قم بتحديث مخطط جرافانا من الدليل المحلي:

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

نتحقق من إضافة grafanaالمنفذ 443 إلى Ingress وأن هناك وصولاً عبر HTTPS:

root@pi-control:~# kubectl -n monitoring get ing grafana
NAME      CLASS    HOSTS                     ADDRESS         PORTS     AGE
grafana   <none>   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=%2F; Path=/; HttpOnly; SameSite=Lax
x-frame-options: deny
strict-transport-security: max-age=15724800; includeSubDomains

لإثبات عمل Grafana ، يمكنك تنزيل وإضافة لوحة تحكم لمقاييس kube-state-metrics . وإليك كيف يبدو:

أوصي أيضًا بإضافة لوحة معلومات لمصدر العقدة: ستعرض بالتفصيل ما يحدث لـ "التوت" (حمل وحدة المعالجة المركزية ، والذاكرة ، والشبكة ، واستخدام القرص ، وما إلى ذلك).

بعد ذلك أعتقد أن الكتلة جاهزة لاستقبال وتشغيل التطبيقات!

ملاحظة الجمعية

يوجد خياران على الأقل لبناء تطبيقات لهندسة ARM. أولاً ، يمكنك البناء على جهاز ARM. ومع ذلك ، بعد النظر في التخلص الحالي من جهازي Raspberry Pi ، أدركت أنهما لن ينجو من التجميع أيضًا. لذلك ، طلبت Raspberry Pi 4 جديدًا (إنه أقوى ويحتوي على 4 جيجابايت من الذاكرة) - أخطط للبناء عليه.

الخيار الثاني هو بناء صورة Docker متعددة المعمار على جهاز أكثر قوة. هناك ملحق عامل بناء بناء لهذا الغرض . إذا كان التطبيق بلغة مترجمة ، فإن التجميع المتقاطع لـ ARM مطلوب. لن أصف جميع الإعدادات الخاصة بهذا المسار ، لأن سيؤدي هذا إلى مقالة منفصلة. عند تنفيذ هذا النهج ، يمكنك الحصول على صور "عالمية": يقوم Docker الذي يعمل على جهاز ARM تلقائيًا بتحميل الصورة المطابقة للبنية.

خاتمة

تجاوزت التجربة التي تم إجراؤها كل توقعاتي: [على الأقل] "الفانيليا" Kubernetes مع القاعدة الضرورية تشعر بالرضا على ARM ، ومع تكوينها ، نشأت فروقان فقط.

يعمل Raspberry Pi 3B + نفسه على إبقاء وحدة المعالجة المركزية مشغولة ، لكن بطاقات SD الخاصة بهم تمثل عنق زجاجة واضح. اقترح الزملاء أنه في بعض الإصدارات من الممكن التمهيد من USB ، حيث يمكنك توصيل SSD: ومن المرجح أن يتحسن الوضع.

فيما يلي مثال على حمل وحدة المعالجة المركزية عند تثبيت Grafana:

للتجارب و "للتجربة" ، في رأيي ، تنقل مجموعة Kubernetes على "التوت" أحاسيس التشغيل بشكل أفضل بكثير من نفس Minikube ، لأن جميع مكونات الكتلة مثبتة وتعمل "بطريقة الكبار".

في المستقبل ، هناك فكرة لإضافة دورة CI / CD بأكملها إلى المجموعة ، والتي يتم تنفيذها بالكامل على Raspberry Pi. وسأكون سعيدًا أيضًا إذا شارك شخص ما تجربته في إعداد K8s على AWS Gravitons.

ملاحظة: نعم ، قد يكون "الإنتاج" أقرب مما كنت أعتقد:

PPS

اقرأ أيضًا على مدونتنا:

" مغامرات مع مجموعة Kubernetes المنزلية ."

أكمل Kubernetes من البداية على Raspberry Pi