В настоящее время я использую спецификацию 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
Очевидно, что этот конкретный синтаксис еще не работает. Но возможно ли что-то подобное, и если да, то как?
Я бы предпочел не полагаться на отдельный инструмент обеспечения. Секретs и 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, и выполняете чтение этого файла. Он выведет файл с замененными env vars их значениями. Вы также можете использовать его для создания таких новых файлов:
envsubst < input.yml > output.yml
envsubst доступен, например, в Ubuntu / Debian gettext пакет.
Было еще одно приятно простое решение: у меня есть вычислительный адрес Google. my-address определен, и я, по-видимому, могу использовать его в спецификации службы следующим образом: loadBalancerIP: my-address.
Поскольку это «внешний» источник IP-адресов и секретов паролей, больше нет необходимости в инструменте подготовки (или шаблонах) для моего простого варианта использования (в среде GKE).
УСТАРЕЛИ СЕЙЧАС: Я решил использовать своего рода инструмент подготовки, а именно «встроенный» sed, после всего.
Мой 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 но он еще не реализован и не доступен.
До того как шаблоны доступны, самый простой способ сделать это - запустить задание, которое использует Kubernetes API для обновления сервиса. Короткий сценарий оболочки в изображении на основе alpine в сочетании с секретом (содержащий IP-адрес) и конфигурационной картой (содержащей шаблон) должен быть достаточно простым. Сложность заключается в правильном использовании функций аутентификации и авторизации apiserver.
https://stackoverflow.com/questions/30690186/how-do-i-access-the-kubernetes-api-from-within-a-pod-container дает пример доступа к API. Очевидно, вы захотите отправить POST на / api / v1 / пространства имен / по умолчанию / службы вместо GET в этом примере.