نموذج شبكات كوبرنيتيس
نموذج شبكات كوبرنيتيس
قبل أن تتمكن من فهم الخدمات (Services) أو Ingress أو سياسات الشبكة (NetworkPolicies)، يجب أن تستوعب العقد الأساسي الذي يضمنه كوبرنيتيس فيما يخص الشبكات — وهو نموذج شبكات كوبرنيتيس. كل مفهوم شبكي متقدم في هذا الدرس يُبنى على هذا الأساس، وكل حادثة إنتاج ستقوم بتشخيصها تعود في النهاية إلى مدى التزام الكلستر بهذا النموذج.
الضمانات الثلاث الأساسية
تُلزم مواصفات كوبرنيتيس بثلاثة ضمانات شبكية يجب أن يفي بها أي كلستر متوافق، بصرف النظر عن مزود الخدمة السحابية أو إضافة CNI أو البنية التحتية:
- كل Pod يحصل على عنوان IP فريد خاص به. لا يتشارك أي بودَّان قيد التشغيل في الكلستر — حتى على عقد مختلفة — في نفس العنوان. الـPod هو أصغر وحدة يمكن عنونتها، وليس الحاوية.
- يمكن للـPods على أي عقدة التواصل مباشرةً مع أي Pod على أي عقدة أخرى، دون NAT. حزمة مُرسَلة من Pod A (10.244.1.5) إلى Pod B (10.244.3.8) تصل إلى Pod B وعنوان المصدر لا يزال 10.244.1.5. لا يوجد تمويه للعناوين، ولا تعيين للمنافذ، ولا ترجمة بواسطة وسيط.
- الوكلاء على العقدة (مثل kubelet، والشياطين النظامية) يمكنهم التواصل مع كل Pod على تلك العقدة.
ما لا يُلزم به النموذج عمداً: آلية التنفيذ. التنفيذ مُفوَّض إلى إضافة واجهة شبكة الحاوية (CNI) المثبتة في كلسترك. هذا الفصل بين العقد والتنفيذ هو السبب الجوهري في أن نفس ملفات YAML تعمل على AWS وGCP والأجهزة المادية والحاسوب المحلي — العقد قابلة للنقل حتى لو كانت الأسلاك تحتها مختلفة تماماً.
ما يعنيه "الشبكة المسطحة" عملياً
يأتي كل عنوان IP للـPod من نطاق Pod CIDR للكلستر كاملاً. في كلستر kubeadm نموذجي يكون هذا 10.244.0.0/16؛ وفي GKE قد يكون 10.4.0.0/14. تُخصص مستوى التحكم شبكة فرعية من هذا النطاق لكل عقدة — لنقل 10.244.1.0/24 للعقدة الأولى و10.244.2.0/24 للعقدة الثانية. يحصل الـPods المجدولة على تلك العقدة على عناوين IP من شبكتها الفرعية.
حتى يتمكن بودَّان على عقدتين مختلفتين من التواصل بدون NAT، يجب أن تضمن إضافة CNI أن حزمة مُوجَّهة إلى 10.244.2.5 — الموجودة على العقدة الثانية — تصل فعلاً إلى العقدة الثانية حتى لو أنشئت على العقدة الأولى. للـCNI عدة استراتيجيات لتحقيق ذلك: شبكات التراكب (أنفاق VXLAN)، أو الإعلان عن المسارات عبر BGP، أو حقن مسارات المضيف، أو واجهات برمجة تطبيقات توجيه VPC لمزود الخدمة السحابية. النتيجة دائماً هي نفس فضاء العناوين المسطح؛ فقط الأنابيب تختلف.
إضافات CNI: منفذو العقد
واجهة شبكة الحاوية (CNI) هي مواصفة وليست منتجاً. عند جدولة Pod على عقدة، تستدعي kubelet ملف إضافة CNI الثنائي — مُمررةً مسار مساحة اسم الشبكة للحاوية والإعداد — وتقوم الإضافة بتوصيل الشبكة. عند حذف الـPod تُستدعى مجدداً للتنظيف. يجب أن تفي الإضافة بضمانات النموذج؛ وكيفية القيام بذلك متروكة كلياً لها.
أبرز إضافات CNI في الكلسترات الإنتاجية، وكيفية تنفيذها للشبكة المسطحة:
- Flannel — الخيار الأبسط. تُنشئ شبكة تراكب VXLAN: يُغلَّف الحركة بين العقد في حزم UDP تُنقل عبر الشبكة الفيزيائية. تعقيد تشغيلي منخفض، مع عقوبة أداء معتدلة بسبب التغليف. شائع في المختبرات المحلية والكلسترات الصغيرة.
- Calico — يستخدم BGP للإعلان عن مسارات الشبكة الفرعية للـPod بين العقد. لا تغليف في الوضع الافتراضي — توجيه IP خالص. أداء أعلى بكثير من شبكات التراكب. الأكثر انتشاراً لتطبيق NetworkPolicy في بيئات المؤسسات.
- Cilium — يستخدم برامج eBPF في النواة لتنفيذ التوجيه وموازنة التحميل وتطبيق الأمان. يستبدل kube-proxy كلياً. أفضل رؤية مراقبة (Hubble)، أفضل أداء على نطاق واسع، دعم أصلي لسياسات الشبكة L7. هذا ما تشغّله Google وMeta داخلياً.
- AWS VPC CNI — على EKS، يحصل كل Pod على عنوان IP ثانوي حقيقي من AWS VPC ENI. لا تغليف: عناوين IP للـPod قابلة للتوجيه أصلاً داخل VPC. يبقى حركة Pod-to-pod في بنية VPC بسرعة خط. التنازل: استنفاد عناوين IP — لكل عقدة حد صارم من ENIs وعناوين IP لكل ENI.
- Azure CNI / GKE Dataplane V2 — مكافئات خاصة بالسحابة لـAWS VPC CNI، تستخدم بنى VPC الخاصة بها.
فحص نموذج الشبكة من داخل الكلستر
عند الانضمام إلى كلستر جديد أو تشخيص مشكلة شبكية، تتمثل الخطوة الأولى في التحقق من أن النموذج يعمل بشكل صحيح. هذه الأوامر تُؤكد الأساسيات:
مساحة اسم شبكة الـPod
لكل Pod مساحة اسم شبكة Linux خاصة به: رؤية معزولة تماماً من واجهات الشبكة وجداول التوجيه وقواعد الجدار الناري. تُنشئ إضافة CNI زوج veth — كابل Ethernet افتراضي — حيث يعيش أحد طرفيه (eth0) داخل مساحة اسم الـPod والطرف الآخر على المضيف، مُوصَّلاً بجسر (عادةً cni0) أو مُبرمَج مباشرةً في جدول التوجيه. الحاويات داخل نفس الـPod تشارك تلك المساحة، وهذا هو سبب تواصلها عبر localhost وإمكانية تعارضها على المنافذ — إذ تشترك فعلاً في مكدس شبكة واحد.
فحص الأسلاك على العقدة
عندما يعطل شبكة Pod، تحتاج إلى النزول إلى العقدة للتحقق من الأسلاك. الأوامر التالية تمنحك رؤية كاملة لما وصّلته إضافة CNI:
m5.large تدعم 3 ENIs × 10 عناوين IP = 30 عنوان Pod IP كحد أقصى، مطروحاً منها عنوان IP للعقدة نفسها). سيفشل الجدولة بصمت مع الرسالة 0/3 nodes available: 3 Insufficient pods عند الوصول لهذا الحد. راقب kubectl describe node ← Allocatable.pods مقابل Non-terminated Pods. الحل: استخدام أنواع أجهزة أكبر، تفعيل prefix delegation (ENABLE_PREFIX_DELEGATION=true على VPC CNI)، أو الانتقال لإضافة CNI تدعم CIDRs الثانوية.لماذا يهم هذا لكل ما يليه
كل بنية شبكية رفيعة المستوى في كوبرنيتيس تفترض وجود النموذج المسطح. ClusterIP للخدمة هو عنوان IP افتراضي يستخدمه kube-proxy لتحويل الحزم إلى عناوين IP حقيقية للـPod — يعمل فقط لأن عناوين IP للـPod قابلة للتوجيه مباشرةً. تُطبَّق سياسات NetworkPolicy بواسطة إضافة CNI على مستوى Pod-to-pod — توجد فقط لأن هناك طبقة pod-to-pod لتطبيق القواعد عليها. وحدات التحكم في Ingress توجه الحركة إلى نقاط نهاية الـPod — مباشرةً، بدون NAT. اكتشاف الخدمة المستند إلى DNS يُعيد عناوين IP للـPod — وهي ذات معنى فقط لأن تلك العناوين يمكن الوصول إليها عالمياً.
عند مواجهة خدمة معطوبة، أو سياسة NetworkPolicy لا تُطبَّق، أو Ingress يُعيد 502، السؤال الأول دائماً هو: هل يمكن للـPod A الوصول إلى Pod B مباشرةً؟ إذا كانت الإجابة لا، فإن CNI معطوب ولن يعمل أي شيء فوقه. ابدأ من أسفل المكدس.