Для новых проектов вам нужно только начать использовать технологический стек Kusion для написания и управления конфигурацией инфраструктуры, мы предоставляем руководство пользователя для различных сред выполнения. Однако, если у вас уже есть существующая инфраструктура, возможно, у вас есть накопленные модели конфигурации и данные. В этом случае Kusion также предоставляет некоторые инструменты автоматизации, которые помогут вам быстро выполнить миграцию.

Для пользователей Kubernetes Kusion предоставляет инструмент преобразования моделей кода из OpenAPI в KCL, который позволяет напрямую повторно использовать более сотни основных моделей Kubernetes. Для пользователей Istio и случаев, когда встроенные модели Kubernetes не поддерживаются, Kusion также поддерживает автоматическое создание CRD в виде кода модели KCL.

5.1.1 Спецификация Kubernetes OpenAPI

С версии Kubernetes 1.4 была введена альфа-поддержка спецификации OpenAPI (ранее известная как swagger 2.0 до пожертвования Open API Initiative). С версии Kubernetes 1.5 Kubernetes может автоматически извлекать модели из исходного кода и генерировать спецификацию OpenAPI, обеспечивая автоматическую синхронизацию между спецификацией и документацией с операциями/моделями.

Кроме того, Kubernetes CRD использует проверку OpenAPI v3.0 для описания пользовательских схем (за исключением встроенных атрибутов apiVersion, kind и metadata). На этапах создания и обновления CR, APIServer будет использовать эту схему для проверки содержимого CR.

5.1.2 Поддержка KCL OpenAPI

Инструмент KCLOpenAPI поддерживает извлечение и генерацию схемы KCL из определений OpenAPI/CRD. В спецификации KCLOpenapi явно определены отношения сопоставления между спецификацией OpenAPI и языком KCL.

При установке пакета инструментов Kusion инструмент KCLOpenapi устанавливается по умолчанию. Использование и примеры инструмента KCLOpenAPI можно найти в документации.

5.1.3 Миграция от моделей Kubernetes к Kusion

Полное определение спецификации OpenAPI для встроенных моделей Kubernetes хранится в файле openapi-spec Kubernetes. Используя этот файл в качестве входных данных, инструмент KCLOpenapi может генерировать соответствующие версии всех моделей schema. Далее, на примере сценария развёртывания, демонстрируется процесс миграции от Kubernetes к Kusion. Предположим, что ваш проект использует определение Deployment Kubernetes для настройки развёртывания. Миграция на Kusion требует следующих шагов:

5.1.3.1 Преобразование модели Kubernetes Deployment в схему KCL

В файле swagger.json версии openapi-spec Kubernetes 1.23 можно найти определения, связанные с моделью apps/v1.Deployment. Фрагмент выглядит следующим образом:

{
    "definitions": {
        "io.k8s.api.apps.v1.Deployment": {
            "description": "Deployment enables declarative updates for Pods and ReplicaSets.",
            "properties": {
                "apiVersion": {
                    "description": "APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources",
                    "type": "string"
                },
                "kind": {
                    "description": "Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds",
                    "type": "string"
                },
                "metadata": {
                    "$ref": "#/definitions/io.k8s.apimachinery.pkg.apis.meta.v1.ObjectMeta",
                    "description": "Standard object's metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata"
                },
                "spec": {
                    "$ref": "#/definitions/io.k8s.api.apps.v1.DeploymentSpec",
                    "description": "Specification of the desired behavior of the Deployment."
                },
                "status": {
                    "$ref": "#/definitions/io.k8s.api.apps.v1.DeploymentStatus",
                    "description": "Most recently observed status of the Deployment."
                }
            },
            "type": "object",
            "x-kubernetes-group-version-kind": [
                {
                    "group": "apps",
                    "kind": "Deployment",
                    "version": "v1"
                }
            ]
        }
    },
    "info": {
        "title": "Kubernetes",
        "version": "unversioned"
    },
    "paths": {},
    "swagger": "2.0"
}
``` **Перевод текста:**

Сохраните указанный выше spec как deployment.json и выполните команду «kclopenapi generate model -f deployment.json». Это позволит создать все связанные файлы KCL schema в текущем рабочем пространстве. В каталоге Konfig base/pkg/kusion_kubernetes мы уже сохранили копию сгенерированного файла [KCL](https://github.com/KusionStack/konfig/blob/master/base/pkg/kusion_kubernetes/api/apps/v1/deployment.k) и создали соответствующий документ модели.

**5.1.3.2 Использование сгенерированной KCL Schema**

* Используя сгенерированную модель, можно напрямую объявить конфигурацию KCL.
  Мы можем непосредственно инстанцировать Deployment в конфигурации KCL, чтобы получить объявление о развёртывании, как показано ниже:

```python
import kusion_kubernetes.api.apps.v1

frontend = v1.Deployment {
    metadata.name: "frontend"
    spec.selector.matchLabels: {app: guestbook, tier: frontend}
    replicas: 3
    template.metadata.labels: {app: guestbook, tier: frontend}
    spec.containers: [
        {
            name: php-redis
            image: gcr.io/google-samples/gb-frontend:v4
            resources.requests: { cpu: "100m", memory: "100Mi"}
        }
        env: [{name: GET_HOSTS_FROM, value: dns}]
        ports: [{containerPort: 80}]
    ]
}

Добавьте указанное выше объявление конфигурации в репозиторий Konfig, и после компиляции результат будет эквивалентен Kubernetes examples guestbook-frontend. Для получения дополнительной информации о репозитории Konfig и командах компиляции см. Konfig Model Library Quick Start.

• Лучшая практика: дальнейшее абстрагирование Kubernetes модели и определение дружественного интерфейса для пользователя.

Поскольку встроенные модели Kubernetes довольно атомизированы и сложны, мы рекомендуем использовать нативные модели Kubernetes в качестве моделей вывода на серверной части, а также предоставлять пользователям более дружественный и простой интерфейс модели на передней части. В каталоге kusion_models Konfig уже сохранена хорошо абстрагированная модель — Server модель. Смотрите Server Schema.

5.1.4 Миграция из CRD Kubernetes в Kusion

Если ваш проект использует CRD, вы также можете использовать аналогичный подход для создания соответствующей KCL схемы и объявления CR на основе этой схемы. Используйте команду kclopenapi generate model --crd --skip-validation -f your_crd.yaml для генерации KCL Schema из CRD. Или используйте режим объявления CR с использованием KCL аналогично режиму объявления конфигурации встроенной модели Kubernetes, здесь не приводится.