Како pod Kubernetes добива IP адреса?

Забелешка. превод.: Оваа статија, напишана од инженер на SRE од LinkedIn, детално ги опфаќа внатрешната магија во Kubernetes - поточно, интеракцијата на CRI, CNI и kube-apiserver - што се случува кога на следниот pod треба да му се додели IP адреса.

Еден од основните барања Модел на мрежа Кубернетес е дека секој pod мора да има своја IP адреса и кој било друг pod во кластерот мора да може да го контактира на таа адреса. Има многу мрежни „провајдери“ (Flannel, Calico, Canal итн.) кои помагаат во имплементацијата на овој мрежен модел.

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

Постојат различни начини за организирање на вмрежување во Kubernetes, исто како што постојат различни опции за траење за контејнери. Оваа публикација ќе користи Фланел да организира мрежа во кластер и како извршна средина - Контејнер. Исто така, претпоставувам дека знаете како функционира вмрежувањето помеѓу контејнерите, па ќе го допрам само накратко, само за контекст.

Некои основни концепти

Контејнерите и мрежата: Краток преглед

Има многу одлични публикации на Интернет кои објаснуваат како контејнерите комуницираат едни со други преку мрежата. Затоа, ќе дадам само општ преглед на основните концепти и ќе се ограничам на еден пристап, кој вклучува создавање на мост за Linux и капсулирање на пакети. Деталите се испуштени, бидејќи самата тема за вмрежување на контејнери заслужува посебна статија. Подолу ќе бидат дадени линкови до некои особено проникливи и едукативни публикации.

Контејнери на еден домаќин

Еден начин да се организира комуникација преку IP адреси помеѓу контејнерите што работат на истиот хост вклучува создавање на Линукс мост. За таа цел, виртуелните уреди се креирани во Kubernetes (и Docker) veth (виртуелен етернет). Едниот крај на уредот veth се поврзува со мрежниот именски простор на контејнерот, другиот со Линукс мост на мрежата домаќин.

Сите контејнери на ист хост имаат едниот крај на ветот поврзан со мост преку кој можат да комуницираат меѓу себе преку IP адреси. Линукс мостот има и IP адреса и делува како порта за излезниот сообраќај од подовите наменети за други јазли.

Контејнери на различни домаќини

Енкапсулацијата на пакети е еден метод кој им овозможува на контејнерите на различни јазли да комуницираат едни со други користејќи IP адреси. Во Flannel, технологијата е одговорна за оваа можност. vxlan, кој го „спакува“ оригиналниот пакет во UDP пакет и потоа го испраќа до неговата дестинација.

Во кластерот Kubernetes, Flannel создава уред vxlan и соодветно ја ажурира табелата за рути на секој јазол. Секој пакет наменет за контејнер на различен домаќин поминува низ уредот vxlan и е инкапсулиран во UDP пакет. На дестинацијата, вгнездениот пакет се извлекува и се препраќа до саканиот под.

Забелешка: ова е само еден начин да се организира мрежната комуникација помеѓу контејнерите.

Што е CRI?

CRI (интерфејс за време на траење на контејнер) е додаток кој му овозможува на kubelet да користи различни средини за извршување на контејнери. CRI API е вграден во различни работни времиња, така што корисниците можат да го изберат времето на работа по свој избор.

Што е CNI?

Проект CNI е спецификација да организира универзално мрежно решение за контејнери за Linux. Покрај тоа, вклучува приклучоци, одговорен за различни функции при поставување на под-мрежа. Приклучокот CNI е извршна датотека што е во согласност со спецификацијата (ќе разговараме за некои приклучоци подолу).

Распределба на подмрежи на јазли за доделување IP адреси на pods

Бидејќи секој дел во кластерот мора да има IP адреса, важно е да се осигурате дека оваа адреса е единствена. Ова се постигнува со доделување на секој јазол уникатна подмрежа, од која на подовите на тој јазол потоа им се доделуваат IP адреси.

Јазол IPAM контролер

Кога nodeipam помина како параметар за знаменце --controllers кубе-контролер-менаџер, доделува посебна подмрежа (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-мрежа.

Закажувањето на pod до одреден јазол го активира следниов синџир на настани:

Помош: Architecture of Containerd CRI plugins.

Интеракција помеѓу траење на контејнер и CNI приклучоци

Секој мрежен провајдер има свој CNI приклучок. Времето на работа на контејнерот го извршува за да ја конфигурира мрежата за подлогата додека се стартува. Во случај на контејнер, приклучокот CNI се активира од приклучокот Контејнер CRI.

Покрај тоа, секој провајдер има свој агент. Инсталиран е на сите Kubernetes јазли и е одговорен за мрежната конфигурација на pods. Овој агент е или вклучен во конфигурацијата CNI или независно го создава на јазолот. Конфигурацијата му помага на CRI приклучокот да постави кој CNI приклучок да го повика.

Локацијата на конфигурацијата CNI може да се прилагоди; стандардно е внатре /etc/cni/net.d/<config-file>. Администраторите на кластерот исто така се одговорни за инсталирање на CNI приклучоци на секој јазол на кластерот. Нивната локација е исто така приспособлива; стандарден директориум - /opt/cni/bin.

Кога користите контејнер, патеките за конфигурацијата на приклучокот и бинарните датотеки може да се постават во делот [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 и ги следи ажурирањата на pod. Како што се создаваат, тој дистрибуира правци до сите мешунки низ кластерот.
• Овие рути им овозможуваат на подовите да комуницираат едни со други преку 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», што е означено во конфигурацијата. Потоа се создава пар вет за секоја мешунка. Едниот крај е поврзан со мрежниот именски простор на контејнерот, другиот е вклучен во мостот Linux на мрежата домаќин. CNI приклучок Bridge ги поврзува сите контејнери за домаќини со мост за 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 Address Mуправување - управување со IP адреса) ја враќа IP адресата за контејнерот од подмрежата и ја складира доделената IP адреса на домаќинот во директориумот наведен во делот dataDir - /var/lib/cni/networks/<network-name=cni0>/<ip>. Оваа датотека го содржи ID на контејнерот на кој е доделена оваа IP адреса.

При повикување на хост-локален IPAM приклучок, тој ги враќа следните податоци:

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

Краток преглед

Kube-контролер-менаџер доделува podCIDR на секој јазол. Подрачјата на секој јазол добиваат IP адреси од адресниот простор во доделениот опсег podCIDR. Бидејќи podCIDR-овите на јазлите не се преклопуваат, сите подлоги добиваат единствени IP адреси.

Администраторот на кластерот Kubernetes го конфигурира и инсталира kubelet, времетраење на контејнер, агент за мрежен добавувач и ги копира CNI приклучоците на секој јазол. За време на стартувањето, агентот на мрежниот провајдер генерира CNI конфигурација. Кога подлогата е закажана за јазол, kubelet го повикува додатокот CRI за да го создаде. Следно, ако се користи контејнер, приклучокот Containerd CRI го повикува приклучокот CNI наведен во конфигурацијата CNI за да ја конфигурира мрежата на подлогата. Како резултат на тоа, pod добива IP адреса.

Ми требаше малку време да ги разберам сите суптилности и нијанси на сите овие интеракции. Се надевам дека ова искуство ќе ви помогне подобро да разберете како функционира Кубернетес. Ако не сум во право за нешто, ве молиме контактирајте ме на Twitter или на адресата [заштитена по е-пошта]. Слободно контактирајте ако сакате да разговарате за аспектите на овој напис или нешто друго. Би сакал да разговарам со тебе!

референци

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

• Преглед на вмрежување на контејнери
• Демистифицирачко поврзување со контејнери

Како функционира Flannel?

• Flannel Networking Demystify
• Kubernetes со Flannel - Разбирање на вмрежувањето

CRI и CNI

• CRI Plugin Architecture
• CNI спец
• CNI приклучоци

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

Прочитајте и на нашиот блог:

• «Калико за вмрежување во Кубернетес: вовед и малку искуство";
• „Илустриран водич за вмрежување во Кубернетес“: делови 1 и 2 (мрежен модел, преклопени мрежи), дел 3 (услуги и сообраќајна обработка);
• «Контејнерски мрежен интерфејс (CNI) - мрежен интерфејс и стандард за контејнери за Linux".

Извор: www.habr.com