🥇چگونه یک غلاف Kubernetes یک آدرس IP دریافت می کند

توجه داشته باشید. ترجمه: این مقاله که توسط یک مهندس SRE از LinkedIn نوشته شده است، به جزئیات در مورد جادوی درونی Kubernetes می پردازد - به طور دقیق تر، تعامل CRI، CNI و kube-apiserver - که زمانی اتفاق می افتد که به pod بعدی نیاز به تخصیص آدرس IP باشد.

یکی از الزامات اساسی مدل شبکه Kubernetes این است که هر پاد باید آدرس IP مخصوص به خود را داشته باشد و هر پاد دیگری در کلاستر باید بتواند در آن آدرس با آن تماس بگیرد. بسیاری از "ارائه دهندگان" شبکه (Flannel، Calico، Canal، و غیره) وجود دارند که به پیاده سازی این مدل شبکه کمک می کنند.

وقتی برای اولین بار کار با Kubernetes را شروع کردم، برای من کاملاً مشخص نبود که پادها دقیقاً چگونه آدرس IP خود را دریافت می کنند. حتی با درک نحوه عملکرد اجزای جداگانه، تصور اینکه آنها با هم کار کنند دشوار بود. برای مثال، من می‌دانستم که پلاگین‌های CNI برای چه هستند، اما نمی‌دانستم دقیقاً چگونه نامیده می‌شوند. بنابراین، تصمیم گرفتم این مقاله را بنویسم تا دانشی در مورد اجزای مختلف شبکه و نحوه کار آنها با یکدیگر در یک خوشه Kubernetes به اشتراک بگذارم، که به هر پاد اجازه می دهد آدرس IP منحصر به فرد خود را دریافت کند.

راه های مختلفی برای سازماندهی شبکه در Kubernetes وجود دارد، درست مانند گزینه های زمان اجرا متفاوت برای کانتینرها. این نشریه استفاده خواهد کرد فلنج برای سازماندهی یک شبکه در یک خوشه، و به عنوان یک محیط اجرایی - ظرف. من همچنین این فرض را می‌کنم که شما می‌دانید شبکه‌سازی بین کانتینرها چگونه کار می‌کند، بنابراین به طور خلاصه به آن اشاره می‌کنم، فقط برای زمینه.

چند مفهوم اساسی

کانتینرها و شبکه: مروری کوتاه

تعداد زیادی نشریه عالی در اینترنت وجود دارد که نحوه ارتباط کانتینرها با یکدیگر از طریق شبکه را توضیح می دهد. بنابراین، من فقط یک نمای کلی از مفاهیم اساسی ارائه می‌دهم و خودم را به یک رویکرد محدود می‌کنم، که شامل ایجاد یک پل لینوکس و کپسوله‌سازی بسته‌ها است. جزئیات حذف شده است، زیرا موضوع شبکه کانتینر خود مستحق یک مقاله جداگانه است. پیوندهایی به برخی از نشریات ویژه و آموزشی در زیر ارائه خواهد شد.

کانتینرها روی یک میزبان

یکی از راه‌های سازماندهی ارتباط از طریق آدرس‌های IP بین کانتینرهایی که روی همان میزبان اجرا می‌شوند، ایجاد یک پل لینوکس است. برای این منظور، دستگاه های مجازی در Kubernetes (و Docker) ایجاد می شوند. veth (اترنت مجازی). یک سر دستگاه veth به فضای نام شبکه کانتینر متصل می شود، سر دیگر به فضای نام شبکه پل لینوکس در شبکه میزبان

همه کانتینرهای موجود در یک میزبان یک انتهای دهانه متصل به یک پل دارند که از طریق آن می توانند از طریق آدرس های IP با یکدیگر ارتباط برقرار کنند. پل لینوکس همچنین دارای یک آدرس IP است و به عنوان دروازه ای برای ترافیک خروجی از پادهای مقصد برای سایر گره ها عمل می کند.

کانتینرها روی میزبان های مختلف

بسته بندی بسته روشی است که به کانتینرهای گره های مختلف اجازه می دهد تا با استفاده از آدرس های IP با یکدیگر ارتباط برقرار کنند. در Flannel، فناوری مسئول این فرصت است. vxlan، که بسته اصلی را در یک بسته UDP "بسته بندی" می کند و سپس آن را به مقصد می فرستد.

در یک خوشه Kubernetes، Flannel یک دستگاه vxlan ایجاد می کند و جدول مسیر را در هر گره متناسب با آن به روز می کند. هر بسته ای که برای یک کانتینر در یک میزبان متفاوت است از دستگاه vxlan عبور می کند و در یک بسته UDP محصور می شود. در مقصد، بسته تودرتو استخراج شده و به غلاف مورد نظر ارسال می شود.

توجه: این تنها یک راه برای سازماندهی ارتباطات شبکه بین کانتینرها است.

CRI چیست؟

CRI (رابط زمان اجرای کانتینر) افزونه ای است که به Kubelet اجازه می دهد تا از محیط های زمان اجرا کانتینر مختلف استفاده کند. CRI API در زمان‌های اجرا مختلف تعبیه شده است، بنابراین کاربران می‌توانند زمان اجرا مورد نظر خود را انتخاب کنند.

CNI چیست؟

پروژه CNI یک است مشخصات برای سازماندهی یک راه حل شبکه جهانی برای کانتینرهای لینوکس. علاوه بر این، شامل پلاگین ها، در هنگام راه اندازی یک شبکه پاد، وظایف مختلفی را بر عهده دارد. افزونه CNI یک فایل اجرایی است که با مشخصات مطابقت دارد (در زیر به برخی از افزونه ها خواهیم پرداخت).

تخصیص زیرشبکه ها به گره ها برای تخصیص آدرس های IP به پادها

از آنجایی که هر پاد در یک کلاستر باید یک آدرس IP داشته باشد، مهم است که اطمینان حاصل شود که این آدرس منحصر به فرد است. این امر با تخصیص به هر گره یک زیرشبکه منحصربفرد حاصل می‌شود که از آن آدرس‌های IP به پادهای آن گره اختصاص داده می‌شود.

Node IPAM Controller

وقتی که nodeipam به عنوان یک پارامتر پرچم ارسال شد --controllers kube-controller-manager، یک زیرشبکه جداگانه (podCIDR) به هر گره از CIDR خوشه (یعنی محدوده آدرس های IP برای شبکه خوشه) اختصاص می دهد. از آنجایی که این podCIDR ها با هم همپوشانی ندارند، این امکان وجود دارد که به هر پاد یک آدرس IP منحصر به فرد اختصاص داده شود.

یک گره Kubernetes زمانی که در ابتدا در خوشه ثبت می شود، یک podCIDR اختصاص می یابد. برای تغییر podCIDR گره‌ها، باید آن‌ها را لغو ثبت کنید و سپس مجدداً ثبت کنید، و در این بین تغییرات مناسبی در پیکربندی لایه کنترل Kubernetes ایجاد کنید. با استفاده از دستور زیر می توانید podCIDR یک گره را نمایش دهید:

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

Kubelet، Container Runtime و پلاگین های CNI: چگونه کار می کند

برنامه ریزی یک غلاف در هر گره شامل مراحل آماده سازی زیادی است. در این بخش فقط به مواردی می پردازم که مستقیماً با راه اندازی یک شبکه پاد مرتبط هستند.

زمان‌بندی یک غلاف برای یک گره خاص، زنجیره‌ای از رویدادهای زیر را آغاز می‌کند:

راهنما: معماری پلاگین های Containerd CRI.

تعامل بین زمان اجرا کانتینر و پلاگین های CNI

هر ارائه دهنده شبکه پلاگین CNI خود را دارد. زمان اجرا کانتینر آن را اجرا می کند تا شبکه را برای پاد هنگام راه اندازی پیکربندی کند. در مورد کانتینر، پلاگین CNI توسط افزونه راه اندازی می شود کانتینر CRI.

علاوه بر این، هر ارائه دهنده نماینده خود را دارد. بر روی تمام گره های Kubernetes نصب شده است و مسئولیت پیکربندی شبکه pods را بر عهده دارد. این عامل یا با پیکربندی CNI گنجانده شده است یا به طور مستقل آن را روی گره ایجاد می کند. این پیکربندی به پلاگین CRI کمک می کند تا تعیین کند که کدام افزونه CNI را فراخوانی کند.

محل پیکربندی CNI را می توان سفارشی کرد. به طور پیش فرض در است /etc/cni/net.d/<config-file>. مدیران کلاستر همچنین مسئول نصب پلاگین های CNI در هر گره خوشه هستند. مکان آنها نیز قابل تنظیم است. دایرکتوری پیش فرض - /opt/cni/bin.

هنگام استفاده از Containerd، مسیرهای پیکربندی افزونه و باینری ها را می توان در بخش تنظیم کرد [plugins.«io.containerd.grpc.v1.cri».cni] в فایل پیکربندی کانتینر.

از آنجایی که ما از Flannel به عنوان ارائه دهنده شبکه خود استفاده می کنیم، اجازه دهید کمی در مورد راه اندازی آن صحبت کنیم:

Flanneld (شیب فلانل) معمولاً در یک خوشه به عنوان DaemonSet با install-cni مانند ظرف اولیه.
Install-cni ایجاد می کند فایل پیکربندی CNI (/etc/cni/net.d/10-flannel.conflist) روی هر گره.
Flanneld یک دستگاه vxlan ایجاد می کند، ابرداده های شبکه را از سرور API بازیابی می کند و به روز رسانی های پاد را نظارت می کند. همانطور که آنها ایجاد می شوند، مسیرها را به همه غلاف ها در سراسر خوشه توزیع می کند.
این مسیرها به پادها اجازه می دهند تا از طریق آدرس های IP با یکدیگر ارتباط برقرار کنند.

برای اطلاعات دقیق تر در مورد کار فلانل، توصیه می کنم از پیوندهای انتهای مقاله استفاده کنید.

در اینجا نموداری از تعامل بین پلاگین Containerd CRI و پلاگین های CNI آورده شده است:

همانطور که در بالا می بینید، kubelet برای ایجاد پاد، پلاگین Containerd CRI را فراخوانی می کند، که سپس پلاگین CNI را برای پیکربندی شبکه پاد فراخوانی می کند. با انجام این کار، پلاگین CNI ارائه دهنده شبکه، سایر پلاگین های اصلی CNI را برای پیکربندی جنبه های مختلف شبکه فراخوانی می کند.

تعامل بین پلاگین های CNI

پلاگین های مختلف CNI وجود دارد که وظیفه آنها کمک به راه اندازی ارتباط شبکه بین کانتینرها در هاست است. این مقاله سه مورد از آنها را مورد بحث قرار خواهد داد.

پلاگین CNI Flannel

هنگام استفاده از Flannel به عنوان یک ارائه دهنده شبکه، مؤلفه Containerd CRI تماس می گیرد پلاگین CNI Flannelبا استفاده از فایل پیکربندی 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 برای پیکربندی و فراخوانی پلاگین CNI bridge.

پلاگین CNI Bridge

این افزونه با تنظیمات زیر فراخوانی می شود:

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

هنگامی که برای اولین بار فراخوانی می شود، یک پل لینوکس با آن ایجاد می کند «name»: «cni0»، که در تنظیمات نشان داده شده است. سپس یک جفت veth برای هر غلاف ایجاد می شود. یک سر آن به فضای نام شبکه کانتینر متصل است، دیگری در پل لینوکس در شبکه میزبان گنجانده شده است. پلاگین CNI Bridge همه کانتینرهای میزبان را به یک پل لینوکس در شبکه میزبان متصل می کند.

پس از اتمام راه‌اندازی جفت veth، افزونه Bridge افزونه IPAM CNI میزبان-محلی را فراخوانی می‌کند. نوع پلاگین IPAM را می توان در پیکربندی CNI که پلاگین CRI برای فراخوانی افزونه Flannel CNI استفاده می کند، پیکربندی کرد.

پلاگین های میزبان محلی IPAM CNI

تماس های CNI بریج CNI پلاگین IPAM میزبان محلی با پیکربندی زیر:

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

پلاگین IPAM میزبان محلی (IP Address Mمدیریت - مدیریت آدرس 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 دریافت می کنند. از آنجایی که podCIDR های گره ها همپوشانی ندارند، همه پادها آدرس های IP منحصر به فردی را دریافت می کنند.

مدیر خوشه Kubernetes، kubelet، زمان اجرا کانتینر، عامل ارائه دهنده شبکه را پیکربندی و نصب می کند و پلاگین های CNI را در هر گره کپی می کند. در طول راه اندازی، عامل ارائه دهنده شبکه یک پیکربندی CNI را ایجاد می کند. هنگامی که یک pod برای یک گره برنامه ریزی می شود، kubelet پلاگین CRI را برای ایجاد آن فراخوانی می کند. در مرحله بعد، در صورت استفاده از Containerd، افزونه Containerd CRI، افزونه CNI مشخص شده در پیکربندی CNI را برای پیکربندی شبکه غلاف فراخوانی می‌کند. در نتیجه، پاد یک آدرس IP دریافت می کند.

مدتی طول کشید تا تمام ظرافت ها و ظرایف همه این تعاملات را درک کنم. امیدوارم این تجربه به شما در درک بهتر نحوه عملکرد Kubernetes کمک کند. اگر در مورد چیزی اشتباه می کنم، لطفا با من تماس بگیرید توییتر یا در آدرس [ایمیل محافظت شده]. اگر مایلید در مورد جنبه های این مقاله یا هر چیز دیگری صحبت کنید، با خیال راحت تماس بگیرید. من دوست دارم با شما چت کنم!

مراجع

کانتینرها و شبکه

فلانل چگونه کار می کند؟

CRI و CNI

PS از مترجم

در وبلاگ ما نیز بخوانید:

«Calico برای شبکه سازی در Kubernetes: مقدمه و کمی تجربه"؛
"راهنمای مصور برای شبکه سازی در Kubernetes": بخش 1 و 2 (مدل شبکه، شبکه های همپوشانی), بخش 3 (خدمات و پردازش ترافیک);
«رابط شبکه کانتینر (CNI) - رابط شبکه و استاندارد برای کانتینرهای لینوکس'.

منبع: www.habr.com

چگونه یک غلاف Kubernetes یک آدرس IP دریافت می کند؟