Блог

У меня есть схема управления, которая устанавливает различные ресурсы kubernetes для развертывания моего приложения. Одним из таких ресурсов является развертывание, которое имеет два варианта: один для клиентской части приложения и один для серверной части, так что на самом деле это два развертывания. Большинство их манифестов (файлов yaml) абсолютно одинаковы, единственное важное отличие заключается в том, что каждый ссылается на другую configmap, чтобы иметь определенные значения для некоторых свойств configmap (в частности, тип: клиент / сервер и количество реплик). Это кажется не очень эффективным, поскольку я дублирую код для развертывания, но я нашел способ сделать это. С другой стороны, для конфигурационных карт я использовал функцию шаблона Helm ( {{ include }} ), поэтому у меня есть «основной» шаблон configmap, который содержит все общее содержимое, и две отдельные конфигурационные карты, определяющие различия для каждого развертывания и включающие основной шаблон.

Пока все хорошо, хотя может быть некоторое ненужное дублирование кода, и в этом случае я не знаю, как улучшить.

Проблема в том, что в игру вступили несколько вариантов двух вышеупомянутых развертываний. Например, я могу захотеть развернуть модуль клиентского типа со свойством X, имеющим определенное значение, и два модуля серверного типа со свойством X, имеющим другое значение. Поэтому, следуя моему подходу, мне пришлось бы начать создавать больше файлов yaml для развертывания, чтобы охватить все возможные комбинации: type= client amp; X = Y, type= client amp; X = Z, type= server amp; X = Y, type = server amp; X = Z и так далее. И единственная цель этого — иметь возможность указать, сколько реплик я хочу для каждого вида или комбинации.

Есть ли какой-либо способ (с использованием Helm или другой связанной с Kubernetes среды) иметь один файл yaml развертывания и иметь возможность устанавливать его несколько раз, указывая только изменяющиеся свойства и количество реплик для этого варианта?

Например:

Я хочу:

• 3 реплики с «type = client» и «X = 1»
• 2 реплики с «type = server» и «X = 1»
• 4 реплики с «type = client» и «X = 2»
• 1 реплики, которые имеют «type= server» и «X = 3»

где type и X — это свойства (данные) в некоторой конфигурационной карте.

Надеюсь, это достаточно ясно, в противном случае, пожалуйста, дайте мне знать, спасибо.

В Helm есть несколько способов подойти к этому вопросу. Вам нужно перенести настройки на уровень конфигурации Helm (они будут находиться в values.yaml или предоставляться с помощью подобного механизма helm install --set ); вы не можете извлечь их из ConfigMap.

Один из подходов заключается в том, чтобы ваша диаграмма управления устанавливала только один экземпляр Развертывания и соответствующую конфигурационную карту. Иметь один templates/deployment.yaml файл, который содержит такие строки, как:

 name: {{ .Release.Name }}-{{ .Chart.Name }}-{{ .Values.type }}-{{ .Values.X }}

replicas: {{ .Values.replicas }}

env:
  - name: TYPE
    value: {{ .Values.type }}
  - name: X
    value: {{ quote .Values.X }}
 

Затем вы можете развернуть несколько его копий:

 helm install c1 . --set type=client --set X=1 --set replicas=3
helm install s1 . --set type=server --set X=1 --set replicas=2
 

Вы упоминаете, что вы уже создаете похожие конфигурационные карты с использованием шаблонов, и вы также можете использовать тот же подход для любой структуры YAML. Шаблон принимает один параметр, и один из возможных приемов заключается в передаче списка в качестве этого параметра. Другая важная деталь, которую следует помнить, заключается в том, что имена верхнего уровня, подобные like .Values , на самом деле являются поиском по полю в специальном объекте . , который может быть переназначен в нескольких контекстах, поэтому вам может потребоваться явно передавать и ссылаться на объект верхнего уровня.

Допустим, вашему шаблону нужны значения верхнего уровня, а также некоторые дополнительные параметры конфигурации:

 {{- define "a.deployment" -}}
{{- $top := index . 0 -}}
{{- $config := index . 1 -}}
metadata:
  name: {{ include "chart.name" $top }}-{{ $config.type }}-{{ $config.X }}
{{ end -}}
 

Обратите внимание, что мы распаковываем два значения из параметра single list, а затем передаем $top в тех местах, где мы могли бы ожидать передачи . в качестве параметра.

У вас может быть файл верхнего уровня для каждого варианта этого. Например, templates/deployment-server-1.yaml может содержать:

 {{- $config := dict "type" "server" "X" "1" -}}
{{- include "a.deployment" (list . $config) -}}
 

Вот . объект верхнего уровня; мы встраиваем его и конфигурационный словарь в один параметр списка, чтобы соответствовать ожиданиям шаблона. Вы могли бы использовать любые шаблонные конструкции в dict вызове, если бы некоторые из значений были указаны в конфигурации Helm.

Наконец, на самом деле не существует правила, согласно которому файл YAML содержит только один объект. Если в вашей конфигурации Helm просто перечислены варианты, вы можете перебирать их в цикле и выдавать их все:

 {{-/* range will reassign . so save its current value */-}}
{{- $top := . -}}
{{- range .Values.installations -}}
{{-/* Now . is one item from the installations list */-}}
{{-/* This is the YAML start-of-document marker: */-}}
---
{{ include "a.deployment" (list $top .) -}}
{{- end -}}
 

Вы бы просто перечислили все варианты и настройки в Helm values.yaml (или, опять же, в файле, предоставленном извне helm install -f more-values.yaml ).:

 installations:
  - type: client
    X: 1
    replicas: 3
  - type: server
    X: 1
    replicas: 2