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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В директории под названием packer содержатся файлы шаблонов в формате JSON. В том числе в ней расположен основной шаблон для Packer — файл 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 хранит все значения переменных, объявленных в первой части файла 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 build -var-file=settings.json -var 'subnet_id=subnet-0854C500' -force base.json

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

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

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

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

После этого запустите Packer. Он находит исходный образ ВМ, разворачивает ее в Облаке КРОК и выполняет на ней 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 — это еще один продукт от компании HashiCorp. От других систем оркестрации облаков Terraform отличает то, что он позволяет описать все состояние инфраструктуры в файлах на языке HCL.

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

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

После окончания работы 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}"
}

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

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

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 описывается создание нескольких шаблонов и инстанс. В частности, создается мастер-инстанс 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"
}