Ինչու է kubectl-ը աշխատում VPN-ով, բայց AKS-ը դադարում է մասշտաբավորվել

Դուք ավելացնում եք գրասենյակի 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-ից. հակառակ կարգով անելը թողնում է պատուհան, որտեղ ոչ ոք չի կարող հասնել API սերվերին՝ CIDR բլոկի տպագրական սխալը ուղղելու համար։

Ինչ թույլատրելիների ցանկը երբեք չի ծածկել

Այն API սերվերը մասնավոր չի դարձնում։ Մասնավոր կլաստերն օգտագործում է մասնավոր վերջնակետ և մասնավոր DNS, և լիազորված միջակայքերի ցանկը այն կառավարումը չէ, որ փոխարինում է դրան։ Այն նաև չի փոխում, թե ընդունված զանգահարողն ինչ կարող է անել, ուստի արտահոսած ադմինիստրատորի kubeconfig-ը դեռ աշխատում է ցանկացած թույլատրված հասցեից։ Վկայականը դիտարկեք որպես անվտանգության սահման, իսկ ցանկը՝ որպես ցանցային հարմարավետություն։

Այն ոչ մի կապ չունի աշխատանքային բեռների հետ։ Pods-ը և Services-ը շարունակում են աշխատել ցանկը միացված վիճակում, և VPN-ով հավելվածին հասնելը առանձին խնդիր է՝ միայն կլաստերի IP ունեցող Service-ը դեռ պետք է ներքին բեռնվածքի հավասարակշռիչ, ingress կամ port-forward, նախքան նոթբուքը կկարողանա բացել այն։ Այս երկու ձևավորումները խառնելը ստեղծում է փոփոխության տոմս, որը պնդում է, թե սահմանափակում է մշակողներին, իսկ իրականում հավելվածների մասին ոչինչ չի սահմանափակում։

Ստուգեք երկու կողմից, ապա կատարեք մեկ իրական գործողություն

Փորձեք VPN-ում նոր հաճախորդով և դրանից դուրս գտնվող հաճախորդով։ Դրսի փորձը պետք է մերժվի API սերվերում, ոչ թե անունների լուծման ժամանակ. եթե անունը չի լուծվում՝ դուք փորձարկում եք DNS-ը և ոչինչ չեք սովորել զտիչի մասին։ Այնուհետև կատարեք գործողություն, որը ինտերակտիվ kubectl կանչ չէ, օրինակ node pool-ի մասշտաբավորում կամ թարմացման ստուգում, և հաստատեք, որ այն ավարտվում է, փոխանակ ենթադրելու, որ կավարտվի։

Պահեք նախորդ ցանկի արժեքը փոփոխության կողքին և թարմացումից հետո նորից կարդացեք արդյունավետ արժեքը՝ փոխանակ վստահելու մուտքագրված հրամանին։ AKS-ի փաստաթղթերը լիազորված IP միջակայքերի մասին թվարկում են աջակցվող պարամետրերը և հարթակի պահանջները, որոնք պատկանում են նույն ցանկին, և հենց այդ մասն են բաց թողնում տոմսերի նկարագրությունների մեծ մասը։