فرض کړئ چې د خپرېدو namespace لا دمخه د app-outbound-proxy په نوم Secret لري. د هغې http_proxy او https_proxy کیلي ګانې هغه بشپړ پروکسي URL لري چې اپلیکیشن ورته اړتیا لري.

Helm 3 چارټ کولای شي په values.yaml کې یوازې د هغې Secret نوم وساتي:

outboundProxy:
  existingSecret: app-outbound-proxy

د پام وړ کانټینر په Deployment کېنډۍ کې کیلي ګانو ته مراجعه وکړئ:

env:
  - name: HTTP_PROXY
    valueFrom:
      secretKeyRef:
        name: {{ .Values.outboundProxy.existingSecret | quote }}
        key: http_proxy
  - name: HTTPS_PROXY
    valueFrom:
      secretKeyRef:
        name: {{ .Values.outboundProxy.existingSecret | quote }}
        key: https_proxy

دا د کانټینر مشخصاتو یوه برخه ده. Secret باید د Pod په namespace کې وي او دواړه یادې شوې کیلي ولري. د هغې ارزښتونه باید د ریښتیني پروکسي اورېدونکي پروتوکول، کوربه او پورټ وکاروي. د اپلیکیشن هغو عامه غوښتنو لپاره چې اجازه لري بې له تصدیق عامه پروکسي وکاروي، هغه URL د وړیا پروکسي لیست کې له مناسب کاندید څخه جوړ کړئ؛ اړین مستقیم استثناوې وساتئ.

د چارټ ارزښت نوم ورکوي؛ secretKeyRef د کانټینر چاپېریال ارزښتونه ورکوي. یوازې په shell کې چې helm چلوي HTTP_PROXY export کول دا env برخه Pod کېنډۍ ته نه زیاتوي.

Secret بدلول هم د ژوند دورې بدلون دی

کانټینر خپل چاپېریال نه تازه کوي کله چې د Secret ډاټا بدله شي. پلان شوی بیا پیل یا rollout تنظیم کړئ ترڅو نوي پیل شوي کانټینرونه تازه شوي ارزښتونه ترلاسه کړي. د همدې Secret نوم لاندې ډاټا بدلول په خپله د Deployment د Pod کېنډۍ نه سمونځای کوي.

اپلیکیشن باید ټاکل شوي پروکسي چاپېریال متغیرونه ملاتړ کړي. Helm ذخیرې ته لاسرسی او په نوډ کې image pull جلا کاروونکي دي چې د دې کانټینر چاپېریال له مرستې مخکې چلیږي.

اړوندې مقالې