Наладка зменных асяроддзя проксі ў Pod Kubernetes

Змясціце падтрыманыя зменныя HTTP-проксі ў спецыфікацыю кантэйнера Kubernetes і захавайце прамыя маршруты кластара асобна ад канфігурацыі загрузкі вобразаў.

Каманда на вузле Kubernetes можа выкарыстоўваць проксі абалонкі, а 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-проксі ўплываюць толькі на кліентаў, якія іх выкарыстоўваюць. Яны не перанакіроўваюць адвольны трафік баз даных, UDP або іншых сокетаў з Pod.

Падобныя артыкулы