Эскертүү. котормо.: LinkedIn компаниясынын SRE инженери тарабынан жазылган бул макалада Кубернетестеги ички сыйкыр жөнүндө - тагыраак айтканда, CRI, CNI жана kube-аписервердин өз ара аракеттешүүсү - кийинки подкокко IP дарегин ыйгаруу керек болгондо болот.
Негизги талаптардын бири ар бир поддондун өзүнүн IP дареги болушу керек, ал эми кластердеги башка подряд ошол дарек боюнча аны менен байланыша алышы керек. Бул тармак моделин ишке ашырууга жардам берген көптөгөн тармак "провайдерлери" (Flannel, Calico, Canal, ж.б.) бар.
Мен биринчи жолу Kubernetes менен иштей баштаганда, поддондор IP даректерин так кантип аларын түшүнгөн жокмун. Жеке компоненттердин кантип иштешин түшүнүү менен да, алардын чогуу иштешин элестетүү кыйын болчу. Мисалы, мен CNI плагиндери эмне үчүн экенин билчүмүн, бирок алар кантип так аталарын билбейм. Ошондуктан, мен бул макаланы ар кандай тармак компоненттери жана алардын Kubernetes кластеринде кантип чогуу иштеши жөнүндө билим менен бөлүшүү үчүн жазууну чечтим, бул ар бир поддондун өзүнүн уникалдуу IP дарегин алууга мүмкүндүк берет.
Кубернетесте тармакты уюштуруунун ар кандай жолдору бар, контейнерлер үчүн иштөө убактысынын ар кандай варианттары бар. Бул басылма колдонот тармакты кластерде уюштуруу жана аткарылуучу чөйрө катары - . Мен ошондой эле сиз контейнерлердин ортосундагы тармактык байланыш кантип иштээрин билесиз деп ойлоп жатам, ошондуктан мен ага контекст үчүн гана кыскача токтолоюн.
Кээ бир негизги түшүнүктөр
Контейнерлер жана тармак: Кыскача баяндама
Интернетте контейнерлердин тармак аркылуу бири-бири менен байланышын түшүндүргөн көптөгөн мыкты басылмалар бар. Ошондуктан, мен негизги түшүнүктөрдүн жалпы баяндамасын гана берем жана өзүмдү бир гана ыкма менен чектейм, ал Linux көпүрөсүн түзүүнү жана пакеттерди капсулдаштырууну камтыйт. Контейнер тармагынын темасы өзүнчө макалага татыктуу болгондуктан, чоо-жайы жок. Кээ бир өзгөчө түшүнүктүү жана билим берүүчү басылмаларга шилтемелер төмөндө берилет.
Бир хосттогу контейнерлер
Бир эле хостто иштеген контейнерлердин ортосундагы IP даректери аркылуу байланышты уюштуруунун бир жолу Linux көпүрөсүн түзүүнү камтыйт. Бул үчүн, виртуалдык түзмөктөр Kubernetes (жана Docker) түзүлөт . Veth аппаратынын бир учу контейнердин тармак мейкиндигине туташат, экинчиси хост тармагында.
Бир эле хосттогу бардык контейнерлердин бир учу көпүрөгө туташтырылып, алар IP даректери аркылуу бири-бири менен байланыша алышат. Linux көпүрөсүнүн дагы IP дареги бар жана башка түйүндөр үчүн арналган поддондордон чыгуучу трафик үчүн шлюз катары иштейт.
Ар кандай хосттордогу контейнерлер
Пакет инкапсуляциясы ар кандай түйүндөрдөгү контейнерлерге IP даректерди колдонуу менен бири-бири менен байланышууга мүмкүндүк берген ыкмалардын бири. Фланелде технология бул мүмкүнчүлүк үчүн жооптуу. , ал түпнуска пакетти UDP пакетине "пакеттеп", андан кийин аны көздөгөн жерине жөнөтөт.
Kubernetes кластеринде, Flannel vxlan түзмөгүн түзүп, ошого жараша ар бир түйүндөгү маршруттук таблицаны жаңылайт. Башка хосттогу контейнерге арналган ар бир пакет vxlan түзмөгү аркылуу өтөт жана UDP пакетинде капсулдалат. Бара турган жерде уя салынган пакет чыгарылып, керектүү подкокко жөнөтүлөт.
Эскертүү: Бул контейнерлердин ортосундагы тармактык байланышты уюштуруунун бир гана жолу.
CRI деген эмне?
kubelet ар кандай контейнер иштөө чөйрөсүн колдонууга мүмкүндүк берген плагин. CRI API ар кандай иштөө убакыттарына курулган, ошондуктан колдонуучулар өз каалоосу боюнча иштөө убактысын тандай алышат.
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: .
Контейнердин иштөө убактысы менен CNI плагиндеринин өз ара аракеттенүүсү
Ар бир тармак камсыздоочу өзүнүн CNI плагинине ээ. Контейнердин иштөө убактысы ал ишке киргенде, поддон үчүн тармакты конфигурациялоо үчүн иштетет. Контейнердик учурда, CNI плагини плагин тарабынан ишке киргизилет .
Мындан тышкары, ар бир провайдердин өзүнүн агенти бар. Ал бардык 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жаратат (/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 конфигурация файлын колдонуу /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», бул конфигурацияда көрсөтүлгөн. Андан кийин ар бир порошок үчүн ветерандык жуп түзүлөт. Анын бир учу контейнердин тармак мейкиндигине туташкан, экинчиси хост тармагындагы Linux көпүрөсүнө киргизилген. бардык хост контейнерлерин хост тармагындагы Linux көпүрөсүнө туташтырат.
Veth жупту орнотууну аяктагандан кийин, Bridge плагини хост-жергиликтүү IPAM CNI плагинин чакырат. IPAM плагининин түрүн CRI плагини Flannel CNI плагинин чакыруу үчүн колдонгон CNI конфигурациясында конфигурациялоого болот.
Хост-жергиликтүү IPAM CNI плагиндери
Bridge 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 кантип иштээрин жакшыраак түшүнүүгө жардам берет деп үмүттөнөм. Эгерде мен бир нерсе жөнүндө жаңылыш болсом, мени менен байланышыңыз же дареги боюнча . Ушул макаланын аспектилерин же башка нерселерди талкуулагыңыз келсе, тартынбай кайрылыңыз. Мен сени менен сүйлөшкүм келет!
шилтемелер
Контейнерлер жана тармак
Фланел кантип иштейт?
CRI жана CNI
Котормочудан PS
Биздин блогдон дагы окуңуз:
- «";
- "Kubernetes тармагында иллюстрацияланган колдонмо": , ;
- ««.
Source: www.habr.com