Kubernetes المستقل عن السحابة على AWS: دليل استراتيجي

هل تذكر أيام الصيانة المستمرة للخوادم؟ قضينا ليالي متأخرة في حل أعطال الانهيار والدعاء بعدم حدوث أي خلل خلال ذروة حركة المرور. جميعنا مررنا بذلك. هذه المعارك المستمرة مع عدم استقرار البنية التحتية كانت الدافع وراء بحثنا عن حل أكثر قابلية للتوسع ومرونة.

قادنا هذا السعي إلى مشروع ممتع لاستكشاف عالم Kubernetes، وهي منصة تنسيق الحاويات التي وعدت بتسهيل إدارة التطبيق ونشره. بينما جلبت تجربتنا الأولى تحدياتها الخاصة، فإن الدروس القيمة التي تعلمناها مهّدت الطريق لانتقال أكثر سلاسة لاستخدام AWS EKS (خدمة أمازون لإدارة Kubernetes المرنة).

في هذه التدوينة، سنخبرك عن مغامرتنا مع Kubernetes، مع التركيز على تجاوز التحديات الشائعة وتعظيم فوائد استراتيجية متعددة السحابات.

Kubernetes المستقل عن السحابة: الفوائد والتحديات

عندما بدأنا الانتقال إلى Kubernetes، واجهنا تحديًا رئيسيًا في إنشاء بيئة مستقلة عن السحابة: الحفاظ على الاتساق والوظائف عبر مزوّدي السحابة المختلفين.

راجعنا أدوات مختلفة بدقة وقررنا اختيار K3s.io لما تتمتع به من مزايا:

• خفيف الوزن: K3s له متطلبات موارد محدودة ويتم تحديثه بانتظام، مما يجعله مناسبًا لمختلف بيئات السحابة.
• بسيط: يوفر K3s عملية تثبيت مباشرة وآمنة مقارنة بالإعدادات الكاملة لـ Kubernetes.
• المصدر المفتوح: طبيعة K3s مفتوحة المصدر تتجنب الاعتماد على أدوات أي مزود سحاب واحد. كما تتوافق مع التزامنا بالانفتاح والتقدم المدفوع من المجتمع.

كيفية تثبيت K3s

إليك كيف يبدو البنية التحتية على مستوى عالٍ:

إعداد K3s Cluster

ابدأ بتثبيت K3s على الخادم الرئيسي وتشغيله في وضع الكتلة (cluster mode). هذه الخطوة أساسية حيث يؤدي بدء K3s في وضع الكتلة تلقائيًا إلى إنشاء رموز. هذا الرمز ضروري لربط العقد الإضافية بالكتلة.

بدلاً من ذلك، يمكنك إنشاء هذا الرمز مسبقًا ودمجه في أمر تهيئة الكتلة. (راجع مقتطف الكود أدناه للحصول على K3S_TOKEN).

يمكن للعقدة في K3s الانضمام إلى الكتلة كسيرفر أو عميل (agent)، حسب التكوين في سكريبت التهيئة.

كيفية بدء خادم K3s في وضع الكتلة

يوفر K3s سكريبت تثبيت بسيط خطوة واحدة يسمح بتهيئة الخادم مع خيار إضافة وظائف إضافية حسب الاحتياجات الخاصة.

فيما يلي السكريبت الأساسي لتهيئة الخادم الرئيسي.

curl -sfL https://get.K3s.io | \
   INSTALL_K3S_EXEC="--tls-san ${K3s_server_nlb_dns}" \
   INSTALL_K3S_VERSION=${K3s_server_version} \
   K3S_TOKEN=${K3s_server_token_secret}\
   sh -s - server --cluster-init \
   --kube-apiserver-arg encryption-provider-config=/etc/rancher/K3s/encryption_config.yaml \
   --kubelet-arg="provider-id=aws:///$instanceAz/$instanceId" \
   --kubelet-arg="cloud-provider=external" \
   --node-taint node-role.kubernetes.io/master:NoSchedule \
   --node-taint node-role.kubernetes.io/control-plane:NoSchedule \
   --node-label "topology.kubernetes.io/region=${region}" \
   --node-label "topology.kubernetes.io/zone=${instanceAz}" \
   --write-kubeconfig-mode 644

كما ترى في مقتطف الكود أعلاه، أضفنا علامات (taints) أثناء تهيئة كتلة K3s لتأكيد أنها عقد رئيسية. تم ذلك باستخدام node-role.kubernetes.io/master:NoSchedule و node-role.kubernetes.io/control-plane:NoSchedule على نقاط التحكم.

كيفية بدء خادم K3s في وضع العميل.

الأمر التالي يقوم بتهيئة عقدة K3s في وضع العميل/العامل:

curl -sfL https://get.K3s.io | \
INSTALL_K3S_VERSION=${K3s_agent_version} \
INSTALL_K3S_EXEC="agent" \
K3S_TOKEN=$(K3s_server_token_secret)\
sh -s - agent --server https://${K3s_server_nlb_dns}:6443 \
 --kubelet-arg="provider-id=aws:///$instanceAz/$instanceId" \
 --node-label "topology.kubernetes.io/region=${region}" \
 --node-label "topology.kubernetes.io/zone=${instanceAz}" \
 --log /var/log/agent.log

في مصطلحات K3s، يُشير "server" إلى العقد الرئيسية، ويُشير "agent" إلى العقد العاملة.

بعد انضمام العقد والعملاء، ستكون النتيجة كما يلي.

وفقًا للهندسة المصممة، هناك ثلاث عقد خادم للتوافر العالي (HA) وعقدتان عاملة قادرتان على التوسّع التلقائي.

مجموعة أدوات لعمليات K3s الفعالة

ما الأدوات الأخرى التي نستخدمها لمراقبة هيكل نظامنا الرقمي؟

1. إدارة الوصول: Rancher هو المفتاح لإدارة من يحصل على الوصول إلى نظامنا وكيف يتم التعرف عليهم. تُسهل هذه الأداة التحكم في الصلاحيات. يعمل Rancher مع طرق تسجيل دخول مختلفة، ونستخدم OKTA لربط هذه الطرق.
2. المراقبة والتسجيل: نستخدم Grafana وVictoriaMetrics وPromtail لمراقبة صحة نظامنا وتسجيل الأنشطة والأحداث.
3. إدارة التخزين: يساعدنا Longhorn في إدارة تخزين البيانات التي تحتاج إلى البقاء متاحة ومتسقة عبر مختلف الحالات.
4. إدارة الأسرار: Hashicorp Vault هو المكان الذي نخزن فيه المعلومات الحساسة مثل كلمات المرور والمفاتيح بشكل آمن.
5. تنفيذ سياسات الأمان: يتحقق OPA Gatekeeper ويفرض القواعد لضمان بقاء نظامنا آمنًا.

وأخيرًا، نستخدم مفهوم البنية التحتية ككود (IaC) لإعداد وإدارة هذه الأدوات والبيئات. وباستخدام AWS CloudFormation لهذا الغرض تحديداً.

IaC: قصة CloudFormation

مكدسات AWS CloudFormation

قبل بدء العمل مع CloudFormation، قمنا بتخطيط عملية العمل بدقة على لوحة بيضاء ووضعنا استراتيجية للنشر.

عزلنا الإعداد باستخدام مكدسات CloudFormation مستفيدين من إعداد مجموعات المكدسات المتداخلة. سمح هذا النهج بنشر بنية تنظيمية وذات وحدات (مُقسمة). ثم قمنا بإنشاء وضبط مجموعات المكدسات التالية بالتتابع:

• root_stack: يعمل كمركز رئيسي، يربط جميع السلاسل الأخرى. تشمل dependencies الضمنية والصريحة على حد سواء. ضمن هذا الهيكل، نحدد المكونات الرئيسية التالية.
• SecurityGroupStack: يزود جميع مجموعات الأمان اللازمة. رجعنا إلى وثائق K3s لوضع قواعد الجدار الناري الافتراضية للعمليات الأساسية.
• InitServerStack: تقوم بتهيئة إعداد العقد الخادم.
• ServerNodesStack: تدير توفير عقد الخادم.
• AgentNodesStack: يتعامل مع إعدادات عقد الوكلاء.

يبدو كود السكريبت الخاص بنشرنا كما يلي.

محرك القوالب يعزز إعادة الاستخدام

لجعل سكريبتات CloudFormation قابلة لإعادة الاستخدام وأكثر كفاءة، استخدمنا محرك قوالب لإنشاء قوالب YAML.

محرك القوالب الذي اخترناه هو Jinja. يأخذ ملف `parameter.yaml` كمدخل، والذي يحدد تفاصيل أساسية عن الكتلة مثل VPC، الشبكات الفرعية، قيود الحد الأدنى والأقصى للتوسع التلقائي، حجم قرص EBS، المنطقة، ورقم الحساب. يمكننا توسيع هذه القائمة بناءً على احتياجاتنا.

يُضيف هذا النهج ديناميكية إلى كودنا. لكل بيئة، ننشئ ملف parameter.yaml منفصل، مثل parameters-dev.yaml و parameters-prod.yaml. هذا يبسط عملية النشر ويسمح لنا بإنشاء بيئات جديدة بسرعة.

مغلف Python-jinja

قمنا بتطوير مغلف Python يستخدم Jinja لرسم سكريبتات CloudFormation الخاصة بنا. هذا المغلف يسمح لنا بإنتاج قوالب مخصصة وفقًا للقيم المحددة في ملف parameter.yaml. تبسط هذه الطريقة إنشاء تكوينات البنية التحتية المُصممة حسب الحاجة.

استخدام AWS Cfn-lint للتحقق من الموارد المرسومة

للتحقق من سلامة الموارد المرسومة، استخدمنا cfn-lint لاختبار والتحقق من سكريبتات CloudFormation الخاصة بنا.

تقوم هذه الأداة بأتمتة عملية التحقق من الصياغة واكتشاف الأخطاء. قمنا بدمجها بسلاسة مع Makefile، الذي يقوم بدوره بتفعيل سكريبت `test.sh`.

استخدام أوامر “make” لتهيئة ونشر عناقيد K3s

بعد أتمتة المراحل المختلفة باستخدام سكريبتات bash، قمنا بتبسيط عملية العمل إلى السكريبتات الرئيسية التالية:

• deploy.sh: ينشر المكدس إلى CloudFormation باستخدام AWS CLI.
• test.sh: ينفذ اختبارات على المكدس.
• destroy.sh: يزيل المكدس من CloudFormation.
• render.sh: يولد ملفات YAML من مدخل `parameter.yaml`.

لتبسيط وتعزيز سهولة الاستخدام، استخدمنا GNU Make لتوحيد هذه الأوامر. هذا يسمح لنا بتنفيذ المهام بأوامر بسيطة مثل `make deploy`، و`make destroy`، و`make test`، و`make render`، مما يوفر واجهة أكثر بديهية لإدارة مكدسات CloudFormation الخاصة بنا.

وفي النهاية، سيبدو مكدس CloudFormation المجهز هكذا:

هذه ليست الفصل الأخير من رحلتنا. في هذا المقال، شاركنا تجربتنا العملية مع Kubernetes، حيث واجهنا العديد من التحديات وتعلمنا دروسًا قيمة. اكتسبنا رؤى حول كيفية إدارة، نسخ احتياطي، واستعادة مكونات Kubernetes. هذا أعدّنا للخطوة التالية باستخدام AWS EKS لإدارة Kubernetes.

تابعوا هذا الفضاء للمرحلة القادمة من مغامرتنا مع Kubernetes!

حول المؤلف

جوتيماني راثاكريشنان، مهندس DevOps أول في Deriv، لديه اهتمام كبير بالتقنيات السحابية. بعيدًا عن دوره الهندسي، هو مدوّن متحمس يكتب عن DevOps، SRE، وتطوير Python.

لا يوجد محتوى لترجمته.