Kubernetes Pod ichida proksi muhit o'zgaruvchilarini sozlash

Qo'llab-quvvatlanadigan HTTP proksi o'zgaruvchilarini Kubernetes konteyner spetsifikatsiyasiga joylashtiring va klasterning to'g'ridan-to'g'ri marshrutlarini image tortish konfiguratsiyasidan alohida saqlang.

Kubernetes tugunidagi buyruq shell proksisidan foydalanishi mumkin, ammo o'sha tugundagi Podda proksi muhiti yo'q. Konteyner muhiti uning image'i va Pod konfiguratsiyasi bilan belgilanadi.

Ushbu o'zgaruvchilarni qo'llab-quvvatlaydigan ilova uchun mavjud konteyner yozuviga env ro'yxatini qo'shing:

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 ichida bu spec.template.spec.containers ichidagi tegishli konteyner ostida joylashadi. Yangi Pods uni olishi uchun ish yukini odatdagi rollout orqali yangilang. Haqiqiy mijoz talab qilsa, kichik harfli nomlarni ham taqdim eting.

Chetlab o'tish ro'yxati boshlang'ich misol, klasterning har bir marshruti ro'yxati emas. Klasterning haqiqiy DNS qo'shimchasi va ichki manzillaridan foydalaning. Xizmat IP'laridan foydalanadigan ilovalarga mijozlari qo'llab-quvvatlaydigan sintaksisda haqiqiy xizmat diapazonlari kerak bo'lishi mumkin.

Init konteynerlar o'z konteyner spetsifikatsiyalariga ega. Ular tashqi yuklab olishni amalga oshirganda u yerda mo'ljallangan konfiguratsiyani qo'shing. Ommaviy HTTP yuklab olishlar uchun HTTP proksi ro'yxatidan olingan oxirgi nuqta ushbu konteyner muhiti qiymatlari uchun nomzod.

Image tortish ilova ishga tushishidan oldin sodir bo'ladi va uni tugunning konteyner runtime'i bajaradi. Pod env bu oldingi reyestr ulanishini sozlay olmaydi.

Nihoyat, HTTP proksi o'zgaruvchilari faqat ularni ishlatadigan mijozlarga ta'sir qiladi. Ular Poddan chiqadigan har qanday ma'lumotlar bazasi, UDP yoki boshqa soket trafigini yo'naltirmaydi.

O'xshash maqolalar