🥇Кубернетестеги поддон кантип IP даректи алат

Эскертүү. котормо.: LinkedIn компаниясынын SRE инженери тарабынан жазылган бул макалада Кубернетестеги ички сыйкыр жөнүндө - тагыраак айтканда, CRI, CNI жана kube-аписервердин өз ара аракеттешүүсү - кийинки подкокко IP дарегин ыйгаруу керек болгондо болот.

Негизги талаптардын бири Kubernetes тармак модели ар бир поддондун өзүнүн IP дареги болушу керек, ал эми кластердеги башка подряд ошол дарек боюнча аны менен байланыша алышы керек. Бул тармак моделин ишке ашырууга жардам берген көптөгөн тармак "провайдерлери" (Flannel, Calico, Canal, ж.б.) бар.

Мен биринчи жолу Kubernetes менен иштей баштаганда, поддондор IP даректерин так кантип аларын түшүнгөн жокмун. Жеке компоненттердин кантип иштешин түшүнүү менен да, алардын чогуу иштешин элестетүү кыйын болчу. Мисалы, мен CNI плагиндери эмне үчүн экенин билчүмүн, бирок алар кантип так аталарын билбейм. Ошондуктан, мен бул макаланы ар кандай тармак компоненттери жана алардын Kubernetes кластеринде кантип чогуу иштеши жөнүндө билим менен бөлүшүү үчүн жазууну чечтим, бул ар бир поддондун өзүнүн уникалдуу IP дарегин алууга мүмкүндүк берет.

Кубернетесте тармакты уюштуруунун ар кандай жолдору бар, контейнерлер үчүн иштөө убактысынын ар кандай варианттары бар. Бул басылма колдонот калыъ тармакты кластерде уюштуруу жана аткарылуучу чөйрө катары - Контейнерд. Мен ошондой эле сиз контейнерлердин ортосундагы тармактык байланыш кантип иштээрин билесиз деп ойлоп жатам, ошондуктан мен ага контекст үчүн гана кыскача токтолоюн.

Кээ бир негизги түшүнүктөр

Контейнерлер жана тармак: Кыскача баяндама

Интернетте контейнерлердин тармак аркылуу бири-бири менен кантип байланышаарын түшүндүргөн көптөгөн мыкты басылмалар бар. Ошондуктан, мен негизги түшүнүктөргө жалпы сереп гана берем жана өзүмдү бир ыкма менен чектейм, ал төмөнкүлөрдү түзүүнү камтыйт Linux- көпүрөлөрдү бириктирүү жана пакеттерди инкапсуляциялоо. Контейнердик тармактын темасы өзүнчө макалага татыктуу болгондуктан, чоо-жайы келтирилген эмес. Айрым өзгөчө маалыматтуу жана түшүнүктүү басылмаларга шилтемелер төмөндө келтирилген.

Бир хосттогу контейнерлер

Бир эле хостта иштеп жаткан контейнерлердин ортосундагы IP даректер аркылуу байланышты уюштуруунун бир жолу - түзүү Linux-көпүрө. Бул үчүн виртуалдык түзмөктөр Kubernetesте (жана Dockerде) түзүлөт veth (виртуалдык Ethernet). Veth аппаратынын бир учу контейнердин тармак мейкиндигине туташат, экинчиси Linux-көпүрө хост тармагында.

Бир хосттогу бардык контейнерлердин бир учу көпүрөгө туташтырылган, ал аркылуу алар бири-бири менен IP даректери аркылуу байланыша алышат. Linux- көпүрөнүн ошондой эле IP дареги бар жана ал башка түйүндөргө багытталган под-станциялардан чыгуучу (чыгуу) трафик үчүн шлюз катары кызмат кылат.

Ар кандай хосттордогу контейнерлер

Пакет инкапсуляциясы ар кандай түйүндөрдөгү контейнерлерге IP даректерди колдонуу менен бири-бири менен байланышууга мүмкүндүк берген ыкмалардын бири. Фланелде технология бул мүмкүнчүлүк үчүн жооптуу. vxlan, ал түпнуска пакетти UDP пакетине "пакеттеп", андан кийин аны көздөгөн жерине жөнөтөт.

Kubernetes кластеринде, Flannel vxlan түзмөгүн түзүп, ошого жараша ар бир түйүндөгү маршруттук таблицаны жаңылайт. Башка хосттогу контейнерге арналган ар бир пакет vxlan түзмөгү аркылуу өтөт жана UDP пакетинде капсулдалат. Бара турган жерде уя салынган пакет чыгарылып, керектүү подкокко жөнөтүлөт.

Эскертүү: Бул контейнерлердин ортосундагы тармактык байланышты уюштуруунун бир гана жолу.

CRI деген эмне?

CRI (Container Runtime Interface) kubelet ар кандай контейнер иштөө чөйрөсүн колдонууга мүмкүндүк берген плагин. CRI API ар кандай иштөө убакыттарына курулган, ошондуктан колдонуучулар өз каалоосу боюнча иштөө убактысын тандай алышат.

CNI деген эмне?

CNI долбоору көрсөтөт спецификация үчүн универсалдуу тармактык чечимди уюштуруу Linux-контейнерлер. Мындан тышкары, ал төмөнкүлөрдү камтыйт плагиндер, pod тармагын орнотууда ар кандай функциялар үчүн жооптуу. CNI плагини бул спецификацияга туура келген аткарылуучу файл (биз төмөндө кээ бир плагиндерди талкуулайбыз).

Поддорго IP даректерди ыйгаруу үчүн түйүндөргө субторлорду бөлүштүрүү

Кластердеги ар бир поддондун IP дареги болушу керек болгондуктан, бул дарек уникалдуу болушун камсыздоо маанилүү. Бул ар бир түйүнгө уникалдуу ички тармакты ыйгаруу жолу менен жетишилет, андан кийин ошол түйүндөгү поддондорго IP даректери ыйгарылат.

Хост IPAM контроллери

качан nodeipam желек параметр катары өттү --controllers кубе-контролёр-менеджер, ал CIDR кластеринин ар бир түйүнүнө өзүнчө ички тармакты (podCIDR) бөлүп берет (б.а. кластердик тармак үчүн IP даректер диапазону). Бул podCIDR'лер бири-бирине дал келбегендиктен, ар бир подкастка уникалдуу IP дарек бөлүнүшү мүмкүн.

Kubernetes түйүнү кластерде алгач катталганда podCIDR ыйгарылат. Түйүндөрдүн podCIDRди өзгөртүү үчүн аларды каттоодон чыгарып, андан кийин алардын ортосунда Kubernetes башкаруу катмарынын конфигурациясына тиешелүү өзгөртүүлөрдү киргизип, кайра катташыңыз керек. Сиз төмөнкү буйрукту колдонуу менен түйүндүн podCIDR көрсөтө аласыз:

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

Kubelet, контейнердин иштөө убактысы жана CNI плагиндери: мунун баары кантип иштейт

Бир түйүнгө бир поддонду пландаштыруу көптөгөн даярдык кадамдарын камтыйт. Бул бөлүмдө мен подклиндик тармакты түзүүгө түздөн-түз байланыштуу болгондорго гана токтолом.

Белгилүү бир түйүнгө подкукту пландаштыруу төмөнкү окуялардын чынжырын козгойт:

FAQ: Containerd CRI плагиндеринин архитектурасы.

Контейнердин иштөө убактысы менен CNI плагиндеринин өз ара аракеттенүүсү

Ар бир тармак камсыздоочу өзүнүн CNI плагинине ээ. Контейнердин иштөө убактысы ал ишке киргенде, поддон үчүн тармакты конфигурациялоо үчүн иштетет. Контейнердик учурда, CNI плагини плагин тарабынан ишке киргизилет Контейнер CRI.

Мындан тышкары, ар бир провайдердин өзүнүн агенти бар. Ал бардык Kubernetes түйүндөрүндө орнотулган жана подкасттардын тармак конфигурациясына жооптуу. Бул агент же CNI конфигурациясына кирет же аны түйүндө өз алдынча түзөт. Конфигурация CRI плагинине кайсы CNI плагинин чакырууга жардам берет.

CNI конфигурациясынын жайгашкан жерин ыңгайлаштырса болот; демейки боюнча ал кирет /etc/cni/net.d/<config-file>. Кластердин администраторлору ошондой эле ар бир кластер түйүнүндө CNI плагиндерин орнотуу үчүн жооптуу. Алардын жайгашкан жери да ыңгайлаштырылган; демейки каталог - /opt/cni/bin.

Контейнерди колдонууда, плагин конфигурациясынын жана бинарлардын жолдорун бөлүмдө коюуга болот [plugins.«io.containerd.grpc.v1.cri».cni] в контейнердин конфигурация файлы.

Биз Фланелди тармак камсыздоочу катары колдонуп жаткандыктан, аны орнотуу жөнүндө бир аз сүйлөшөлү:

Flanneld (Flannel's demon) адатта кластерде DaemonSet катары орнотулат. install-cni катары баштапкы контейнер.
Install-cni жаратат CNI конфигурация файлы (/etc/cni/net.d/10-flannel.conflist) ар бир түйүндө.
Фланелд vxlan түзмөгүн жаратат, API серверинен тармак метаберилиштерин чыгарып, поддон жаңыртууларын көзөмөлдөйт. Алар түзүлүп жатканда, ал маршруттарды кластер боюнча бардык поддондорго бөлүштүрөт.
Бул маршруттар pods IP даректери аркылуу бири-бири менен байланышууга мүмкүндүк берет.

Фланелдин иши жөнүндө көбүрөөк маалымат алуу үчүн, мен макаланын аягындагы шилтемелерди колдонууну сунуштайм.

Бул жерде Containerd CRI плагини менен CNI плагиндеринин ортосундагы өз ара аракеттенүү диаграммасы:

Жогоруда көрүнүп тургандай, kubelet поддонду түзүү үчүн Containerd CRI плагинин чакырат, андан кийин поддондун тармагын конфигурациялоо үчүн CNI плагинин чакырат. Муну менен, тармак провайдеринин CNI плагини тармактын ар кандай аспектилерин конфигурациялоо үчүн башка негизги CNI плагиндерин чакырат.

CNI плагиндеринин ортосундагы өз ара аракеттенүү

Ар кандай CNI плагиндери бар, алардын милдети хосттогу контейнерлердин ортосунда тармактык байланышты орнотууга жардам берет. Бул макалада алардын үчөө талкууланат.

CNI плагини Flannel

Фланелди тармак камсыздоочу катары колдонгондо, Containerd CRI компоненти чакырат CNI плагини FlannelCNI конфигурация файлын колдонуу /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 менен бирге иштейт. Ишке киргизүү учурунда Фланелд API серверинен podCIDR жана башка тармакка тиешелүү деталдарды чыгарып, аларды файлга сактайт. /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 көпүрө плагин чакыруу үчүн.

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 плагининин түрүн CRI плагини Flannel CNI плагинин чакыруу үчүн колдонгон 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 дареги дайындалган контейнердин ID бар.

Хост-локалдык IPAM плагинине чалганда, ал төмөнкү маалыматтарды кайтарат:

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

на

Kube-контроллер-менеджер ар бир түйүнгө podCIDR дайындайт. Ар бир түйүндүн подкектери бөлүнгөн podCIDR диапазонундагы дарек мейкиндигинен IP даректерди алышат. Түйүндөрдүн podCIDRлери бири-бирине дал келбегендиктен, бардык подколор уникалдуу IP даректерди алышат.

Kubernetes кластеринин администратору кубелетти, контейнердин иштөө убактысын, тармак камсыздоочу агентти конфигурациялайт жана орнотот жана CNI плагиндерин ар бир түйүнгө көчүрөт. Ишке киргизүү учурунда тармак камсыздоочу агент CNI конфигурациясын түзөт. Под түйүнгө пландаштырылганда, kubelet аны түзүү үчүн CRI плагинин чакырат. Андан кийин, эгерде контейнер колдонулса, Containerd CRI плагини поддондун тармагын конфигурациялоо үчүн CNI конфигурациясында көрсөтүлгөн CNI плагинин чакырат. Натыйжада, pod IP дарегин алат.

Бул өз ара аракеттенүүнүн бардык татаалдыктарын жана нюанстарын түшүнүү мага бир аз убакытты талап кылды. Бул тажрыйба сизге Kubernetes кантип иштээрин жакшыраак түшүнүүгө жардам берет деп үмүттөнөм. Эгерде мен бир нерсе жөнүндө жаңылыш болсом, мени менен байланышыңыз Твиттер же дареги боюнча hello@ronaknathani.com. Ушул макаланын аспектилерин же башка нерселерди талкуулагыңыз келсе, тартынбай кайрылыңыз. Мен сени менен сүйлөшкүм келет!