Kubernetes дахь Pod VPN ба гарах гарц: туннель хэнийх вэ?
Pod нь өөрийн сүлжээний нэрийн огторгуйтай, тиймээс жинхэнэ сонголт нь туннелийг аль давхарга эзэмших вэ: ажлын ачаалал бүрийн таних тэмдэг эсвэл нэг нийтлэг эх үүсвэртэй CNI-д удирдуулсан гарах урсгал.
Та vpn-gateway нэртэй Pod байрлуулж, туршилтын клиентийг түүний хаяг руу чиглүүлэхэд пакетууд алга болж байгааг харна. Манифестэд буруу зүйл байхгүй бөгөөд kubelet-д гомдол байхгүй. Шалтгаан нь тохиргооны бус, бүтцийн: Kubernetes Pod бүрт өөрийн сүлжээний нэрийн огторгуйг өгдөг тул нэр, шошго эсвэл нийтлэг API нэрийн огторгуй пакетуудын чиглэлийг өөрчлөхгүй. Тиймээс VPN трафик кластерээс хэрхэн гарахыг шийдэх нь эзэмшлийн тухай асуултаас эхэлдэг, контейнерын дүрсээс биш.
Хоёр механизм бодит байршуулалтын ихэнхийг хамардаг бөгөөд тэдгээр нь харилцан солигдохгүй. Нэг нь туннелийг ажлын ачааллын өөрийн сүлжээний нэрийн огторгуйд байрлуулна. Нөгөө нь CNI-ээс сонгосон трафикийг томилогдсон гарцын зангилаагаар дамжуулахыг хүснэ. Тэд өөр өөрөөр бүтэлгүйтдэг, өөр өөрөөр масштаблагддаг, өөр багуудад хариуцлагатай байдаг тул контейнерын асуулт ихэвчлэн хэзээ ч шийдэгддэггүй маргаан үүсгэдэг.
Pod-ын хил бол нэрийн огторгуй, үсрэх хост биш
Linux сүлжээний нэрийн огторгуй нь өөрийн интерфейс, хаяг, маршрут, галт ханын дүрмийг эзэмшдэг бөгөөд Pod бүр нэгийг авдаг. Тэр Pod доторх контейнерууд түүнд нэгддэг, тиймээс туслах контейнер аппликейшн дараа нь дагах маршрутыг дахин бичиж чаддаг. Хөрш Pod нь ижил харагдах боловч бүрэн тусдаа стектэй. Гарцын Pod өвлөж болох нийтлэг хүснэгт байхгүй, нэг нэрийн огторгуйгаас нөгөөд трафик далд шилжихгүй.
Тиймээс гарцын Pod загвар нь дээрээс ямар нэг зүйл түүнд пакетуудыг үнэхээр илгээж байж л ажиллана: Service, зангилаа дээрх статик маршрут эсвэл CNI дахь чиглүүлэх бодлого. Ганц хаяг юу ч татахгүй.
Pod бүрийн туннель юу өгдөг, юу үнэтэй вэ
Ажлын ачааллын нэрийн огторгуйд ажиллах туннель нь тэр ачаалалд өөрийн клиентийн таних тэмдгийг өгдөг бөгөөд олон алсын хандалтын үйлчилгээ сесс зөвшөөрөх эсвэл тооцоолохын өмнө үүнийг шаарддаг. Хохирлын радиус ч локал хэвээр байна: эвдэрсэн туннель бүгдийн ашигладаг нийтлэг замын оронд нэг Deployment-ыг зогсоодог. Хэрхэн ажиллах нь хэрэгжүүлэлтээс хамаардаг бөгөөд хүмүүс яг энд буруу таамагладаг.
Зөвхөн цөмийн төлөв шаарддаг тохиргоо init контейнерт дуусаж гарч болно. Pod-ын бүх амьдралын турш амьд байх ёстой хэрэглэгчийн орон зайн демон нь Kubernetes 1.29-д төрөлх sidecar хэлбэрээр нэвтрүүлсэн дахин эхлүүлэх боломжтой init контейнер хэлбэрийг шаарддаг бөгөөд энэ ялгаа нь амтаас биш, туннелийн хэрэгжүүлэлтээс гардаг. Энэ загварын үнэ бол давхардал: хуулбар бүр баталгаажуулалт хийж, өөрийн туннелийн хаягыг авч, алсын сессийн байр эзэлдэг тул автоскейлингийн үйл явдал холбоосын нөгөө талд багтаамжийн үйл явдал болно. Нэг итгэмжлэлийг бүх хуулбарт хуулах нь тэр үнийг арилгахгүй, аудитын мөрийг арилгана. Эрх мэдэл ч мөн адил шалгалт хүртэх ёстой, учир нь өөрийн нэрийн огторгуйд NET_ADMIN хүсдэг туннель privileged: true жишээний бүх хостын эрх мэдлийг өвлөх ямар ч шалтгаангүй.
CNI гарцыг эзэмших үед
Хэрэв CNI үүнийг дэмждэг бол гарцын гарц нь ажлын ачаалал, очих хүрээгээр трафикийг сонгож, дараа нь сонгосон зангилаагаар нэг урьдчилан таамаглах боломжтой эх хаягийн дор илгээдэг. Cilium-ийн хувилбар нь нийтлэг лавлагаа бөгөөд түүний баримт бичиг энэ функцэд тодорхой Cilium тохиргоо, зөв интерфейс, хаягтай гарцын зангилаанууд шаардлагатай гэдгийг тодорхой хэлдэг. Мөн Pod үүссэний дараах анхны үеийг дурддаг бөгөөд тухайн үед чиглүүлэлт хараахан хэрэгжихгүй байгаа нь зүүлт биш, дизайны оролт юм.
Тэр саатыг өөрийн амлалттай харьцуулан уншина уу. Хэрэв өөр замаар ямар ч трафик гарах ёсгүй гэсэн дүрэм бол, завсарт илгээж буй шинэ Pod түүнийг аль хэдийн зөрчсөн тул эхлүүлэх дараалал өөрийн хариултыг шаардана: бодлого хэрэгжих хүртэл аппликейшныг барих, эсвэл цонхыг хүлээн авч баримтжуулах.
Мэдэгдлийг нарийн барина уу. Гарцын гарц зам сонгож, орчуулдаг. Энэ нь VPN-ыг дуусгахгүй бөгөөд ард нь дэмжигдсэн холбоосгүйгээр кластерыг таны алсын сүлжээний клиент болгохгүй.
| Question | Per-Pod tunnel | CNI egress gateway |
|---|---|---|
| Who holds the client identity | Each workload | The gateway, shared |
| What scaling changes | Enrollment and sessions per replica | Throughput and capacity per node |
| What the remote side sees | Distinct addresses | One translated source |
| Failure scope | One Deployment | Every workload behind the gateway |
Орчуулга алсын талын харж буй зүйлийг чимээгүй өөрчилдөг
Гарц эх сурвалжийг дахин бичсэний дараа Pod бүрийн хаяг алга болно, тиймээс таних тэмдэгт суурилсан зөвшөөрлийн жагсаалт нэг нийтлэг хаягт суурилсан жагсаалт болно. Энэ нь алдаа биш, солилцоо: засварлахад цөөн дүрэм, ямар нэг зүйл муу ажиллавал бүдүүлэг хамааруулалт.
Аппликейшны түвшний баталгаажуулалт, хүсэлтийн лог нь сүлжээ цаашид мэдээлэхгүй байгаа зүйлийг үүрэх ёстой. Гарцын багтаамж, солигдолыг нийтлэг дэд бүтэц гэж үзээрэй, учир нь нэг зангилаа дахин ачааллах нь ард нь байгаа бүх ажлын ачааллыг тасалдуулдаг, буцах замыг эрт шалгаарай: алсын тал орчуулсан хаяг руу хэрхэн хүрэхээ мэдэх ёстой, ихэвчлэн манифест бус, хүн эзэмших ёстой маршрут эсвэл NAT-аар. Хаягийн төлөвлөлт ч энд хамаарна, учир нь давхцаж буй кластер болон алсын хүрээ хоёр загварыг эвддэг бөгөөд IPv6-г хэрэглэх нь зөрчилтэй төлөвлөгөөг зөвтгөхгүй.
Эзэмшлээр шийдэж, дараа нь амласан бүтэлгүйтлийг шалга
Алсын үйлчилгээ тус тусдаа ажлын ачааллыг баталгаажуулдаг үед, холбоос цөөн Deployment-д л хэрэгтэй үед, бүтэлгүйтэл локал байх ёстой үед Pod бүрийн туннелийг сонго. Сүлжээний баг зам эзэмшдэг үед, олон ачаалал нэг очих газар хуваалцдаг үед, тогтвортой эх хаяг бүх дасгалын зорилго болох үед гарцыг сонго.
Ямар ч тохиолдолд тогтвортой төлөв биш, зарсан шинж чанараа шалга. Pod үүсгэж, түүнийг даруй илгээхийг зөвшөөрч, туннелиас юу ч зугтахгүй гэсэн амлалт байсан бол эхний секундуудыг ажигла. Таван хуулбар хүртэл масштаблаж, амлалт ажлын ачаалал бүрийн таних тэмдэг байсан бол алсын талын мэдээлэх сессүүдийг тоол. Эдгээр хоёр шалгалт манифестыг хянахаас хамаагүй хурдан механизмын хязгаарыг илрүүлж, дараагийн осол аль багийнх болохыг хэлж өгнө.