Kubernetes v1.34: Використання init-контейнера для визначення змінних середовища застосунку

Зазвичай Kubernetes використовує ConfigMap і Secret для встановлення змінних середовища, що призводить до додаткових викликів API та складності. Наприклад, вам потрібно окремо керувати Podʼами ваших робочих навантажень і їх конфігураціями, забезпечуючи при цьому впорядковані оновлення як для конфігурацій, так і для Podʼів робочих навантажень.

Або ж ви, можливо, використовуєте контейнер, наданий постачальником, який вимагає змінних середовища (таких як ліцензійний ключ або одноразовий токен), але ви не хочете їх жорстко прописувати в коді або монтувати томи лише для того, щоб виконати завдання.

Якщо ви опинилися в такій ситуації, у вас тепер є новий (альфа) спосіб досягти цього. За умови, що у вашому кластері увімкнено функціональну можливість EnvFiles, ви можете вказати kubelet завантажити змінні середовища контейнера з тома (цей том повинен бути частиною Podʼа, до якого належить контейнер). Ця функціональна можливість дозволяє вам завантажувати змінні середовища безпосередньо з файлу з тома emptyDir без фактичного монтування цього файлу в контейнер. Це просте, але елегантне рішення для деяких дивовижно поширених проблем.

Що це все означає?

По суті, ця можливість дає змогу вказати контейнеру файл, який генерується initContainer, і доручити Kubernetes розібрати цей файл для встановлення змінних середовища. Файл розташовується в томі emptyDir (тимчасовому сховищі, яке існує так довго, як існує Pod), ваш основний контейнер не потребує монтування тома. kubelet прочитає файл і впровадить ці змінні, коли контейнер запуститься.

Як це працює

Ось простий приклад:

apiVersion: v1
kind: Pod
spec:
  initContainers:
  - name: generate-config
    image: busybox
    command: ['sh', '-c', 'echo "CONFIG_VAR=HELLO" > /config/config.env']
    volumeMounts:
    - name: config-volume
      mountPath: /config
  containers:
  - name: app-container
    image: gcr.io/distroless/static
    env:
    - name: CONFIG_VAR
      valueFrom:
        fileKeyRef:
          path: config.env
          volumeName: config-volume
          key: CONFIG_VAR
  volumes:
  - name: config-volume
    emptyDir: {}

Використання цього підходу дуже просте. Ви визначаєте свої змінні середовища в специфікації Podʼа, використовуючи поле fileKeyRef, яке вказує Kubernetes, де знайти файл і який ключ витягти. Сам файл має синтаксис, подібний до стандартного .env (на кшталт KEY=VALUE), і (принаймні у цій альфа-стадії) ви повинні переконатися, що він записується в том emptyDir. Інші типи томів не підтримуються для цієї можливості. Принаймні один init-контейнер повинен змонтувати цей том emptyDir (щоб записати файл), але основний контейнер не потребує цього — він просто отримує змінні, передані йому під час запуску.

Слово про безпеку

Хоча ця можливість підтримує обробку чутливих даних, таких як ключі або токени, слід зазначити, що її реалізація спирається на томи emptyDir, змонтовані в Pod. Тому оператори з доступом до файлової системи вузлів можуть легко отримати ці чутливі дані через шляхи тек Podʼа.

Якщо ви зберігаєте чутливі дані, такі як ключі або токени, за допомогою цієї можливості, переконайтеся, що політики безпеки вашого кластера ефективно захищають вузли від несанкціонованого доступу, щоб запобігти витоку конфіденційної інформації.

Підсумок

Ця можливість усуне ряд складних обхідних шляхів, які використовуються сьогодні, спростивши створення застосунків і відкриваючи нові можливості для використання. Kubernetes залишається гнучким і відкритим для відгуків. Скажіть нам, як ви використовуєте цю можливість або чого бракує.

• ←Попередня
• Наступна→