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

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

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

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

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

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

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

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

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

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

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

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

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

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

ملاحظة: هذه فقط إحدى طرق تنظيم الشبكات بين الحاويات.

ما هو CRI؟

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

ما هو CNI؟

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

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

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

وحدة تحكم Node IPAM

عندما nodeipam تم تمريره كمعامل علم --controllers مدير تحكم kube، فإنه يخصص لكل عقدة شبكة فرعية منفصلة (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 runtime و CNI plugins: كيف يعمل كل شيء

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

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

أسئلة وأجوبة: هندسة البرنامج المساعد للحاويات CRI.

التفاعل بين وقت تشغيل الحاوية ومكونات CNI الإضافية

كل مزود شبكة لديه المكون الإضافي CNI الخاص به. يقوم وقت تشغيل الحاوية بتشغيلها لتهيئة الشبكة للحجرة عند بدء تشغيلها. في حالة containerd ، يتم تشغيل المكون الإضافي CNI بواسطة المكون الإضافي كونتيند سي..

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

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

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

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

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

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

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

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

التفاعل بين الإضافات CNI

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

المكون الإضافي Flannel 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»، والذي تم تحديده في ملف التكوين. ثم يتم إنشاء زوج من veth لكل جراب. يتصل أحد الطرفين بمساحة شبكة الحاوية ، ويتصل الطرف الآخر بجسر Linux على شبكة المضيف. المكون الإضافي جسر CNI يربط جميع حاويات المضيف بجسر Linux على الشبكة المضيفة.

عندما يتم تكوين زوج veth ، يستدعي المكون الإضافي Bridge المكوّن الإضافي IPAM CNI للمضيف المحلي. يمكن تكوين نوع المكون الإضافي 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 (IP Address Management - إدارة عنوان IP) يُرجع عنوان 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 بشكل أفضل. إذا كنت مخطئًا بشأن أي شيء ، فيرجى الاتصال بي على تويتر أو في العنوان [البريد الإلكتروني محمي]. لا تتردد في التواصل معي إذا كنت ترغب في مناقشة جوانب هذه المقالة أو أي شيء آخر. سأكون سعيدا للدردشة معك!

مراجع

الحاويات والشبكة

كيف يعمل الفانيلا

CRI و CNI

PS من المترجم

اقرأ أيضًا على مدونتنا:

«كاليكو للتواصل في Kubernetes: مقدمة وقليل من الخبرة"؛
"دليل مصور للتواصل في Kubernetes": الأجزاء 1 و 2 (نموذج الشبكة ، شبكات التراكب), الجزء 3 (الخدمات ومعالجة المرور);
«واجهة شبكة الحاويات (CNI) - واجهة شبكة ومعيار لحاويات Linux".

المصدر: www.habr.com

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