Русский
Русский
English
Статистика
Реклама

Operations

Перевод Построение кластеров Kubernetes средствами самого Kubernetes

10.06.2021 18:12:02 | Автор: admin

Думаете, я сошел с ума? Я уже сталкивался с такой реакцией, когда впервые предложил развертывать кластеры 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Кластер 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 и группа узлов с зависимостями

Для построения кластера 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с. Рассмотрим, чем отличаются и в каких случаях используются. Регистрация здесь

Подробнее..

Перевод Разворачиваем кластер Kubernetes с помощью Kubernetes

17.02.2021 20:19:33 | Автор: admin

В рамках курса 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).

Готовый к продакшену кластер K8s, построенный с помощью Argo WorkflowsГотовый к продакшену кластер K8s, построенный с помощью Argo Workflows

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 control plane и nodegroup с зависимостями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 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 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: быстрый старт.

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru