Эмне үчүн kubectl VPN аркылуу иштейт, бирок AKS масштабдоону токтотот
Уруксат берилген IP диапазондору VPN серверинин коомдук чыгышын көрөт, иштеп чыгуучуну эмес. Платформа диапазондорун кошуңуз, болбосо өзгөртүүдөн кийин автоматташтыруу жана масштабдоо ишке ашпайт.
Сиз кеңсе VPNинин коомдук дарегин AKS API серверинин уруксат тизмесине кошосуз, жана kubectl иштейт. Бир жумадан кийин node pool масштабдоосу ишке ашпайт, CI тапшырмасы кластерге жете албайт, ал эми портал IP диапазондору жөнүндө эч нерсе айтпаган ката көрсөтөт. Уруксат тизмесин эч ким өзгөрткөн жок. Сиз күйгүзгөн көзөмөл — API серверинин алдындагы коомдук IP чыпкасы, ал ким чалып жатканын билбейт, чалуу кайсы даректен келгенин гана билет. VPN кластерге керектүү бир нече даректин бири, жана биринчи бузулган дал ошол болушу сейрек.
Уруксат тизмеси дарекке туура келет, адамга эмес
--api-server-authorized-ip-ranges CIDR блокторун кабыл алат, колдонуучуларды же топторду эмес. Иштеп чыгуучунун суроосу VPN серверинен Azure тарапка чыкканда, API сервериндеги баштапкы дарек — VPN серверинин коомдук чыгышы. Ошондуктан ошол VPNдеги ар бир адам бир жазууну бөлүшөт, ал эми VPNден тышкары ар ким аутентификация боло электе эле четке кагылат.
Бул жазуу сиз ойлогондон көбүрөөк адамды киргизерин да билдирет. VPN уруксаты бар мердигер, ошол концентратордогу жеке ноутбук жана бузулган аккаунт — баары бир даректен келет. Кластердин авторизациясы өзгөргөн жок, ошондуктан ролго негизделген кирүүнү көзөмөлдөө чалуучу эмне кыла аларын чечет, бирок уруксат тизмеси инсандык көзөмөл эмес жана андай сүрөттөлбөшү керек.
Биринчи бузулган нерсе адатта kubectl эмес
Уруксат тизмеси API серверинин коомдук акыркы чекитине колдонулат, ошондуктан тизмедеги даректерден тышкары бардык нерсе дароо иштебей калат. Ачык жабыр тартуучулар — VPN маршруту жок экинчи кеңсе, хостингдик түтүктөгү CI runner жана туташууну унутуп калган ноутбук. Аларды таануу оңой, анткени адам күтүп турат.
Анча ачык эмес учур — Azure же өз куралдарыңыз башкарган автоматташтыруу. Платформа баштаган айрым операциялар API серверине сиздин VPN эмес даректерден жетет, жана алардын бири тизме катуулатылгандан кийин дароо ишке ашпай баштаса, убакыт — белги. Интерактивдүү кирүү иштейт деп тизме толук деп ойлобоңуз; кластер бузулду деген тыянакка келүүдөн мурун функциянын аймагыңыз жана жазылууларыңыз үчүн эмнени талап кылганын текшериңиз.
Ишке ашпоо белгиси жардам берет. Эгер суроо эч качан аутентификацияга жетпесе, бул чыпка. Эгер ал аутентификациядан өтүп, анан уруксат катасын алса, чыпка өз ишин кылды, ал эми маселе уруксат тизмеси эч качан тийбеген ролго негизделген кирүүнү көзөмөлдөөдө.
Бүт тизмени бир буйрук менен түзүңүз
Жаңыртуу параметри жазуу кошуунун ордуна бүт тизмени алмаштырат, ошондуктан VPN дарегин гана алып жүргөн буйрук ал жерде болгон калгандын баарын үнсүз таштап кетет. Адегенде учурдагы маанини окуңуз, аны сактаңыз жана бириктирүүнү жөнөтүңүз:
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Буга таянуудан мурун VPN сервери үчүн резервделген коомдук IP колдонуңуз. Динамикалык дарек кайра туташканда өзгөрөт, жана ар бир өзгөртүү дагы уруксат берилген тармактан бирөө тизмени жаңыртпайынча команданы кластерден үнсүз кууп чыгарат. Ашыкчалык үчүн эки VPN чыгуу чекити болсо, экөөнү тең тизмелеңиз, анткени чыпкада артык көрүлгөн жол түшүнүгү жок.
Биринчи уруксат берилген аракет да сынак болушу үчүн өзгөртүүнү иреттеңиз. Жаңы тизмени жарыялаңыз, колдонуңуз жана дароо VPNден туташыңыз; тескери тартипте кылсаңыз, CIDR блогундагы катаны оңдоо үчүн эч ким API серверине жете албаган терезе калат.
Уруксат тизмеси эч качан эмнени камтыган эмес
Ал API серверин жеке кылбайт. Жеке кластер жеке акыркы чекитти жана жеке DNS колдонот, ал эми уруксат берилген диапазондор тизмеси аны алмаштырган көзөмөл эмес. Ал ошондой эле уруксат берилген чалуучу эмне кыла аларын өзгөртпөйт, ошондуктан агып кеткен админ kubeconfig каалаган уруксат берилген даректен дагы иштейт. Күбөлүктү коопсуздук чеги, ал эми тизмени тармактык ыңгайлуулук деп караңыз.
Анын жумуш жүктөрүнө эч кандай тиешеси жок. Тизме күйүк турганда да Pods жана Services ишин улантат, жана VPN аркылуу колдонмого жетүү өзүнчө маселе: кластер IPси гана бар Service ноутбук аны ача алышы үчүн дагы ички жүктөм теңдегичин, ingress же port-forward талап кылат. Бул эки долбоорду аралаштыруу иштеп чыгуучуларды чектейт деп ырастаган, бирок колдонмолорго карата эч нерсени чектебеген өзгөртүү билетин жаратат.
Эки тараптан тең текшериңиз, анан бир реалдуу операция аткарыңыз
VPNдеги жаңы кардар менен жана анын сыртындагы кардар менен сынаңыз. Сырткы аракет ат ажыратууда эмес, API серверинде четке кагылышы керек; эгер ат чечилбесе, сиз DNS сынап жатасыз жана чыпка жөнүндө эч нерсе үйрөнгөн жоксуз. Анан интерактивдүү kubectl чакыруу эмес операцияны аткарыңыз, мисалы node pool масштабдоо же жаңыртуу текшерүүсү, жана болот деп болжолдоонун ордуна аяктаганын ырастаңыз.
Өзгөртүүнүн жанында мурунку тизме маанисин жазып коюңуз жана тергиленген буйрукка ишенүүнүн ордуна жаңыртуудан кийин натыйжалуу маанини кайра окуңуз. AKSтин уруксат берилген IP диапазондору боюнча документтери колдоого алынган параметрлерди жана ошол эле тизмеге кирген платформа талаптарын тизмелейт, көпчүлүк билет сүрөттөмөлөрү ушул бөлүктү калтырып кетишет.