په Kubernetes کې د Pod VPN د وتلو دروازې په وړاندې: تونل د چا دی؟
Pod خپله شبکهیي نومتشکیل دی، نو ریښتینی انتخاب دا دی چې کوم پوښ تونل لري: د هر کاري بار لپاره هویت یا د CNI لخوا لارښوونکی وتل چې یو ګډ سرچینه لري.
تاسو vpn-gateway نومي Pod ځای پرځای کوئ، یو ازموینهیی کلاینټ د هغې پتې ته اشاره کوئ او ګورئ چې پاکټونه ورک کیږي. په مانیفست کې هیڅ غلط نه دی او kubelet هیڅ شکایت نه لري. لامل جوړښتي دی، نه د ترتیباتو: Kubernetes هر Pod ته خپله شبکهیي نومتشکیل ورکوي، نو نوم، لیبل یا ګډ API نومتشکیل هیڅ نه بدلوي چې پاکټونه چېرته ځي. نو د دې پریکړه چې VPN ترافیک له کلسټر څخه څنګه ووځي، د مالکیت په اړه له پوښتنې سره پیل کیږي، نه د کانټینر انځورونو سره.
دوه میتودونه ډیری ریښتیني ځای پرځای کول پوښي، او دوی د یو بل بدلیدونکي نه دي. یو تونل د کاري بار په خپل شبکهیي نومتشکیل کې ځای پرځای کوي. بل د CNI څخه غواړي چې ټاکل شوی ترافیک د ټاکل شوې دروازې نوډ له لارې تېر کړي. دوی په بېلابېلو لارو ناکام کیږي، په بېلابېلو لارو سکیل کیږي او بېلابېلو ټیمونو ته ځواب وایي، ځکه چې د کانټینر پوښتنه معمولاً هغه بحثونه رامنځته کوي چې هیڅکله نه حل کیږي.
د Pod پوله یو نومتشکیل دی، نه د ټوپ وهلو کوربه
د Linux شبکهیي نومتشکیل خپل انټرفیسونه، پتې، لارې او د اورېدونکي دیوال قواعد لري، او هر Pod یو ترلاسه کوي. د هغه Pod دننه کانټینرونه ورسره یوځای کیږي، او همدا لامل دی چې یو مرستندوی کانټینر کولی شي هغه لارې بیا ولیکي چې اپلیکیشن وروسته تعقیبوي. ګاونډی Pod ورته ښکاره خو په بشپړه توګه جلا سټاک لري. هیڅ ګډ جدول نشته چې د دروازې Pod یې میراث واخلي، او نه د یو نومتشکیل څخه بل ته د ترافیک ناڅرګنده سپارل کیږي.
همدا لامل دی چې د دروازې-Pod بڼه یوازې هغه وخت کار کوي کله چې پورته یو څه واقعاً هغې ته پاکټونه واستوي: یو Service، په نوډ کې ثابته لاره یا په CNI کې د لارښوونې پالیسي. یوازې پته هیڅ نه جذبوي.
د هر Pod لپاره تونل څه اخلي او څه لګښت لري
هغه تونل چې د کاري بار په نومتشکیل کې ځي، هغه کاري بار ته خپل کلاینټ هویت ورکوي، چې ډیری لیرې لاسرسي خدمتونه یې د یوې ناستې اجازه یا حساب مخکې غواړي. د زیان وړانګه هم سیمهیی پاتې کیږي: مات تونل یو Deployment بندوي، نه هغه ګډه لاره چې هر څه یې کاروي. چې څنګه ځي دا د تطبیق پورې اړه لري، او همدلته خلک غلط اټکل کوي.
هغه ترتیبات چې یوازې د کرنل حالت ته اړتیا لري کولی شي په init کانټینر کې پای ته ورسي او ووځي. د کاروونکي فضا ډیمون چې باید د Pod په ټول ژوند کې ژوندی پاتې شي هغه بیا پیلیدونکې init کانټینر بڼه غواړي چې په Kubernetes 1.29 کې د اصلي سایډکار په توګه معرفي شوه، او دا توپیر د خوند نه، د تونل له تطبیق څخه راځه. د دې ماډل لګښت تکرار دی: هر نقل تصدیق کوي، خپله تونل پته ترلاسه کوي او د لیرې ناستې ځای نیسي، نو د اتوماتیک سکیل پېښه د لینک بلې خوا ته د ظرفیت پېښه کیږي. یو اعتبارنامه په ټولو نقلونو کې کاپي کول هغه لګښت نه لیرې کوي، دا د پلټنې لاره لیرې کوي. وړتیاوې هم همدا کتنه مستحق دي، ځکه هغه تونل چې په خپل نومتشکیل کې NET_ADMIN غواړي، هیڅ دلیل نه لري چې د privileged: true بېلګې ټول کوربه واک میراث واخلي.
کله چې CNI وتل لري
که CNI یې ملاتړ وکړي، د وتلو دروازه د کاري بار او هدف حد له مخې ترافیک ټاکي، بیا یې د یوې وړاندوینې وړ سرچینې پتې لاندې د ټاکلو نوډونو له لارې استوي. د Cilium نسخه عمومي مرجع ده، او د هغې اسناد روښانه وایي چې دا ځانګړتیا ځانګړي Cilium ترتیبات او د سم انټرفیسونو او پتو سره سمبال شوي دروازې نوډونه غواړي. دا د Pod له جوړیدو وروسته یوه پیلنیزه موده هم یادوي چې پکې لارښوونه لا نه تطبیقیږي، او دا د ډیزاین ننوتل دي نه پښلیک.
هغه ځنډ د خپلې ژمنې په وړاندې ولولئ. که قاعده دا وي چې هیڅ ترافیک د بلې لارې له مخې نه شي وتلی، نو هغه نوی Pod چې د تشې په جریان کې استوي لا دمخه یې مات کړی، نو د پیل ترتیب خپل ځواب غواړي: اپلیکیشن تر هغه ونیسئ چې پالیسي تطبیق شي، یا هغه کړکۍ ومنئ او اسناد یې کړئ.
ادعا تنګه وساتئ. د وتلو دروازه یوه لاره ټاکي او ژباړي. دا VPN نه پای ته رسوي، او پرته له شاته ملاتړ شوې اړیکې کلسټر ستاسو د لیرې شبکې کلاینټ نه جوړوي.
| Question | Per-Pod tunnel | CNI egress gateway |
|---|---|---|
| Who holds the client identity | Each workload | The gateway, shared |
| What scaling changes | Enrollment and sessions per replica | Throughput and capacity per node |
| What the remote side sees | Distinct addresses | One translated source |
| Failure scope | One Deployment | Every workload behind the gateway |
ژباړه په خاموشۍ بدلوي چې لیرې خوا څه ویني
کله چې دروازه سرچینه بیا ولیکي، د هر Pod پتې ورکې کیږي، نو د هویت پر بنسټ اجازهلیست د یوې ګډې پتې پر بنسټ لیست کیږي. دا تبادله ده نه نیمګړتیا: د ساتنې لپاره کم قواعد، کله چې یو څه بد چلند وکړي نو ډبله نسبت.
د اپلیکیشن کچې تصدیق او د غوښتنو ثبت باید هغه څه وړي چې شبکه نور یې نه رپوټ کوي. د دروازې ظرفیت او بدلون د ګډ بنسټیز جوړښت په توګه وګورئ، ځکه د یو نوډ بیا پیل اوس هر هغه کاري بار قطع کوي چې شاته وي، او د بېرته راتلو لاره ژر وګورئ: لیرې پای باید پوه شي چې ژباړل شوې پتې ته څنګه ورسیږي، معمولاً د یوې لارې یا NAT له لارې چې یو انسان، نه مانیفست، باید مالک وي. د پتو پلان هم دلته راځي، ځکه نښتي کلسټر او لیرې سیمې دواړه ماډلونه ماتوي او IPv6 منل د متضاد پلان عذر نه دی.
د مالکیت له مخې پریکړه وکړئ، بیا هغه ناکامي وازموئ چې ژمنه یې کړې وه
د هر Pod لپاره تونل هغه وخت وټاکئ کله چې لیرې خدمت جلا کاري بارونه تصدیقوي، کله چې یوازې څو Deployment لینک ته اړتیا لري، او کله چې ناکامي باید سیمهیی پاتې شي. دروازه هغه وخت وټاکئ کله چې شبکهیي ټیم لا دمخه لاره لري، کله چې ډیری کاري بارونه یو هدف شریکوي، او کله چې ثابته سرچینه پته د ټول تمرین هدف وي.
هر څنګه وي، ثابت حالت نه، هغه ځانګړتیا وګورئ چې تاسو پلورلې وه. یو Pod جوړ کړئ، سمدلاسه یې استولو ته پرېږدئ، او که ژمنه دا وه چې له تونل څخه هیڅ نه تښتي نو لومړۍ ثانیې وګورئ. پنځو نقلونو ته سکیل کړئ او که ژمنه د هر کاري بار لپاره هویت و، هغه ناستې وشمېرئ چې لیرې پای یې رپوټ کوي. دا دوه کتنې د مانیفست له بیاکتنې څخه ډیر ژر د میتود حدود ښکاره کوي، او تاسو ته وایي چې راتلونکې پېښه د کوم ټیم ده.