В предыдущем разделе мы представили, как использовать KCL для написания и управления конфигурациями Kubernetes и применения их к кластеру. В этом разделе мы более подробно представили сценарии управления конфигурацией KCL Kubernetes, сравнив их с другими инструментами управления конфигурацией Kubernetes, такими как Kustomize.

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

Поэтому KCL рассчитывает решить следующие проблемы в управлении ресурсами Kubernetes YAML:

  • Используйте высокопроизводительный язык программирования производственного уровня для написания кода, чтобы повысить гибкость конфигурации, например условные операторы, циклы, функции, управление пакетами и другие функции для улучшения возможность повторного использования конфигурации.
  • Улучшите возможности семантической проверки конфигурации на уровне кода, такие как необязательные/обязательные атрибуты, типы, диапазоны и другие проверки конфигурации.
  • Обеспечьте возможность писать, комбинировать и абстрагировать блоки конфигурации, такие как определение структуры, наследование структуры, определение ограничения и т. д.

Эта статья является второй в серии статей о возможностях KCL. В нем основное внимание уделяется некоторым расширенным возможностям использования языка KCL и различиям между KCL и инструментом Kustomize. В будущем мы продолжим обновлять и делиться рядом функций KCL, сценариями, а также сходствами и различиями между KCL и другими инструментами управления конфигурацией Kubernetes. Пожалуйста, с нетерпением ждите этого.

Различия между KCL и Kustomize

Kustomize предоставляет решение для настройки базовой конфигурации и дифференциальной конфигурации ресурсов Kubernetes без использования шаблонов. Конфигурацию можно объединить или перезаписать с помощью конфигурации YAML на уровне файлов с несколькими стратегиями. В Kustomize пользователям необходимо больше знать о содержимом и местоположении, которые необходимо изменить. Для базового YAML со слишком сложной рекурсией может быть непросто сопоставить файлы Kustomize с помощью селекторов.

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

Классический пример управления конфигурацией Kustomize в нескольких средах используется для объяснения различий между Kustomize и KCL в управлении конфигурацией ресурсов Kubernetes.

настроить

В Kustomize есть концепции base и overlay. Как правило, base и overlay — это общий каталог, включающий файл kustomization.yaml. Один базовый каталог может использоваться несколькими оверлейными каталогами.

Мы можем выполнить следующую командную строку, чтобы получить типичный проект Kustomize.

  • Создайте базовый каталог и создайте ресурс развертывания
# Create a directory to hold the base
mkdir base
# Create a base/deployment.yaml
cat <<EOF > base/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ldap
  labels:
    app: ldap
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ldap
  template:
    metadata:
      labels:
        app: ldap
    spec:
      containers:
        - name: ldap
          image: osixia/openldap:1.1.11
          args: ["--copy-service"]
          volumeMounts:
            - name: ldap-data
              mountPath: /var/lib/ldap
          ports:
            - containerPort: 389
              name: openldap
      volumes:
        - name: ldap-data
          emptyDir: {}
EOF
# Create a base/kustomization.yaml
cat <<EOF > base/kustomization.yaml
resources:
- deployment.yaml
EOF
  • Создайте каталог для хранения конфигурации оверлея prod.
# Create a directory to hold the prod overlay
mkdir prod
# Create a prod/deployment.yaml
cat <<EOF > prod/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ldap
spec:
  replicas: 6
  template:
    spec:
      volumes:
        - name: ldap-data
          emptyDir: null
          gcePersistentDisk:
            readOnly: true
            pdName: ldap-persistent-storage
EOF
cat <<EOF > prod/kustomization.yaml
resources:
  - ../base
patchesStrategicMerge:
  - deployment.yaml
EOF

Таким образом, мы можем получить базовую директорию Kustomize

.
├── base
│   ├── deployment.yaml
│   └── kustomization.yaml
└── prod
    ├── deployment.yaml
    └── kustomization.yaml

В базовом каталоге хранится базовая конфигурация развертывания, а в рабочей среде хранится конфигурация развертывания, которую необходимо перезаписать. metadata.name и другие атрибуты, такие как spec.template.spec.volumes[0].name, используются для указания того, какой ресурс перезаписывать.

Мы можем отобразить реальную конфигурацию развертывания среды prod с помощью следующей команды.

$ kubectl kustomize ./prod
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: ldap
  name: ldap
spec:
  replicas: 6
  selector:
    matchLabels:
      app: ldap
  template:
    metadata:
      labels:
        app: ldap
    spec:
      containers:
      - args:
        - --copy-service
        image: osixia/openldap:1.1.11
        name: ldap
        ports:
        - containerPort: 389
          name: openldap
        volumeMounts:
        - mountPath: /var/lib/ldap
          name: ldap-data
      volumes:
      - gcePersistentDisk:
          pdName: ldap-persistent-storage
          readOnly: true
        name: ldap-data

Мы также можем напрямую применить конфигурацию к кластеру с помощью следующей команды.

$ kubectl apply -k ./prod

deployment.apps/ldap created

ККЛ

Мы можем написать следующий код KCL и назвать его main k. KCL вдохновлен Python. Его базовый синтаксис очень близок к Python, который легко освоить.

apiVersion = "apps/v1"
kind = "Deployment"
metadata = {
    name = "ldap"
    labels.app = "ldap"
}
spec = {
    replicas = 1
    # When env is prod, override the `replicas` attribute with `6`
    if option("env") == "prod": replicas = 6
    # Assign `metadata.labels` to `selector.matchLabels`
    selector.matchLabels = metadata.labels
    template.metadata.labels = metadata.labels
    template.spec.containers = [
        {
            name = metadata.name
            image = "osixia/openldap:1.1.11"
            args = ["--copy-service"]
            volumeMounts = [{ name = "ldap-data", mountPath = "/var/lib/ldap" }]
            ports = [{ containerPort = 80, name = "openldap" }]
        }
    ]
    template.spec.volumes = [
        {
            name = "ldap-data"
            emptyDir = {}
            # When env is prod
            # override the `emptyDir` attribute with `None`
            # patch a `gcePersistentDisk` attribute with the value `{readOnly = True, pdName = "ldap-persistent-storage"}`
            if option("env") == "prod":
                emptyDir = None
                gcePersistentDisk = {
                    readOnly = True
                    pdName = "ldap-persistent-storage"
                }
        }
    ]
}

В приведенном выше коде KCL мы объявляем apiVersion, kind, metadata, spec и другие атрибуты ресурса Kubernetes Deployment и соответственно назначаем соответствующее содержимое. В частности, мы присваиваем metadata.labels spec.selector.matchLabels и spec.template.metadata.labels. Видно, что структура данных, определенная KCL, более компактна, чем Kustomize или YAML, а повторное использование конфигурации может быть реализовано путем определения локальных переменных.

В KCL мы можем динамически получать внешние параметры через условные операторы и встроенную функцию option, а также устанавливать разные значения конфигурации для разных сред для генерации ресурсов. Например, для приведенного выше кода мы написали условный оператор и ввели динамический параметр с именем env. Когда env равно prod, мы перезапишем атрибут replicas с 1 на 6 и внесем некоторые изменения в конфигурацию тома с именем ldap-data, например изменим атрибут emptyDir на None и добавим значение конфигурации gcePersistentDisk.

Мы можем использовать следующую команду для просмотра различий между различными конфигурациями среды.

diff \
  <(kcl main.k) \
  <(kcl main.k -D env=prod) |\
  more

Выход

8c8
<   replicas: 1
---
>   replicas: 6
30c30,33
<         emptyDir: {}
---
>         emptyDir: null
>         gcePersistentDisk:
>           readOnly: true
>           pdName: ldap-persistent-storage

Видно, что разница между конфигурацией производственной среды и базовой конфигурацией в основном заключается в атрибутах replicas, emptyDir и gcePersistentDisk, что соответствует ожиданиям.

Кроме того, мы можем использовать параметр -o инструмента командной строки KCL для вывода скомпилированного YAML в файл и просмотра различий между файлами.

# Generate base deployment
kcl main.k -o deployment.yaml
# Generate prod deployment
kcl main.k -o prod-deployment.yaml -D env=prod
# Diff prod deployment and base deployment
diff prod-deployment.yaml deployment.yaml

Конечно, мы также можем использовать инструменты KCL вместе с kubectl и другими инструментами, чтобы применить конфигурацию производственной среды к кластеру.

$ kcl main.k -D env=prod | kubectl apply -f -

deployment.apps/ldap created

Наконец, проверьте статус развертывания через kubectl.

$ kubectl get deploy

NAME   READY   UP-TO-DATE   AVAILABLE   AGE
ldap   0/6     6            0           15s

Из результатов команды видно, что она полностью соответствует опыту развертывания с использованием конфигурации Kustomize и применения kubectl напрямую, а побочных эффектов больше нет.

Краткое содержание

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

Видно, что по сравнению с Kustomize KCL уменьшает количество файлов конфигурации и строк кода за счет генерации кода на основе повторного использования и покрытия конфигурации. И, как и Kustomize, это чисто клиентское решение, которое может перемещать конфигурацию и проверка политик максимально влево без дополнительной зависимости или нагрузки на кластер или даже без реального кластера Kubernetes.

Помимо Kustomize, на данном этапе Helm также очень популярен в области определения конфигурации Kubernetes и управления ею. Небольшие партнеры, знакомые с Kubernetes, могут предпочесть явный метод написания конфигурации. В чем разница между использованием KCL для записи рендеринга файла конфигурации и Helm? В следующей статье я расскажу о методе KCL для написания соответствующего кода конфигурации Helm.

Чтобы узнать больше, посетите:

Добро пожаловать в наше сообщество для общения:

https://github.com/KusionStack/сообщество

Если вам нравятся эти проекты, звезда Github 🌟🌟🌟 может поддержать нас и присоединиться к нашему сообществу для общения 👏👏👏：

https://github.com/KusionStack/сообщество