Монтирование структуры файла конфигурации в модуле заданий - PullRequest
Новая
       11

Монтирование структуры файла конфигурации в модуле заданий

0 голосов
/ 29 мая 2020

В нашем приложении у нас будет задание Kubernetes, которое будет bootstrap микросервисов на основе набора (устаревших) файлов конфигурации. Они находятся в устаревшем приложении, упакованном в виде файловой структуры, и мы хотели бы сохранить это, чтобы нам не нужно было поддерживать разные упаковки файлов конфигурации для варианта Kubernetes и устаревшего варианта, а также есть много унаследованный код, который мы все еще хотим использовать, который ожидает эту файловую структуру. ConfigMap - это плоское хранилище ключей и значений.

Мы используем Helm, поэтому идея состоит в том, что микросервис будет включать задание и применять его с помощью хуков. Как лучше всего сопоставить структуру файла конфигурации с модулем задания? Можете ли вы легко создать том, заполнить его файловой структурой, а затем смонтировать его в модуле заданий?

Ответы [ 2 ]

0 голосов
/ 29 мая 2020

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

Теоретически вы можете использовать configmaps, но вы также упомянули "... есть много устаревшего кода" , и поэтому вам необходимо знать, что configmaps имеет ограничение в 1 МБ (чтобы быть более конкретным c Я должен упомянуть, что это ограничение применяется etcd, а не самим configmap ). Теперь, предполагая, что это не проблема, вам нужно будет хранить каждый файл как один ключ в configmap, а затем монтировать каждый файл отдельно в свой каталог. Конечно, вы можете автоматизировать этот процесс, так как это не идеальное решение при наличии большого количества файлов.

Теперь отвечая на ваш вопрос:

Можете ли вы легко создать том, заполнить его с файловой структурой, а затем смонтировать его в модуле заданий?

Вероятно, самый простой способ достичь указанного результата - это смонтировать том emptyDir и заполнить его с помощью initContainers. Контейнер инициализации может извлечь папку конфигурации (либо из репозитория git, либо из какого-либо другого репозитория файлов) и сохранить ее в томе emptyDit, который позже будет смонтирован в фактический контейнер. Вот пример того, как это будет выглядеть.

То, что вы предлагаете, также является допустимым решением, но оно требует использования постоянных томов и не всегда может быть необходимо. Но если вы решите использовать его, все, что вам нужно сделать, это использовать то же имя тома и использовать сохранить для поля persistentVolumeReclaimPolicy.

Вам также необходимо запомнить этот код контейнера init (hook) должен быть идемпотентным. В частности, код, записывающий в EmptyDirs (постоянный том), должен быть подготовлен к тому, что выходные файлы уже существуют.

0 голосов
/ 29 мая 2020

Вы можете создать конфигурационную карту из файла или каталога и добавить данные configmap в том . Это создаст файлы только для чтения из ключей configmap в смонтированном каталоге. Однако сохранить структуру каталогов в Configmap невозможно, так как это приведет к ошибке 

... a valid config key must consist of alphanumeric characters, '-', '_' or '.' (e.g. 'key.name',  or 'KEY_NAME',  or 'key-name', regex used for validation is '[-._a-zA-Z0-9]+')

configmap.yaml 

apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config
data:
  some.properties: |
    foo=bar
  other.properties: |
    baz=qux

pod. yaml 

apiVersion: v1
kind: Pod
metadata:
  name: test
spec:
  containers:
    - name: test-container
      image: k8s.gcr.io/busybox
      args:
      - /bin/sh
      - -c
      - ls -la /etc/config; cat /etc/config/some/some.properties; cat /etc/config/other.properties
      volumeMounts:
      - name: config-volume
        mountPath: /etc/config
  volumes:
    - name: config-volume
      configMap:
        name: special-config
        items:
        - key: some.properties
          path: some/some.properties
        - key: other.properties
          path: other.properties

проверка журналов с помощью kubectl logs test

 drwxrwxrwx    3 root     root            95 May 29 09:14 .
 drwxr-xr-x    1 root     root            20 May 29 09:14 ..
 drwxr-xr-x    3 root     root            42 May 29 09:14 ..2020_05_29_09_14_34.418889646
 lrwxrwxrwx    1 root     root            31 May 29 09:14 ..data -> ..2020_05_29_09_14_34.418889646
 lrwxrwxrwx    1 root     root            23 May 29 09:14 other.properties -> ..data/other.properties
 lrwxrwxrwx    1 root     root            11 May 29 09:14 some -> ..data/some
 foo=bar
 baz=qux
...