Պրոքսի միջավայրի փոփոխականների սահմանումը Kubernetes Pod-ում

Տեղադրեք աջակցվող HTTP պրոքսի փոփոխականները Kubernetes կոնտեյների սպեցիֆիկացիայում և ուղիղ կլաստերային ուղիները առանձնացրեք պատկերների ներբեռնման կարգավորումից։

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 պրոքսիների ցանկից մի վերջնակետ թեկնածու է այս կոնտեյների միջավայրի արժեքների համար։

Պատկերների ներբեռնումը տեղի է ունենում հավելվածի գործարկումից առաջ և կատարվում է հանգույցի կոնտեյների runtime-ի կողմից։ Pod-ի միջավայրը չի կարող կարգավորել այդ ավելի վաղ ռեեստրի կապը։

Վերջապես, HTTP պրոքսի փոփոխականները ազդում են միայն դրանք օգտագործող հաճախորդների վրա։ Դրանք չեն վերահասցեավորում Pod-ից եկող կամայական տվյալների բազայի, UDP կամ այլ socket երթևեկությունը։

Առնչվող հոդվածներ