Введение в операции Kubernetes: настройка кластера Kubernetes на AWS с помощью kOps

Вступление

В этом посте я собираюсь представить концепцию kOps - операций Kubernetes - почему вы должны ее использовать, ее преимущества и обзор. Затем я предоставлю некоторую инфраструктуру AWS с использованием kOps, масштабирую нашу инфраструктуру вверх и вниз, и в результате я разверну решение для мониторинга, чтобы протестировать нашу инфраструктуру с использованием входящего трафика.

Что такое КОПС?

Управление кластером Kubernetes в нескольких регионах и облаках представляет собой ряд невероятно сложных задач, и kOps - это самый простой способ запустить и запустить кластер Kubernetes производственного уровня. Kubernetes Operations помогает нам создавать, уничтожать, обновлять и поддерживать производственный высокодоступный кластер Kubernetes в облачной инфраструктуре. Как администраторы Kubernetes, мы знаем, как важно обеспечить обновление наших кластеров Kubernetes до версии, исправленной для устранения уязвимости, и kops помогает нам в этом. Еще одна задача - подготовить кластер Kubernetes в облачной инфраструктуре, потому что мы имели дело с группами экземпляров, route53, группами автомасштабирования, ELB (для сервера API), группами безопасности, основной начальной загрузкой, начальной загрузкой узлов и скользящими обновлениями для вашего кластера и копий. облегчает эту работу. В результате управление кластером Kubernetes на AWS без каких-либо инструментов - сложный процесс, и я не рекомендую его.

Kops - это инструмент с открытым исходным кодом, и его можно использовать совершенно бесплатно, но вы несете ответственность за оплату и поддержку базовой инфраструктуры, созданной kops для управления вашим кластером Kubernetes. Согласно официальному сайту, теперь AWS (Amazon Web Services) в настоящее время официально поддерживается, с бета-поддержкой DigitalOcean, GCE и OpenStack, а в альфа-версии - Azure и AliCloud.

Преимущества kOps

В частности, в AWS, зачем использовать kops вместо облачных решений других поставщиков, таких как EKS?

Одним из основных преимуществ является то, что kops создаст наш кластер как экземпляры EC2, и вы сможете напрямую обращаться к узлам и вносить некоторые изменения, в результате чего вы можете выбрать, какой сетевой уровень использовать, размер мастер-экземпляров и напрямую контролировать главный и рабочий узлы, а также увеличивать и уменьшать масштаб вашей инфраструктуры, только редактируя файл. У вас также есть возможность настроить подготовку кластеров с высокой доступностью Kubernetes или только одного главного, что может быть желательно для сред разработки и тестирования, где высокая доступность не является обязательной.

KOps также поддерживает встроенную модель синхронизации состояния для пробных прогонов, а автоматическая идемпотентность предоставляет мощную модель для управления версиями настройки вашего кластера и дает возможность использовать GitOps в качестве модели pull вместо модели push с использованием лучших практик. Если хотите, Kops также поддерживает создание конфигурации terraform для ваших ресурсов вместо их непосредственного создания, что является хорошей функцией, если вы используете terraform.

Согласно официальному сайту, kOps имеет следующие особенности:

Автоматизирует подготовку высокодоступных кластеров Kubernetes
Построен на модели синхронизации состояний для пробных прогонов и автоматической идемпотентности
Возможность генерировать Terraform
Поддерживает надстройки Kubernetes с нулевой конфигурацией
Автозаполнение в командной строке
Конфигурация API на основе манифеста YAML
Режимы создания шаблонов и пробного запуска для создания манифестов
Выбирайте из самых популярных сетевых провайдеров CNI прямо из коробки
Готовность к мультиархитектуре с поддержкой ARM64
Возможность добавлять контейнеры в качестве перехватчиков и файлы на узлы через манифест кластера.

Обзор kOps

В этом разделе я предоставлю вам только основные команды, которые я считаю важными для предоставления и поддержки кластера Kubernetes с kOps. Если вы хотите выйти за рамки, вы можете найти это на официальном сайте.

kops create

kops create создает ресурс, например кластер, группу экземпляров или секрет, используя параметры командной строки, файлы спецификации конфигурации YAML или стандартный ввод.

Например, есть два способа регистрации кластера: с помощью файла спецификации кластера или с использованием аргументов CLI.

Если вы хотите создать кластер в AWS с мастерами высокой доступности, вы можете использовать следующие параметры:

export KOPS_STATE_STORE="s3://my-state-store"
  export MASTER_SIZE="c5.large"
  export NODE_SIZE="m5.large"
  export ZONES="us-east-1a,us-east-1b,us-east-1c"
  kops create cluster k8s-cluster.example.com \
  --node-count 3 \
  --zones $ZONES \
  --node-size $NODE_SIZE \
  --master-size $MASTER_SIZE \
  --master-zones $ZONES \
  --networking cilium \
  --topology private \
  --bastion="true" \
  --yes

Или вы можете сохранить свою конфигурацию в файле и применить ее позже, чтобы сохранить ее в системе контроля версий. Вы можете использовать --dry-run -o yaml как кубернет вместо --yes параметров.

После производства вы можете добавить узел, если это необходимо ... Например, для добавления одного узла с ролью node в кластер вы можете использовать следующую команду:

kops create ig --name=k8s-cluster.example.com node-example \
  --role node --subnet my-subnet-name

Как уже упоминалось, вы можете сначала зарегистрировать инфраструктуру, а затем использовать --yes с kops update cluster --yes для эффективного создания ресурса.

kops edit

Как мы видели, kops create cluster <clustername> создает облачную спецификацию в реестре, используя аргументы CLI. В большинстве случаев вам нужно будет отредактировать спецификацию кластера с помощью kops edit перед фактическим созданием облачных ресурсов. Как уже упоминалось, после подтверждения вы можете добавить флаг --yes, чтобы немедленно создать кластер, включающий облачные ресурсы. Даже если ресурсы работают, вы можете использовать их в любое время и после подачи заявки.

kops edit cluster k8s.cluster.site --state=s3://my-state-store

kops edit instancegroup --name k8s-cluster.example.com nodes --state=s3://my-state-store

Состояние S3

Мы увидим более подробно состояние в S3, но пока имейте в виду, что оно будет использоваться для хранилища в файле конфигурации верхнего уровня. В этом файле хранится основная конфигурация вашего кластера, такая как типы экземпляров, зоны, конфигурации…

kops update cluster

kops update cluster <clustername> создает или обновляет облачные ресурсы в соответствии со спецификацией кластера. Если кластер или облачные ресурсы уже существуют, эта команда может изменить эти ресурсы. В качестве меры предосторожности безопаснее сначала запускать в режиме «предварительного просмотра», и после подтверждения того, что результат соответствует вашим ожиданиям, вы можете применить изменения, добавив --yes к команде - kops update cluster --name <name> --yes.

kops update cluster k8s-cluster.example.com --yes --state=s3://my-state-store --yes

kops get clusters

kops get clusters перечисляет все кластеры в реестре (хранилище состояний), один или несколько ресурсов, таких как кластер, группы экземпляров и секрет.

kops get k8s-cluster.example.com -o yaml

Очевидно, что вы можете получить ресурсы с форматом YAML или без него.

kops get secrets admin -oplaintext

kops delete cluster

kops delete cluster удаляет облачные ресурсы (экземпляры, записи DNS, тома, ELB, VPC и т. Д.) Для определенного кластера. Также удаляет кластер из реестра.

В качестве меры предосторожности безопаснее сначала запустить в режиме «предварительного просмотра» kops delete cluster --name <name>, и после подтверждения того, что результат соответствует вашим ожиданиям, вы можете выполнить фактическое удаление, добавив --yes к команде - kops delete cluster --name <name> --yes.

kops delete cluster --name=k8s.cluster.site --yes

kops delete instance ip-xx.xx.xx.xx.ec2.internal --yes   (delete an instance (node) from active cluster)

kops rolling-update cluster

Некоторые изменения иногда требуют выполнения непрерывного обновления. Такие изменения, как добавление, удаление или обновление узла, или изменения, требующие серьезных изменений в конфигурации кластера. Чтобы выполнить непрерывное обновление, вам необходимо сначала обновить облачные ресурсы с помощью команды kops update cluster --yes. Узлы можно дополнительно пометить для обновления, разместив на них аннотацию kops.k8s.io/needs-update.

kops rolling-update cluster (Preview a rolling update)

kops rolling-update cluster --yes (Nodes will be drained and the cluster will be validated between node replacement)

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

Предоставление инфраструктуры AWS с помощью kOps

В этом разделе я покажу, как установить kOps, установить и настроить AWS, настроить поддомен route53, настроить, изменить и удалить кластер и экземпляры.

Установить kOps

KOps можно установить отдельно от kubectl для управления кластером Kubernetes. Через Linux вы можете установить его следующим образом:

curl -Lo kops https://github.com/kubernetes/kops/releases/download/$(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4)/kops-linux-amd64
chmod +x ./kops
sudo mv ./kops /usr/local/bin/

или установить из исходников. Если вы хотите установить с другой ОС, вы можете получить информацию на официальном сайте.

Настройка AWS CLI

Для взаимодействия с ресурсами AWS необходимо установить AWS CLI, и вы можете сделать это через pip:

pip install awscli

После установки вы должны запустить и настроить с помощью следующей команды:

$ aws configure
AWS Access Key ID [None]: XXXXXXX
AWS Secret Access Key [None]:  XXXXXXX
Default region name [None]: us-west-2
Default output format [None]: json

Для правильной работы Kops требуются следующие разрешения IAM:

AmazonEC2FullAccess
AmazonRoute53FullAccess
AmazonS3FullAccess
IAMFullAccess
AmazonVPCFullAccess

Создание IAM-группы и пользовательских копов с необходимыми разрешениями:

aws iam create-group --group-name kops
aws iam attach-group-policy --policy-arn arn:aws:iam::aws:policy/AmazonEC2FullAccess --group-name kops
aws iam attach-group-policy --policy-arn arn:aws:iam::aws:policy/AmazonRoute53FullAccess --group-name kops
aws iam attach-group-policy --policy-arn arn:aws:iam::aws:policy/AmazonS3FullAccess --group-name kops
aws iam attach-group-policy --policy-arn arn:aws:iam::aws:policy/IAMFullAccess --group-name kops
aws iam attach-group-policy --policy-arn arn:aws:iam::aws:policy/AmazonVPCFullAccess --group-name kops
aws iam create-user --user-name kops
aws iam add-user-to-group --user-name kops --group-name kops
aws iam create-access-key --user-name kops

Теперь вы можете перечислить своих пользователей:

aws iam list-users

Если у вас есть другой профиль AWS в вашей среде, вы можете установить или изменить профиль по умолчанию, прежде чем предоставить нашей инфраструктуре kOps.

Сначала настройте новый профиль. В этом случае я позвонил в копс и настроил свои ключи.

aws configure --profile kops                                                                         
AWS Access Key ID [None]: XXXXXXXXXXXX
AWS Secret Access Key [None]: XXXXXXXXXX
Default region name [None]: us-west-2
Default output format [None]: json

После этого мы сможем подтвердить новый профиль в: cat ~/.aws/config

[default]
region = us-east-2
[profile kops]
region = us-west-2
output = json

Итак, чтобы использовать новый профиль, у нас есть два способа, первый - установить переменную AWS_PROFILE с именем профиля по умолчанию. Другой вариант - установить --profile параметр с помощью команды aws. Я собираюсь использовать первый.

❯ export AWS_PROFILE=kops

Поскольку «aws configure» не экспортирует эти переменные для использования kops, мы экспортируем их сейчас.

export AWS_ACCESS_KEY_ID=$(aws configure get aws_access_key_id)
export AWS_SECRET_ACCESS_KEY=$(aws configure get aws_secret_access_key)

Маршрут53

Чтобы построить кластер Kubernetes с kops, нам нужны записи DNS. Вот несколько решений, которые вы можете использовать здесь. В моем случае я собираюсь использовать свой собственный домен - filipemotta.me, который размещен в AWS с помощью route53. Чтобы использовать этот сценарий, мы должны создать новую зону поддомена - kubernetes.filipemotta.me - а затем настроить делегирование маршрута в новую зону, чтобы kops создала соответствующие записи.

Чтобы создать поддомен в route53, вам необходимо выполнить следующие шаги:

создать зону хостинга с именем поддомена (в моем случае kubernetes.filipemotta.me)
route53 создаст для вас NS-записи, связанные с этим поддоменом
создайте записи ns в родительском домене (filipemotta.me), используя имя поддомена (kubernetes.filipemotta.me), в запись ns, которую route53 создал для вас на первом шаге. Это нормально!

Вы можете проверить с помощью команды dig:

❯ dig +short NS kubernetes.filipemotta.me
ns-1293.awsdns-33.org.
ns-2009.awsdns-59.co.uk.
ns-325.awsdns-40.com.
ns-944.awsdns-54.net.

Создать сегмент S3

Нам нужно создать корзину S3, в которой kops будет хранить состояние нашего кластера. Эта корзина станет источником истины для конфигурации нашего кластера.

Важно создать корзину S3 с именем вашего субдомена (или домена).

aws s3 mb s3://clusters.kubernetes.filipemotta.me

Управление версиями S3

Он строго контролирует версии вашей корзины S3 на тот случай, если вам когда-нибудь понадобится вернуть или восстановить предыдущее хранилище состояний.

aws s3api put-bucket-versioning --bucket kubernetes.filipemotta.me  --version

Прежде чем приступить к созданию нашего кластера, давайте установим некоторые переменные env. Вы можете экспортировать KOPS_STATE_STORE=s3://clusters.kubernetes.filipemotta.me, и тогда копы будут использовать это местоположение по умолчанию. Мы предлагаем поместить это в свой профиль bash.

export KOPS_STATE_STORE=s3://clusters.kubernetes.filipemotta.me

ПРЕДОСТАВЛЕНИЕ

Прежде чем подготовить наш кластер, давайте перечислим, какие зоны доступности доступны в конкретном регионе.

aws ec2 describe-availability-zones --region us-west-2 --output text
AVAILABILITYZONES     us-west-2       available       usw2-az2        us-west-2a 
AVAILABILITYZONES     us-west-2       available       usw2-az1        us-west-2b 
AVAILABILITYZONES     us-west-2       available       usw2-az3        us-west-2c
AVAILABILITYZONES     us-west-2       available       usw2-az4        us-west-2d

В этом конкретном случае мы можем использовать us-west-2a, us-west-2b, us-west-2c и us-west-2d.

Наконец, давайте создадим наш первый кластер:

kops create cluster --networking calico --node-count 3 --master-count 3 --zones us-west-2a,us-west-2b,us-west-2c --master-zones us-west-2a,us-west-2b,us-west-2c kubernetes.filipemotta.me

Здесь необходимо краткое объяснение.

Если KOPS_STATE_STORE=s3://clusters.kubernetes.filipemotta.me был установлен ранее, его не нужно устанавливать в этой команде. Сетью по умолчанию kOps является Kubernetes, но не рекомендуется для производства, поскольку он не поддерживает сетевые политики и другие функции, поэтому мы должны использовать одну из этих поддерживаемых сетей. В данном случае я использовал бязь.

Чтобы мастер не стал недоступен, мы предоставили кластер Kubernetes высокой доступности с 3 главными узлами и 3 рабочими узлами. Каждый из этих узлов - master и worker - доступен во всех зонах доступности (мы можем указать меньшее количество). Если вы не определяете кластер с высокой доступностью, вы не можете взаимодействовать с сервером API во время любого обновления или сбоя узла, поэтому вы не можете добавлять узлы, масштабировать модули или заменять завершенные модули.

Поэтому, когда вы определяете счетчик узла, он запускает выделенную ASG (группы автомасштабирования) и сохраняет данные на томах EBS. Скоро мы увидим в файле конфигурации, что мы определяем минимальное и максимальное количество узлов. (минимум - это количество, определяемое параметрами –node-count 3 –master-count 3). Наконец, мы устанавливаем имя кластера, которое должно совпадать с именем поддомена, созданным ранее.

Есть еще важный вариант - топология. Если не задан, топология публичная (в нашем случае). Если он установлен, типология будет частной (–topology private). Итак, в чем разница между ними?

Общедоступная подсеть направляется к Интернет-шлюзу, эта подсеть известна как общедоступная подсеть. Частная подсеть будет иметь открытый доступ через Kubernetes API и (необязательный) экземпляр бастиона SSH (–bastion = «true»).

После применения конфигураций просмотрите предложения:

Suggestions:
 * list clusters with: kops get cluster
 * edit this cluster with: kops edit cluster kubernetes.filipemotta.me
 * edit your node instance group: kops edit ig --name=kubernetes.filipemotta.me nodes-us-west-2a
 * edit your master instance group: kops edit ig --name=kubernetes.filipemotta.me master-us-west-2a

Согласно предложениям, перед применением мы можем отредактировать любой кластер конфигурации, группу узлов экземпляра или главную группу экземпляра. Давайте проверим или отредактируем, например, конфигурацию кластера:

kops edit cluster kubernetes.filipemotta.me
etcdClusters:
  - cpuRequest: 200m
    etcdMembers:
    - encryptedVolume: true
      instanceGroup: master-us-west-2a
      name: a
    - encryptedVolume: true
      instanceGroup: master-us-west-2b
      name: b
...
kubernetesApiAccess:
  - 0.0.0.0/0
...
  networkCIDR: 172.20.0.0/16
  networking:
    calico: {}
  nonMasqueradeCIDR: 100.64.0.0/10
  sshAccess:
  - 0.0.0.0/0
  subnets:
  - cidr: 172.20.32.0/19
    name: us-west-2a
    type: Public
    zone: us-west-2a
...
  topology:
    dns:
      type: Public
    masters: public
    nodes: public

Обратите внимание, что мы можем изменить CIDR подсети, сети и кластера, запрошенные ресурсы, ограничить доступ к API и многое другое.

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

kops edit ig --name=kubernetes.filipemotta.me nodes-us-west-2b

Обратите внимание, что мы редактируем nodes-us-west-2b, то есть группу экземпляров узла в определенной зоне доступности. Kops создал для нас одну группу экземпляров для каждой определенной зоны доступности.

kind: InstanceGroup
...
  machineType: t3.medium
  maxSize: 1
  minSize: 1
...
  role: Node
  subnets:
  - us-west-2b

После просмотра и редактирования любой конфигурации, которую вы хотели, пора применить эти конфигурации, чтобы начать подготовку.

kops update cluster --name kubernetes.filipemotta.me --yes --admin
...
kOps has set your kubectl context to kubernetes.filipemotta.me
Cluster changes have been applied to the cloud.
...

Да!! Это сделано! Как видите, kOps установил для вашего контекста kubectl значение kubernetes.filipemotta.me.

Через несколько минут вы должны были настроить кластер высокой доступности Kubernetes в инстансах EC2 через kOps.

❯ kubectl cluster-info           
Kubernetes master is running at https://api.kubernetes.filipemotta.me
CoreDNS is running at https://api.kubernetes.filipemotta.me/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
❯ kubectl get nodes   
NAME                                          STATUS   ROLES                  AGE     VERSION
ip-172-20-101-63.us-west-2.compute.internal   Ready    node                   7m52s   v1.21.2
ip-172-20-56-77.us-west-2.compute.internal    Ready    node                   7m57s   v1.21.2
ip-172-20-58-251.us-west-2.compute.internal   Ready    control-plane,master   10m     v1.21.2
ip-172-20-67-111.us-west-2.compute.internal   Ready    control-plane,master   10m     v1.21.2
ip-172-20-75-21.us-west-2.compute.internal    Ready    node                   118s    v1.21.2
ip-172-20-96-18.us-west-2.compute.internal    Ready    control-plane,master   10m     v1.21.2

Вы можете увидеть все модули, запущенные в кластере, и теперь можете проверить, развернута ли ваша установка с сетью calico.

Теперь мы собираемся развернуть еще один узел в нашем кластере. Это просто. Отредактируйте файл группы экземпляров узла, который вы хотите развернуть. В этом случае я собираюсь разместить в нас-запад-2а. Итак, давайте отредактируем и настроим:

kops edit ig --name=kubernetes.filipemotta.me nodes-us-west-2a
...
spec:
  machineType: t3.medium
  maxSize: 2
  minSize: 2
...

Не забудьте применить эти изменения…

❯ kops update cluster --name kubernetes.filipemotta.me --yes --admin

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

❯ kops rolling-update cluster --yes

Теперь вы можете видеть, что новый узел был развернут в определенной зоне доступности и теперь является частью кластера.

Обычно узким местом плоскости управления является сервер API. По мере роста количества модулей и узлов вам потребуется добавить больше ресурсов для обработки нагрузки. Итак, давайте развернем новый сервер API:

kops create ig --name=kubernetes.filipemotta.me new-apiserver --dry-run -o yaml > api-server.yaml
❯ cat api-server.yaml
apiVersion: kops.k8s.io/v1alpha2
kind: InstanceGroup
...
  name: new-apiserver
spec:
  machineType: t3.micro
  maxSize: 1
  minSize: 1
  ...
  role: APIServer
  subnets:
  - us-west-2a
  - us-west-2b

В этом случае я изменил параметр роли на APIServer, минимальный и максимальный размер, а тип машины - на micro.

❯ kops create -f api-server.yaml
❯ kops update cluster --name kubernetes.filipemotta.me --yes    
❯ kops rolling-update cluster --yes

В этом случае, как меняются узлы плоскости управления, требуется опция скользящего обновления. Каждый главный узел будет отключен с применением обновления по одному, но наш кластер не останется недоступным, потому что мы настроили кластер с высокой доступностью.

Наконец, в конце этого раздела удалим один узел группы экземпляров.

❯ kops get instancegroups #get the instancegroups
❯ kops delete ig --name=kubernetes.filipemotta.me nodes-us-west-2b
Do you really want to delete instance group "nodes-us-west-2b"? This action cannot be undone. (y/N)
y
InstanceGroup "nodes-us-west-2b" found for deletion
I0716 15:15:48.767476   21651 delete.go:54] Deleting "nodes-us-west-2b"

Конечный результат:

❯ kubectl get nodes                
NAME                                          STATUS   ROLES                             AGE     VERSION
ip-172-20-101-63.us-west-2.compute.internal   Ready    node                              68m     v1.21.2
ip-172-20-108-27.us-west-2.compute.internal   Ready    api-server,control-plane,master   2m54s   v1.21.2
ip-172-20-56-77.us-west-2.compute.internal    Ready    node                              68m     v1.21.2
ip-172-20-59-46.us-west-2.compute.internal    Ready    node                              46m     v1.21.2
ip-172-20-60-40.us-west-2.compute.internal    Ready    api-server,control-plane,master   17m     v1.21.2
ip-172-20-91-25.us-west-2.compute.internal    Ready    api-server,control-plane,master   9m56s   v1.21.2
ip-172-20-93-4.us-west-2.compute.internal     Ready    api-server                        11m     v1.21.2

Развертывание Prometheus и Grafana в кластере Kubernetes

В целях тестирования я развернул Prometheus и Grafana в кластере AWS. Я развернул контроллер входящего трафика Nginx, чтобы опубликовать свое приложение за пределами кластера. Я не рассматриваю здесь развернутое приложение, конфигурацию входа и установку, но вы можете увидеть здесь окончательный результат:

kubectl describe ingress -n ingress-nginx     
Name:             ingress-host
Namespace:        ingress-nginx
Address:          a205622a4b5f24923fc8516-615762329.us-west-2.elb.amazonaws.com
Default backend:  default-http-backend:80 (<error: endpoints "default-http-backend" not found>)
Rules:
  Host                               Path  Backends
  ----                               ----  --------
  grafana.kubernetes.filipemotta.me  
                                     /   grafana:3000 (100.111.236.136:3000)
Annotations:                         <none>
Events:
  Type    Reason  Age                From                      Message
  ----    ------  ----               ----                      -------
  Normal  Sync    15s (x3 over 10m)  nginx-ingress-controller  Scheduled for sy

При входе был обнаружен следующий адрес: a205622a4b5f24923fc8516–615762329.us-west-2.elb.amazonaws.com. Итак, я должен настроить CNAME DNS grafana.kubernetes.filipemotta.me на этот URL.

Графана развернута

Заключение

Вот и все. Мы успешно развернули высокодоступный и отказоустойчивый кластер Kubernetes с помощью Kops. В этом посте показано, как управлять кластером Kubernetes на AWS с помощью kops. Думаю, Kops - отличный инструмент для запуска производственного кластера Kubernetes в AWS или других облачных провайдерах. Попытайся!

Больше контента на plainenglish.io