ولې 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 چلوونکی، او هغه لپ‌ټاپ چې نښلول یې هېر کړي. دا اسانه پېژندل کیږي ځکه چې یو انسان انتظار کوي۔

لږ ښکاره حالت هغه اتوماتیک دی چې 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 زنګ نه دی، لکه د node pool پراخېدل یا د لوړونې کتنه، او تایید کړئ چې بشپړیږي، نه دا چې به بشپړ شي فرض کړئ۔

پخوانی لیست ارزښت د بدلون ترڅنګ ثبت کړئ، او له تازه کولو وروسته اغېزمن ارزښت بیا ولولئ، نه دا چې ټایپ شوي امر باور وکړئ. د AKS د اجازه‌لرونکو IP سیمو اسناد هغه ملاتړ شوي پارامیټرونه او د پلیټفورم اړتیاوې لیستوي چې په هماغه لیست کې راځي، او دا هغه برخه ده چې ډېری د ټکټ توضیحات یې پریږدي۔