badcasedaily1 6 часов назад

Функциональное тестирование Kubernetes Operators с Kubebuilder

Средний

8 мин

223

Обзор

Привет, Хабр!

Сегодня поговорим о том, как тестировать Kubernetes Operators с помощью одного замечательного фреймворка. Функциональное тестирование — это не просто «хорошо бы», это необходимость. А вот как сделать качественное тестирование без боли? Здесь и поможет фреймворк Kubebuilder — инструмент, который упрощает тестирование и разработку операторов.

Немного про Kubebuilder

Kubebuilder построен на базе controller‑runtime и client‑go, двух мощнейших библиотек от самого Kubernetes.

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

Для начала понадобится установить несколько зависимостей. Прежде чем двигаться дальше, нужно будет установить Go, потому что Kubebuilder — это инструмент для Golang.

А сам Kubebuilder можно скачать с официального репозитория, есть команда, которая сделает все за тебя:

curl -L https://github.com/kubernetes-sigs/kubebuilder/releases/download/v3.4.0/kubebuilder_linux_amd64 -o kubebuilder
chmod +x kubebuilder
sudo mv kubebuilder /usr/local/bin/

Если ты на MacOS:

brew install kubebuilder

Проверяем установку:

kubebuilder version

Если все прошло успешно, увидишь версию Kubebuilder и то, что все нужные компоненты работают.

Теперь создадим новый проект оператора. Kubebuilder генерирует основу для оператора, начиная с командной строки. Сначала нужно инициализировать проект:

kubebuilder init --domain my.domain --repo github.com/your-username/my-operator

Эта команда создаст минимальную структуру проекта с основными файлами для Go-модуля и зависимостями. Параметр --domain указывает доменное имя для твоих CRD. Например, если ты разрабатываешь оператора для своей компании, то можешь указать --domain yourcompany.com.

Далее нужно создать API и контроллер для нашего оператора:

kubebuilder create api --group batch --version v1 --kind Job

Эта команда генерирует необходимые файлы для API и контроллера Kubernetes. Параметр --group указывает на группу ресурсов (в данном случае это batch), --version на версию API, а --kind на тип ресурса, с которым работает оператор (например, Job).

После этого мы видим новую структуру проекта с файлом API в api/v1/job_types.go, где определена структура CRD, и файлом контроллера в controllers/job_controller.go, где прописана логика работы оператора.

Теперь рассмотрим как писать логику для нашего оператора. Возьмем за основу пример с контроллером Job. В файле job_controller.go ты найдешь метод Reconcile, который отвечает за то, как оператор реагирует на изменения в ресурсах. Здесь мы будем писать логику, что делать, когда Kubernetes вносит изменения в объект Job.

Пример простейшей логики:

func (r *JobReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {
    log := log.FromContext(ctx)

    // Получаем ресурс
    var job batchv1.Job
    if err := r.Get(ctx, req.NamespacedName, &job); err != nil {
        log.Error(err, "unable to fetch Job")
        return ctrl.Result{}, client.IgnoreNotFound(err)
    }

    // Здесь пишем логику работы с ресурсом, например:
    // Проверяем, создан ли под для этого Job, если нет — создаем.
    
    return ctrl.Result{}, nil
}

Здесь мы используем стандартный клиент Kubebuilder для получения объекта Job из кластера. После этого можно написать любую логику, которую ты хочешь внедрить в работу оператора.

Но мы здесь собрались для тестирования. Приступим.

Функциональное тестирование Kubernetes Operators с Kubebuilder

EnvTest — это lightweight-окружение для тестирования контроллеров Kubernetes, которое позволяет запускать тесты без развертывания полноценного кластера.

Первым делом нам нужно подготовить тестовое окружение. Для этого воспользуемся пакетом controller-runtime/pkg/envtest, который уже входит в состав Kubebuilder. Для начала, добавим его в зависимости нашего проекта:

go get sigs.k8s.io/controller-runtime/pkg/envtest

Затем создаем файл main_test.go, где будет находиться наш тестовый код:

package main_test

import (
    "testing"
    "sigs.k8s.io/controller-runtime/pkg/client"
    "sigs.k8s.io/controller-runtime/pkg/envtest"
    "sigs.k8s.io/controller-runtime/pkg/log/zap"
    "github.com/onsi/gomega"
)

var k8sClient client.Client
var testEnv *envtest.Environment

func TestMain(m *testing.M) {
    gomega.RegisterFailHandler(gomega.Fail)
    testEnv = &envtest.Environment{
        CRDDirectoryPaths: []string{"../config/crd/bases"},
    }

    var err error
    cfg, err := testEnv.Start()
    if err != nil {
        panic(err)
    }

    k8sClient, err = client.New(cfg, client.Options{})
    if err != nil {
        panic(err)
    }

    code := m.Run()
    testEnv.Stop()
    os.Exit(code)
}

Что тут происходит:

envtest.Environment настраивает минимальный Kubernetes API-сервер и etcd для тестирования CRD и контроллеров.
client.New создает клиента для взаимодействия с объектами в кластере.

Этот код запускает тестовую среду и инициализирует API-сервер. Теперь можно приступать к написанию тестов.

Тестирование CRD

Начнем с простого теста, который проверяет, создается ли корректно наш CRD.

Допустим, мы работаем с ресурсом Job. Пример кода для создания CRD и проверки, что оно корректно создано в кластере:

func TestCreateCRD(t *testing.T) {
    g := gomega.NewWithT(t)

    // Создаем объект CRD
    job := &batchv1.Job{
        ObjectMeta: metav1.ObjectMeta{
            Name: "test-job",
            Namespace: "default",
        },
        Spec: batchv1.JobSpec{
            Template: corev1.PodTemplateSpec{
                Spec: corev1.PodSpec{
                    Containers: []corev1.Container{
                        {
                            Name:  "busybox",
                            Image: "busybox",
                            Command: []string{"sleep", "10"},
                        },
                    },
                    RestartPolicy: corev1.RestartPolicyNever,
                },
            },
        },
    }

    // Создаем объект в тестовой среде
    err := k8sClient.Create(context.Background(), job)
    g.Expect(err).NotTo(gomega.HaveOccurred())

    // Проверяем, что объект действительно создан
    fetchedJob := &batchv1.Job{}
    err = k8sClient.Get(context.Background(), client.ObjectKey{Name: "test-job", Namespace: "default"}, fetchedJob)
    g.Expect(err).NotTo(gomega.HaveOccurred())
    g.Expect(fetchedJob.Name).To(gomega.Equal("test-job"))
}

Этот тест проверяет, что при создании объекта Job наш контроллер корректно его обрабатывает и объект появляется в кластере. Используя gomega как фреймворк для утверждений, можно убедиться, что ошибки не возникают, и объект действительно создан.

Взаимодействие с другими объектами в кластере

Теперь усложним задачу и проверим, как оператор взаимодействует с другими объектами Kubernetes. Например, оператор должен автоматически создавать ConfigMap при создании определенного CRD. Вот как можно протестировать эту логику:

func TestConfigMapCreation(t *testing.T) {
    g := gomega.NewWithT(t)

    // Создаем CRD
    job := &batchv1.Job{
        ObjectMeta: metav1.ObjectMeta{
            Name: "job-with-configmap",
            Namespace: "default",
        },
        Spec: batchv1.JobSpec{
            Template: corev1.PodTemplateSpec{
                Spec: corev1.PodSpec{
                    Containers: []corev1.Container{
                        {
                            Name:  "nginx",
                            Image: "nginx",
                        },
                    },
                    RestartPolicy: corev1.RestartPolicyNever,
                },
            },
        },
    }

    err := k8sClient.Create(context.Background(), job)
    g.Expect(err).NotTo(gomega.HaveOccurred())

    // Проверяем, что ConfigMap создан
    configMap := &corev1.ConfigMap{}
    err = k8sClient.Get(context.Background(), client.ObjectKey{Name: "job-configmap", Namespace: "default"}, configMap)
    g.Expect(err).NotTo(gomega.HaveOccurred())
    g.Expect(configMap.Data["config"]).To(gomega.Equal("some-config-data"))
}

Здесь проверяем, что при создании Job, наш контроллер автоматически создает ConfigMap, содержащий нужные данные.

Обработка событий и реакция на изменения

Последний важный момент — это проверка, как оператор реагирует на изменения в ресурсах и события. Например, если Job завершился с ошибкой, оператор должен создавать уведомление или перезапускать Pod.

Пример теста, который проверяет реакцию на событие:

func TestJobFailureEvent(t *testing.T) {
    g := gomega.NewWithT(t)

    // Создаем объект Job с ошибочным подом
    job := &batchv1.Job{
        ObjectMeta: metav1.ObjectMeta{
            Name: "failing-job",
            Namespace: "default",
        },
        Spec: batchv1.JobSpec{
            Template: corev1.PodTemplateSpec{
                Spec: corev1.PodSpec{
                    Containers: []corev1.Container{
                        {
                            Name:  "busybox",
                            Image: "busybox",
                            Command: []string{"false"}, // Под завершится с ошибкой
                        },
                    },
                    RestartPolicy: corev1.RestartPolicyNever,
                },
            },
        },
    }

    err := k8sClient.Create(context.Background(), job)
    g.Expect(err).NotTo(gomega.HaveOccurred())

    // Проверяем, что оператор среагировал на событие и выполнил корректные действия
    // Например, оператор создает событие с ошибкой
    events := &corev1.EventList{}
    err = k8sClient.List(context.Background(), events, client.InNamespace("default"))
    g.Expect(err).NotTo(gomega.HaveOccurred())
    g.Expect(events.Items).NotTo(gomega.BeEmpty())
    g.Expect(events.Items[0].Reason).To(gomega.Equal("FailedJob"))
}

Этот тест симулирует ошибку в Job и проверяет, что оператор правильно реагирует на это событие, создавая запись о сбое.

Тестирование обновлений ресурсов

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

func TestUpdateJobConfig(t *testing.T) {
    g := gomega.NewWithT(t)

    // Создаем исходный объект Job
    job := &batchv1.Job{
        ObjectMeta: metav1.ObjectMeta{
            Name:      "update-job",
            Namespace: "default",
        },
        Spec: batchv1.JobSpec{
            Template: corev1.PodTemplateSpec{
                Spec: corev1.PodSpec{
                    Containers: []corev1.Container{
                        {
                            Name:  "nginx",
                            Image: "nginx",
                        },
                    },
                    RestartPolicy: corev1.RestartPolicyNever,
                },
            },
        },
    }

    err := k8sClient.Create(context.Background(), job)
    g.Expect(err).NotTo(gomega.HaveOccurred())

    // Изменяем Job
    job.Spec.Template.Spec.Containers[0].Image = "nginx:latest"
    err = k8sClient.Update(context.Background(), job)
    g.Expect(err).NotTo(gomega.HaveOccurred())

    // Проверяем, что изменения были приняты и оператор обновил ConfigMap
    configMap := &corev1.ConfigMap{}
    err = k8sClient.Get(context.Background(), client.ObjectKey{Name: "update-job-configmap", Namespace: "default"}, configMap)
    g.Expect(err).NotTo(gomega.HaveOccurred())
    g.Expect(configMap.Data["config"]).To(gomega.Equal("updated-config-data"))
}

Оператор реагирует на обновление существующего ресурса и выполняет соответствующие действия, как обновление ConfigMap.

Тестирование зависимостей между ресурсами

Иногда оператор должен управлять несколькими ресурсами одновременно и поддерживать их состояние в синхронизации. Например, если один ресурс зависит от другого, оператор должен следить за тем, чтобы все компоненты оставались в актуальном состоянии. В следующем примере оператор следит за тем, чтобы Deployment был в актуальном состоянии, когда изменяется связанный Job:

func TestJobDeploymentSync(t *testing.T) {
    g := gomega.NewWithT(t)

    // Создаем Job
    job := &batchv1.Job{
        ObjectMeta: metav1.ObjectMeta{
            Name:      "sync-job",
            Namespace: "default",
        },
        Spec: batchv1.JobSpec{
            Template: corev1.PodTemplateSpec{
                Spec: corev1.PodSpec{
                    Containers: []corev1.Container{
                        {
                            Name:  "nginx",
                            Image: "nginx",
                        },
                    },
                    RestartPolicy: corev1.RestartPolicyNever,
                },
            },
        },
    }

    err := k8sClient.Create(context.Background(), job)
    g.Expect(err).NotTo(gomega.HaveOccurred())

    // Создаем связанный Deployment
    deployment := &appsv1.Deployment{
        ObjectMeta: metav1.ObjectMeta{
            Name:      "sync-deployment",
            Namespace: "default",
        },
        Spec: appsv1.DeploymentSpec{
            Selector: &metav1.LabelSelector{
                MatchLabels: map[string]string{"app": "nginx"},
            },
            Template: corev1.PodTemplateSpec{
                ObjectMeta: metav1.ObjectMeta{
                    Labels: map[string]string{"app": "nginx"},
                },
                Spec: corev1.PodSpec{
                    Containers: []corev1.Container{
                        {
                            Name:  "nginx",
                            Image: "nginx",
                        },
                    },
                },
            },
        },
    }

    err = k8sClient.Create(context.Background(), deployment)
    g.Expect(err).NotTo(gomega.HaveOccurred())

    // Проверяем, что Deployment синхронизирован с Job
    fetchedDeployment := &appsv1.Deployment{}
    err = k8sClient.Get(context.Background(), client.ObjectKey{Name: "sync-deployment", Namespace: "default"}, fetchedDeployment)
    g.Expect(err).NotTo(gomega.HaveOccurred())
    g.Expect(fetchedDeployment.Spec.Template.Spec.Containers[0].Image).To(gomega.Equal("nginx"))
}

Этот тест проверяет, что оператор синхронизирует состояние Deployment с изменениями в Job.

Заключение

Kubebuilder дает возможность тестировать сложные сценарии в легковесной среде, не поднимая полноценный Kubernetes кластер.

Скоро в рамках онлайн-курса «Инфраструктурная платформа на основе Kubernetes» пройдут открытые уроки:

8 октября: «Хранение данных в Kubernetes: Volumes, Storages, Stateful-приложения». Узнать подробнее
21 октября: «Service Mesh: Введение в Istio». Узнать подробнее

Теги:

Хабы:

Функциональное тестирование Kubernetes Operators с Kubebuilder

Немного про Kubebuilder

Функциональное тестирование Kubernetes Operators с Kubebuilder

Тестирование CRD

Взаимодействие с другими объектами в кластере

Обработка событий и реакция на изменения

Тестирование обновлений ресурсов

Тестирование зависимостей между ресурсами

Заключение

Публикации

Информация