# ConfigMaps LLMS index: [llms.txt](/llms.txt) ---

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

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

Увага:

ConfigMap не забезпечує конфіденційності або шифрування. Якщо дані, які ви хочете зберегти, конфіденційні, використовуйте Secret замість ConfigMap, або використовуйте додаткові (зовнішні) інструменти для збереження ваших даних в таємниці.
## Мотивація {#motivation} Використовуйте ConfigMap для визначення конфігураційних даних окремо від коду застосунку. Наприклад, уявіть, що ви розробляєте застосунок, який ви можете запускати на своєму власному компʼютері (для розробки) і в хмарі (для обробки реального трафіку). Ви пишете код, який переглядає змінну середовища з назвою `DATABASE_HOST`. Локально ви встановлюєте цю змінну як `localhost`. У хмарі ви встановлюєте її так, щоб вона посилалася на Service, який надає доступ до компонента бази даних вашому кластеру. Це дозволяє вам отримати образ контейнера, який працює в хмарі, і у разі потреби налагоджувати той самий код локально.

Примітка:

ConfigMap не призначено для зберігання великих обсягів даних. Дані, збережені в ConfigMap, не можуть перевищувати 1 MiB. Якщо потрібно зберегти налаштування, які перевищують це обмеження, варто розглянути можливість монтування тому або використання окремої бази даних або файлової служби.
## Обʼєкт ConfigMap {#configmap-object} ConfigMap — це обʼєкт API, який дозволяє зберігати конфігураційні дані для використання іншими обʼєктами. На відміну від більшості обʼєктів Kubernetes, у яких є `spec`, ConfigMap має поля `data` та `binaryData`. Ці поля приймають пари ключ-значення як свої значення. Обидва поля `data` і `binaryData` є необовʼязковими. Поле `data` призначене для зберігання рядків UTF-8, тоді як поле `binaryData` призначене для зберігання бінарних даних у вигляді рядків, закодованих у base64. Назва ConfigMap повинна бути дійсним [піддоменом DNS](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). Кожний ключ у полі `data` або `binaryData` повинен складатися з алфавітно-цифрових символів, `-`, `_` або `.`. Ключі, збережені в `data`, не повинні перетинатися з ключами у полі `binaryData`. Починаючи з версії v1.19, ви можете додати поле `immutable` до визначення ConfigMap, щоб створити [незмінний ConfigMap](#configmap-immutable). ## ConfigMaps та Podʼи {#configmaps-and-pods} Ви можете написати `spec` Podʼа, який посилається на ConfigMap і конфігурує контейнер(и) в цьому Podʼі на основі даних з ConfigMap. Pod і ConfigMap повинні бути в тому самому namespace.

Примітка:

spec статичного Podʼа не може посилатися на ConfigMap або на інші обʼєкти API.
Ось приклад ConfigMap, який має деякі ключі з одними значеннями, та інші ключі, де значення виглядає як фрагмент формату конфігурації. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: game-demo data: # ключі у вигляді властивостей; кожен ключ зіставляється з простим значенням player_initial_lives: "3" ui_properties_file_name: "user-interface.properties" # ключі у формі файлів game.properties: | enemy.types=aliens,monsters player.maximum-lives=5 user-interface.properties: | color.good=purple color.bad=yellow allow.textmode=true ``` Є чотири різних способи використання ConfigMap для конфігурації контейнера всередині Podʼа: 1. В команді та аргументах контейнера 1. У змінних середовища для контейнера 1. Додайте файл до тому тільки для читання, щоб застосунок міг його читати 1. Напишіть код для виконання всередині Podʼа, який використовує Kubernetes API для читання ConfigMap Ці різні методи підходять для різних способів моделювання даних, які споживаються. Для перших трьох методів kubelet використовує дані з ConfigMap при запуску контейнер(ів) для Podʼа. Четвертий метод означає, що вам потрібно написати код для читання ConfigMap та його даних. Однак, оскільки ви використовуєте прямий доступ до Kubernetes API, ваш застосунок може підписатися на отримання оновлень, коли змінюється ConfigMap, і реагувати на це. Завдяки прямому доступу до Kubernetes API цей технічний підхід також дозволяє вам отримувати доступ до ConfigMap в іншому namespace. Ось приклад Podʼа, який використовує значення з `game-demo` для конфігурації Podʼа:
configmap/configure-pod.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: configmap-demo-pod
spec:
  containers:
    - name: demo
      image: alpine
      command: ["sleep", "3600"]
      env:
        # Визначення змінної середовища
        - name: PLAYER_INITIAL_LIVES # Зверніть увагу, що регістр відрізняється тут
                                     # від назви ключа в ConfigMap.
          valueFrom:
            configMapKeyRef:
              name: game-demo           # ConfigMap, з якого отримується це значення.
              key: player_initial_lives # Ключ для отримання значення.
        - name: UI_PROPERTIES_FILE_NAME
          valueFrom:
            configMapKeyRef:
              name: game-demo
              key: ui_properties_file_name
      volumeMounts:
      - name: config
        mountPath: "/config"
        readOnly: true
  volumes:
  # Ви встановлюєте томи на рівні Pod, а потім монтуєте їх в контейнери всередині цього Pod
  - name: config
    configMap:
      # Вкажіть назву ConfigMap, який ви хочете змонтувати.
      name: game-demo
      # Масив ключів з ConfigMap, які треба створити як файли
      items:
      - key: "game.properties"
        path: "game.properties"
      - key: "user-interface.properties"
        path: "user-interface.properties"
ConfigMap не розрізняє значення властивостей з окремих рядків та багаторядкові файлоподібні значення. Важливо, як Podʼи та інші обʼєкти використовують ці значення. У цьому прикладі визначення тому та монтування його всередину контейнера `demo` як `/config` створює два файли, `/config/game.properties` та `/config/user-interface.properties`, навіть якщо в ConfigMap є чотири ключі. Це тому, що визначення Podʼа вказує на масив `items` в розділі `volumes`. Якщо ви взагалі опустите масив `items`, кожен ключ у ConfigMap стане файлом з тією ж назвою, що й ключ, і ви отримаєте 4 файли. ## Використання ConfigMap {#using-configmaps} ConfigMap можуть бути змонтовані як томи даних. ConfigMap також можуть бути використані іншими частинами системи, не піддаючись безпосередньому впливу Podʼа. Наприклад, ConfigMap можуть містити дані, які повинні використовуватися іншими частинами системи для конфігурації. Найпоширеніший спосіб використання ConfigMap — це конфігурація налаштувань для контейнерів, які запускаються в Podʼі в тому ж namespace. Ви також можете використовувати ConfigMap окремо. Наприклад, ви можете зустріти надбудови або оператори, які налаштовують свою поведінку на основі ConfigMap. ### Використання ConfigMaps як файлів у Podʼі {#using-configmaps-as-files-from-a-pod} Щоб використовувати ConfigMap в томі в Podʼі: 1. Створіть ConfigMap або використовуйте наявний. Декілька Podʼів можуть посилатися на один ConfigMap. 2. Змініть ваше визначення Podʼа, щоб додати том в `.spec.volumes[]`. Назвіть том будь-яким імʼям, та встановіть поле `.spec.volumes[].configMap.name` для посилання на ваш обʼєкт ConfigMap. 3. Додайте `.spec.containers[].volumeMounts[]` до кожного контейнера, який потребує ConfigMap. Вкажіть `.spec.containers[].volumeMounts[].readOnly = true` та `.spec.containers[].volumeMounts[].mountPath` на невикористану назву теки, де ви хочете, щоб зʼявився ConfigMap. 4. Змініть ваш образ або командний рядок так, щоб програма шукала файли у цій теці. Кожен ключ в ConfigMap `data` стає імʼям файлу в `mountPath`. Ось приклад Podʼа, який монтує ConfigMap в том: ```yaml apiVersion: v1 kind: Pod metadata: name: mypod spec: containers: - name: mypod image: redis volumeMounts: - name: foo mountPath: "/etc/foo" readOnly: true volumes: - name: foo configMap: name: myconfigmap ``` Кожен ConfigMap, який ви хочете використовувати, слід зазначити в `.spec.volumes`. Якщо в Podʼі є кілька контейнерів, то кожен контейнер потребує свого власного блоку `volumeMounts`, але потрібно лише одне поле `.spec.volumes` на ConfigMap. #### Змонтовані ConfigMaps оновлюються автоматично {#mounted-configmaps-are-updated-automatically} Коли ConfigMap, що наразі використовується в томі, оновлюється, ключі, що зіставляються, в кінцевому підсумку також оновлюються. Kubelet перевіряє, чи змонтований ConfigMap є свіжим під час кожної синхронізації. Однак Kubelet використовує свій локальний кеш для отримання поточного значення ConfigMap. Тип кешу настроюється за допомогою поля `configMapAndSecretChangeDetectionStrategy` в [структурі KubeletConfiguration](/docs/reference/config-api/kubelet-config.v1beta1/). ConfigMap можна поширити за допомогою watch (типово), на основі ttl або шляхом перенаправлення всіх запитів безпосередньо до сервера API. Отже, загальна затримка від моменту оновлення ConfigMap до моменту, коли нові ключі зʼявляться в Podʼі може становити стільки, скільки й періодична затримка kubelet + затримка поширення кешу, де затримка поширення кешу залежить від обраного типу кешу (вона дорівнює затримці поширення watch, ttl кешу або нулю відповідно). ConfigMap, що використовуються як змінні оточення, не оновлюються автоматично і потребують перезапуску Podʼа.

Примітка:

Контейнер, який використовує ConfigMap як том з монтуванням subPath, не отримує оновлення ConfigMap.
### Використання ConfigMaps як змінних середовища {#using-configmaps-as-environment-variables} Щоб використовувати ConfigMap у змінних середовища в Podʼі: 1. Для кожного контейнера у вашій специфікації Podʼа додайте змінну середовища для кожного ключа ConfigMap, який ви хочете використовувати, до поля `env[].valueFrom.configMapKeyRef`. 1. Змініть ваш образ та/або командний рядок так, щоб програма шукала значення у вказаних змінних середовища. Ось приклад визначення ConfigMap як змінної середовища Podʼа: Цей ConfigMap (myconfigmap.yaml) містить дві властивості: username та access_level: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: myconfigmap data: username: k8s-admin access_level: "1" ``` Наступна команда створить обʼєкт ConfigMap: ```shell kubectl apply -f myconfigmap.yaml ``` Наступний Pod використовує вміст ConfigMap як змінні середовища:
configmap/env-configmap.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: env-configmap
spec:
  containers:
    - name: app
      command: ["/bin/sh", "-c", "printenv"]
      image: busybox:latest
      envFrom:
        - configMapRef:
            name: myconfigmap
Поле `envFrom` вказує Kubernetes створити змінні середовища з джерел, вкладених у нього. Внутрішній `configMapRef` посилається на ConfigMap за його імʼям і вибирає всі його пари ключ-значення. Додайте Pod до свого кластера, а потім перегляньте його логи, щоб побачити виведення команди printenv. Це має підтвердити, що дві пари ключ-значення з ConfigMap були встановлені як змінні середовища: ```shell kubectl apply -f env-configmap.yaml ``` ```shell kubectl logs pod/env-configmap ``` Вивід буде подібний до цього: ```console ... username: "k8s-admin" access_level: "1" ... ``` Іноді Pod не потребуватиме доступу до всіх значень у ConfigMap. Наприклад, можна мати інший Pod, який використовує тільки значення username з ConfigMap. Для цього випадку можна використовувати синтаксис `env.valueFrom`, який дозволяє вибирати окремі ключі в ConfigMap. Імʼя змінної середовища також може відрізнятися від ключа в ConfigMap. Наприклад: ```yaml apiVersion: v1 kind: Pod metadata: name: env-configmap spec: containers: - name: envars-test-container image: nginx env: - name: CONFIGMAP_USERNAME valueFrom: configMapKeyRef: name: myconfigmap key: username ``` У Podʼі, створеному з цього маніфесту, ви побачите, що змінна середовища `CONFIGMAP_USERNAME` встановлена на значення `username` з ConfigMap. Інші ключі з даних ConfigMap не будуть скопійовані у середовище. Важливо зауважити, що набір символів, дозволених для назв змінних середовища в Podʼах, [обмежений](/docs/tasks/inject-data-application/define-environment-variable-container/#using-environment-variables-inside-of-your-config). Якщо будь-які ключі не відповідають правилам, ці ключі не будуть доступні вашому контейнеру, хоча Pod може бути запущений. ## Незмінні ConfigMap {#configmap-immutable}
СТАН ФУНКЦІОНАЛУ: Kubernetes v1.21 [stable]
Функція Kubernetes _Immutable Secrets та ConfigMaps_ надає опцію встановлення індивідуальних Secret та ConfigMap як незмінних. Для кластерів, що інтенсивно використовують ConfigMap (принаймні десятки тисяч унікальних монтувань ConfigMap до Podʼів), запобігання змінам їх даних має наступні переваги: - захищає від випадкових (або небажаних) оновлень, які можуть призвести до відмов застосунків - покращує продуктивність кластера шляхом значного зниження навантаження на kube-apiserver, закриваючи спостереження за ConfigMap, які позначені як незмінні. Ви можете створити незмінний ConfigMap, встановивши поле `immutable` в `true`. Наприклад: ```yaml apiVersion: v1 kind: ConfigMap metadata: ... data: ... immutable: true ``` Після того, як ConfigMap позначено як незмінний, відмінити цю зміну або змінити вміст поля `data` або `binaryData` неможливо. Ви можете лише видалити та створити ConfigMap знову. Оскільки поточні Podʼи підтримують точку монтування для видаленого ConfigMap, рекомендується створити заново ці Podʼи. ## Що далі - Дізнайтеся більше про [Secret](/docs/concepts/configuration/secret/). - Прочитайте про [Налаштування Podʼа для використання ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/). - Дізнайтеся про [зміну ConfigMap (або будь-якого іншого обʼєкту Kubernetes)](/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/) - Прочитайте про [12-факторні застосунки](https://12factor.net/), щоб зрозуміти мотивацію для відокремлення коду від конфігурації.