🥇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 ثابت ، ويجب أن يكون لدى العقد العاملة حسب تقديرها. فضلت العناوين الثابتة في كل مكان لأسباب تتعلق بسهولة الإعداد.
يمكن تكوين العنوان الثابت في نظام التشغيل (في الملف /etc/dhcpcd.conf هناك مثال مناسب) أو عن طريق تحديد عقد الإيجار في خادم DHCP لجهاز التوجيه المستخدم (في حالتي ، المنزل).
يتم تضمين خادم ssh ببساطة في raspi-config (خيارات التواصل → 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

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

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 Pis ، لذا تبرع بواحد منهما. فقط تحت طائرة التحكم لم أرغب في ذلك. لذلك قمت بإزالة التلوث المثبت تلقائيًا من عقدة التحكم في 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/

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

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

تحكم الدخول

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

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 من مخطط إعادة الشراء.

نجد محب العمل، أنشئ مساحة اسم واضبطها على:

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 قرصين: لبيانات Prometheus نفسه وبيانات AlertManager. نظرًا لعدم إنشاء فئة تخزين في الكتلة ، لن يتم طلب الأقراص ولن يتم بدء البودات. بالنسبة إلى تركيبات Kubernetes المعدنية العارية ، نستخدم عادةً Ceph rbd ، ولكن في حالة Raspberry Pi ، يعد هذا مبالغة.

لذلك ، سننشئ تخزينًا محليًا بسيطًا على hostpath. يتم دمج ملفات PV (الحجم الدائم) لخادم Prometheus و prometheus-alertmanager في الملف prometheus-pv.yaml в مستودعات Git مع أمثلة للمقال. هناك حاجة إلى دليل الكهروضوئية مقدما إنشاء على قرص العقدة التي نريد ربط بروميثيوس بها: في المثال مكتوب 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

جرافانا ومدير الشهادات

للمخططات ولوحات المعلومات ، قم بتعيين جرافانا:

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

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

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

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. (يتم إنشاء المنافذ بشكل عشوائي ، لذا ستكون منافذك مختلفة.)

هنا مثال على شهادة (شهادة مدير-جرافانا- شهادة):

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

بعد ذلك ، سيظهر مورد Ingress ، والذي من خلاله سوف نتحقق من صحة 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

هنا يمكنك تكوين ملف بروميثيوس المثبت على الفور 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"}

نتحقق من ذلك في Ingress grafana تمت إضافة المنفذ 443 ويمكن الوصول إليه عبر 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 Pis ، أدركت أنهما لن ينجيا من التجميع أيضًا. لذلك ، طلبت Raspberry Pi 4 جديدًا لنفسي (إنه أقوى ولديه ذاكرة تصل إلى 4 غيغابايت) - أخطط لتجميعه عليه.

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

اختتام

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

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

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

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

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

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