Автотестирование кастомного K8s CNI: как правильно входить в ха… то есть поду

В сфере искусственного интеллекта произошло заметное событие. time2test 11 минут назад Автотестирование кастомного K8s CNI: как правильно входить в ха… то есть поду Средний 10 мин 321 Блог компании Cloud. ru Разработка публичных облаков * Тестирование IT-систем * Kubernetes * Python * Кейс Представьте, однажды вы приходите в новую компанию на позицию Automation QA и перед вами возникает задача: на пустом поле проекта посеять зерна автотестов, которые прорастут в регулярный процесс тестирования и будут отлавливать различные баги. Такая задача возникла и передо мной, поэтому я хочу поделиться своим опытом, как строил тестирование кастомного K8s CNI-плагина, в новой для себя области.

Статья будет полезна QA-инженерам, которые на «ты» с Python, но на «вы» с тестированием Kubernetes с помощью автотестов. При решении задачи я столкнулся с вопросами, на которые нигде не нашел ответа. Возможно, раз мне помог описанный путь, поможет и вам.

Технические детали

Немного контекстаЯ Роман Черепанов, Automation QA, уже семь лет работаю в тестировании различных сетевых продуктов. Моя команда занимается разработкой своего Kubernetes CNI-плагина с доработками, необходимыми для настройки сетевой связности между различными облачными сервисами предоставляемыми Cloud. В качестве основы взят Multus — плагин создания нескольких интерфейсов в рамках Pod.

В процессе повествования я опущу базовые понятия о Kubernetes (что такое кластер, Pod, контейнер и т. ), чтобы сократить хронометраж. О них вы можете прочитать в документации на официальном сайте, там достаточно доступно объяснено.

Базовые требования к тестовому фреймворку, который будет тестировать CNI-плагин, были следующими: возможность деплоить Pod с CNI, добавлять network attach definition (далее по тексту net-attach-def) для создания сетевых интерфейсов, проверять сетевую связность с созданными интерфейсами как с внутренних, так и внешних (через интернет) хостов. Язык фреймворка — Python. Общение с кластером через kube-api.

Отраслевые последствия

И первый же вопрос, который встал передо мной, оказался такой: какую библиотеку для взаимодействия с kube-api выбрать? Как тестировщик библиотеки Kubernetes API выбиралНа официальном сайте есть список библиотек API клиента, можно поискать в интернете другие, но с высокой вероятностью это будут неактуальные вещи. Вот пару мыслей о клиентах из списка:БиблиотекаКомментарийkubernetes-clientОфициальный клиент, самый распространенный и популярный, есть документация, много примеров как в репозитории, так и в интернете.

Проект регулярно обновляется на момент написания статьи свежая версия, v36. Это синхронный клиент, хотя в некоторых методах есть возможность делать асинхронные запросы. kubernetes_asyncioФорк официального клиента с доработками для улучшения работы в асинхронном режиме, также использована другая библиотека для работы с HTTP.

Проект продолжает развиваться. cloudcoilВысокоуровневый клиент, в котором Pydantic-модели используются для представления компонентов k8s. Нацелен, в первую очередь, на асинхронный режим работы.

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