kubectl VPN પર કેમ કામ કરે છે પણ AKS સ્કેલિંગ કેમ બંધ કરે છે

તમે ઓફિસ VPNનું જાહેર સરનામું AKS API સર્વરની મંજૂર સૂચિમાં ઉમેરો છો, અને kubectl કામ કરે છે. એક અઠવાડિયા પછી નોડ પૂલનું સ્કેલ-અપ નિષ્ફળ જાય છે, CI કાર્ય ક્લસ્ટર સુધી પહોંચી શકતું નથી, અને પોર્ટલ એવી ભૂલ બતાવે છે જેમાં IP શ્રેણીઓનો કોઈ ઉલ્લેખ નથી. કોઈએ મંજૂર સૂચિ બદલી નથી. તમે ચાલુ કરેલું નિયંત્રણ API સર્વરની સામેનું જાહેર IP ફિલ્ટર છે, અને તે જાણતું નથી કે કોણ કૉલ કરે છે, ફક્ત જાણે છે કે કૉલ કયા સરનામેથી આવ્યો. VPN એ ક્લસ્ટરને જરૂરી કેટલાક સરનામાંઓમાંથી એક છે, અને પહેલું તૂટે તે ભાગ્યે જ એ હોય છે.

મંજૂર સૂચિ સરનામા સાથે મેળ ખાય છે, વ્યક્તિ સાથે નહીં

--api-server-authorized-ip-ranges તે CIDR બ્લોક સ્વીકારે છે, વપરાશકર્તાઓ કે જૂથો નહીં. જ્યારે ડેવલપરની વિનંતી VPN સર્વર છોડીને Azure તરફ જાય છે, ત્યારે API સર્વર પરનું સ્રોત સરનામું VPN સર્વરનું જાહેર ઇગ્રેસ હોય છે. તેથી તે VPN પરની દરેક વ્યક્તિ એક જ એન્ટ્રી વહેંચે છે, અને VPNની બહારની કોઈપણ વ્યક્તિને પ્રમાણીકરણ થાય તે પહેલાં જ નકારી કાઢવામાં આવે છે.

એનો અર્થ એ પણ છે કે એન્ટ્રી તમે ધારો છો તેના કરતાં વધુ લોકોને પ્રવેશ આપે છે. VPN ઍક્સેસ ધરાવતો કોન્ટ્રાક્ટર, એ જ કન્સેન્ટ્રેટર પરનું અંગત લેપટોપ અને ચેપી થયેલું ખાતું — બધા એક જ સરનામેથી આવે છે. ક્લસ્ટર અધિકૃતિ બદલાતી નથી, તેથી ભૂમિકા-આધારિત ઍક્સેસ નિયંત્રણ હજી પણ નક્કી કરે છે કે કૉલર શું કરી શકે, પણ મંજૂર સૂચિ ઓળખ નિયંત્રણ નથી અને તેને ક્યારેય એમ વર્ણવવી ન જોઈએ.

પહેલું તૂટે તે સામાન્ય રીતે kubectl નથી

મંજૂર સૂચિ API સર્વરના જાહેર એન્ડપોઇન્ટ પર લાગુ થાય છે, તેથી તમારા સૂચિબદ્ધ સરનામાંઓની બહારનું બધું તરત જ કામ કરવાનું બંધ કરે છે. સ્પષ્ટ ભોગ બનનારા છે VPN રૂટ વગરની બીજી ઓફિસ, હોસ્ટેડ પાઇપલાઇનમાં CI રનર, અને જોડાવાનું ભૂલી ગયેલું લેપટોપ. આને ઓળખવા સહેલા છે કારણ કે કોઈ માણસ રાહ જોઈ રહ્યું છે.

ઓછું સ્પષ્ટ કિસ્સો એ ઓટોમેશન છે જેને 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 દ્વારા એપ્લિકેશન સુધી પહોંચવું અલગ સમસ્યા છે: જે Service પાસે ફક્ત ક્લસ્ટર IP છે તેને લેપટોપ ખોલી શકે તે પહેલાં હજી પણ આંતરિક લોડ બેલેન્સર, ingress અથવા port-forward ની જરૂર છે. આ બે ડિઝાઇન ભેગી કરવાથી એવું ફેરફાર-ટિકિટ બને છે જે ડેવલપરોને મર્યાદિત કરવાનો દાવો કરે છે અને વાસ્તવમાં એપ્લિકેશનો વિશે કંઈપણ મર્યાદિત કરતું નથી.

બંને બાજુથી ચકાસો, પછી એક વાસ્તવિક કામગીરી ચલાવો

VPN પર નવા ક્લાયન્ટ સાથે અને તેની બહારના ક્લાયન્ટ સાથે પરીક્ષણ કરો. બહારનો પ્રયાસ નામ રિઝોલ્યુશન પર નહીં, API સર્વર પર નકારવો જોઈએ; જો નામ રિઝોલ્વ ન થાય, તો તમે DNSનું પરીક્ષણ કરી રહ્યા છો અને ફિલ્ટર વિશે કંઈ શીખ્યા નથી. પછી એવી કામગીરી ચલાવો જે ઇન્ટરેક્ટિવ kubectl કૉલ ન હોય, જેમ કે નોડ પૂલ સ્કેલ અથવા અપગ્રેડ તપાસ, અને તે પૂર્ણ થશે એમ માનવાને બદલે પૂર્ણ થયાની ખાતરી કરો.

ફેરફારની બાજુમાં અગાઉની સૂચિનું મૂલ્ય નોંધો, અને ટાઇપ કરેલા આદેશ પર ભરોસો કરવાને બદલે અપડેટ પછી અસરકારક મૂલ્ય ફરી વાંચો. AKS અધિકૃત IP શ્રેણી દસ્તાવેજીકરણ સમર્થિત પરિમાણો અને એ જ સૂચિમાં આવતી પ્લેટફોર્મની આવશ્યકતાઓની સૂચિ આપે છે, અને આ એ જ ભાગ છે જે મોટાભાગના ટિકિટ વર્ણનો છોડી દે છે.