Конфиг: библиотека базовых конфигурационных моделей

Конфиг — это встроенная базовая библиотека конфигурационных моделей Kusion (комбинация слов Kuison+config). В этом разделе будет показано, как создать собственную модельную библиотеку с использованием языка KCL на основе существующей конфигурации YAML. Также будет кратко рассказано о происхождении Конфига.

1.3.1 Моделирование на YAML

YAML — это язык, используемый для написания конфигурационных файлов, он лаконичен и мощен, в настоящее время является официальным предпочтительным форматом обмена конфигурациями Kubernetes. YAML гибкий, простой в написании и легко может привести к ошибкам! Например, в примере Nginx-Deployment на сайте Kubernetes:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    spec:
      containers:
      - image: nginx:1.14.2
        name: nginx
        ports:
        - containerPort: 80

Этот пример развёртывает сервис Nginx. Если мы случайно ошибёмся в какой-либо конфигурации и не сможем сразу обнаружить ошибку, это может привести к неизвестным рискам. На самом деле, для контекста Kubernetes у этого Deployment есть чёткое определение: каждое поле имеет имя, тип и значение, которые должны соответствовать определённым правилам. Разработка специализированного DSL (предметно-ориентированного языка) для повышения безопасности конфигурации — основная цель разработки языка программирования KCL.

Мы можем попробовать смоделировать конфигурацию Deployment с помощью KCL:

schema Deployment:
    final apiVersion: str = "apps/v1"
    final kind: str = "Deployment"

    metadata?: apis_ObjectMeta
    spec?: DeploymentSpec

Здесь мы определяем модель Deployment, используя ключевое слово schema. Поля apiVersion и kind имеют фиксированные типы и значения, поэтому мы используем final и присваиваем им значения по умолчанию. Для сложных полей metadata и spec мы описываем новые модели ObjectMeta и DeploymentSpec, где поля с вопросительными знаками в конце являются необязательными.

Модель ObjectMeta имеет множество атрибутов, здесь определены только необходимые:

schema ObjectMeta:
    name?: str
    namespace?: str

Аналогично, модель DeploymentSpec определяется следующим образом:

schema DeploymentSpec:
    replicas?: int
    selector: LabelSelector
    template: PodTemplateSpec

Поле replicas является необязательным, а поля selector и template продолжают использовать новые модели.

LabelSelector описывает параметры выбора меток, определяя следующее:

schema LabelSelector:
    matchLabels?: {str:str}

Где matchLabels — словарь, ключи и значения которого являются строками.

PodTemplateSpec определяет следующее:

schema PodTemplateSpec:
    metadata?: ObjectMeta
    spec?: PodSpec

schema PodSpec:
    containers: [Container]

schema Container:
    image?: str
    name: str
    ports?: [ContainerPort]

schema ContainerPort:
    containerPort: int

Здесь поле metadata использует уже определённую модель ObjectMeta, а поле spec описывается с помощью PodSpec и Container. Поле ports описывается моделью ContainerPort.

1.3.2 Переписывание конфигурации на основе модельной библиотеки

Теперь мы можем объединить приведённый выше код в файл apps/deployment.k как пользовательскую модельную библиотеку, которая представляет собой первую версию Конфига (открытая модельная библиотека Конфиг доступна в base.pkg.kusion_kubernetes.api.apps.v1 и предоставляет более полное определение модели Deployment).

Теперь можно создать файл main.k, который будет использовать эту модель для перестройки конфигурации:

import apps

demo = apps.Deployment {
    metadata.name = "nginx-deployment"
    spec = {
        replicas = 3
        selector.matchLabels = {
            app = "nginx"
        }
        template.spec.containers = [
            {
                name = "nginx"
                image = "nginx:1.14.2"
                ports = [
                    {containerPort = 80}
                ]
            }
        ]
    }
}

Хотя введённый код конфигурации KCL похож на исходный файл YAML, он обладает статической типизацией и возможностями проверки во время выполнения, предоставляемыми библиотекой Конфиг. Кроме того, его можно комбинировать с IDE-плагинами для улучшения эффективности кодирования и обеспечения большей безопасности написанного кода конфигурации. Затем команда kcl main.k может преобразовать модель в исходный файл YAML.

1.3.3 Происхождение Конфига

Из этого примера видно, что в коде модели больше абстракции, чем в бизнес-конфигурационном коде. Реальная модельная библиотека Конфига гораздо более обширна и обеспечивает более полную и гибкую статическую типизацию и проверку правил. Первоначальная цель Конфига заключалась в том, чтобы улучшить эффективность и опыт пользователей при работе с YAML. Мы надеемся упростить написание кода конфигурации для пользователей, инкапсулируя более сложные модели в единую модельную библиотеку.

Предшественником Конфига была система управления инфраструктурой как кодом (IaC) и GitOps в Ant, использующая Конфиг в качестве основной библиотеки. Ant начал хранить весь код IaC в одном централизованном репозитории Конфига, включая базовый код и бизнес-код. Причина использования одного большого репозитория для управления всем кодом IaC заключается в том, что Ant имеет различные основные субъекты разработки для разных пакетов кода, что может вызвать проблемы с управлением версиями и пакетами, требуя от платформы поддержки, подобной компиляционной платформе. В большом репозитории код бизнес-логики и базовый код находятся в одном большом репозитории, поэтому управление зависимостями между версиями проще, и платформа может легче обрабатывать его, просто находя уникальный каталог и файлы репозитория, обеспечивая общий код, управление и удобство поиска, изменения и обслуживания (большой репозиторий также является моделью, используемой Google и другими ведущими компаниями в области Интернета).

Несмотря на то, что большой репозиторий упрощает управление версиями, у него также есть много недостатков: например, большой размер репозитория может увеличить нагрузку на сеть при загрузке, что делает его неподходящим для открытого исходного кода и распределённой асинхронной совместной разработки. Поэтому, когда проект Kusion стал полностью открытым исходным кодом, мы внесли значительные изменения и разделение в Конфиг, сохранив связанные с Kubernetes базовые модели и отделив тесно связанный с внутренним бизнесом Ant код (лучшие практики для бизнес-кода будут продемонстрированы в примерах сценариев использования). Таким образом, открытая версия Конфига может рассматриваться как базовая инфраструктурная модельная библиотека Kusion для облачной экосистемы Kubernetes, помогающая пользователям развертывать и обслуживать приложения в экосистеме Kubernetes с меньшим количеством кода конфигурации. Одновременно мы надеемся совместно с сообществом улучшать и совершенствовать базовую модельную библиотеку инфраструктуры для экосистемы Kubernetes.