Kubernetes الحيادي السحابي على AWS: دليل استراتيجي

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

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

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

Kubernetes الحيادية السحابية: الفوائد والتحديات

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

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

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

كيفية تثبيت K3s

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

إعداد K3sCluster

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

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

يمكن أن تنضم عقدة في K3s إلى الكتلة كخادم أو وكيل، اعتمادًا على التكوين في البرنامج النصي للتهيئة.

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

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

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

curl -sfL -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-lable "topology.kubernetes.io/region=${region}" \
   --node-lable "topology.kubernetes.io/zone=${instanceAz}" \
   - كتابة-كوبكونفيج-وضع-وضع 644

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

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

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

Curl -sfL -sfL https://get.K3s.io | \ \
INSTALL_K3S_VERSION=${K3s_agent_version} \
INSTALL_K3S_EXEC="وكيل" \
K3S_TOKEN=$(K3s_server_token_secret)\
sh -s - agent - agent --server https://${K3s_server_nlb_dns}:6443 \
 --kubelet-arg="provider-id=/aws:////$instanceAz/$instanceId" \
 --node-label "topology.kubernetes.io/ io/region=${region}" \
 --عُقدة-تسمية العقدة "topology.kubernetes.io/ io/zone=${instanceAz}" \
 - سجل /var/log/agent.log

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

بعد انضمام العقد والوكلاء، سيظهر الناتج الناتج على النحو التالي.

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

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

ما هي الأدوات الأخرى التي نستخدمها للإشراف على بنية نظامنا الرقمي؟

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

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

IaC: قصة CloudFormation

مكدسات AWS CloudFormation AWS CloudFormation

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

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

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

تبدو قاعدة كود البرنامج النصي للنشر لدينا كالتالي.

محرك النمذجة يعزز إمكانية إعادة الاستخدام

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

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

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

مجمّع بايثون-جينجا

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

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

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

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

استخدام أوامر "إنشاء" لتمهيد مجموعات K3s ونشرها

بعد أتمتة المراحل المختلفة باستخدام البرامج النصية لباش، قمنا بتبسيط العملية في البرامج النصية الرئيسية التالية:

• نشر. ش: نشر المكدس إلى CloudFormation باستخدام واجهة مستخدم AWS CLI.
• test.sh: ينفذ الاختبارات على المكدس.
• تدمير: يزيل المكدس من CloudFormation.
• render.sh: يُنشئ ملفات YAML من مدخلات 'parameter.yaml'.

لتبسيط وتحسين سهولة الاستخدام، استخدمنا GNU Make لتوحيد هذه الأوامر. يتيح لنا هذا تنفيذ المهام بأوامر بسيطة مثل "جعل النشر" و"جعل التدمير" و"جعل الاختبار" و"جعل التصيير"، مما يوفر واجهة أكثر سهولة لإدارة مكدسات CloudFormation الخاصة بنا.

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

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

شاهد هذه المساحة للمرحلة التالية من مغامرتنا Kubernetes!

نبذة عن المؤلف

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

‍