В рамках курса «DevOps практики и инструменты» подготовили для вас перевод полезной статьи.

Также приглашаем на открытый вебинар по теме «Prometheus: быстрый старт». На вебинаре участники вместе с экспертом рассмотрят архитектуру Prometheus и как она работает с метриками; разберут, как формировать алерты и события в системе.

Подождите… что, что? Да, я уже слышал подобную реакцию на мое предложение использовать Kubernetes для построения кластеров Kubernetes.

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

Примечание: SAP Concur использует AWS EKS, но концепции, рассматриваемые здесь, применимы и к Google GKE, Azure AKS и к любому другому облачному провайдеру, предлагающему Kubernetes.

Готовность к промышленной эксплуатации

Развернуть кластер Kubernetes в любом из основных облачных провайдеров очень легко. Создать и запустить кластер в AWS EKS можно одной командой:

$ eksctl create cluster

Однако для создания кластера Kubernetes, готового к промышленной эксплуатации (production ready), требуется нечто большее. Хотя «готовность к промышленной эксплуатации» каждый понимает по своему, SAP Concur использует следующие четыре этапа создания и поставки кластеров Kubernetes.

Четыре этапа сборки

• Предварительные тесты. Набор базовых тестов целевого окружения AWS, проверяющих выполнение всех требований перед непосредственным созданием кластера. Например: доступные IP-адреса для каждой подсети, AWS exports, параметры SSM и другие переменные.

• EKS control plane и nodegroup. Фактическая сборка кластера AWS EKS с подключением рабочих нод.

• Установка дополнений. Это то, что сделает ваш кластер более милым :-) Установите такие дополнения как Istio, logging integration, autoscaler и т.д. Этот список дополнений не является исчерпывающим и совершенно необязателен.

• Валидация кластера. На этом этапе мы проверяем кластер (основные компоненты EKS и дополнения) с функциональной точки зрения перед передачей его в эксплуатацию. Чем больше тестов вы напишете, тем крепче будете спать. (Особенно если вы дежурный в техподдержке!)

Склеиваем этапы вместе

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

И мы нашли Argo. В частности, Argo Events и Argo Workflows. Оба они запускаются в Kubernetes как CRD и используют декларативный YAML, который используется и в других деплоях Kubernetes.

Мы нашли идеальную комбинацию: императивная оркестрация (Imperative Orchestration), декларативная автоматизация (Declarative Automation).

Argo Workflows

Argo Workflows — это container-native workflow engine с открытым исходным кодом для оркестрации параллельных заданий в 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 и еще трех) с использованием Argo Workflow может выглядеть следующим образом:

— 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 control plane и nodegroup

Для создания кластера EKS вы можете выбрать различные инструменты. Доступны eksctl, CloudFormation или Terraform. Построение EKS в два этапа с зависимостями, используя шаблоны CloudFormation (eks-controlplane.yaml и eks-nodegroup.yaml), в Argo Workflow может выглядеть следующим образом.

— 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 template и 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 bats
load “lib/utils”
load “lib/detik”
DETIK_CLIENT_NAME=”kubectl”
DETIK_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 conformance tests, Popeye — A Kubernetes Cluster Sanitizer и Fairwinds’ Polaris. Подключайте их с помощью Argo Workflows!

Если вы дошли до этого момента, то значит, у вас есть полностью рабочий AWS EKS кластер, готовый к промышленной эксплуатации, с установленным, протестированным и готовым metrics-server. Вы молодцы!

Но мы еще не прощаемся, самое интересное я оставил на конец.

WorkflowTemplate

Argo Workflows поддерживает шаблоны (WorkflowTemplate), что позволяет создавать повторно используемые workflow. Каждый из четырех этапов сборки — это шаблон. По сути, мы создали строительные блоки, которые можно комбинировать по мере необходимости. Используя один «главный» workflow, можно выполнять все этапы сборки по порядку (как в примере выше), или независимо друг от друга. Такая гибкость достигается с помощью Argo Events. 

Argo Events

Argo Events — это управляемый событиями фреймворк автоматизации рабочих процессов для Kubernetes (workflow automation framework), который помогает запускать объекты K8s, рабочие процессы Argo Workflow, бессерверные рабочие нагрузки и др. по событиям из различных источников, таких как webhook, s3, расписания, очереди сообщений, gcp pubsub, sns, sqs и т.д.

Сборка кластера запускается вызовом API (Argo Events) с использованием JSON. Кроме того, каждый из четырех этапов сборки (WorkflowTemplate) имеет собственную конечную точку API. Персонал, сопровождающий Kubernetes, может извлечь из этого большую пользу:

• Не уверены в состоянии облачной среды? Используйте API предварительных тестов.

• Хотите построить голый EKS-кластер? Используйте eks-core (control-plane и nodegroup) API.

• Хотите установить или переустановить дополнения в существующем EKS-кластере? Есть addons API.

• С кластером происходит что-то странное и вам нужно быстро запустить тесты? Вызовите test API.

Возможности Argo

Как Argo Events, так и Argo Workflows включают в себя большой набор возможностей, которые вам не потребуется реализовывать самостоятельно.

Вот семь из них, которые наиболее важны для нас:

• Параллелизм

• Зависимости

• Повторные попытки — обратите внимание на скриншотах выше на красные предварительные и валидационные тесты. Argo автоматически повторил их с последующим успешным завершением.

• Условия

• Поддержка S3

• Шаблоны рабочих процессов (WorkflowTemplate)

• Параметры Events Sensor

Заключение

Мы получили возможность использовать различные инструменты, которые работают совместно и определяют желаемое состояние инфраструктуры, обеспечивая гибкость и высокую скорость проекта. Мы планируем использовать Argo Events, Argo Workflows и для других задач автоматизации. Возможности безграничны.

Узнать больше о курсе «DevOps практики и инструменты».

Смотреть открытый вебинар по теме «Prometheus: быстрый старт».