💺 ⛰️ 👨‍🍳 كيف تحصل pod في Kubernetes على عنوان IP 🧝🏻 🦖 👐🏻

تقريبا. ترجمة. : هذا المقال ، الذي كتبه مهندس SRE في LinkedIn ، يخوض في التفاصيل حول "السحر الداخلي" في Kubernetes - بتعبير أدق ، تفاعل CRI و CNI و kube-apiserver - ماذا يحدث عندما يحتاج جراب آخر إلى تخصيص عنوان IP.

أحد المتطلبات الأساسية لنموذج شبكة Kubernetes هو أن كل جراب يجب أن يكون له عنوان IP خاص به ، ويجب أن تكون كل حجرة أخرى في الكتلة قادرة على الاتصال بها على هذا العنوان. هناك العديد من "مزودي" الشبكات (Flannel ، Calico ، Canal ، إلخ) الذين يساعدون في تنفيذ نموذج الشبكة هذا.

عندما بدأت العمل مع Kubernetes لأول مرة ، لم يكن واضحًا تمامًا بالنسبة لي كيف تحصل البودات على عناوين IP الخاصة بها. حتى مع فهم كيفية عمل المكونات الفردية ، كان من الصعب تخيلها تعمل معًا. على سبيل المثال ، كنت أعرف ما هي مكونات CNI الإضافية ، لكن لم يكن لدي أي فكرة عن كيفية تسميتها. لذلك ، قررت أن أكتب هذه المقالة لمشاركة المعرفة حول مكونات الشبكات المختلفة وكيف تعمل معًا في مجموعة Kubernetes ، والتي تسمح لكل جراب بالحصول على عنوان IP الفريد الخاص به.

توجد طرق مختلفة لتنظيم الشبكات في Kubernetes ، تمامًا كما توجد خيارات وقت تشغيل مختلفة للحاويات. سيستخدم هذا المنشور Flannel للشبكات العنقودية و Containerd كوقت تشغيل . أنا أيضًا أنطلق من افتراض أنك تعرف كيف تعمل الشبكات بين الحاويات ، لذلك سأتطرق إليها لفترة وجيزة فقط من أجل السياق فقط.

بعض المفاهيم الأساسية

الحاويات والشبكات: نظرة عامة

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

حاويات على مضيف واحد

تتمثل إحدى طرق التواصل عبر عنوان IP بين الحاويات التي تعمل على نفس المضيف في إنشاء جسر Linux. لهذا الغرض ، يتم إنشاء أجهزة veth (إيثرنت افتراضية) في Kubernetes (و Docker ) . يتصل أحد طرفي جهاز veth بمساحة شبكة الحاوية ، بينما يتصل الآخر بجسر Linux على شبكة المضيف.

تحتوي جميع الحاويات الموجودة على نفس المضيف على طرف واحد من veth متصل بجسر يمكنهم من خلاله التواصل مع بعضهم البعض باستخدام عناوين IP. يحتوي جسر Linux أيضًا على عنوان IP ويعمل كبوابة لحركة مرور الخروج من القرون إلى العقد الأخرى.

حاويات على مضيفين مختلفين

يعد تغليف الحزم إحدى الطرق للسماح للحاويات الموجودة على مضيفين مختلفين بالتواصل مع بعضها البعض باستخدام عناوين IP. في Flannel ، تكون تقنية vxlan مسؤولة عن هذه الميزة ، والتي "تحزم" الحزمة الأصلية في حزمة UDP ثم ترسلها إلى وجهتها.

في مجموعة Kubernetes ، ينشئ Flannel جهاز vxlan ويزيد جدول التوجيه في كل عقدة وفقًا لذلك. تمر كل حزمة مخصصة لحاوية على مضيف مختلف عبر جهاز vxlan ويتم تغليفها في حزمة UDP. في الوجهة ، يتم استخراج الحزمة المتداخلة وإعادة توجيهها إلى الحجرة المطلوبة.

ملاحظة: هذه مجرد طريقة واحدة للتواصل بين الحاويات.

ما هو CRI؟

CRI (واجهة تشغيل الحاوية) هو مكون إضافي يسمح لـ kubelet باستخدام بيئات مختلفة لوقت تشغيل الحاوية. تم تضمين واجهة برمجة تطبيقات CRI في بيئات وقت تشغيل مختلفة ، بحيث يمكن للمستخدمين اختيار وقت التشغيل الذي يختارونه.

ما هو CNI؟

مشروع CNI هو مواصفات لتنظيم حل شبكات عالمي لحاويات Linux. بالإضافة إلى ذلك ، فهو يتضمن مكونات إضافية مسؤولة عن وظائف مختلفة عند إعداد شبكة pod. المكون الإضافي CNI هو ملف قابل للتنفيذ يتوافق مع المواصفات (سنناقش بعض المكونات الإضافية أدناه).

شبكات مضيفة لتعيين عناوين IP للبودات

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

جهاز تحكم IPAM المضيف

عند nodeipamتمريره كمعامل لعلامة --controllers kube-controller-manager ، فإنه يخصص شبكة فرعية منفصلة لكل عقدة (podCIDR) من مجموعة CIDR (أي نطاق عناوين IP لشبكة الكتلة). نظرًا لأن podCIDRs لا تتداخل ، يصبح من الممكن لكل جراب تعيين عنوان IP فريد.

يتم تعيين podCIDR لعقدة Kubernetes عند تسجيلها لأول مرة مع المجموعة. لتغيير podCIDR للعقد ، تحتاج إلى إلغاء تسجيلها ثم إعادة تسجيلها ، في غضون ذلك ، إجراء التغييرات المناسبة على تكوين طبقة التحكم Kubernetes. يمكنك عرض podCIDR للعقدة باستخدام الأمر التالي:

$ kubectl get no <nodeName> -o json | jq '.spec.podCIDR'
10.244.0.0/24

Kubelet و Container Launcher و CNI plugins: كيف يعمل كل شيء

تتضمن جدولة جراب لكل عقدة العديد من الخطوات التحضيرية. في هذا القسم ، سأركز فقط على تلك المرتبطة مباشرة بشبكات البودات.

تؤدي جدولة حجرة إلى عقدة إلى تشغيل سلسلة الأحداث التالية:

التعليمات: Containerd CRI Plugin Architecture .

التفاعل بين قاذفة الحاوية ومكونات CNI

كل مزود شبكة لديه المكون الإضافي CNI الخاص به. يقوم وقت تشغيل الحاوية بتشغيله لتكوين الشبكة للحافظة عند بدء تشغيلها. في حالة containerd ، يكون المكون الإضافي Containerd CRI مسؤولاً عن تشغيل المكون الإضافي CNI .

علاوة على ذلك ، لكل مزود وكيله الخاص. يتم تثبيته على جميع عقد Kubernetes وهو مسؤول عن توصيل الكبسولات. يأتي هذا العامل إما مع تكوين CNI ، أو يقوم بإنشائه على العقدة نفسها. يساعد التكوين المكون الإضافي CRI في تحديد المكون الإضافي CNI الذي يجب الاتصال به.

يمكن تخصيص موقع تكوين CNI ؛ بشكل افتراضي تكمن فيه /etc/cni/net.d/<config-file>. مسؤولو الكتلة مسؤولون أيضًا عن تثبيت مكونات CNI الإضافية على كل عقدة نظام مجموعة. موقعهم قابل للتخصيص أيضًا ؛ الدليل الافتراضي هو /opt/cni/bin.

عند استخدام containerd ، يمكن تعيين مسارات ثنائيات التكوين والمكونات الإضافية في قسم [plugins.«io.containerd.grpc.v1.cri».cni]في ملف تكوين containerd .

نظرًا لأننا نستخدم Flannel كمزود للشبكة ، فلنتحدث قليلاً عن إعداده:

عادة يتم تثبيت Flanneld (Flannel'a الخفي) في الكتلة كما هو الحال مع DaemonSet install-cniكما الحرف الأول حاوية .
Install-cniينشئ ملف تكوين CNI ( /etc/cni/net.d/10-flannel.conflist) على كل عقدة.
ينشئ Flanneld جهاز vxlan ، ويجلب البيانات الوصفية للشبكة من خادم API ، ويراقب تحديثات البود. أثناء إنشائها ، توزع المسارات لجميع القرون في جميع أنحاء الكتلة.
تسمح هذه المسارات للقرون بالتواصل مع بعضها البعض باستخدام عناوين IP.

لمزيد من المعلومات حول كيفية عمل Flannel ، أوصي باستخدام الروابط الموجودة في نهاية المقالة.

فيما يلي رسم تخطيطي للتفاعل بين المكون الإضافي Containerd CRI والمكونات الإضافية CNI:

كما ترى أعلاه ، يستدعي kubelet المكون الإضافي Containerd CRI لإنشاء pod ، والذي يستدعي بالفعل المكون الإضافي CNI لتكوين شبكة pod. عند القيام بذلك ، يستدعي المكون الإضافي CNI الخاص بموفر الشبكة ملحقات CNI الأساسية الأخرى لتكوين جوانب مختلفة من الشبكة.

التفاعل بين المكونات الإضافية CNI

هناك العديد من المكونات الإضافية لـ CNI المصممة للمساعدة في إعداد الشبكات بين الحاويات على مضيف. ستركز هذه المقالة على ثلاثة منهم.

البرنامج المساعد الفانيل CNI

عند استخدام Flannel كموفر للشبكة ، يستدعي مكون Containerd CRI المكون الإضافي Flannel CNI باستخدام ملف تكوين CNI /etc/cni/net.d/10-flannel.conflist.

$ cat /etc/cni/net.d/10-flannel.conflist
{
  "name": "cni0",
  "plugins": [
    {
      "type": "flannel",
      "delegate": {
         "ipMasq": false,
        "hairpinMode": true,
        "isDefaultGateway": true
      }
    }
  ]
}

يعمل المكون الإضافي Flannel CNI جنبًا إلى جنب مع Flanneld. عند بدء التشغيل ، يستخرج Flanneld podCIDR والتفاصيل الأخرى المتعلقة بالشبكة من خادم API ويحفظها في ملف /run/flannel/subnet.env.

FLANNEL_NETWORK=10.244.0.0/16 
FLANNEL_SUBNET=10.244.0.1/24
FLANNEL_MTU=1450 
FLANNEL_IPMASQ=false

يستخدم المكون الإضافي Flannel CNI البيانات من /run/flannel/subnet.envلتكوين واستدعاء المكون الإضافي لـ bridge CNI.

جسر البرنامج المساعد CNI

يتم استدعاء هذا المكون الإضافي بالتكوين التالي:

{
  "name": "cni0",
  "type": "bridge",
  "mtu": 1450,
  "ipMasq": false,
  "isGateway": true,
  "ipam": {
    "type": "host-local",
    "subnet": "10.244.0.0/24"
  }
}

في الاستدعاء الأول ، يقوم بإنشاء جسر Linux به «name»: «cni0»، والذي يشار إليه في ملف config. ثم يتم إنشاء زوج من veth لكل جراب. يتصل أحد الطرفين بمساحة اسم الشبكة الخاصة بالحاوية ، بينما يتصل الآخر بجسر Linux على شبكة المضيف. يربط المكون الإضافي CNI Bridge جميع حاويات المضيف بجسر Linux على الشبكة المضيفة.

عند الانتهاء من تكوين زوج veth ، يستدعي المكوِّن الإضافي Bridge المكوِّن الإضافي المضيف المحلي CNI IPAM. يمكن تكوين نوع المكون الإضافي IPAM في تكوين CNI ، والذي يستخدمه المكون الإضافي CRI لاستدعاء المكون الإضافي Flannel CNI.

ملحقات IPAM CNI للمضيف المحلي

يستدعي Bridge CNI المكوّن الإضافي IPAM CNI للمضيف المحلي مع التكوين التالي:

{
  "name": "cni0",
  "ipam": {
    "type": "host-local",
    "subnet": "10.244.0.0/24",
    "dataDir": "/var/lib/cni/networks"
  }
}

المضيف المحلي IPAM-plug ( IP A ddress M anagement - IP-address management) يعيد عنوان IP للشبكة الفرعية للحاوية ويخزن عنوان IP المحدد في المضيف في الدليل المحدد في القسم dataDir- /var/lib/cni/networks/<network-name=cni0>/<ip>. يحتوي هذا الملف على معرف الحاوية التي تم تعيين عنوان IP هذا.

عندما يتم استدعاء المكون الإضافي IPAM المضيف المحلي ، فإنه يقوم بإرجاع البيانات التالية:

{
  "ip4": {
    "ip": "10.244.4.2",
    "gateway": "10.244.4.3"
  },
  "dns": {}
}

ملخص

يقوم Kube-controller-manager بتعيين podCIDR لكل عقدة. تحصل قرون كل عقدة على عناوين IP من مساحة العنوان في نطاق podCIDR المخصص. نظرًا لأن podCIDRs الخاصة بالعقد لا تتداخل ، فإن جميع البودات تتلقى عناوين IP فريدة.

يقوم مسئول مجموعة Kubernetes بتكوين وتثبيت kubelet ومشغل الحاوية ووكيل مزود الشبكة ونسخ مكونات CNI الإضافية إلى كل عقدة. أثناء بدء التشغيل ، يقوم وكيل موفر الشبكة بإنشاء تكوين CNI. عندما تتم جدولة pod لعقد ما ، يستدعي kubelet البرنامج المساعد CRI لإنشائه. علاوة على ذلك ، إذا تم استخدام containerd ، فإن المكون الإضافي Containerd CRI يستدعي المكون الإضافي CNI المحدد في تكوين CNI لتكوين شبكة pod. هذا يعطي الكبسولة عنوان IP.

لقد استغرق الأمر مني بعض الوقت لفهم كل التفاصيل الدقيقة والفروق الدقيقة لكل هذه التفاعلات. آمل أن تساعدك الخبرة المكتسبة على فهم كيفية عمل Kubernetes بشكل أفضل. إذا كنت مخطئًا بشأن أي شيء ، فيرجى الاتصال بي على Twitter أو على hello@ronaknathani.com . لا تتردد في الاتصال إذا كنت ترغب في مناقشة جوانب هذه المقالة أو أي شيء آخر. سأكون سعيدا للتحدث معك!

كيف تحصل pod في Kubernetes على عنوان IP