Nega GKE podlari VPN orqali mahalliy xostlarga yetib bormaydi

Ping nodedan ishlaydi va poddan ishlamaydi, mahalliy tomonga esa hech narsa yetib bormaydi. Tunnel va marshrut joyida; simdagi manba manzili joyida emas. Bu ikki holatni ajratadigan narsa — paket klasterni tark etayotganda o'zini kim deb e'lon qilishi, va GKE bu borada o'z fikriga ega. Mexanizm masquerade istisnolari ro'yxati, va uni o'qish uchun bitta buyruq kifoya.

Biror narsani o'zgartirishdan oldin amaldagi ro'yxatni o'qing

GKE har bir manzil oralig'i uchun pod trafigi chiqishda node manziliga qayta yozilishini yoki yozilmasligini hal qiladigan agentni yetkazib beradi. Uning standart konfiguratsiyasi uchta RFC1918 blokini, 10.0.0.0/8, 172.16.0.0/12 va 192.168.0.0/16, istisno qilingan manzillar deb nomlaydi. Shuning uchun poddan mahalliy 10.x xostga yuborgan hamma narsa nodedan podning o'z manzili bilan chiqadi. Nodening o'z trafigi qayta yozilmaydi, va aynan shuning uchun uning pingi ishlaydi.

Mo'ljallangan konfiguratsiyani va o'rnatilgan qoidalarni o'qing, chunki ular mos kelmasligi mumkin. kubectl -n kube-system get configmap ip-masq-agent -o yaml agentga nima aytilganini ko'rsatadi, kubectl -n kube-system get pods -l k8s-app=ip-masq-agent esa buni qo'llash uchun biror narsa ishlayotganini ko'rsatadi. Nodeda iptables-save | grep -i masq yadroda haqiqatan mavjud qoidalarni ko'rsatadi. ConfigMap bir narsa, qoidalar boshqa narsa desa, gumondor tarmoq emas, agent.

Manba manzilini ushlash bilan tasdiqlang

Ro'yxatni o'zgartirishdan oldin ushlash qiling. Bitta manzilga filtr chiqishni o'qish mumkin qilib turadi: tcpdump -ni any host 10.20.30.40.

Buni qarshi tomon xabar bergani bilan solishtiring. Mahalliy tomonda pod manzilini ko'rsatadigan va javob bo'lmagan ushlash doirani yopadi: istisnolar ro'yxati assimetriyani hech qanday tunnel nosozligisiz tushuntiradi. Bitta manba manzilining ikki kuzatuvi CNI haqida taxmin qilishni to'xtatish uchun yetarli.

Istisnoni pod CIDR gacha toraytiring

Qo'llab-quvvatlanadigan tuzatish istisnoni olib tashlash o'rniga toraytiradi: pod CIDR ni istisno qilib qoldiring va 10.x bo'shlig'ining qolganini tashlang. Bu ro'yxat agentning ConfigMap ida nonMasqueradeCIDRs ostida yashaydi, va uni o'zgartirish tahrir va undan keyin joylashtirishdir. Keng yozuvni klasterning haqiqiy pod oralig'i bilan almashtiring, klaster ichidagi trafik hali kerak bo'lsa boshqa xususiy bloklarni qoldiring, va sababingiz bo'lmasa resyncInterval ga tegmaslik. Qo'llang, agent podlari qayta ishga tushganini va yadro qoidalari o'zgarganini tasdiqlang.

Bu haqiqiy ta'sir radiusiga ega butun klaster bo'ylab o'zgarish. U kuchga kirgach, ilgari o'z pod manbasini saqlagan trafik endi nodega qayta yozilgan holda keladi, shuning uchun o'sha pod manzillariga bog'langan hamma narsa boshqa jo'natuvchini ko'radi. Jabrlanganlar pod manzillarini nomlaydigan loglar, ruxsat ro'yxatlari va mahalliy firewall qoidalari, va ular jimgina ishlamay qoladi. O'zgarishni tuzatish emas, xatti-harakat o'zgarishi deb e'lon qiling.

Bir nechta node puli bo'lgan klasterda agent ta'sirlangan podlar haqiqatan ishlaydigan nodelarga rejalashtirilganini tekshiring. DaemonSet bo'lmagan pul o'z eski qoidalarini saqlaydi, va ConfigMap da buni ko'rsatadigan hech narsa bo'lmaydi.

Muqobil va uning narxi

Boshqa variant pod manzillarini daxlsiz qoldiradi va yo'lga ular haqida o'rgatadi. Pod CIDR Cloud VPN trafik selektorlariga kiradi, va mahalliy tomonga javoblar qayerga borishini bilishi uchun unga qaytish marshruti kerak. Bu ba'zi xavfsizlik modellari xohlaydigan pod identifikatorini saqlaydi va qarshi tomon qabul qilishi kerak bo'lgan ham marshrutlash, ham firewall qamrovini kengaytiradi.

Ayirboshlash — o'qilishi va qamrov. Tarjima mahalliy tomonga har bir node uchun bitta manzil ko'rsatadi, uni ruxsat ro'yxatiga qo'shish oson va qaysi pod nima yuborganini yashiradi. Tarjima qilmasa, pod manzili boshdan oxirigacha saqlanadi, bu atributsiya uchun yaxshi, yangi diapazonni o'rganishi kerak bo'lgan yo'ldagi har bir qurilma uchun yomon. Hech bir variant Docker yoki CNI nuqsoni emas; ikkalasi ham operatsion hisob-fakturasi bo'lgan marshrutlash qarorlari. Jamoangiz to'lay oladigan variantni tanlang va sababini yozing.

Tekshiring va qaytaring

O'sha ushlashni yana ishga tushiring. Tahriringizdan keyin ham node darajasidagi ushlash pod manzilini chop etsa, ConfigMap nima desa ham qoidalar hech qachon o'zgarmagan. Sim — bu fakt; qolgani taxmin.

Keyin qarama-qarshi yo'nalishni tekshiring, chunki bu o'zgarishlarning yarmi faqat chiqish yo'nalishida tekshiriladi. Javob so'rov yuborgan node yoki podga yetib borishini va ilova faqat SYN olib qolmasdan tugaganini tasdiqlang. Javobsiz so'rovni ko'rsatadigan ushlash qarshi tomondagi marshrutlash muammosi, bu tomondagi masquerade muammosi emas.

Qaytarish — oldingi ConfigMap, xuddi shu tarzda qo'llanilgan, agent qayta ishga tushgani va qoidalar o'zgargani haqidagi xuddi shu tasdiq bilan. O'zgarish yozuvida bitta ma'lum so'rovning manba manzilini oldin va keyin saqlang, chunki aynan o'sha bitta satr o'zgarish aytganingizni qilganini isbotlaydi. GKE IP masquerade agent qo'llanmasi standart qiymatlar va ConfigMap maydonlarini hujjatlashtiradi. Agar joylashtirishdan keyin manba manzili o'zgarmasa, agent o'sha nodeda ishlamaydi va qancha YAML tahrirlansa ham tuzatilmaydi.