په Kubernetes نوډ کې یو حکم کولای شي shell پراکسي وکاروي، خو په همدې نوډ کې Pod هیڅ د پراکسي چاپېریال نلري. د کانټینر چاپېریال د هغه د عکس او د Pod ترتیباتو په مرسته ټاکل کېږي.

د هغه اپلیکیشن لپاره چې دا متغیرونه ملاتړ کوي، په خپل موجود کانټینر ننوتلو کې د env لیست اضافه کړئ:

env:
  - name: HTTP_PROXY
    value: http://proxy.example:8080
  - name: HTTPS_PROXY
    value: http://proxy.example:8080
  - name: NO_PROXY
    value: localhost,127.0.0.1,kubernetes.default.svc,.svc,.cluster.local

په Deployment کې، دا د spec.template.spec.containers په مربوط کانټینر لاندې راځي. کاري بار د هغه د عادي rollout له لارې تازه کړئ ترڅو نوي Pods یې ترلاسه کړي. کله چې ریښتینی کلاینټ غوښتنه وکړي نو د کوچنیو تورو نومونه هم وړاندې کړئ.

د تېرېدو لیست یو پیلنی مثال دی، نه د کلسټر د هرې لارې لیست. د کلسټر ریښتینی DNS پای ضمیمه او داخلي منزلونه وکاروئ. هغه اپلیکیشنونه چې د خدماتو IP کاروي ممکن په هغه نحو کې چې د دوی کلاینټ ملاتړ کوي د خدماتو ریښتیني حدودو ته اړتیا ولري.

د init کانټینرونو خپل کانټینر مشخصات لري. کله چې دوی بهرنی ډاونلوډ کوي هلته ټاکل شوې ترتیبات اضافه کړئ. د عمومي HTTP ډاونلوډونو لپاره، د HTTP پراکسي لیست څخه یو endpoint د دې کانټینر چاپېریال ارزښتونو لپاره نوماند دی.

د عکس راکشول د اپلیکیشن له چلېدو دمخه پېښېږي او د نوډ د کانټینر runtime لخوا ترسره کېږي. Pod env نشي کولای هغه پخوانی د ثبت سره تړاو تنظیم کړي.

په پای کې، د HTTP پراکسي متغیرونه یوازې هغو کلاینټونو ته اغېزه کوي چې دوی یې کاروي. دوی د Pod څخه هر ډول د ډیټابیس، UDP یا نور socket ترافیک نه بدلوي.

اړوندې مقالې