Функции configMapRef и secretMapRef для envFrom и valueFrom доступны только для переменных среды, что означает, что их нельзя использовать в этом контексте. Требуемая функциональность недоступна в Vanilla Kubernetes с 1.18.0.
Однако это можно сделать. Helm и Kustomize , вероятно, являются двумя лучшими способами выполнить sh, но это также можно сделать с помощью sed или awk. Хелм - это шаблонизатор для манифестов Кубернетеса. Это значит, что вы создаете манифесты c generic, шаблонируете дельты между желаемыми манифестами с помощью манифестов c generi по переменным, а затем предоставляете файл переменных. Затем во время выполнения переменные из вашего файла переменных автоматически вставляются в шаблон для вас.
Еще один способ достижения sh, поэтому Kustomize. Что я лично рекомендую. Kustomize похож на Helm в том, что он имеет дело с созданием персонализированных манифестов из обобщенных c, но не делает это с помощью шаблонов. Kustomize уникален тем, что он выполняет исправления слияния между YAML или JSON файлами во время выполнения. Эти патчи называются оверлеями , поэтому их часто называют оверлейным механизмом, чтобы отличаться от традиционных шаблонных движков. Причиной является то, что Kustomize может использоваться с рекурсивными деревьями каталогов баз и оверлеев . Это делает его гораздо более масштабируемым для сред, в которых могут потребоваться десятки, сотни или тысячи манифестов из шаблонных обобщенных примеров c.
Так как мы это сделаем? Что ж, с Kustomize вы сначала определите файл kustomization.yml . Внутри вы определяете свои ресурсы. В этом случае myingress:
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- myingress.yml
Создайте каталог example и создайте в нем подкаталог с именем base. Создайте ./example/base/kustomization.yml и заполните его настройкой выше. Теперь создайте файл ./example/base/myingress.yml и заполните его примером файла myingress, который вы дали выше.
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: myingress
spec:
tls:
- hosts:
- config.MY_DOMAIN
secretName: mytls
rules:
- host: config.MY_DOMAIN
http:
paths:
- backend:
serviceName: myservice
servicePort: 3000
Теперь нам нужно определить наше первое наложение. Мы создадим две разные конфигурации домена, чтобы предоставить пример того, как работают оверлеи. Сначала создайте каталог ./example/overlays/domain-a и создайте в нем файл kustomization.yml со следующим содержимым:
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
bases:
- ../../../base/
patchesStrategicMerge:
- ing_patch.yml
configMapGenerator:
- name: config_a
literals:
- MY_DOMAIN='domain_a'
На этом этапе мы определили ing_patch.yml и config_a в этом файле. ing_patch.yml будет служить нашим входным патчем, а config_a будет нашим configMap. Однако в этом случае мы будем использовать функцию Kustomize, известную как configMapGenerator , вместо того, чтобы вручную создавать файлы configMap для отдельных литеральных пар key:value.
Теперь, когда мы сделали это, нам нужно сделать наш первый патч! Поскольку дельты в вашем входе довольно маленькие, это не так сложно. Создайте ./example/overlays/domain_a/ing_patch.yml и заполните его:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: myingress
spec:
tls:
- hosts:
- domain.a.com
rules:
- host: domain.a.com
Отлично, вы создали свой первый оверлей. Теперь вы можете использовать kubectl или kustomize для генерации результирующего манифеста для применения к серверу Kubernetes API.
- Kubectl Build:
kubectl kustomize ./example/overlays/domain_a - Kustomize Build:
kustomize build ./example/overlays/domain_a
Run one из вышеупомянутых команд Build и просмотрите STDOUT, произведенный в вашем терминале. Обратите внимание, что он содержит два файла, myingress и config? И myingress содержит конфигурацию домена, присутствующую в патче наложения?
Итак, на данный момент вы, вероятно, спрашиваете. Почему Kustomize существует, если Kubectl поддерживает функции по умолчанию? Итак, Kustomize изначально был запущен как внешний проект, и бинарный файл Kustomize часто запускает более новую версию, чем версия, доступная в Kubectl.
Следующим шагом является создание второго наложения. Итак, go впереди и cp ваше первое наложение: cp -r ./example/overlays/domain_a ./example/overlays/domain_b.
Теперь, когда вы сделали это, откройте ./example/overlays/domain_b/ing_patch.yml в текстовом редакторе и измените содержимое так, чтобы оно выглядело так:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: myingress
spec:
tls:
- hosts:
- domain.b.com
rules:
- host: domain.b.com
Сохраните файл и затем создайте два отдельных оверлея:
kustomize build ./example/overlays/domain_a
kustomize build ./example/overlays/domain_b
Обратите внимание, как каждый сгенерированный поток STDOUT изменяется в зависимости от патча, присутствующего в каталоге Overlay? Вы можете продолжить абстрагирование этого шаблона, сделав свои Базы наложениями для других баз. Или сделав ваши оверлеи основ для других оверлеев. Это может позволить вам масштабировать этот проект чрезвычайно мощным и эффективным способом. Примените их к вашему API-серверу, если вы sh:
kubectl apply -k ./example/overlays/domain_a
kubectl apply -k ./example/overlays/domain_b
Это только начало Kustomize на самом деле. Как вы могли догадаться, увидев поле configMapGenerator в файле kustomization.yml для каждого наложения, Kustomize имеет множество встроенных функций. Он может добавлять метки ко всем вашим ресурсам, он может переопределять их пространства имен или контейнер image information, et c.
Надеюсь, это поможет. Дайте мне знать, если у вас есть еще вопросы.