Nega kubectl VPN orqali ishlaydi, lekin AKS masshtablashni to'xtatadi

Ofis VPN-ining ommaviy manzilini AKS API serverining ruxsat etilgan ro'yxatiga qo'shasiz va kubectl ishlaydi. Bir hafta o'tib node pool masshtablash muvaffaqiyatsiz bo'ladi, CI ishi klasterga yeta olmaydi va portal IP diapazonlari haqida hech narsa aytmaydigan xatoni ko'rsatadi. Ruxsat etilgan ro'yxatni hech kim o'zgartirmagan. Siz yoqqan nazorat API server oldidagi ommaviy IP filtrdir va u kim qo'ng'iroq qilayotganini bilmaydi, faqat qo'ng'iroq qaysi manzildan kelganini biladi. VPN klasterga kerak bo'ladigan bir nechta manzillardan biri va birinchi buziladigan aynan o'sha bo'lishi kamdan-kam.

Ruxsat etilgan ro'yxat manzilga mos keladi, shaxsga emas

--api-server-authorized-ip-ranges CIDR bloklarini qabul qiladi, foydalanuvchilar yoki guruhlarni emas. Dasturchining so'rovi VPN serveridan Azure tomon chiqqanda, API serverdagi manba manzil VPN serverining ommaviy chiqishidir. Shuning uchun o'sha VPNdagi har bir kishi bitta yozuvni bo'lishadi va VPN tashqarisidagi har kim autentifikatsiya boshlanishidan oldin rad etiladi.

Bu yozuv siz o'ylagandan ko'ra ko'proq odamni kiritishini ham anglatadi. VPN ruxsatiga ega pudratchi, o'sha konsentratordagi shaxsiy noutbuk va buzilgan hisob — barchasi bir manzildan keladi. Klaster avtorizatsiyasi o'zgarmagan, shuning uchun rolga asoslangan kirish nazorati qo'ng'iroq qiluvchining nima qilishi mumkinligini hal qiladi, lekin ruxsat etilgan ro'yxat shaxsni tasdiqlash nazorati emas va hech qachon shunday ta'riflanmasligi kerak.

Birinchi buziladigan narsa odatda kubectl emas

Ruxsat etilgan ro'yxat API serverining ommaviy oxirgi nuqtasiga qo'llaniladi, shuning uchun siz sanab o'tgan manzillardan tashqaridagi hamma narsa darhol ishlashdan to'xtaydi. Aniq jabrlanganlar VPN marshrutisiz ikkinchi ofis, xostingli quvurdagi CI ijrochisi va ulanishni unutgan noutbuk. Ularni tanib olish oson, chunki bir kishi kutmoqda.

Kamroq aniq holat — Azure yoki o'zingizning vositalaringiz boshqaradigan avtomatlashtirish. Platforma boshlagan ba'zi operatsiyalar API serverga sizning VPNingiz bo'lmagan manzillardan yetib boradi va ulardan biri ro'yxat qattiqlashtirilgandan so'ng darhol muvaffaqiyatsiz bo'la boshlasa, vaqt ishora bo'ladi. Interaktiv kirish ishlayapti deb ro'yxatni to'liq deb hisoblamang; klaster buzilgan degan xulosaga kelishdan oldin funksiya sizning hududingiz va obunalaringiz uchun nima talab qilishini tekshiring.

Muvaffaqiyatsizlik belgisi yordam beradi. So'rov hech qachon autentifikatsiyaga yetib bormasa, bu filtr. Agar u autentifikatsiyadan o'tib, keyin ruxsat xatosini olsa, filtr o'z ishini qilgan va muammo ruxsat etilgan ro'yxat hech qachon tegmaydigan rolga asoslangan kirish nazoratida.

Butun ro'yxatni bitta buyruqda tuzing

Yangilash parametri yozuv qo'shish o'rniga butun ro'yxatni almashtiradi, shuning uchun faqat VPN manzilini olib yuruvchi buyruq u yerda bo'lgan hamma narsani jimgina tashlab yuboradi. Avval joriy qiymatni o'qing, uni saqlang va birlashmani yuboring:

az aks show -g rg-app -n aks-prod \
  --query apiServerAccessProfile.authorizedIpRanges -o tsv

az aks update -g rg-app -n aks-prod \
  --api-server-authorized-ip-ranges 203.0.113.10/32,198.51.100.0/24

Bunga tayanishdan oldin VPN server uchun zaxiralangan ommaviy IPdan foydalaning. Dinamik manzil qayta ulanganda o'zgaradi va har bir o'zgarish jamoadan klasterdan jimgina qulflab qo'yadi, toki kimdir hali ham ruxsat etilgan tarmoqdan ro'yxatni yangilamaguncha. Ortiqchalik uchun ikkita VPN chiqish nuqtasi bo'lsa, ikkalasini ham sanang, chunki filtrda afzal yo'l tushunchasi yo'q.

O'zgartirishni shunday tartiblang ki, birinchi ruxsat etilgan urinish sinov ham bo'lsin. Yangi ro'yxatni e'lon qiling, qo'llang va darhol VPNdan ulanib oling; teskari tartibda qilish CIDR blokidagi xatoni tuzatish uchun hech kim API serverga yetib bora olmaydigan oyna qoldiradi.

Ruxsat etilgan ro'yxat hech qachon qamramagan narsa

U API serverni shaxsiy qilmaydi. Shaxsiy klaster shaxsiy oxirgi nuqta va shaxsiy DNSdan foydalanadi va ruxsat etilgan diapazonlar ro'yxati uni almashtiruvchi nazorat emas. U shuningdek qabul qilingan qo'ng'iroq qiluvchining nima qilishi mumkinligini o'zgartirmaydi, shuning uchun oqib ketgan administrator kubeconfig har qanday ruxsat etilgan manzildan hali ham ishlaydi. Hisob ma'lumotlarini xavfsizlik chegarasi, ro'yxatni esa tarmoq qulayligi deb biling.

Uning ish yuklamalariga hech qanday aloqasi yo'q. Ro'yxat yoqilgan bo'lsa ham Pods va Services ishlashda davom etadi va VPN orqali ilovaga yetib borish alohida muammo: faqat klaster IPsiga ega Service noutbuk uni ochishi uchun hali ham ichki yuk balanslagichi, ingress yoki port-forward talab qiladi. Bu ikki dizaynni aralashtirish dasturchilarni cheklashini da'vo qiladigan, aslida esa ilovalar haqida hech narsani cheklamaydigan o'zgartirish chiptasini keltirib chiqaradi.

Ikki tomondan tekshiring, keyin bitta haqiqiy operatsiyani bajaring

VPNda yangi mijoz va uning tashqarisidagi mijoz bilan sinab ko'ring. Tashqaridagi urinish nomni aniqlashda emas, API serverda rad etilishi kerak; agar nom hal qilinmasa, siz DNSni sinab ko'ryapsiz va filtr haqida hech narsa o'rganmadingiz. Keyin interaktiv kubectl chaqiruvi bo'lmagan operatsiyani bajaring, masalan node pool masshtablash yoki yangilanishni tekshirish, va bo'ladi deb taxmin qilish o'rniga tugaganini tasdiqlang.

Oldingi ro'yxat qiymatini o'zgartirish yonida yozib qo'ying va terilgan buyruqqa ishonish o'rniga yangilashdan keyin samarali qiymatni qayta o'qing. AKSning ruxsat etilgan IP diapazonlari bo'yicha hujjati qo'llab-quvvatlanadigan parametrlarni va o'sha ro'yxatga tegishli platforma talablarini sanab o'tadi, ko'p chipta tavsiflari aynan shu qismni tashlab ketadi.