Как под в Kubernetes получава IP адрес

Забележка. превод: Тази статия, написана от инженер на SRE в LinkedIn, описва подробно „вътрешната магия“ в Kubernetes – по-точно взаимодействието между CRI, CNI и kube-apiserver – какво се случва, когато на следващия pod трябва да бъде присвоен IP адрес.

Едно от основните изисквания Мрежов модел на Kubernetes е, че всеки pod трябва да има свой собствен IP адрес и всеки друг pod в клъстера трябва да може да се свързва с него на този адрес. Има много мрежови "доставчици" (Flannel, Calico, Canal и т.н.), които помагат за прилагането на този мрежов модел.

Когато за първи път започнах да работя с Kubernetes, не ми беше напълно ясно как точно pods получават своите IP адреси. Дори и с разбирането за това как функционират отделните компоненти, беше трудно да си ги представим да работят заедно. Например, знаех за какво са CNI добавките, но нямах представа как точно се наричат. Затова реших да напиша тази статия, за да споделя знания за различните мрежови компоненти и как те работят заедно в клъстер на Kubernetes, което позволява на всеки pod да получи свой собствен уникален IP адрес.

Има различни начини за организиране на работа в мрежа в Kubernetes - точно като различните опции за изпълнение на контейнери. Тази публикация ще използва бархет за работа в мрежа в клъстер и като изпълнима среда - Контейнер. Предполагам също, че знаете как работи работата в мрежа между контейнери, така че ще го засегна само накратко, чисто за контекст.

Някои основни понятия

Контейнери и мрежи с един поглед

В мрежата има доста отлични публикации, обясняващи как контейнерите комуникират помежду си по мрежата. Затова ще дам само общ преглед на основните концепции и ще се огранича до един подход, който включва създаване на Linux мост и капсулиране на пакети. Подробностите са пропуснати, тъй като самата тема за мрежовия контейнер заслужава отделна статия. По-долу ще бъдат предоставени връзки към някои особено информативни и информативни публикации.

Контейнери на същия хост

Един от начините за организиране на IP адресна комуникация между контейнери, работещи на един и същ хост, включва създаването на Linux мост. За целта Kubernetes (и Docker) създават виртуални устройства veth (виртуален Ethernet). Единият край на veth устройството се свързва към мрежовото пространство на имената на контейнера, а другият край се свързва към Linux мост в хост мрежата.

Всички контейнери на един и същ хост имат един край на veth, свързан към мост, чрез който могат да комуникират помежду си чрез IP адреси. Мостът на Linux също има IP адрес и действа като шлюз за изходящ (изходящ) трафик от подове, предназначени за други възли.

Контейнери на различни хостове

Капсулирането на пакети е един от начините, по който контейнерите на различни хостове могат да комуникират помежду си, използвайки IP адреси. Във Flannel технологията е това, което прави това възможно. vxlan, който "опакова" пакета източник в UDP пакет и след това го изпраща до местоназначението му.

В клъстер на Kubernetes Flannel създава vxlan устройство и съответно актуализира таблицата с маршрути на всеки възел. Всеки пакет, предназначен за контейнер на друг хост, преминава през vxlan устройството и се капсулира в UDP пакет. На местоназначението вложеният пакет се извлича и пренасочва към правилния pod.

Забележка: Това е само един от начините за организиране на работа в мрежа между контейнери.

Какво е CRI?

CRI (Интерфейс за изпълнение на контейнери) е плъгин, който позволява на kubelet да използва различни изпълнения на контейнери. CRI API е вграден в различни среди за изпълнение, така че потребителите могат да избират времето за изпълнение, което искат.

Какво е CNI?

CNI проект е a спецификация да организира универсално мрежово решение за Linux контейнери. Освен това включва плъгини, които отговарят за различни функции при настройка на мрежата на pod. CNI плъгинът е изпълним файл, който отговаря на спецификацията (ще обсъдим някои от плъгините по-долу).

Подмрежови хостове за присвояване на IP адреси на подс

Тъй като всеки под в клъстера трябва да има IP адрес, важно е да се уверите, че този адрес е уникален. Това се постига чрез присвояване на всеки възел на уникална подмрежа, от която на подовете в този възел след това се присвояват IP адреси.

Възел IPAM контролер

Когато nodeipam предадено като флагов параметър --controllers kube-контролер-мениджър, той разпределя на всеки възел отделна подмрежа (podCIDR) от CIDR клъстера (т.е. диапазона от IP адреси за клъстерната мрежа). Тъй като тези podCIDR не се припокриват, става възможно на всеки pod да бъде присвоен уникален IP адрес.

На възел на Kubernetes се присвоява podCIDR, когато се регистрира за първи път в клъстера. За да промените podCIDR на възлите, трябва да ги дерегистрирате и след това да ги регистрирате отново, като направите съответните промени в конфигурацията на контролния слой на Kubernetes между тях. Можете да покажете podCIDR на възел със следната команда:

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

Kubelet, среда за изпълнение на контейнери и CNI добавки: как работи всичко

Планирането на под към възел включва извършването на много подготвителна работа. В този раздел ще се съсредоточа само върху тези, които са пряко свързани с настройката на мрежата на pod.

Планирането на под към възел задейства следната верига от събития:

Помощ: Контейнерна CRI плъгин архитектура.

Взаимодействие между време за изпълнение на контейнер и CNI добавки

Всеки мрежов доставчик има свой собствен CNI плъгин. Средата за изпълнение на контейнера го изпълнява, за да конфигурира мрежата за pod, когато се стартира. В случай на контейнер CNI плъгинът се стартира от плъгина Контейнер C.R.I..

Освен това всеки доставчик има свой агент. Той е инсталиран във всички възли на Kubernetes и отговаря за мрежовата конфигурация на подовете. Този агент или идва в пакет с CNI конфигурацията, или го създава самостоятелно на възела. Конфигурацията помага на CRI плъгина да определи кой CNI плъгин да извика.

Местоположението на CNI конфигурацията може да бъде персонализирано; по подразбиране е в /etc/cni/net.d/<config-file>. Клъстерните администратори също са отговорни за инсталирането на CNI добавки на всеки клъстерен възел. Тяхното местоположение също може да се конфигурира; директория по подразбиране - /opt/cni/bin.

Когато използвате контейнер, пътищата за двоичните файлове на конфигурацията и приставката могат да бъдат зададени в секцията [plugins.«io.containerd.grpc.v1.cri».cni] в конфигурационен файл на контейнера.

Тъй като използваме Flannel като наш мрежов доставчик, нека поговорим малко за настройката му:

• Flanneld (демонът на Flannel) обикновено се инсталира в клъстер като DaemonSet с install-cni като init контейнер.
• Install-cni създава CNI конфигурационен файл (/etc/cni/net.d/10-flannel.conflist) във всеки възел.
• Flanneld създава vxlan устройство, извлича мрежови метаданни от API сървъра и следи актуализациите на pod. Докато се създават, той разпространява маршрути до всички подове в целия клъстер.
• Тези маршрути позволяват на модулите да комуникират помежду си чрез IP адреси.

За повече информация относно работата на Flannel препоръчвам да използвате връзките в края на статията.

Ето диаграмата на взаимодействие между приставката Containerd CRI и приставките CNI:

Както се вижда по-горе, kubelet извиква приставката Containerd CRI, за да създаде под, който вече извиква приставката CNI, за да настрои мрежата на под. В този случай CNI плъгинът на мрежовия доставчик извиква други основни CNI плъгини, за да конфигурират различни аспекти на мрежата.

Взаимодействие между CNI добавки

Има различни CNI плъгини, чиято задача е да помогнат за настройване на мрежова комуникация между контейнери на хоста. Тази статия ще обсъди три от тях.

Flannel CNI плъгин

Когато използвате Flannel като мрежов доставчик, компонентът Container 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 плъгина.

Bridge 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 мост в мрежата на хоста. Bridge CNI плъгин свързва всички хост контейнери към Linux мост в хост мрежата.

След като двойката veth е конфигурирана, приставката Bridge извиква приставката IPAM CNI на локалния хост. Типът приставка IPAM може да бъде конфигуриран в конфигурацията на CNI, която приставката CRI използва за извикване на приставката Flannel CNI.

Хост-локални IPAM CNI добавки

Мостови CNI разговори хост-локален IPAM CNI плъгин със следната конфигурация:

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

Хост-локален IPAM плъгин (IP Aс адреси 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 конфигурация. Когато под е планиран към възел, kubelet извиква приставката CRI, за да го създаде. След това, ако се използва контейнер, приставката Containerd CRI извиква приставката CNI, посочена в конфигурацията на CNI, за да настрои мрежата на pod. В резултат на това подът получава IP адрес.

Отне ми известно време, за да разбера всички тънкости и нюанси на всички тези взаимодействия. Надявам се, че натрупаният опит ще ви помогне да разберете по-добре как работи Kubernetes. Ако греша за нещо, моля свържете се с мен на Twitter или на адрес [имейл защитен]. Чувствайте се свободни да се свържете, ако искате да обсъдите аспекти на тази статия или нещо друго. Ще се радвам да си поговорим!

Позоваването

Контейнери и мрежа

• Преглед на контейнерна мрежа
• Демистифициране на мрежата от контейнери

Как действа фланелът

• Flannel Networking Demystify
• Kubernetes с фланел – разбиране на работата в мрежа

CRI и CNI

• CRI плъгин архитектура
• CNI спец
• CNI плъгини

PS от преводача

Прочетете също в нашия блог:

• «Calico за работа в мрежа в Kubernetes: въведение и малко опит»;
• „Илюстровано ръководство за работа в мрежа в Kubernetes“: части 1 и 2 (мрежов модел, мрежи с наслагване), част 3 (услуги и обработка на трафик);
• «Container Networking Interface (CNI) - мрежов интерфейс и стандарт за Linux контейнери".

Източник: www.habr.com