Использование переменных среды в спецификации развертывания Kubernetes

В настоящее время я использую спецификацию Kubernetes Deployment.yamlдля развертывания службы. Спецификация включает дословную ссылку на конкретный IP-адрес (помечен как <static-ip-address>показано ниже):

spec:
  type: LoadBalancer
  loadBalancerIP: <static-ip-address>

Я обеспокоен передачей информации, такой как пароли или IP-адреса, в удаленные репозитории Git. Можно ли избежать этого, например, используя переменные среды, например, со спецификацией развертывания и фактическим развертыванием примерно следующим образом:

spec:
   type: LoadBalancer
   loadBalancerIP: ${SERVICE_ADDRESS}

и

export SERVICE_ADDRESS=<static-ip-address>
kubectl create -f Deployment.yaml

Очевидно, этот специфический синтаксис еще не работает. Но возможно ли что-то подобное, и если да, то как?

Я бы предпочел не полагаться на отдельный инструмент обеспечения . Секретные секреты ConfigMapкажутся многообещающими, но, очевидно, они не могут быть использованы таким образом, который подходит для этой цели. Если бы я мог напрямую ссылаться на статический IP-адрес, который был определен с gcloud compute addresses create service-addressэтим, было бы лучше.

Гораздо проще / чище решение: envsubst

В deploy.yml:

LoadbalancerIP: $LBIP

Затем просто создайте свой env var и запустите kubectl следующим образом:

export LBIP="1.2.3.4"
envsubst < deploy.yml | kubectl apply -f -

Вы просто помещаете обычные переменные Bash в любой файл, который хотите использовать, в данном случае в манифест YAML, и начинаете читать этот файл. Он выведет файл с заменой переменных на их значения. Вы также можете использовать его для создания новых файлов, таких как:

envsubst < input.yml > output.yml

envsubstдоступно, например, в gettextпакете Ubuntu / Debian .

Было еще приятно простое решение: у меня есть Google Compute Адрес my-addressопределен, и я могу по- видимому , использовать его в спецификации сервиса , как так: loadBalancerIP: my-address.

При этом в качестве «внешнего» источника для IP-адресов и секретов для паролей больше не требуется инструмент обеспечения (или шаблоны) для моего простого варианта использования (в среде GKE).

ОБЕСПЕЧИВАЙТЕ СЕЙЧАС: Я решил использовать своего рода инструмент обеспечения, а именно «встроенный» sed, в конце концов.

My Deployment.yamlтеперь содержит «переменную шаблона», например, в

loadBalancerIP: $$EXTERNAL_IP

и я развертываю службу с, скажем, 1.2.3.4 в качестве внешнего IP-адреса с

cat Deployment.yaml | sed s/\$\$EXTERNAL_IP/1.2.3.4/ | kubectl create -f -

Вы можете написать простой препроцессор для подстановки переменных в ваших файлах yaml (или вы можете использовать jsonnet, чтобы выполнить то же самое в файлах конфигурации json).

Существует некоторая дискуссия о добавлении шаблонов непосредственно в конфигурацию Kubernetes, но она еще не реализована и не доступна.

Пока шаблоны не доступны, самый простой способ сделать это - запустить задание, которое использует API Kubernetes для обновления службы. Короткий сценарий оболочки в альпийском изображении в сочетании с секретом (содержащим IP-адрес) и картой конфигурации (содержащей шаблон) должен быть достаточно простым. Сложным является правильное использование функций аутентификации и авторизации на сервере.

/programming/30690186/how-do-i-access-the-kubernetes-api-from-within-a-pod-container приводит пример доступа к API. Очевидно, что вы захотите поместить POST в / api / v1 / namespaces / default / services вместо GET в этом примере.