Как изменить файл манифеста при использовании Ansible для установки службы в кластере kubernetes?
Я пытаюсь автоматизировать создание кластера HA с помощью Ansible.
Обычно у меня есть два варианта установки балансировщика нагрузки (MetalLb): с манифестом или с helm.
Мне очень нравится, что у helm есть опция --values. Это полезно, потому что я могу добавить терпимость к динамикам MetalLB, таким образом, я могу развернуть их на узлах, на которых я не хочу развертывать задания.
При создании playbook я хочу иметь способ развертывания динамиков MetalLB с допуском, чтобы их можно было развернуть, но я не хочу устанавливать helm на одном из узлов.
Когда playbook запущен, я могу загрузить файл манифеста https://raw.githubusercontent.com/metallb/metallb/v0.13.7/config/manifests/metallb-native.yaml но теперь я хочу иметь возможность добавлять допуски. Как я могу сделать это, не загружая файл yaml и не редактируя его самостоятельно, что-то вроде опции --values в helm было бы неплохо
Похоже, Ansible поддерживает шаблоны Jinja2: docs.ansible.com/ansible/latest/collections/ansible/builtin/…
@mdaniel На этой неделе я читал кое-что о настройке, но не смог заставить это работать. Я также видел, что есть патч kubectl, но я не знаю, что лучше всего сделать в этом случае.
Я думаю, у вас есть два жизнеспособных решения: использовать Kustomize, для которого есть поддержка в Anisble, или использовать собственный механизм шаблонов Ansible, который предоставляет вам набор функций, почти идентичный тому, что вы получаете, используя шаблоны Helm.
@Fcmam5 Fcmam5 Я не видел ни одного параметра, позволяющего мне изменить файл, чтобы я мог добавить допуск
@larsks Я проверю это. Мне нужно сначала обновить заголовок, чтобы сделать его более конкретным для возможности, так как я отказываюсь от голосования...
Мой совет: закройте этот вопрос, изучите предоставленные предложения и вернитесь, когда попытаетесь реализовать решение и у вас возникнет конкретный технический вопрос. Так вы получите лучшие ответы.
Ответы 1
https://kubectl.docs.kubernetes.io/references/kustomize/kustomization/ излагает общую идею того, как будет работать kustomize: взять какие-то базы, применить к ним какие-то трансформации. В большинстве случаев стратегическое слияние ведет себя так, как ожидают люди, и именно так ведет себя kubectl patch, о котором вы упомянули1. Но работать со значениями массива при слиянии сложно, поэтому мне больше повезло с использованием JSON Patch array add support, что мы и будем использовать здесь.
# the contents of "kustomization.yaml" in the current directory
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- https://raw.githubusercontent.com/metallb/metallb/v0.13.7/config/manifests/metallb-native.yaml
patches:
- target:
version: v1
group: apps
kind: DaemonSet
namespace: metallb-system
name: speaker
patch: |-
- op: add
path: /spec/template/spec/tolerations/-
value: {"effect":"NoSchedule","key":"example.com/some-taint","operator":"Exists"}
Затем с помощью kubectl kustomize . мы видим результат от применения этого патча:
tolerations:
- effect: NoSchedule
key: node-role.kubernetes.io/master
operator: Exists
- effect: NoSchedule
key: node-role.kubernetes.io/control-plane
operator: Exists
- effect: NoSchedule
key: example.com/some-taint
operator: Exists
Очевидно, что если вы хотите полностью заменить допуски, вам может повезти со стратегическим слиянием, но, учитывая, что в вашем вопросе не указано, а этот случай является более сложным из двух, я начал с него.
FN 1: Я видел, что вы упомянули kubectl patch, но это для редактирования существующих ресурсов kubernetes, поэтому после того, как вы уже развернули свой metallb-native.yaml в кластере, только тогда kubectl patch сделает что-нибудь для вас. Использование kustomize является заменой helm, поскольку оно предназначено для того, чтобы манифесты переходили в кластер в правильном состоянии, а не исправляли его позже.
Насколько я знаю, kustomize — это «kubectl версия helm»; вы уже пробовали это?