🥇Ինչպես Kubernetes pod-ը IP հասցե է ստանում

Նշում. թարգմ.Այս հոդվածը, որը գրվել է LinkedIn-ից SRE-ի ինժեների կողմից, մանրամասնում է Kubernetes-ի ներքին մոգությունը, ավելի ճիշտ՝ CRI-ի, CNI-ի և kube-apiserver-ի փոխազդեցությունը, որը տեղի է ունենում, երբ հաջորդ pod-ին անհրաժեշտ է IP հասցե հատկացնել:

Հիմնական պահանջներից մեկը Kubernetes ցանցի մոդել այն է, որ յուրաքանչյուր pod պետք է ունենա իր սեփական IP հասցեն, և կլաստերի ցանկացած այլ pod պետք է կարողանա կապվել դրա հետ այդ հասցեով: Կան բազմաթիվ ցանցային «մատակարարներ» (Flannel, Calico, Canal և այլն), որոնք օգնում են իրականացնել այս ցանցի մոդելը:

Երբ ես առաջին անգամ սկսեցի աշխատել Kubernetes-ի հետ, ինձ համար լիովին պարզ չէր, թե կոնկրետ ինչպես են pod-ները ստանում իրենց IP հասցեները: Նույնիսկ հասկանալով, թե ինչպես են գործում առանձին բաղադրիչները, դժվար էր պատկերացնել, որ դրանք միասին աշխատեն: Օրինակ, ես գիտեի, թե ինչի համար են նախատեսված CNI պլագինները, բայց չգիտեի, թե կոնկրետ ինչպես են դրանք կոչվում: Հետևաբար, ես որոշեցի գրել այս հոդվածը, որպեսզի կիսեմ գիտելիքները ցանցի տարբեր բաղադրիչների մասին և թե ինչպես են դրանք աշխատում Kubernetes կլաստերում, որը թույլ է տալիս յուրաքանչյուր pod ստանալ իր ուրույն IP հասցեն:

Kubernetes-ում կան ցանցեր կազմակերպելու տարբեր եղանակներ, ինչպես որ կան կոնտեյներների աշխատանքի ժամանակի տարբեր տարբերակներ: Այս հրապարակումը կօգտագործի Ֆլանել ցանցը կազմակերպել կլաստերում, և որպես գործարկվող միջավայր՝ Կոնտեյներ. Ես նաև ենթադրում եմ, որ դուք գիտեք, թե ինչպես է աշխատում բեռնարկղերի միջև ցանցը, այնպես որ ես պարզապես կանդրադառնամ դրան համառոտ, միայն համատեքստի համար:

Որոշ հիմնական հասկացություններ

Կոնտեյներներ և ցանց. համառոտ ակնարկ

Ինտերնետում կան բազմաթիվ հիանալի հրապարակումներ, որոնք բացատրում են, թե ինչպես են կոնտեյներները միմյանց հետ հաղորդակցվում ցանցի միջոցով: Հետևաբար, ես միայն ընդհանուր ակնարկ կտամ հիմնական հասկացություններին և կսահմանափակվեմ ինձ մեկ մոտեցմամբ, որը ներառում է Linux կամուրջի ստեղծում և փաթեթների ամփոփում: Մանրամասները բաց են թողնված, քանի որ կոնտեյներների ցանցի թեման ինքնին արժանի է առանձին հոդվածի: Որոշ հատկապես խորաթափանց և կրթական հրապարակումների հղումները կտրամադրվեն ստորև:

Կոնտեյներներ մեկ հյուրընկալողի վրա

Նույն հոսթի վրա աշխատող կոնտեյներների միջև IP հասցեների միջոցով հաղորդակցությունը կազմակերպելու եղանակներից մեկը ներառում է Linux կամուրջի ստեղծումը: Այդ նպատակով վիրտուալ սարքերը ստեղծվում են Kubernetes-ում (և Docker-ում) veth (վիրտուալ Ethernet). Veth սարքի մի ծայրը միանում է կոնտեյների ցանցի անվանատարածքին, մյուսը՝ Linux կամուրջ հյուրընկալող ցանցում:

Միևնույն հոսթի վրա գտնվող բոլոր կոնտեյներներն ունեն վեթի մի ծայրը միացված կամրջին, որի միջոցով նրանք կարող են շփվել միմյանց հետ IP հասցեների միջոցով: Linux-ի կամուրջը նաև ունի IP հասցե և գործում է որպես այլ հանգույցների համար նախատեսված պատյաններից ելքային տրաֆիկի դարպաս:

Տարաներ տարբեր տանտերերի վրա

Փաթեթների ինկապսուլյացիան մի մեթոդ է, որը թույլ է տալիս տարբեր հանգույցների կոնտեյներներին հաղորդակցվել միմյանց հետ՝ օգտագործելով IP հասցեներ: Flannel-ում տեխնոլոգիան պատասխանատու է այս հնարավորության համար: vxlan, որը «փաթեթավորում» է սկզբնական փաթեթը UDP փաթեթի մեջ և այնուհետև այն ուղարկում իր նպատակակետին:

Kubernetes կլաստերում Flannel-ը ստեղծում է vxlan սարք և համապատասխանաբար թարմացնում է երթուղու աղյուսակը յուրաքանչյուր հանգույցի վրա: Յուրաքանչյուր փաթեթ, որը նախատեսված է տարբեր հյուրընկալողի կոնտեյների համար, անցնում է vxlan սարքի միջով և պարփակվում է UDP փաթեթում: Նպատակակետում տեղադրված փաթեթը արդյունահանվում և ուղարկվում է ցանկալի պատին:

Նշում. սա կոնտեյներների միջև ցանցային հաղորդակցությունը կազմակերպելու ընդամենը մեկ միջոց է:

Ի՞նչ է CRI-ն:

CRI (կոնտեյների գործարկման միջերես) plugin է, որը թույլ է տալիս kubelet-ին օգտագործել տարբեր կոնտեյներների գործարկման միջավայրեր: CRI API-ն ներկառուցված է տարբեր գործարկման ժամանակներում, այնպես որ օգտվողները կարող են ընտրել իրենց նախընտրած գործարկման ժամանակը:

Ի՞նչ է CNI-ն:

CNI նախագիծ ա ճշգրտում Linux կոնտեյներների համար ունիվերսալ ցանցային լուծում կազմակերպելու համար: Բացի այդ, այն ներառում է պլագիններ, որը պատասխանատու է տարբեր գործառույթների համար, երբ ստեղծվում է pod ցանց: CNI plugin-ը գործարկվող ֆայլ է, որը համապատասխանում է ճշգրտմանը (մենք կքննարկենք որոշ պլագիններ ստորև):

Ենթացանցերի տեղաբաշխում հանգույցներին IP հասցեներ pods-ին հատկացնելու համար

Քանի որ կլաստերի յուրաքանչյուր պատիճ պետք է ունենա IP հասցե, կարևոր է ապահովել, որ այս հասցեն եզակի է: Սա ձեռք է բերվում յուրաքանչյուր հանգույցին հատկացնելով եզակի ենթացանց, որտեղից այդ հանգույցի վրա գտնվող բլոկներին այնուհետև վերագրվում են IP հասցեներ:

Node IPAM Controller

Երբ 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 ցանցի ստեղծման հետ:

Որոշակի հանգույցին պատիճ պլանավորելը առաջացնում է իրադարձությունների հետևյալ շղթան.

Օգնություն: Containerd CRI plugins-ի ճարտարապետություն.

Փոխազդեցություն կոնտեյների գործարկման ժամանակի և CNI պլագինների միջև

Ցանցի յուրաքանչյուր մատակարար ունի իր սեփական CNI հավելվածը: Կոնտեյների գործարկման ժամանակն այն գործարկում է ցանցը կարգավորելու համար, երբ այն սկսվում է: Կոնտեյներների դեպքում CNI plugin-ը գործարկվում է plugin-ի կողմից Կոնտեյներ CRI.

Ավելին, յուրաքանչյուր մատակարար ունի իր գործակալը: Այն տեղադրված է 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's daemon) սովորաբար տեղադրվում է կլաստերի մեջ որպես DaemonSet՝ install-cni ինչպես սկզբնական կոնտեյներ.
Install-cni ստեղծում է CNI կազմաձևման ֆայլ (/etc/cni/net.d/10-flannel.conflist) յուրաքանչյուր հանգույցի վրա:
Flanneld-ը ստեղծում է vxlan սարք, առբերում ցանցի մետատվյալները API սերվերից և վերահսկում pod թարմացումները: Քանի որ դրանք ստեղծվում են, այն բաշխում է երթուղիները դեպի բոլոր պատյանները ամբողջ կլաստերի վրա:
Այս երթուղիները թույլ են տալիս փոդներին միմյանց հետ շփվել IP հասցեների միջոցով:

Flannel-ի աշխատանքի մասին ավելի մանրամասն տեղեկությունների համար խորհուրդ եմ տալիս օգտագործել հոդվածի վերջում գտնվող հղումները։

Ահա Containerd CRI plugin-ի և CNI plugin-ների միջև փոխազդեցության դիագրամ.

Ինչպես տեսնում եք վերևում, kubelet-ը զանգահարում է Containerd CRI plugin-ը՝ pod ստեղծելու համար, որն այնուհետև կանչում է CNI փլագինը պատի ցանցը կարգավորելու համար: Դրանով ցանցի մատակարարի CNI հավելվածը կանչում է այլ հիմնական CNI պլագիններ՝ ցանցի տարբեր ասպեկտները կարգավորելու համար:

Փոխազդեցություն CNI պլագինների միջև

Կան տարբեր CNI պլագիններ, որոնց խնդիրն է օգնել հյուրընկալողի վրա բեռնարկղերի միջև ցանցային հաղորդակցություն ստեղծել: Այս հոդվածում կքննարկվեն դրանցից երեքը:

CNI plugin Flannel

Flannel-ը որպես ցանցի մատակարար օգտագործելիս Containerd CRI բաղադրիչը զանգահարում է CNI plugin 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 plugin-ը աշխատում է 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 կամուրջի հավելվածը:

CNI plugin Bridge

Այս plugin-ը կոչվում է հետևյալ կազմաձևով.

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

Երբ առաջին անգամ կանչվում է, այն ստեղծում է Linux կամուրջ «name»: «cni0», որը նշված է կազմաձևում: Այնուհետև յուրաքանչյուր պատի համար ստեղծվում է վեթի զույգ: Դրա մի ծայրը միացված է կոնտեյների ցանցի անվանատարածքին, մյուսը ներառված է հյուրընկալող ցանցի Linux կամուրջում: CNI plugin Bridge միացնում է բոլոր հյուրընկալող կոնտեյներները հյուրընկալող ցանցի Linux կամրջին:

Ավարտելով veth զույգի կարգավորումը՝ Bridge plugin-ը կոչ է անում հոսթ-տեղական IPAM CNI plugin-ը: IPAM հավելվածի տեսակը կարող է կազմաձևվել CNI կոնֆիգուրացիայի մեջ, որը CRI հավելվածն օգտագործում է Flannel CNI փլագինը կանչելու համար:

Հոսթ-տեղական IPAM CNI հավելվածներ

Bridge CNI զանգեր հոսթ-տեղական IPAM plugin 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-controller-manager-ը յուրաքանչյուր հանգույցին վերագրում է podCIDR: Յուրաքանչյուր հանգույցի պատյաններ ստանում են IP հասցեներ հատկացված podCIDR տիրույթի հասցեների տարածությունից: Քանի որ հանգույցների podCIDR-ները չեն համընկնում, բոլոր բլոկները ստանում են եզակի IP հասցեներ:

Kubernetes կլաստերի ադմինիստրատորը կարգավորում և տեղադրում է kubelet-ը, կոնտեյների գործարկման ժամանակը, ցանցի մատակարարի գործակալը և պատճենում է CNI հավելվածները յուրաքանչյուր հանգույցում: Գործարկման ընթացքում ցանցի մատակարարի գործակալը ստեղծում է CNI կոնֆիգուրացիա: Երբ հանգույցը նախատեսված է հանգույցում, kubelet-ը կանչում է CRI plugin-ը՝ այն ստեղծելու համար: Այնուհետև, եթե օգտագործվում է կոնտեյներ, Containerd CRI plugin-ը կանչում է CNI կոնֆիգուրայում նշված CNI փլագինը, որպեսզի կարգավորի պատի ցանցը: Արդյունքում, pod-ը ստանում է IP հասցե:

Ինձանից որոշ ժամանակ պահանջվեց այս բոլոր փոխազդեցությունների բոլոր նրբություններն ու նրբությունները հասկանալու համար: Հուսով եմ, որ այս փորձը կօգնի ձեզ ավելի լավ հասկանալ, թե ինչպես է աշխատում Kubernetes-ը: Եթե ինչ-որ բանում սխալվում եմ, խնդրում եմ կապվեք ինձ հետ Twitter կամ հասցեով [էլեկտրոնային փոստով պաշտպանված]. Ազատորեն դիմեք, եթե ցանկանում եք քննարկել այս հոդվածի կամ որևէ այլ ասպեկտների մասին: Ես կցանկանայի զրուցել ձեզ հետ:

Սայլակ

Կոնտեյներներ և ցանց

Ինչպե՞ս է աշխատում Flannel-ը:

CRI և CNI

PS թարգմանչից

Կարդացեք նաև մեր բլոգում.

«Կալիկո Kubernetes-ում ցանցերի համար. ներածություն և մի փոքր փորձ";
«Կուբերնետեսում ցանցային կապի պատկերազարդ ուղեցույց». մասեր 1 և 2 (ցանցային մոդել, ծածկույթի ցանցեր), մաս 3 (ծառայություններ և երթևեկության մշակում);
«Container Networking Interface (CNI) - ցանցային ինտերֆեյս և ստանդարտ Linux կոնտեյներների համար.

Source: www.habr.com

Ինչպե՞ս է Kubernetes pod-ը IP հասցե ստանում: