Kubernetes для начинающих: разворачиваем кластер за час
Запросить демо
Я подтверждаю свое согласие на обработку компанией КРОК моих персональных данных, указанных в форме, в целях и пределах, установленных законодательством РФ о персональных данных в рамках проводимых мероприятий в течение неопределенного срока
Предпочтительный способ связи
Оставить заявку
Я подтверждаю свое согласие на обработку компанией КРОК моих персональных данных, указанных в форме, в целях и пределах, установленных законодательством РФ о персональных данных в рамках проводимых мероприятий в течение неопределенного срока
Узнать стоимость
Я подтверждаю свое согласие на обработку компанией КРОК моих персональных данных, указанных в форме, в целях и пределах, установленных законодательством РФ о персональных данных в рамках проводимых мероприятий в течение неопределенного срока
Предпочтительный способ связи
Попробовать бесплатно
Я подтверждаю свое согласие на обработку компанией КРОК моих персональных данных, указанных в форме, в целях и пределах, установленных законодательством РФ о персональных данных в рамках проводимых мероприятий в течение неопределенного срока
Предпочтительный способ связи
Регистрация в консоли
Я подтверждаю свое согласие на обработку компанией КРОК моих персональных данных, указанных в форме, в целях и пределах, установленных законодательством РФ о персональных данных в рамках проводимых мероприятий в течение неопределенного срока
Предпочтительный способ связи
cloud.croc.ru
Быть в теме

Kubernetes для начинающих: разворачиваем кластер за час

Павел Селиванов

архитектор решений в Southbridge, преподаватель курсов «Слёрм»

Новое в нашем блоге - текст выступления Павла Селиванова, архитектор решений в Southbridge. В конце ноября он на нашем вебинаре рассказал, как разворачивать кластер Kubernetes на примере инфрастуктуры в Облаке КРОК.

О спикере и теме вебинара

Меня зовут Павел Селиванов, я архитектор решений в компании Southbridge. Наша компания занимается созданием инфраструктур на различных платформах, в число которых входит Kubernetes. К тому же мы проводим учебные курсы по Kubernetes в учебном центре «Слёрм».

На вебинаре я покажу, как пользоваться возможностями современных облаков для установки Kubernetes на примере Облака КРОК. Я расскажу о современных подходах к управлению инфраструктурой, про связку компонентов Packer, Terraform и Ansible, а также про инструмент Kubeadm, с помощью которого мы будем производить установку. В завершение вебинара я подробно остановлюсь на том, что представляет собой кластер Kubernetes.

Pets vs. Cattle

Существует множество различных концепций управления инфраструктурой. Одна из них называется Pets vs. Cattle, то есть «домашние животные против сельскохозяйственного скота». Данная концепция описывает два противоположных подхода к инфраструктуре.

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

То же применимо к инфраструктуре. Стандартный подход, к которому часто прибегают системные администраторы, — выбирать и настраивать серверы индивидуально и давать им уникальные имена. В случае поломки такой сервер чинят, и это касается не только оборудования, но и операционной системы (ОС), пакетов и т. д. Это подход Pets.

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

Есть инструменты, которые позволяют реализовывать такой подход. В нашем случае первый инструмент — Облако КРОК, второй — Terraform.

Fried vs. Baked

Следующая концепция управления инфраструктурой раскрывается через противопоставление Fried vs. Baked, то есть «жареное против печеного». Эта аналогия из мира кулинарии описывает подходы к настройке серверов.

Предположим, что есть некие «стада» серверов. Можно устанавливать на них чистую ОС, ничего не в ней не меняя, и в дальнейшем ее настраивать — это называется «зажарить» сервер. Оркестраторы вроде Ansible, Chef, Puppet и SaltStack делают именно это — приводят чистые серверы к состоянию готовой системы. Это требует немалых затрат времени и приводит к большим задержкам при поломке серверов.

Существует альтернативный подход Baked, то есть «запеченный». Образ чистой ОС подготавливается к эксплуатации: устанавливаются все настраиваемые пакеты, нужные параметры и конфигурации — а далее создается снапшот этого образа. Все остальные серверы разворачиваются с использованием «запеченного», готового образа. Если вы работаете с контейнерами вроде Docker, вам должен быть знаком этот подход.

Packer

Для создания baked-инфраструктуры применяется Packer. Этот инструмент разработан компанией HashiCorp.

Packer использует JSON Template, т. е. файлы шаблонов, в которых есть описание того, что необходимо получить в качестве «запеченной» виртуальной машины (ВМ). После создания шаблона файл передается в Packer, и настраиваются необходимые разрешения для создания сервера в облаке.

Packer позволяет поднять ВМ локально в KVM, VirtualBox, Vagrant, AWS, GCP, Alibaba Cloud, OpenStack и т. д. Выбор в пользу Облака КРОК при работе с Packer обусловлен тем, что КРОК реализует интерфейсы AWS — то есть все инструменты, которые написаны для AWS, работают и с Облаком КРОК.

После задания необходимых шаблонов Packer поднимает в Облаке КРОК ВМ, ожидает ее запуск, а далее в работу вступает Ansible. Ansible — это своего рода заменитель Bash: он настраивает ВМ в облаке и готовит ее ко вводу в эксплуатацию.

Когда ВМ готова, Packer создает ее образ и помещает его в Облако КРОК, чтобы другие ВМ можно было запускать из этого же образа.

image10.png

В директории под названием packer содержатся файлы шаблонов в формате JSON. В том числе в ней расположен основной шаблон для Packer — файл base.json.

Структура файла base.json

В начале файла есть секция, в которой объявляются переменные:


"variables" : {
 "source_ami_name": "{{env `SOURCE_AMI_NAME`}}",
 "ami_name": "{{env `AMI_NAME`}}",
 "instance_type": "{{env `INSTANCE_TYPE`}}",
 "kubernetes_version": "{{env `KUBERNETES_VERSION`}}",
 "docker_version": "{{env `DOCKER_VERSION`}}",
 "subnet_id": "",
 "availability_zone": "",
},

Основной набор этих переменных будет задаваться из файла settings.json. А те переменные, которые часто меняются, удобнее задавать из консоли при запуске Packer и сборке нового образа.

Далее следует секция Builders.


"builders" : [
 {
  "type": "amazon-ebs",
  "region": "croc",
  "skip_region_validation": true,
  "custom_endpoint_ec2": "https://api.cloud.croc.ru",
  "source_ami": "",
  "source_ami_filter": {
   "filters": {
    "name": "{{user `source_ami_name`}}"
    "state": "available",
    "virtualization-type": "kvm-virtio"
     },
...

Здесь описаны целевые облака и метод запуска ВМ. Обратите внимание, что в данном случае объявлен тип amazon-ebs, но для работы Packer с Облаком КРОК задан соответствующий адрес в custom_endpoint_ec2.

Стоит отдельно отметить секцию source_ami_filter. Здесь задается первоначальный образ ВМ, в которую будут внесены необходимые изменения. Однако Packer требует AMI этого образа, т. е. его случайный идентификатор. Поскольку этот идентификатор редко известен заранее и меняется с каждым обновлением, AMI источника задается не как конкретная величина, а как переменная source_ami_filter. В данном случае определяющим параметром фильтра является имя образа. Это имя задано в переменных через файл settings.json.

Далее определены настройки ВМ: задан тип инстанса, процессор, объем памяти, выделяемое место и т. д.


"instance_type": "{{user `instance_type`}}",
"launch_block_device_mappings": [
 {
  "device_name": "disk1",
  "volume_type": "io1",
  "volume_size": "8",
  "iops": "1000",
  "delete_on_termination": "true"
 }
],

Следом в base.json определены параметры подключения к данной ВМ:


"availability_zone": "{{user `availability_zone`}}",
"subnet_id": "{{user `subnet_id`}}",
"associate_public_ip_address": true,
"ssh_username": "ec2-user",
"ami_name": "{{user `ami_name`}}"

Здесь важно отметить параметр subnet_id. Его необходимо задать вручную, поскольку без указания подсети ВМ в Облаке КРОК создать нельзя.

Еще один параметр, требующий предварительной подготовки, — associate_public_ip_address. Необходимо выделить белый IP-адрес, поскольку после создания ВМ Packer начнет применять нужные настройки посредством Ansible. При этом Ansible подключается к ВМ через SSH, что требует наличия белого IP-адреса или VPN.

Последняя секция — это Provisioners:


"provisioners": [
 {
  "type": "ansible",
  "playbook_file": "playbook.yml",
  "extra_arguments": [
   "--extra-vars",
   "kubernetes_version={{user `kubernetes_version`}}",
   "--extra-vars",
   "docker_version={{user `docker_version`}}"
   ]
  }
]

Это поставщики, т. е. утилиты, с помощью которых Packer настраивает сервер. В данном случае используется поставщик типа ansible. Далее следует параметр playbook_file, который определяет роли Ansible и хосты, на которых заданные роли будут применяться. Чуть ниже представлены дополнительные параметры extra_arguments, которые при запуске Ansible передают версии Kubernetes и Docker.

Структура файла settings.json

Файл settings.json хранит все значения переменных, объявленных в первой части файла base.json:


{
"source_ami_name": "CentOS 7.5 [Cloud image]",
 "ami_name": "centos-k8s-base",
 "instance_type": "m3.2small",
 "kubernetes_version": "1.16.1",
 "docker_version": "18.09.5",
}

Имя исходного образа определяется в source_ami_name, а далее задается имя конечного образа. Также указаны тип инстанса и версии Kubernetes и Docker.

Запуск Packer

Для запуска Packer необходимо выполнить следующую команду:

packer build -var-file=settings.json -var 'subnet_id=subnet-0854C500' -force base.json

В качестве файла с переменными задан файл settings.json. При этом ключ base.json определяет исходный шаблон, а ключ -force нужен для того, чтобы при наличии уже созданного образа с таким же именем Packer не останавливался, а создавал образ заново.

Подготовка Облака КРОК

1.jpg

В Облаке КРОК необходимо выделить белый IP-адрес и создать новую подсеть.

  1. Нажмите «Выделить адрес». При этом Packer найдет нужный белый IP-адрес самостоятельно.

    2.jpg

  2. Нажмите «Создать подсеть» и укажите подсеть и маску.
  3. Скопируйте ID подсети.
  4. Вставьте это значение в параметр subnet_id в команде запуска Packer.

3.png

После этого запустите Packer. Он находит исходный образ ВМ, разворачивает ее в Облаке КРОК и выполняет на ней Ansible-роль. Новую ВМ можно увидеть в Облаке КРОК в разделе «Экземпляры».

Работа Ansible

Как упоминалось ранее, в параметрах поставщика Ansible передается параметр playbook. Сам файл playbook.yml выглядит так:


- hosts: all
  become: true

  roles:
  | - base

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

Роль base позволяет получить готовый кластер посредством одной команды. Файл main.yml показывает, что именно делает эта роль:

  • добавляет в шаблон системы репозиторий Docker;
  • добавляет в шаблон системы репозиторий Kubernetes;
  • устанавливает необходимые пакеты;
  • создает директорию для конфигурации Docker-демона;
  • конфигурирует машину согласно файлу конфигурации daemon.json.j2;
  • загружает ядро br_netfilter;
  • включает необходимые параметры для br_netfilter;
  • включает компоненты Docker и Kubelet;
  • запускает Docker в ВМ;
  • выполняет команду, которая скачивает образы Docker, необходимые для работы Kubernetes.

    При этом устанавливаемые пакеты задаются в файле main.yml из каталога vars. В нашем случае мы устанавливаем пакет docker-ce, а также три пакета, необходимые для работы Kubernetes: kubelet, kubeadm и kubectl.

Terraform

Terraform — это еще один продукт от компании HashiCorp. От других систем оркестрации облаков Terraform отличает то, что он позволяет описать все состояние инфраструктуры в файлах на языке HCL.

Кроме того, Terraform позволяет планировать необходимые состояния, сравнивая конфигурацию, описанную в файлах, с текущей конфигурацией в облаке. После проведения сравнения Terraform выдает план действий, необходимых для перехода из текущего состояния в желаемое, что позволяет заранее видеть, что именно изменится в инфраструктуре. Спланировав нужные действия, выполните команду terraform apply — и Terraform развернет инфраструктуру, описанную в файлах.

Как и Packer, этот инструмент поддерживает AWS, GCP, Alibaba Cloud, Azure, OpenStack, VMware и т. д.

Структура файла main.tf

4.jpg

После окончания работы Packer удаляет ВМ из облака и оставляет на ее месте готовый образ, который можно найти в разделе «Шаблоны». Из этого образа будет создана вся инфраструктура Kubernetes.

В директории Terraform есть набор файлов с расширением .tf. В этих файлах описаны компоненты инфраструктуры, с которой мы будем работать.

Знакомство начнем с файла main.tf, в котором настраивается доступ к облаку. В частности, объявляются несколько параметров, которые настраивают Terraform для работы с Облаком КРОК:


provider "aws" {
 endpoints {
  ec2 = "https://api.cloud.croc.ru"
 }

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


resource "tls_private_key" "ssh" {
 algorithm = "RSA"
}

resource "aws_key_pair" "kube" {
 key_name = "terraform"
 public_key = "${tls_private_key.ssh.public_key_openssh}"
}

output "ssh" {
value = "${tls_private_key.ssh.private_key_pem}"
}

Структура файла network.tf

В этом файле описываются сетевые компоненты, необходимые для запуска ВМ:


data "aws_availability_zones" "az" {
 state = "available"
}

resource "aws_vpc" "kube" {
 cidr_block = "${var.vpc_cidr}"
}

resource "aws_eip" "master" {
 count = "1"
 vpc = true
}

resource "aws_subnet" "private" {
 vpc_id = "${aws_vpc.kube.id}"
 count = "${length(data.aws_availability_zones.az.names)}"
 cidr_block = "${var.private_subnet_cidr_list[count.index]}"
 availability_zone = "${data.aws_availability_zones.az.names[count.index]}"
}

В Terraform используется два типа компонентов:

  • resource — что необходимо создать;
  • data — что необходимо получить.

В данном случае параметр data указывает, что Terraform должен получить зоны доступности заданного облака, которые находятся в состоянии available.

Первый параметр resource описывает создание виртуального частного облака, а следующий параметр описывает создание Elastic IP Address. Для кластера Kubernetes мы заказываем этот IP-адрес через Terraform.

Далее в каждой из зон доступности, а их на данный момент у КРОК Облачные сервисы две, создается собственная подсеть. Объявляется создание ресурса типа aws_subnet, и в рамках этого параметра передается ID создаваемой aws_vpc. Но поскольку ID этого ресурса еще не известен, мы указываем параметр aws_vpc.kube.id, который обращается к созданному ресурсу и подставляет значение из поля ID.

Поскольку количество создаваемых подсетей определяется количеством зон доступности облака, и это количество может со временем меняться, данный параметр задается через переменную length (data.aws_availability_zones.az.names), т. е. длину списка зон доступности, полученного через параметр data.

Последние два параметра — это cidr_block (выделяемая подсеть), и зона доступности, в которой создается данная подсеть. Последний параметр также задается через переменную, берущую значение из списка data по индексу цикла, объявленного посредством [count.index].

Структура файла security_groups.tf

Security-группы — это своего рода файрвол для облаков, который может быть создан не внутри самих ВМ, а средствами облака. В данном случае в файрволе описаны два правила:


resource "aws_security_group" "kube" {
 vpc_id = "${aws_vpc.kube.id}"
 name   = "kubernetes"

 # Allow all outbound
 egress {
  from_port = 0
  to_port = 0
  protocol = "-1"
  cidr_blocks = ["0.0.0.0/0"]
 }

 # Allow all internal
 ingress {
  from_port = 0
  to_port = 0
  protocol = "-1"
  cidr_blocks = ["${var.vpc_cidr}"]
 }
}

resource "aws_security_group" "ssh" {
 vpc_id = "${aws_vpc.kube.id}"
 name   = "ssh"

 # Allow all inbound
 ingress {
  from_port = 22
  to_port = 22
  protocol = "tcp"
  cidr_blocks = ["0.0.0.0/0"]
 }
}

Первое правило создает security-группу, которая называется kube. Эта security-группа нужна для того, чтобы разрешить весь исходящий трафик из нод Kubernetes, позволяя нодам свободно выходить в интернет. Также разрешен входящий трафик к нодам Kubernetes от подсетей самих нод. Таким образом ноды Kubernetes могут работать между собой без ограничений.

Второе правило создает security-группу ssh. Она разрешает подключение по SSH с любых IP-адресов на порт 22 ВМ кластера Kubernetes.

Структура файла master.tf

В файле master.tf описывается создание нескольких шаблонов и инстанс. В частности, создается мастер-инстанс Kubernetes:


resource "aws_instance" "master" {
 count = "1"

 ami = "${var.kubernetes_ami}"
 instance_type = "c3.large"

 disable_api_termination = false
 instance_initiated_shutdown_behavior = "terminate"
 source_dest_check = false

 subnet_id = "${aws_subnet.private.*.id[count.index % length(data.aws_availability_zones.az.names)]}"

 associate_public_ip_address = true

 vpc_security_group_ids = [
  "${aws_security_group.ssh.id}",
  "${aws_security_group.kube.id}",
 ]

 key_name = "${aws_key_pair.kube.key_name}"

 user_data = "${data.template_cloudinit_config.master.rendered}"

 monitoring = "true"
}

Переменная ami задает AMI исходного образа для ВМ. Далее описаны тип ВМ и подсеть, в которой она создается. При задании подсети снова используется цикл, чтобы создавать ВМ в каждой зоне доступности.

Далее объявляются используемые security-группы и ключ, который был указан в файле main.tf. В поле user_data прописано выполнение набора скриптов cloud-init, результаты работы которых будут внедрены в ВМ.

Cloud-init

Cloud-init позволяет автоматически выполнить в облачных инфраструктурах определенный набор команд после запуска ВМ. Поскольку невозможно «запечь» в ВМ все необходимое, после запуска в зависимости от своего типа она должна либо присоединиться к кластеру Kubernetes, либо инициализировать кластер Kubernetes.

В шаблоне файла cloud-init под названием master.tpl выполняется несколько действий.

  1. записываются конфигурационные файлы для Kubeadm:
    
    #cloud-config
    
    write_files:
    - path: etc/kubernetes/kubeadm.conf
      owner: root:root
      content:
    ...
    
  2. выполняется набор команд:
    • в генерируемый файл конфигурации записывается IP-адрес мастера;
    • инициализируется мастер в кластере Kubernetes командой kubeadm init;
    • в кластере Kubernetes устанавливается оверлейная сеть Calico командой kubectl apply.
      
      runcmd:
       - sed -i "s/CONTROL_PLANE_IP/$(curl http://169.254.169.254/latest/meta-data-local-ipv4)/g" /etc/kubernetes/kubeadm.conf
       - kubeadm init --config /etc/kubernetes/kubeadm.conf
       - mkdir -p $HOME/.kube
       - sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
       - sudo chown $(id -u):$(id -g) $HOME/.kube/config
       - kubectl apply -f https://docs.projectcalico.org/v3.8/manifests/calico.yaml
      

      После выполнения команд при запуске ВМ получается рабочий кластер Kubernetes из одной мастер-ноды. Остальные ноды будут присоединяться к этой мастер-ноде.

Ноды

Файл node.tf похож на файл master.tf. Здесь также создаются ресурсы, которые в данном случае называются node. Единственное отличие в том, что мастер-нода создается в единственном экземпляре, а количество создаваемых рабочих нод задано через переменную nodes_count:


resource "aws_instance" "node" {
 count = "${var.nodes_count}"
 ami = "${var.kubernetes_ami}"
 instance_type = "c3.large"

Файл cloud-init для рабочих нод выполняет всего одну команду — kubeadm join. Эта команда присоединяет готовую машину к кластеру Kubernetes, используя передаваемый нами токен авторизации.

Запуск Terraform

При запуске Terraform использует несколько модулей:

  • модуль AWS;
  • модуль шаблонов;
  • модуль TLS, отвечающий за генерацию ключей.

Эти модули необходимо установить на локальную машину:


terraform init terraform/

Вместе с этой командой указывается директория, в которой расположены все необходимые файлы. При инициализации Terraform скачивает все указанные модули, после чего необходимо выполнить команду terraform plan:


terraform plan -var-file terraform/vars/dev.tfvars terraform/

Обратите внимание, что помимо директории с файлами Terraform указывается файл var-file, в котором содержатся значения переменных, использующихся в файлах Terraform. Директория vars может содержать несколько файлов .tfvars, что позволяет управлять различными типами инфраструктур с помощью одного набора файлов Terraform.

В самом файле dev.tfvars содержатся следующие важные переменные:

  • Kubernetes_version ( устанавливаемая версия Kubernetes);
  • Kubernetes_ami (AMI образа, который создал Packer).

Задав необходимые значения переменных, выполните команду terraform plan, после чего Terraform предоставит список действий, необходимых для достижения состояния, описанного в файлах Terraform.

Проверив этот список, примените предлагаемые изменения:


terraform apply -auto-approve -var-file terraform/vars/dev.tfvars terraform/

От команды terraform plan ее отличает наличие ключа -auto-approve, который избавляет от необходимости подтверждать вносимые изменения.

Кластер Kubernetes

image13.png

Кластер Kubernetes состоит из мастер-ноды, которая выполняет функции управления, и рабочих нод, которые запускают приложения, устанавливаемые в кластере.

На мастер-ноде установлено четыре компонента, обеспечивающих работу данной системы:

  • ETCD, т. е. база данных Kubernetes;
  • API Server, через который мы сохраняем информацию в Kubernetes и получаем из него информацию;
  • Controller Manager;
  • Scheduler.

На рабочих нодах установлено два дополнительных компонента:

  • Kube-proxy (отвечает за генерацию сетевых правил в кластере Kubernetes);
  • Kubelet (отвечает за передачу команды Docker-демону для запуска приложений в кластере Kubernetes).

Между нодами работает сетевой плагин Calico.

Работа компонентов кластера

image14.png

Предположим, что пользователь создает в кластере Kubernetes объект под названием replicaset.

  1. Информация от пользователя передается на API-сервер, который содержит базу данных ETCD. В базе данных сохраняется информация о запуске объекта.
  2. API-сервер возвращает пользователю информацию о создании объекта.
  3. Controller-manager записывает на API-сервер информацию о том, что необходимо создать «поды», то есть инстансы приложения.
  4. Scheduler назначает созданным подам конкретные ноды из кластера. Информация об этом снова сохраняется в ETCD на API-сервере.
  5. Kubelet передает API-запрос в Docker по запуску необходимого образа.
  6. Docker выполняет установку подов.
  7. Kubelet передает на API-сервер информацию о том, что контейнеры запущены и работают.

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

Kubeadm

image7.png

Процесс установки кластера Kubernetes включает в себя установку и настройку всех компонентов, налаживание связи между ними по защищенным TLS-каналам, генерацию нужных сертификатов и т. д. Для автоматизации данных действий используется утилита Kubeadm. Она сертифицирована Kubernetes и поддерживается самим сообществом Kubernetes.

Kubeadm позволяет:

  • установить, сконфигурировать и запустить все основные компоненты кластера;
  • управлять сертификатами, в т. ч. ротировать их и выписывать новы;
  • управлять версиями компонентов кластера (производить апгрейд и даунгрейд).

При этом Kubeadm не является полноценной системой управления кластером Kubernetes, а представляет собой своего рода строительный блок, который позволяет настроить Kubernetes на той ноде, на которой утилита Kubeadm запущена. Это означает, что необходима система оркестрации, которая будет запускать все необходимые ВМ, настраивать их и запускать Kubeadm на всех нодах. Именно для этих целей используется Terraform.

Сервисы упоминаемые в статье

  1. Публичное облако КРОК

Не пропустите самые важные, интересные и полезные статьи недели

Ваш e-mail успешно подписан.

Смотрите также