Kubernetes pod нь IP хаягийг хэрхэн авдаг вэ?

Анхаарна уу. орчуулга.: LinkedIn-ийн SRE инженерийн бичсэн энэхүү нийтлэлд Кубернетес дэх дотоод ид шидийн талаар дэлгэрэнгүй тайлбарласан болно - илүү нарийвчлалтай, CRI, CNI болон kube-apiserver-ийн харилцан үйлчлэл - дараагийн подонд IP хаяг өгөх шаардлагатай үед тохиолддог.

Үндсэн шаардлагуудын нэг Kubernetes сүлжээний загвар Под бүр өөрийн гэсэн IP хаягтай байх ёстой бөгөөд кластерт байгаа бусад бүх pod нь тухайн хаягаар холбогдох боломжтой байх ёстой. Энэхүү сүлжээний загварыг хэрэгжүүлэхэд тусалдаг олон сүлжээний "үзүүлэгч" (Flannel, Calico, Canal гэх мэт) байдаг.

Намайг анх Кубернетестэй хамтран ажиллаж эхлэхэд pods хэрхэн IP хаягаа авдаг нь тодорхойгүй байсан. Бүр бие даасан бүрэлдэхүүн хэсгүүд хэрхэн ажилладаг талаар ойлголттой байсан ч тэд хамтдаа ажиллаж байгааг төсөөлөхөд хэцүү байсан. Жишээлбэл, би CNI залгаасууд юунд зориулагдсан болохыг мэддэг байсан ч яг яаж дуудагддагийг мэдэхгүй байсан. Тиймээс би сүлжээний төрөл бүрийн бүрэлдэхүүн хэсгүүд болон тэдгээр нь Кубернетес кластерт хэрхэн хамтран ажилладаг тухай мэдлэгээ хуваалцахын тулд энэ нийтлэлийг бичихээр шийдсэн бөгөөд энэ нь под бүр өөрийн гэсэн өвөрмөц IP хаягийг авах боломжийг олгодог.

Кубернетес дэх сүлжээг зохион байгуулах янз бүрийн арга замууд байдаг. Үүний нэгэн адил контейнеруудын ажиллах цагийн өөр сонголтууд байдаг. Энэ хэвлэлийг ашиглах болно Flannel сүлжээг кластерт зохион байгуулах, гүйцэтгэх орчин болгон - Контейнер. Би ч гэсэн чингэлэг хоорондын сүлжээ хэрхэн ажилладагийг та мэднэ гэсэн таамаг дэвшүүлж байгаа тул би үүнийг контекстийн үүднээс товчхон дурдъя.

Зарим үндсэн ойлголтууд

Контейнер ба сүлжээ: Товч тойм

Интернет дээр чингэлэгүүд хоорондоо сүлжээгээр хэрхэн харилцдагийг тайлбарласан маш сайн нийтлэлүүд байдаг. Тиймээс, би зөвхөн үндсэн ойлголтуудын ерөнхий тоймыг өгч, Линуксийн гүүр үүсгэх, багцуудыг багтаасан нэг арга барилаар өөрийгөө хязгаарлах болно. Контейнер сүлжээний сэдэв нь тусдаа нийтлэл байх ёстой тул дэлгэрэнгүй мэдээллийг орхигдуулсан болно. Зарим онцгой ойлголттой, боловсролын нийтлэлүүдийн холбоосыг доор өгөх болно.

Нэг хост дээрх савнууд

Нэг хост дээр ажиллаж байгаа контейнер хоорондын IP хаягаар дамжуулан харилцаа холбоог зохион байгуулах нэг арга бол Линукс гүүр үүсгэх явдал юм. Энэ зорилгоор виртуал төхөөрөмжүүдийг Kubernetes (болон Docker) дээр бүтээдэг. veth (виртуал этернет). Veth төхөөрөмжийн нэг төгсгөл нь контейнерийн сүлжээний нэрийн орон зайд, нөгөө нь холбогддог Линуксийн гүүр хост сүлжээнд.

Нэг хост дээрх бүх контейнерууд нь гүүрний нэг төгсгөлтэй бөгөөд гүүрээр дамжуулан хоорондоо IP хаягаар холбогддог. Линуксийн гүүр нь мөн IP хаягтай бөгөөд бусад зангилаанд зориулагдсан подкуудаас гарах урсгалын гарц болж ажилладаг.

Kubernetes pod нь IP хаягийг хэрхэн авдаг вэ?

Өөр өөр хостууд дээрх савнууд

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

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

Kubernetes pod нь IP хаягийг хэрхэн авдаг вэ?
Тайлбар: Энэ бол контейнер хоорондын сүлжээний холбоог зохион байгуулах нэг арга зам юм.

CRI гэж юу вэ?

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

CNI гэж юу вэ?

CNI төсөл нь тодорхойлолт Линукс контейнерт зориулсан бүх нийтийн сүлжээний шийдлийг зохион байгуулах. Үүнээс гадна үүнд орно залгаасууд, pod сүлжээг тохируулах үед янз бүрийн функцийг хариуцдаг. CNI залгаас нь техникийн үзүүлэлтэд нийцсэн гүйцэтгэх боломжтой файл юм (бид доор зарим залгаасуудын талаар хэлэлцэх болно).

pods-д IP хаяг өгөх дэд сүлжээг зангилаанд хуваарилах

Кластер дахь под бүр нь IP хаягтай байх ёстой тул энэ хаяг нь өвөрмөц байх нь чухал юм. Энэ нь зангилаа бүрд өвөрмөц дэд сүлжээ өгөх замаар хийгддэг бөгөөд үүнээс тухайн зангилааны хонхорцог IP хаягуудыг оноодог.

Зангилааны IPAM хянагч

Хэзээ nodeipam тугийн параметр болгон дамжуулсан --controllers kube-хянагч-менежер, энэ нь CIDR кластераас (өөрөөр хэлбэл кластерийн сүлжээний IP хаягийн хүрээ) зангилаа бүрт тусдаа дэд сүлжээ (podCIDR) хуваарилдаг. Эдгээр podCIDR-ууд нь давхцдаггүй тул под бүрд өвөрмөц IP хаяг хуваарилах боломжтой болдог.

Кубернетес зангилаа нь кластерт анх бүртгэгдсэн үед podCIDR оноогдсон байна. Зангилааны podCIDR-ийг өөрчлөхийн тулд та тэдгээрийг бүртгэлээс хасч, дараа нь Кубернетес хяналтын давхаргын тохиргоонд зохих өөрчлөлтүүдийг хийж дахин бүртгүүлэх хэрэгтэй. Та дараах тушаалыг ашиглан зангилааны podCIDR-г харуулах боломжтой.

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

Kubelet, контейнер ажиллуулах хугацаа болон CNI залгаасууд: энэ бүхэн хэрхэн ажилладаг

Нэг зангилаа тус бүрийг хуваарилах нь маш олон бэлтгэл үе шатыг хамардаг. Энэ хэсэгт би зөвхөн pod сүлжээг тохируулахтай шууд холбоотой зүйлд анхаарлаа хандуулах болно.

Тодорхой зангилаа руу хонхорцог хуваарилах нь дараах үйл явдлын гинжин хэлхээг үүсгэдэг.

Kubernetes pod нь IP хаягийг хэрхэн авдаг вэ?

Тусламж: Containerd CRI залгаасуудын архитектур.

Контейнерын ажиллах хугацаа болон 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 demon) нь ихэвчлэн кластерт DaemonSet хэлбэрээр суурилагдсан байдаг. install-cni зэрэг эхлүүлэх сав.
  • Install-cni бий болгодог CNI тохиргооны файл (/etc/cni/net.d/10-flannel.conflist) зангилаа бүр дээр.
  • Фланелд нь vxlan төхөөрөмж үүсгэж, API серверээс сүлжээний мета өгөгдлийг авч, под шинэчлэлтүүдийг хянадаг. Тэдгээрийг үүсгэснээр энэ нь кластерын бүх поддод чиглүүлэлтүүдийг хуваарилдаг.
  • Эдгээр маршрутууд нь pods-ууд хоорондоо IP хаягаар дамжуулан холбогдох боломжийг олгодог.

Фланнелийн ажлын талаар илүү дэлгэрэнгүй мэдээлэл авахыг хүсвэл нийтлэлийн төгсгөлд байгаа холбоосыг ашиглахыг зөвлөж байна.

Containerd CRI залгаас болон CNI залгаасуудын хоорондын харилцан үйлчлэлийн диаграммыг энд харуулав.

Kubernetes pod нь IP хаягийг хэрхэн авдаг вэ?

Дээрээс харж байгаагаар kubelet нь pod үүсгэхийн тулд Containerd CRI залгаасыг дуудаж, дараа нь pod-ын сүлжээг тохируулахын тулд CNI залгаасыг дууддаг. Ингэхдээ сүлжээний үйлчилгээ үзүүлэгчийн CNI залгаас нь сүлжээний янз бүрийн талыг тохируулахын тулд бусад үндсэн CNI залгаасуудыг дууддаг.

CNI залгаасуудын хоорондын харилцан үйлчлэл

Төрөл бүрийн CNI залгаасууд байдаг бөгөөд тэдгээрийн үүрэг нь хост дээрх контейнер хоорондын сүлжээний холболтыг тохируулахад туслах явдал юм. Энэ нийтлэлд эдгээрийн гурвыг авч үзэх болно.

CNI залгаас Flannel

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"
  }
}

Анх удаа дуудахдаа энэ нь Линуксийн гүүрийг үүсгэдэг «name»: «cni0», үүнийг тохиргоонд заасан. Дараа нь хонхорцог бүрт ветерийн хос үүсгэнэ. Үүний нэг төгсгөл нь контейнерийн сүлжээний нэрийн орон зайд холбогдсон бол нөгөө нь хост сүлжээн дэх 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 Aдарангуйлагч 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 оноодог. Зангилаа бүрийн pods нь хуваарилагдсан podCIDR муж дахь хаягийн зайнаас IP хаягуудыг хүлээн авдаг. Зангилааны podCIDR нь давхцдаггүй тул бүх pods өвөрмөц IP хаягийг хүлээн авдаг.

Kubernetes кластерын администратор нь kubelet, контейнер ажиллах хугацаа, сүлжээний үйлчилгээ үзүүлэгч агентийг тохируулж суулгаж, CNI залгаасуудыг зангилаа бүрд хуулдаг. Эхлүүлэх явцад сүлжээний үйлчилгээ үзүүлэгч агент нь CNI тохиргоог үүсгэдэг. Под зангилаанд хуваарилагдсан үед kubelet үүнийг үүсгэхийн тулд CRI залгаасыг дууддаг. Дараа нь, хэрэв containerd ашигласан бол Containerd CRI залгаас нь CNI тохиргоонд заасан CNI залгаасыг дуудаж, подын сүлжээг тохируулах болно. Үүний үр дүнд pod IP хаягийг хүлээн авдаг.

Энэ бүх харилцан үйлчлэлийн бүх нарийн ширийн зүйл, нарийн ширийн зүйлийг ойлгоход надад бага зэрэг хугацаа зарцуулагдсан. Энэхүү туршлага нь Кубернетес хэрхэн ажилладагийг илүү сайн ойлгоход тусална гэж найдаж байна. Хэрэв миний ямар нэг зүйл буруу байвал надтай холбогдоно уу Twitter эсвэл хаягаар [имэйлээр хамгаалагдсан]. Хэрэв та энэ нийтлэлийн талаар болон бусад зүйлийн талаар ярилцахыг хүсвэл чөлөөтэй холбогдоорой. Би чамтай чатлах дуртай!

лавлагаа

Контейнер ба сүлжээ

Фланел хэрхэн ажилладаг вэ?

CRI ба CNI

Орчуулагчийн жич

Мөн манай блог дээрээс уншина уу:

Эх сурвалж: www.habr.com

сэтгэгдэл нэмэх