Думаете, я сошел с ума? Я уже сталкивался с такой реакцией, когда впервые предложил развертывать кластеры Kubernetes с помощью Kubernetes.
Но я убежден, что для автоматизации облачной инфраструктуры нет более эффективного инструмента, чем сам Kubernetes.С помощью одного центрального кластера K8s мы можем создать сотни других подконтрольных кластеров K8s. В этой статье я покажу, как это делается.
Примечание.SAP Concur использует AWS EKS, но рассматриваемые здесь концепции также применимы к Google GKE, Azure AKS и любым другим реализациям Kubernetes от облачных провайдеров.
Готовность к эксплуатации в рабочей среде
Создать кластер Kubernetes у любого из распространенных облачных провайдеров стало проще простого. Например, в AWS EKS кластер поднимается одной командой:
$ eksctl create cluster
Совсем другое дело, если нужно получить кластер Kubernetes, готовый к эксплуатации в рабочей среде production-ready Понятие production-ready может толковаться по-разному, но в SAP Concur используются следующие четыре этапа для создания и предоставления кластеров Kubernetes, готовых к эксплуатации в рабочей среде.
Четыре этапа сборки
-
Предварительное тестирование.Перечень простых тестов целевой среды AWS, которые проверяют соответствие всем необходимым требованиям до начала сборки кластера. Например, проверяются доступные IP-адреса в подсетях, экспортируемые параметры для AWS, параметры SSM или другие переменные.
-
Уровень управления EKS и группа узлов.Непосредственно сборка кластера AWS EKS с подключением рабочих узлов.
-
Установка дополнений.Добавим в кластер любимую приправу. :) По желанию можно установить такие дополнения, как Istio, Logging Integration, Autoscaler и пр.
-
Валидация кластера.На этом этапе мы проверяем кластер (основные компоненты EKS и дополнения) с функциональной точки зрения перед его передачей в эксплуатацию. Чем больше тестов вы напишете, тем крепче будете спать. (Особенно, если в техподдержке именно вы на дежурстве!)
Склеиваем все вместе
Четыре этапа сборки включают в себя разные инструменты и методы (мы вернемся к ним позже). Нам нужен был универсальный инструмент для всех этапов, который склеил бы все вместе, поддерживал последовательное и параллельное выполнение, был событийно-ориентированным и, желательно, визуализировал сборку.
В результате мы нашли семейство решений Argo, в частности инструменты Argo Events и Argo Workflows. Они оба запускаются в Kubernetes как CRD и полагаются на декларативную концепцию YAML, как и множество других развертываний Kubernetes.
У нас получилась идеальная комбинация: императивная оркестрация и декларативная автоматизация
Кластер K8s, готовый к эксплуатации в
рабочей среде. Создан с помощью Argo Workflows
Поэтапная реализация процесса в Argo Workflows
Argo Workflows это движок рабочих процессов с открытым кодом и нативной поддержкой контейнеров, предназначенный для оркестрации параллельных заданий в среде Kubernetes. Argo Workflows реализован как Kubernetes CRD.
Примечание.Если вы знакомы с K8s YAML, обещаю, что вы разберетесь.
Давайте посмотрим, как все эти четыре этапа сборки могут выглядеть в Argo Workflows.
1. Предварительное тестирование
Предварительные тесты выполняются
параллельно, с повторением попыток в случае сбоев
Мы пишем тесты на фреймворке BATS. Написать предварительный тест в BATS очень просто:
#!/usr/bin/env bats@test More than 100 available IP addresses in subnet MySubnet {AvailableIpAddressCount=$(aws ec2 describe-subnets --subnet-ids MySubnet | jq -r .Subnets[0].AvailableIpAddressCount) [ ${AvailableIpAddressCount} -gt 100 ]}
Параллельный запуск приведенного выше тестового файла BATS
(avail-ip-addresses.bats) вместе с тремя другими
вымышленными тестами BATS через Argo Workflows выглядит следующим
образом:
name: preflight-tests templateRef: name: argo-templates template: generic-template arguments: parameters: name: command value: {{item}} withItems: bats /tests/preflight/accnt-name-export.bats bats /tests/preflight/avail-ip-addresses.bats bats /tests/preflight/dhcp.bats bats /tests/preflight/subnet-export.bats
2. Уровень управления EKS и группа узлов
Уровень управления EKS и группа узлов с зависимостями
Для построения кластера EKS можно использовать любой удобный
инструмент. Например, eksctl, CloudFormation или
Terraform. Двухэтапное построение базового кластера EKS с
зависимостями в Argo Workflows с помощью шаблонов CloudFormation
(eks-controlplane.yaml и
eks-nodegroup.yaml) реализуется следующим образом.
name: eks-controlplane dependencies: [preflight-tests] templateRef: name: argo-templates template: generic-template arguments: parameters: name: command value: | aws cloudformation deploy \ --stack-name {{workflow.parameters.CLUSTER_NAME}} \ --template-file /eks-core/eks-controlplane.yaml \ --capabilities CAPABILITY_IAM- name: eks-nodegroup dependencies: [eks-controlplane] templateRef: name: argo-templates template: generic-template arguments: parameters: name: command value: | aws cloudformation deploy \ --stack-name {{workflow.parameters.CLUSTER_NAME}}-nodegroup \ --template-file /eks-core/eks-nodegroup.yaml \ --capabilities CAPABILITY_IAM
3. Установка дополнений
Параллельная установка дополнений с зависимостями
Для установки дополнений можно применить kubectl,
helm, kustomize или их комбинацию.
Например, установка дополнения metrics-server с
шаблоном helm и kubectl, при условии что
запрошена установка metrics-server, может выглядеть в
Argo Workflows следующим образом.
name: metrics-server dependencies: [eks-nodegroup] templateRef: name: argo-templates template: generic-template when: {{workflow.parameters.METRICS-SERVER}} != none arguments: parameters: name: command value: | helm template /addons/{{workflow.parameters.METRICS-SERVER}}/ \ --name metrics-server \ --namespace kube-system \ --set global.registry={{workflow.parameters.CONTAINER_HUB}} | \ kubectl apply -f -
4. Валидация кластера
Параллельная валидация кластера с
повторением попыток в случае сбоев
Для валидации дополнений мы применяем BATS-библиотеку DETIK, которая заметно упрощает написание тестов для K8s.
#!/usr/bin/env batsload lib/utilsload lib/detikDETIK_CLIENT_NAME=kubectlDETIK_CLIENT_NAMESPACE="kube-system"@test verify the deployment metrics-server { run verify there are 2 pods named metrics-server [ $status -eq 0 ] run verify there is 1 service named metrics-server [ $status -eq 0 ] run try at most 5 times every 30s to find 2 pods named metrics-server with status being running [ $status -eq 0 ] run try at most 5 times every 30s to get pods named metrics-server and verify that status is running [ $status -eq 0 ]}
Запуск приведенного выше тестового файла BATS DETIK
(metrics-server.bats), при условии что установлено
дополнение metrics-server, можно реализовать в Argo
Workflows так:
name: test-metrics-server dependencies: [metrics-server] templateRef: name: worker-containers template: addons-tests-template when: {{workflow.parameters.METRICS-SERVER}} != none arguments: parameters: name: command value: | bats /addons/test/metrics-server.bats
Только представьте, сколько еще можно сюда подключить тестов. Нужны тесты Sonobuoy, Popeye или Fairwinds Polaris? Просто подключите их через Argo Workflows!
К этому моменту у вас должен получиться полнофункциональный,
готовый к эксплуатации в рабочей среде кластер AWS EKS с
установленным дополнением metrics-server. Все тесты
пройдены, кластер можно принимать в работу. Дело сделано!
Но мы еще не прощаемся самое интересное я оставил напоследок.
Шаблоны рабочих процессов
Argo Workflows поддерживает многоразовые шаблоны рабочих процессов (WorkflowTemplates). Каждый из четырех этапов сборки представляет собой такой шаблон. По сути, мы получили сборочные элементы, которые можно произвольно комбинировать друг с другом. Все этапы сборки можно выполнять по порядку через главный рабочий процесс (как в примере выше) или можно запускать их независимо друг от друга. Такая гибкость стала возможной благодаря Argo Events.
Argo Events
Argo Events это событийно-ориентированный фреймворк для Kubernetes, который позволяет инициировать объекты K8s, Argo Workflows, бессерверные рабочие нагрузки и другие операции на основе различных триггеров, таких как веб-хуки, события в S3, расписания, очереди сообщений, Google Cloud Pub/Sub, SNS, SQS и пр.
Сборка кластера запускается посредством API-вызова (Argo Events) с использованием полезной нагрузки из JSON. Кроме того, каждый из четырех этапов сборки (WorkflowTemplates) имеет собственную конечную точку API. Операторы Kubernetes (тоесть люди) получают явные преимущества:
-
Не уверены, в каком состоянии находится облачная среда? Вызывайте API предварительных тестов.
-
Хотите собрать голый кластер EKS? Вызывайте API eks-core (control-plane и nodegroup).
-
Хотите установить или переустановить дополнения в существующем кластере EKS? Вызывайте API дополнений.
-
Кластер начал чудить и вам нужно быстро его протестировать? Вызывайте API тестирования.
Возможности Argo
Решения Argo Events и Argo Workflows предлагают широкий функционал прямо из коробки, не нагружая вас лишней работой.
Вот семь самых востребованных функций:
-
Параллелизм
-
Зависимости
-
Повторные попытки (см. выделенные красным предварительные тесты и тесты валидации на рисунках выше: они завершались сбоем, но Argo повторял их до успешного прохождения)
-
Условия
-
Поддержка S3
-
Шаблоны рабочих процессов
-
Параметры сенсоров событий
Заключение
Мы подружили множество различных инструментов и смогли через них императивно задать желаемое состояние инфраструктуры. Мы получили гибкое, бескомпромиссное и быстрое в реализации решение на основе Argo Events и Workflows. В планах приспособить эти инструменты под другие задачи автоматизации. Возможности безграничны.
Перевод материала подготовлен в рамках курса Инфраструктурная платформа на основе Kubernetes. Всех желающих приглашаем на двухдневный онлайн-интенсив Примитивы, контроллеры и модели безопасности k8s. На нем будет обзор и практика по основным примитивам и контроллерам к8с. Рассмотрим, чем отличаются и в каких случаях используются. Регистрация здесь
