Версії зберігання

Сервер API Kubernetes зберігає обʼєкти, використовуючи бекенд etcd-сумісного сховища (часто, сховище є самим etcd). Кожен обʼєкт серіалізується за допомогою певної версії типу API; наприклад, представлення v1 ConfigMap. Kubernetes використовує термін версія зберігання для опису того, як зберігається обʼєкт у вашому кластері.

API Kubernetes також покладається на автоматичне перетворення; наприклад, якщо у вас є HorizontalPodAutoscaler, то ви можете взаємодіяти з цим HorizontalPodAutoscaler, використовуючи будь-яку комбінацію версій v1 та v2 API HorizontalPodAutoscaler. Kubernetes відповідає за перетворення кожного API-запиту, щоб клієнти не бачили, яка версія насправді серіалізується.

Для адміністраторів кластерів версія зберігання обʼєкта є важливим поняттям для розуміння, оскільки саме вона звʼязує представлення обʼєкта у API з фактичним кодуванням у бекенд сховища. Це може бути важливим у разі, коли певне бінарне кодування обʼєкта має значення, наприклад для шифрування на диску або визнання API застарілим.

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

Версія обʼєкта повністю відокремленою від версії сховища. Наприклад, API-обʼєкти v1alpha1 та v1beta1 для одного й того ж ресурсу будуть закодовані однаково в сховищі, доки версія сховища не буде оновлена ​​між двома обʼєктами.

Версія зберігання у зіставлення ресурсів

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

Зчитування з API-сервера конвертуватиме збережені дані в API-представлення обʼєкта. Це дозволяє старим версіям сховища зберігатися необмежений час, доки не відбудуться оновлення обʼєкта. З іншого боку, записи конвертуватимуть збережений обʼєкт у нове представлення після оновлення.

Версії зберігання для власних ресурсів користувача

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

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

Наприклад, див. це CustomResourceDefinition для crontabs:

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: crontabs.example.com
spec:
  group: example.com
  # перелік версій, що підтримуються цим CustomResourceDefinition
  versions:
  - name: v1beta1
    # Кожна версія може бути увімкнена/вимкнена за допомогою прапорця Served.
    served: true
    # Одна і тільки одна версія повинна бути позначена як версія сховища.
    storage: true
    schema:
      openAPIV3Schema:
        type: object
        properties:
          host:
            type: string
          port:
            type: string
  - name: v1
    served: true
    storage: false
    schema:
      openAPIV3Schema:
        type: object
        properties:
          host:
            type: string
          port:
            type: string
          time:
            type: string
  conversion:
    strategy: None
  scope: Namespaced
  names:
    plural: crontabs
    singular: crontab
    kind: CronTab
    shortNames:
    - ct

Визначення API v1beta1 використовується як версія сховища, тобто будь-які оновлення або створення crontabs зберігатимуться разом зі схемою обʼєкта API v1beta1. У цьому випадку це фактично означатиме, що обʼєкт API v1 ніколи не зможе зберігати поле time, оскільки воно не є частиною визначення сховища. Ця схема використовується на рівні сховища як двійкове кодування самого обʼєкта. Спроба встановити дві версії як версію, що зберігається, одночасно вважається недійсною, оскільки це означатиме, що дві схеми даних вважатимуться дійсними способами зберігання обʼєктів одночасно.

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

Як версії сховища впливають на шифрування в стані спокою

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

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

Міграція на іншу версію сховища

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

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

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