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

Зазвичай Kubernetes використовує ConfigMaps і Secrets для встановлення змінних середовища, що призводить до додаткових викликів 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. Інші типи томів не підтримуються для цієї функції. Принаймні один контейнер ініціалізації повинен змонтувати цей том emptyDir (щоб записати файл), але основний контейнер не потребує цього — він просто отримує змінні, передані йому під час запуску.

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

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

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

Підсумок

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

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