პროქსის გარემოს ცვლადების დაყენება Kubernetes Pod-ში

მოათავსეთ მხარდაჭერილი HTTP პროქსის ცვლადები Kubernetes კონტეინერის სპეციფიკაციაში და კლასტერის პირდაპირი მარშრუტები ცალკე შეინახეთ image-ის ჩამოტვირთვის კონფიგურაციისგან.

Kubernetes-ის კვანძზე მოქმედ ბრძანებას შეუძლია shell-პროქსის გამოყენება, მაშინ როცა ამ კვანძზე არსებულ Pod-ს პროქსის გარემო არ აქვს. კონტეინერის გარემოს განსაზღვრავს მისი image და 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-ის მეშვეობით, რათა ახალმა Pod-ებმა მიიღონ ის. მიუთითეთ ასევე პატარა ასოებით სახელები, როცა ამას რეალური კლიენტი მოითხოვს.

გვერდის ავლის სია საწყისი მაგალითია და არა კლასტერის ყველა მარშრუტის ჩამონათვალი. გამოიყენეთ კლასტერის რეალური DNS სუფიქსი და შიდა დანიშნულებები. სერვისის IP-ების გამოყენებად აპლიკაციებს შეიძლება დასჭირდეს სერვისის რეალური დიაპაზონები იმ სინტაქსში, რომელსაც მათი კლიენტი მხარს უჭერს.

init კონტეინერებს აქვთ საკუთარი კონტეინერის სპეციფიკაციები. დაამატეთ სასურველი კონფიგურაცია იქ, როცა ისინი გარე ჩამოტვირთვას ასრულებენ. საჯარო HTTP ჩამოტვირთვებისთვის HTTP პროქსის სიიდან ერთი საბოლოო წერტილი კანდიდატია ამ კონტეინერის გარემოს მნიშვნელობებისთვის.

image-ების ჩამოტვირთვა ხდება აპლიკაციის გაშვებამდე და მას ასრულებს კვანძის კონტეინერის runtime. Pod-ის გარემოს არ შეუძლია ამ ადრინდელი რეესტრთან კავშირის კონფიგურაცია.

დაბოლოს, HTTP პროქსის ცვლადები მოქმედებს მხოლოდ იმ კლიენტებზე, რომლებიც მათ იყენებენ. ისინი არ გადამისამართებს Pod-იდან მომავალ თვითნებურ მონაცემთა ბაზის, UDP ან სხვა socket ტრაფიკს.

დაკავშირებული სტატიები