GKE-ийн pod-ууд VPN-ээр дамжин локал хост руу хүрч чадахгүй байгаа шалтгаан

Ping зангилаанаас ажиллаж, pod-оос бүтэлгүйтдэг бөгөөд локал талд юу ч хүрдэггүй. Тунель болон маршрут зөв; утсан дээрх эх үүсвэрийн хаяг зөв биш. Эдгээр хоёр тохиолдлын ялгаа нь пакет кластерээс гарахдаа өөрийгөө хэн гэж мэдэгдэхэд байдаг бөгөөд GKE үүнд өөрийн гэсэн бодолтой. Механизм нь masquerade үл хамаарах зүйлсийн жагсаалт бөгөөд түүнийг уншихад нэг команд хангалттай.

Ямар нэг зүйлийг өөрчлөхөөс өмнө хүчин төгөлдөр жагсаалтыг уншина уу

GKE нь очих газрын хүрээ тус бүрээр pod-ын урсгал гадагш гарахдаа зангилааны хаяг руу дахин бичигдэх эсэхийг шийддэг агент нийлүүлдэг. Түүний нийлүүлсэн тохиргоо нь гурван RFC1918 блокыг, 10.0.0.0/8, 172.16.0.0/12 болон 192.168.0.0/16, үл хамаарах очих газрууд гэж нэрлэдэг. Тиймээс pod-оос локал 10.x хост руу илгээсэн бүхэн зангилааг pod-ын өөрийн хаягтайгаа гардаг. Зангилааны өөрийн урсгал дахин бичигддэггүй, яг ийм учраас түүний ping ажилладаг.

Төлөвлөсөн тохиргоо болон суулгасан дүрмийг уншина уу, учир нь тэд нийцэхгүй байж болно. kubectl -n kube-system get configmap ip-masq-agent -o yaml агентад юу хэлснийг харуулж, kubectl -n kube-system get pods -l k8s-app=ip-masq-agent үүнийг хэрэгжүүлэх зүйл ажиллаж байгаа эсэхийг харуулна. Зангилаа дээр iptables-save | grep -i masq цөмд бодитоор байгаа дүрмийг харуулна. ConfigMap нэг зүйл, дүрмүүд өөр зүйл хэлбэл сэжиглэх зүйл нь сүлжээ биш, агент юм.

Эх үүсвэрийн хаягийг бичлэгээр баталгаажуулна уу

Жагсаалтыг өөрчлөхөөс өмнө бичлэг хий. Нэг очих газарт шүүлтүүр хийвэл гаралт уншигдахуйц хэвээр байна: tcpdump -ni any host 10.20.30.40.

Үүнийг нөгөө тал мэдээлж буйтай харьцуул. Локал талд pod-ын хаягийг харуулж, хариу байхгүй бичлэг тойргийг хаана: үл хамаарах зүйлсийн жагсаалт тунелийн ямар ч гэмтэлгүйгээр тэгш бус байдлыг тайлбарлана. Нэг эх үүсвэрийн хаягийн хоёр ажиглалт CNI-ийн талаар таамаглахаа болиход хангалттай.

Үл хамаарах зүйлийг pod-ын CIDR хүртэл нарийсгана уу

Дэмжигдсэн засвар нь үл хамаарах зүйлийг устгахын оронд нарийсгадаг: pod-ын CIDR-ийг үл хамаарах хэвээр үлдээж, 10.x огторгуйн үлдсэнийг хая. Тэр жагсаалт агентын ConfigMap-д nonMasqueradeCIDRs дор байдаг бөгөөд түүнийг өөрчлөх нь засвар, дараа нь нэвтрүүлэлт юм. Өргөн бичлэгийг кластерын бодит pod-ын хүрээгээр сольж, кластер доторх урсгалд одоо ч хэрэгтэй бол бусад хувийн блокуудыг үлдээж, шалтгаан байхгүй бол resyncInterval-ыг хөндөхгүй бай. Хэрэгжүүлж, агентын pod-ууд дахин эхэлснийг болон цөмийн дүрмүүд өөрчлөгдснийг баталгаажуул.

Энэ бол бодит нөлөөллийн радиустай кластер даяарх өөрчлөлт юм. Хэрэгжиж эхэлсний дараа өмнө нь pod-ын эх үүсвэрээ хадгалж байсан урсгал одоо зангилаа руу дахин бичигдэж ирдэг тул тэдгээр pod-ын хаягт тулгуурласан бүхэн өөр илгээгчийг хардаг. Хохирогчид нь pod-ын хаягийг нэрлэсэн лог, зөвшөөрлийн жагсаалт, локал галын хананы дүрмүүд бөгөөд тэд чимээгүйгээр бүтэлгүйтдэг. Өөрчлөлтийг засвар гэж бус, зан төлөвийн өөрчлөлт гэж зарла.

Хэд хэдэн зангилааны пултай кластерт агент нь нөлөөлөгдсөн pod-ууд бодитоор ажиллаж буй зангилаануудад хуваарилагдсан эсэхийг шалга. DaemonSetгүй пул хуучин дүрмээ хадгалдаг бөгөөд ConfigMap-д үүнийг харуулах зүйл байхгүй.

Өөр хувилбар ба түүний өртөг

Нөгөө хувилбар pod-ын хаягийг хөндөхгүй үлдээж, замд тэдний тухай заадаг. Pod-ын CIDR Cloud VPN-ийн урсгалын сонгогчдод орж, локал талд хариу хаашаа явахаа мэдэхийн тулд буцах маршрут хэрэгтэй. Энэ нь зарим аюулгүй байдлын загварт хүсдэг pod-ын таних тэмдгийг хадгалж, нөгөө талын хүлээн зөвшөөрөх ёстой маршрут болон галын хананы хүрээг хоёуланг нь өргөжүүлдэг.

Солилцоо нь уншигдахуйц байдал ба хүрээний хооронд. Орчуулга нь локал талд зангилаа бүрт нэг хаяг харагдуулдаг бөгөөд үүнийг зөвшөөрлийн жагсаалтад оруулахад хялбар бөгөөд аль pod юу илгээснийг нуудаг. Орчуулгагүй бол pod-ын хаяг эхнээс төгсгөл хүртэл хадгалагдаж, энэ нь хамааруулалтад сайн, шинэ хүрээ сурах ёстой зам дээрх төхөөрөмж бүрд муу. Аль ч хувилбар Docker эсвэл CNI-ийн алдаа биш; хоёулаа үйл ажиллагааны төлбөртэй маршрутжуулалтын шийдвэр юм. Баг тань төлж чадах төлбөртэйг сонгож, яагаад гэдгийг бич.

Шалгаж, буцаана уу

Мөнөөх бичлэгийг дахин ажиллуул. Засварын дараа ч зангилааны түвшний бичлэг pod-ын хаягийг хэвлэж байвал ConfigMap юу ч гэсэн дүрмүүд хэзээ ч өөрчлөгдөөгүй гэсэн үг. Баримт нь утас; бусад бүхэн дүгнэлт.

Дараа нь эсрэг чиглэлийг шалга, учир нь эдгээр өөрчлөлтийн тал нь зөвхөн гадагш чиглэлд шалгагддаг. Хариу нь хүсэлт илгээсэн зангилаа эсвэл pod руу хүрч байгаа, аппликейшн зөвхөн SYN авсангүй дууссан эсэхийг баталгаажуул. Хариугүй хүсэлт харуулсан бичлэг нь нөгөө талын маршрутжуулалтын асуудал, энэ талын masquerade асуудал биш.

Буцаах гэдэг нь өмнөх ConfigMap-ыг мөн адил хэрэгжүүлж, агент дахин эхэлсэн, дүрмүүд өөрчлөгдсөн гэдгийг мөн адил баталгаажуулах юм. Өөрчлөлтийн бүртгэлд нэг мэдэгдэх хүсэлтийн эх үүсвэрийн хаягийг өмнө болон дараа нь хадгал, учир нь яг тэр нэг мөр нь өөрчлөлт таны хэлснийг хийснийг нотолдог. GKE-ийн IP masquerade агентын гарын авлага анхдагч утгууд болон ConfigMap-ын талбаруудыг баримтжуулдаг. Хэрэв нэвтрүүлсний дараа эх үүсвэрийн хаяг өөрчлөгдөөгүй бол агент тэр зангилаа дээр ажиллахгүй байгаа бөгөөд YAML-ыг хэчнэн засварласан ч засахгүй.