Всем привет! Меня зовут Виктор, я DevOps‑инженер компании Nixys, которая помогает другим компаниям внедрять в их IT‑решения передовые практики DevOps, MLOps и DevSecOps.
Сегодня я приглашаю вас вместе со мной пройти путь «от незнания к best practices» в работе с Terraform. Этот материал подготовлен для серии наших одноименных видеороликов на YouTube, но мы решили дополнить его и предложить вам более детальное описание процесса в этой статье.
Не забывайте следить за нашими обновлениями на YouTube, Habr и подписывайтесь на наш Telegram‑канал DevOps FM — мы всегда рады новым друзьям. Начнём?
Чем мне поможет Terraform? Так ли он мне нужен?
Ответ однозначный — да! Если у вашего провайдера есть возможность работы с этим инструментом, обязательно используйте его.
Почему? В первую очередь, Terraform — это автоматизация. А всё, что можно автоматизировать, надо автоматизировать. Да‑да, тавтология, но, надеюсь, так лучше закрепится мысль. Вы же не задаетесь вопросом: «а зачем конвейерные линии на производстве ставят», верно? Вот и здесь принцип тот же. Да, вам нужен оператор этой линии (в нашем случае толковый DevOps‑инженер с нужными скиллами), но просто вдумайтесь, сколько проблем вы этим решаете!
Предоставление инфраструктуры и решение долгих рутинных задач. Наверняка перед вами когда‑то возникала проблема, что нужно обеспечить несколько сред для разработки своего продукта, так как параллельно у вас 20 разрабов сражаются за то, чтобы запустить свой код на единственном сервере (а в большинстве случаев они просто будут ждать пока под них не настроят окружение). Вы же в это время получаете простой в разработке, неконкурентоспособность на рынке и т. д. и т. п. Если это про вас, тогда вам определенно нужен Terraform, ведь он автоматизирует процесс создания и предоставления ресурсов инфраструктуры — таких, как серверы, сети, балансировщики нагрузки и базы данных. И вуаля — вам не нужно тратить кучу времени на новое окружение.
Снижение человеческого фактора. У вас было такое, что в процессе работы проекта, возникали ошибки по вине человека? Это может быть что угодно: опечатка в названии сервиса при обращении к нему, или же просто кто‑то мог поторопиться, мискликнуть и случайно удалить не ту машину. Вот 100% что было, все мы люди. Тогда опишите свою инфраструктуру кодом, вы снизите шанс подобного к минимуму. Не до нуля, нет, но на несколько порядков меньше — это факт.
Обновление. Ох, когда‑нибудь сталкивались с тем, что на рабочем проекте нужно обновить софт? И ладно если это что‑то несущественное, а вдруг надо прям куб обновлять, да ещё через несколько мажорных версий? В общем, Terraform и тут поможет: потратьте время на описание своей инфраструктуры в коде и вы забудете эту боль. Это не снимет с вас обязанность продумать все нюансы. Но во‑первых, Terraform изначально заставляет вас организовать инфраструктуру особым образом, и с такой организацией легче обновляться, а во‑вторых — запускаете две команды, и вы подняли полный клон своей инфраструктуры — можете там ломать, откатывать, переделывать всё, что вашей душе угодно. И если у вас получилось обновиться, с вероятностью, крайне близкой к 100%, вы без проблем обновите и свой прод.
Стандартизация. Если у вас команда из двух и более человек, работающих с инфраструктурой, то вы наверняка сталкивались с тем, что они работают по‑разному. Да есть нормы, но они разнятся от компании к компании, и в регламенты всё не затолкаешь, и по итогу получаете вроде бы одну инфраструктуру, но часть поднята одним способом, часть — другим. Это может быть что угодно — от нестандартизированных имён сервисов до использования разных ОС для однотипных хостов. С Terraform вы это решаете, так или иначе. Даже если у вас нет регламента к написанию кода, всё устроено таким образом, что инженерам всё равно придётся работать по одному стандарту.
Очевидность. Нанимали нового человека? Сколько времени ему нужно на то, чтобы влиться в работу? С инфраструктурой, которая поднята руками, всё ещё сложнее — там может быть столько неочевидных вещей, что обнаружить их можно будет только когда что‑то уже сломалось, и инженеру приходится носом землю рыть в поисках неисправности. Если вы описали всё с помощью кода, это означает, что больше нет кучи мест, где может быть реализован тот или иной функционал — всё здесь, в манифестах. Да, они могут быть сложны и запутанны, но, по крайней мере, это не какой‑нибудь пользовательский cron на 101-м сервере ходит в прод и забивает весь пул соединений — если он есть, то описан в коде, и мы знаем где его искать. Есть один универсальный источник — это код: ознакомился с ним, значит ознакомился со всей инфраструктурой.
Работа в команде. Здесь всё просто — система контроля версий. Если есть код, мы и работаем с ним, как с кодом. Заливаем его в GitHub, GitLab или где вы привыкли работать — и всё, мы обеспечили необходимый функционал для нормальной работы в команде. Если у вас всё руками поднималось, забудьте про такие плюшки.
В целом, Terraform — это мощный инструмент, который решает множество проблем как IT‑отдела в частности, так и, соответственно, бизнеса в целом.
Теперь повторим основы
Terraform — это инструмент, который позволяет описывать инфраструктуру в виде кода и автоматизировать её развёртывание, модификацию и удаление. Он поддерживает множество провайдеров — таких, как AWS, Google Cloud, Azure, Yandex Cloud и других.
Одним из основных преимуществ Terraform является возможность описать желаемое состояние инфраструктуры в виде кода, и затем он автоматически приводит её в это состояние, а вы не заботитесь о ручном управлении каждым ресурсом.
Чтобы начать эффективно работать с этим инструментом, важно понимать основные концепции — такие, как манифесты, провайдеры и команды. Далее в статье мы рассмотрим их, а также принципы работы с Terraform. Кроме того, я расскажу про best practices, которые помогут вам создавать качественный и надежный код.
Итак, Terraform использует манифесты, чтобы описать состояние инфраструктуры, которую вы хотите создать или управлять. Манифесты Terraform — это файлы с расширением.tf, которые содержат описание ресурсов, их атрибутов и зависимостей. Для описания манифестов используется HashiCorp Configuration Language (HCL). HCL является удобным и понятным языком, который позволяет описывать ресурсы, зависимости между ними и указывать значения атрибутов.
После того, как манифесты написаны, Terraform может использовать их для управления ресурсами в провайдере. Это позволяет вам автоматизировать процесс работы с инфраструктурой, улучшать ее надежность и снижать вероятность возникновения ручных ошибок.
Terraform использует несколько основных элементов для описания инфраструктуры:
Providers: провайдеры — это интерфейсы для взаимодействия с ресурсами, такими, как AWS, Google Cloud, Microsoft Azure и т. д.
Resources: ресурсы — это объекты, которые вы хотите создать, удалить или изменить. Например, виртуальная машина, балансировщик нагрузки, база данных.
Variables: переменные — это значения, которые можно передать в Terraform для конфигурирования вашей инфраструктуры.
Data Sources: источники данных — это инструменты, которые позволяют Terraform получать данные из внешних источников, таких как API, базы данных или другие службы.
Outputs: выводы — это результаты, которые Terraform выдает после выполнения конфигурации, например, IP‑адреса, идентификаторы ресурсов и т. д.
Дополнительные элементы Terraform, которые стоит упомянуть:
Модули. Позволяют повторно использовать код и упрощают управление сложными инфраструктурами.
Варианты окружения. Terraform позволяет управлять различными версиями инфраструктуры в зависимости от окружения.
Выражения. Terraform использует выражения для вычисления значений и проверки условий.
Итак, мы понимаем, что с помощью Terraform можно описать инфраструктуру в коде, этот код содержится в файлах, что логично🙂, так давайте поговорим с вами о них.
Основные типы файлов, которые вы можете использовать в Terraform, включают в себя:
Файлы конфигурации (.tf файлы) — это основные файлы Terraform, которые содержат описание ресурсов, которые вы хотите создать или управлять.
Файлы переменных (.tfvars файлы) — это файлы, которые содержат значения переменных, использующихся в файлах конфигурации.
Файл состояния (.tfstate файл): это файл, который хранит текущее состояние вашей инфраструктуры. Он обновляется каждый раз, когда вы запускаете apply (конечно, если вы что‑то изменили в коде).
Также, стоит отдельно рассказать про файл состояния ‑.tfstate. Terraform сохраняет информацию о текущем состоянии вашей инфраструктуры в файле состояния. Этот файл содержит информацию о ресурсах, которые уже были созданы в вашей инфраструктуре, и их текущих свойствах.
Terraform использует этот файл, чтобы определить, какие ресурсы необходимо изменить, какие создать, а какие необходимо удалить, когда вы запускаете команду apply. Грубо говоря, он помогает Terraform определять, какие изменения необходимо внести в инфраструктуру, чтобы ее состояние соответствовало описанному в конфигурационных файлах.
Файл состояния может храниться локально или удаленно, например, в объектном хранилище. Это позволяет вам хранить общую копию файла состояния и управлять им с нескольких хостов.
Важно отметить, что файл состояния является важным аспектом управления вашей инфраструктурой, поэтому необходимо обеспечить его блокировку на время работы с ним.
Также, нужно понимать, что файл состояния является конфиденциальным, и его необходимо хранить в безопасном месте, так как он содержит важную информацию о всей вашей инфраструктуре.
Кроме всего этого, хочу упомянуть, что если вам пришлось вручную залезть в tfstate‑файл, то, как говорит мой коллега: «Вы где‑то что‑то сделали не так в этой жизни» 🙂
Теперь давайте поговорим с вами о том, на какие best practices стоит обратить внимание:
Не храните всю инфраструктуру в одном месте, разбейте её на части;
Изолируйте несвязанные компоненты друг от друга. Разделяйте логически свою инфраструктуру, сеть, сервисы, мониторинг и т. д.;
Не храните файл состояния локально;
Блокируйте файл состояния при работе;
Пишите код так, чтобы потом его можно было использовать в другом месте, используйте модули.
Пользуйтесь переменными — удобнее использовать переменные для управления конфигурацией инфраструктуры.
Пишите документацию, она всегда пригодится.
Чуть подробнее о том, что мы здесь перечислили
Когда вы пишите код своей инфраструктуры, достаточно написать всё в одном файле, к примеру в файле main.tf:
my_project/
└── main.tfВ нём будет всё, и объявление провайдеров, и ресурсы, и data sources, и outputs:
terraform {
required_providers {
yandex = {
source = "yandex-cloud/yandex"
}
}
required_version = ">= 0.13"
backend "s3" {
endpoint = "storage.yandexcloud.net"
bucket = "BAKET_NAME"
region = "ru-central1"
key = "FILE_NAME"
shared_credentials_file = "storage.key"
skip_region_validation = true
skip_credentials_validation = true
}
}
provider "yandex" {
service_account_key_file = "key.json"
cloud_id = "CLOUD_ID"
folder_id = "FOLDER_ID"
zone = "ru-central1-a"
}
resource "yandex_vpc_network" "test-vpc" {
name = "nixys"
}
resource "yandex_vpc_subnet" "test-subnet" {
v4_cidr_blocks = ["10.2.0.0/16"]
network_id = yandex_vpc_network.test-vpc.id
}
resource "yandex_vpc_security_group" "test-sg" {
name = "My security group"
description = "description for my security group"
network_id = yandex_vpc_network.test-vpc.id
labels = {
my-label = "my-label-value"
}
dynamic "ingress" {
for_each = ["80", "8080"]
content {
protocol = "TCP"
description = "rule1 description"
v4_cidr_blocks = ["0.0.0.0/0"]
from_port = ingress.value
to_port = ingress.value
}
}
egress {
protocol = "ANY"
description = "rule2 description"
v4_cidr_blocks = ["0.0.0.0/0"]
from_port = 0
to_port = 65535
}
}
resource "yandex_vpc_address" "test-ip" {
name = "exampleAddress"
external_ipv4_address {
zone_id = "ru-central1-a"
}
}
resource "yandex_compute_instance" "nixys" {
name = "nixys"
platform_id = "standard-v1"
resources {
cores = 2
memory = 2
}
boot_disk {
initialize_params {
image_id = "fd83h3kff4ja27ejq0d9"
}
}
network_interface {
subnet_id = yandex_vpc_subnet.test-subnet.id
nat = true
nat_ip_address = yandex_vpc_address.test-ip.external_ipv4_address.0.address
}
metadata = {
ssh-keys = "debian:${file("/root/.ssh/id_rsa.pub")}"
user-data = "${file("init.sh")}"
}
}
output "external_ip" {
value = yandex_vpc_address.test-ip.external_ipv4_address.0.address
}
output "external_ip-2" {
value = yandex_compute_instance.nixys.network_interface.0.nat_ip_address
}Terraform это «прожуёт» и исполнит код. Всё бы ничего, если вы описали один ресурс, но их может быть два, а может и пару десятков. В таком файле будет уже сложнее разбираться и вносить изменения в инфраструктуру.
Хорошо, мы можем под каждый ресурс создавать отдельный файл, например gitlab.tf, mongodb.tf, rebbitmq.tf и т. д.:
my_project/
├── k8s
└── networkУже лучше, теперь мы знаем в каком файле необходимо изменить значение или дописать параметр. Но возникает ещё одна проблема — Terraform воспринимает все файлы в рабочем каталоге как один, а это значит, что и при запуске plan или apply он пойдёт перепроверять всю вашу инфраструктуру. Это долго и никому не нужно. Нет необходимости перепроверять ресурсы для кластера k8s, если изменения вносились в подсеть. Какой тогда выход? Всё просто, мы создадим отдельный рабочий каталог под каждый ресурс или связанную логически группу ресурсов:
my_project/
├── k8s
│ └── main.tf
└── network
└── main.tfТеперь у нас имеется несколько манифестов Terraform, каждый из которых описывает свою часть общей инфраструктуры, но всё же у нас остаётся проблема с тем, что всё свалено в одну кучу. Описание того же кластера k8s достаточно большое, и работать в одном файле совсем не удобно. Решение следующее — мы разбиваем конфигурационные файлы по типу описываемых компонентов, т. е. есть главный файл main.tf, где мы объявим провайдера и пропишем доступы к облаку. Далее, мы логически распределим код в отдельные файлы. Выглядит это следующим образом:
my_project/
├── k8s
│ ├── cluster.tf
│ ├── main.tf
│ ├── node_group.tf
│ ├── service_account.tf
└── network
├── external_ip.tf
├── main.tf
├── security_group.tf
└── vpc.tfТаким образом, мы и разделяем конфигурацию логически и с легкостью разберемся в инфраструктуре, если видим её впервые.
Конечно, можно придумывать ещё много разных усовершенствований, но иногда стоит просто остановиться и работать дальше)
Поднимаем кластер
Итак, теперь мы примерно понимаем, что к чему, и как нам организовать нашу конфигурацию. Давайте теперь перейдём к делу и начнём создание межрегионального кластера kubernetes с автоскейлингом worker-нод с помощью Terraform в Yandex Cloud. В этом кластере мы поднимем мониторинг посредством kube-prometheus-stack.
Части про установку Terraform и yc (консольной утилиты Yandex Cloud) я снова пропускаю, вы можете самостоятельно ознакомиться с этой информацией по приведённым ссылкам.
Также я не буду останавливаться на создании сервисного аккаунта и организации доступа к облаку, об этом я рассказывал в демонстрационном ролике – DevOps с Nixys | Знакомство с Terraform - Tutorial для начинающих #1.
Начнём мы, как это водится, с документации. Согласно ей, код по созданию межрегионального кластера будет выглядеть так:
main.tf
locals {
cloud_id = "b1gq90dgh25bebiu75o"
folder_id = "b1gia87mbaomkfvsleds"
k8s_version = "1.22"
sa_name = "myaccount"
}
terraform {
required_providers {
yandex = {
source = "yandex-cloud/yandex"
}
}
}
provider "yandex" {
folder_id = local.folder_id
}
resource "yandex_kubernetes_cluster" "k8s-regional" {
network_id = yandex_vpc_network.mynet.id
master {
version = local.k8s_version
regional {
region = "ru-central1"
location {
zone = yandex_vpc_subnet.mysubnet-a.zone
subnet_id = yandex_vpc_subnet.mysubnet-a.id
}
location {
zone = yandex_vpc_subnet.mysubnet-b.zone
subnet_id = yandex_vpc_subnet.mysubnet-b.id
}
location {
zone = yandex_vpc_subnet.mysubnet-c.zone
subnet_id = yandex_vpc_subnet.mysubnet-c.id
}
}
security_group_ids = [yandex_vpc_security_group.k8s-main-sg.id]
}
service_account_id = yandex_iam_service_account.myaccount.id
node_service_account_id = yandex_iam_service_account.myaccount.id
depends_on = [
yandex_resourcemanager_folder_iam_binding.k8s-clusters-agent,
yandex_resourcemanager_folder_iam_binding.vpc-public-admin,
yandex_resourcemanager_folder_iam_binding.images-puller
]
kms_provider {
key_id = yandex_kms_symmetric_key.kms-key.id
}
}
resource "yandex_vpc_network" "mynet" {
name = "mynet"
}
resource "yandex_vpc_subnet" "mysubnet-a" {
v4_cidr_blocks = ["10.5.0.0/16"]
zone = "ru-central1-a"
network_id = yandex_vpc_network.mynet.id
}
resource "yandex_vpc_subnet" "mysubnet-b" {
v4_cidr_blocks = ["10.6.0.0/16"]
zone = "ru-central1-b"
network_id = yandex_vpc_network.mynet.id
}
resource "yandex_vpc_subnet" "mysubnet-c" {
v4_cidr_blocks = ["10.7.0.0/16"]
zone = "ru-central1-c"
network_id = yandex_vpc_network.mynet.id
}
resource "yandex_iam_service_account" "myaccount" {
name = local.sa_name
description = "K8S regional service account"
}
resource "yandex_resourcemanager_folder_iam_binding" "k8s-clusters-agent" {
# Сервисному аккаунту назначается роль "k8s.clusters.agent".
folder_id = local.folder_id
role = "k8s.clusters.agent"
members = [
"serviceAccount:${yandex_iam_service_account.myaccount.id}"
]
}
resource "yandex_resourcemanager_folder_iam_binding" "vpc-public-admin" {
# Сервисному аккаунту назначается роль "vpc.publicAdmin".
folder_id = local.folder_id
role = "vpc.publicAdmin"
members = [
"serviceAccount:${yandex_iam_service_account.myaccount.id}"
]
}
resource "yandex_resourcemanager_folder_iam_binding" "images-puller" {
# Сервисному аккаунту назначается роль "container-registry.images.puller".
folder_id = local.folder_id
role = "container-registry.images.puller"
members = [
"serviceAccount:${yandex_iam_service_account.myaccount.id}"
]
}
resource "yandex_kms_symmetric_key" "kms-key" {
# Ключ для шифрования важной информации, такой как пароли, OAuth-токены и SSH-ключи.
name = "kms-key"
default_algorithm = "AES_128"
rotation_period = "8760h" # 1 год.
}
resource "yandex_kms_symmetric_key_iam_binding" "viewer" {
symmetric_key_id = yandex_kms_symmetric_key.kms-key.id
role = "viewer"
members = [
"serviceAccount:${yandex_iam_service_account.myaccount.id}",
]
}
resource "yandex_vpc_security_group" "k8s-main-sg" {
name = "k8s-main-sg"
description = "Правила группы обеспечивают базовую работоспособность кластера. Примените ее к кластеру и группам узлов."
network_id = yandex_vpc_network.mynet.id
ingress {
protocol = "TCP"
description = "Правило разрешает проверки доступности с диапазона адресов балансировщика нагрузки. Нужно для работы отказоустойчивого кластера и сервисов балансировщика."
predefined_target = "loadbalancer_healthchecks"
from_port = 0
to_port = 65535
}
ingress {
protocol = "ANY"
description = "Правило разрешает взаимодействие мастер-узел и узел-узел внутри группы безопасности."
predefined_target = "self_security_group"
from_port = 0
to_port = 65535
}
ingress {
protocol = "ANY"
description = "Правило разрешает взаимодействие под-под и сервис-сервис. Укажите подсети вашего кластера и сервисов."
v4_cidr_blocks = concat(yandex_vpc_subnet.mysubnet-a.v4_cidr_blocks, yandex_vpc_subnet.mysubnet-b.v4_cidr_blocks, yandex_vpc_subnet.mysubnet-c.v4_cidr_blocks)
from_port = 0
to_port = 65535
}
ingress {
protocol = "ICMP"
description = "Правило разрешает отладочные ICMP-пакеты из внутренних подсетей."
v4_cidr_blocks = ["10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16"]
}
ingress {
protocol = "TCP"
description = "Правило разрешает входящий трафик из интернета на диапазон портов NodePort. Добавьте или измените порты на нужные вам."
v4_cidr_blocks = ["0.0.0.0/0"]
from_port = 30000
to_port = 32767
}
egress {
protocol = "ANY"
description = "Правило разрешает весь исходящий трафик. Узлы могут связаться с Yandex Container Registry, Yandex Object Storage, Docker Hub и т. д."
v4_cidr_blocks = ["0.0.0.0/0"]
from_port = 0
to_port = 65535
}
}А чтобы развернуть ещё и группы узлов, понадобится новый ресурс:
main.tf
resource "yandex_kubernetes_node_group" "my_node_group_a" {
cluster_id = yandex_kubernetes_cluster.k8s-regional.id
name = "worker-a"
description = "description"
version = local.k8s_version
labels = {
"key" = "value"
}
instance_template {
platform_id = "standard-v1"
name = "worker-a-{instance.short_id}"
network_interface {
nat = true
subnet_ids = [yandex_vpc_subnet.mysubnet-a.id]
security_group_ids = [yandex_vpc_security_group.k8s-main-sg.id]
}
resources {
memory = 2
cores = 2
}
boot_disk {
type = "network-hdd"
size = 32
}
scheduling_policy {
preemptible = false
}
}
scale_policy {
auto_scale {
min = 1
max = 3
initial = 1
}
}
allocation_policy {
location {
zone = "ru-central1-a"
}
}
}Это согласно инструкции Яндекса + документации Terraform.
Если хотим больше групп — давайте сделаем по одной в каждой зоне и в конечном итоге, с остальными ресурсами мы получим такую картину:
main.tf
locals {
cloud_id = "b1gq90dgh25bebiu75o"
folder_id = "b1gia87mbaomkfvsleds"
k8s_version = "1.22"
sa_name = "myaccount"
}
terraform {
required_providers {
yandex = {
source = "yandex-cloud/yandex"
}
}
}
provider "yandex" {
folder_id = local.folder_id
}
resource "yandex_kubernetes_cluster" "k8s-regional" {
network_id = yandex_vpc_network.mynet.id
master {
version = local.k8s_version
regional {
region = "ru-central1"
location {
zone = yandex_vpc_subnet.mysubnet-a.zone
subnet_id = yandex_vpc_subnet.mysubnet-a.id
}
location {
zone = yandex_vpc_subnet.mysubnet-b.zone
subnet_id = yandex_vpc_subnet.mysubnet-b.id
}
location {
zone = yandex_vpc_subnet.mysubnet-c.zone
subnet_id = yandex_vpc_subnet.mysubnet-c.id
}
}
security_group_ids = [yandex_vpc_security_group.k8s-main-sg.id]
}
service_account_id = yandex_iam_service_account.myaccount.id
node_service_account_id = yandex_iam_service_account.myaccount.id
depends_on = [
yandex_resourcemanager_folder_iam_binding.k8s-clusters-agent,
yandex_resourcemanager_folder_iam_binding.vpc-public-admin,
yandex_resourcemanager_folder_iam_binding.images-puller
]
kms_provider {
key_id = yandex_kms_symmetric_key.kms-key.id
}
}
resource "yandex_vpc_network" "mynet" {
name = "mynet"
}
resource "yandex_vpc_subnet" "mysubnet-a" {
v4_cidr_blocks = ["10.5.0.0/16"]
zone = "ru-central1-a"
network_id = yandex_vpc_network.mynet.id
}
resource "yandex_vpc_subnet" "mysubnet-b" {
v4_cidr_blocks = ["10.6.0.0/16"]
zone = "ru-central1-b"
network_id = yandex_vpc_network.mynet.id
}
resource "yandex_vpc_subnet" "mysubnet-c" {
v4_cidr_blocks = ["10.7.0.0/16"]
zone = "ru-central1-c"
network_id = yandex_vpc_network.mynet.id
}
resource "yandex_iam_service_account" "myaccount" {
name = local.sa_name
description = "K8S regional service account"
}
resource "yandex_resourcemanager_folder_iam_binding" "k8s-clusters-agent" {
# Сервисному аккаунту назначается роль "k8s.clusters.agent".
folder_id = local.folder_id
role = "k8s.clusters.agent"
members = [
"serviceAccount:${yandex_iam_service_account.myaccount.id}"
]
}
resource "yandex_resourcemanager_folder_iam_binding" "vpc-public-admin" {
# Сервисному аккаунту назначается роль "vpc.publicAdmin".
folder_id = local.folder_id
role = "vpc.publicAdmin"
members = [
"serviceAccount:${yandex_iam_service_account.myaccount.id}"
]
}
resource "yandex_resourcemanager_folder_iam_binding" "images-puller" {
# Сервисному аккаунту назначается роль "container-registry.images.puller".
folder_id = local.folder_id
role = "container-registry.images.puller"
members = [
"serviceAccount:${yandex_iam_service_account.myaccount.id}"
]
}
resource "yandex_kms_symmetric_key" "kms-key" {
# Ключ для шифрования важной информации, такой как пароли, OAuth-токены и SSH-ключи.
name = "kms-key"
default_algorithm = "AES_128"
rotation_period = "8760h" # 1 год.
}
resource "yandex_kms_symmetric_key_iam_binding" "viewer" {
symmetric_key_id = yandex_kms_symmetric_key.kms-key.id
role = "viewer"
members = [
"serviceAccount:${yandex_iam_service_account.myaccount.id}",
]
}
resource "yandex_vpc_security_group" "k8s-main-sg" {
name = "k8s-main-sg"
description = "Правила группы обеспечивают базовую работоспособность кластера. Примените ее к кластеру и группам узлов."
network_id = yandex_vpc_network.mynet.id
ingress {
protocol = "TCP"
description = "Правило разрешает проверки доступности с диапазона адресов балансировщика нагрузки. Нужно для работы отказоустойчивого кластера и сервисов балансировщика."
predefined_target = "loadbalancer_healthchecks"
from_port = 0
to_port = 65535
}
ingress {
protocol = "ANY"
description = "Правило разрешает взаимодействие мастер-узел и узел-узел внутри группы безопасности."
predefined_target = "self_security_group"
from_port = 0
to_port = 65535
}
ingress {
protocol = "ANY"
description = "Правило разрешает взаимодействие под-под и сервис-сервис. Укажите подсети вашего кластера и сервисов."
v4_cidr_blocks = concat(yandex_vpc_subnet.mysubnet-a.v4_cidr_blocks, yandex_vpc_subnet.mysubnet-b.v4_cidr_blocks, yandex_vpc_subnet.mysubnet-c.v4_cidr_blocks)
from_port = 0
to_port = 65535
}
ingress {
protocol = "ICMP"
description = "Правило разрешает отладочные ICMP-пакеты из внутренних подсетей."
v4_cidr_blocks = ["10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16"]
}
ingress {
protocol = "TCP"
description = "Правило разрешает входящий трафик из интернета на диапазон портов NodePort. Добавьте или измените порты на нужные вам."
v4_cidr_blocks = ["0.0.0.0/0"]
from_port = 30000
to_port = 32767
}
egress {
protocol = "ANY"
description = "Правило разрешает весь исходящий трафик. Узлы могут связаться с Yandex Container Registry, Yandex Object Storage, Docker Hub и т. д."
v4_cidr_blocks = ["0.0.0.0/0"]
from_port = 0
to_port = 65535
}
}
resource "yandex_kubernetes_node_group" "my_node_group_a" {
cluster_id = yandex_kubernetes_cluster.k8s-regional.id
name = "worker-a"
description = "description"
version = local.k8s_version
labels = {
"key" = "value"
}
instance_template {
platform_id = "standard-v1"
name = "worker-a-{instance.short_id}"
network_interface {
nat = true
subnet_ids = [yandex_vpc_subnet.mysubnet-a.id]
security_group_ids = [yandex_vpc_security_group.k8s-main-sg.id]
}
resources {
memory = 2
cores = 2
}
boot_disk {
type = "network-hdd"
size = 32
}
scheduling_policy {
preemptible = false
}
}
scale_policy {
auto_scale {
min = 1
max = 3
initial = 1
}
}
allocation_policy {
location {
zone = "ru-central1-a"
}
}
}
resource "yandex_kubernetes_node_group" "my_node_group_b" {
cluster_id = yandex_kubernetes_cluster.k8s-regional.id
name = "worker-b"
description = "description"
version = local.k8s_version
labels = {
"key" = "value"
}
instance_template {
platform_id = "standard-v1"
name = "worker-b-{instance.short_id}"
network_interface {
nat = true
subnet_ids = [yandex_vpc_subnet.mysubnet-b.id]
security_group_ids = [yandex_vpc_security_group.k8s-main-sg.id]
}
resources {
memory = 2
cores = 2
}
boot_disk {
type = "network-hdd"
size = 32
}
scheduling_policy {
preemptible = false
}
}
scale_policy {
auto_scale {
min = 1
max = 3
initial = 1
}
}
allocation_policy {
location {
zone = "ru-central1-b"
}
}
}
resource "yandex_kubernetes_node_group" "my_node_group_c" {
cluster_id = yandex_kubernetes_cluster.k8s-regional.id
name = "worker-c"
description = "description"
version = local.k8s_version
labels = {
"key" = "value"
}
instance_template {
platform_id = "standard-v1"
name = "worker-c-{instance.short_id}"
network_interface {
nat = true
subnet_ids = [yandex_vpc_subnet.mysubnet-c.id]
security_group_ids = [yandex_vpc_security_group.k8s-main-sg.id]
}
resources {
memory = 2
cores = 2
}
boot_disk {
type = "network-hdd"
size = 32
}
scheduling_policy {
preemptible = false
}
}
scale_policy {
auto_scale {
min = 1
max = 3
initial = 1
}
}
allocation_policy {
location {
zone = "ru-central1-c"
}
}
}В принципе, если не париться, можно запускать и так. Всё заведётся и будет работать. Мы получим отказоустойчивый кластер k8s с рабочими узлами в разных зонах доступности, да ещё и с автоскейлингом. Но сможем ли мы оставить всё как есть? Конечно же нет, давайте сделаем из этого франкенштейна аккуратные, красивые, а главное функциональные манифесты, с которыми в дальнейшем можно будет жить с чистой совестью.
Погнали)
Работать мы будем в отдельной директории my_project.
mkdir ~/my_projectДля того, чтобы создать кластер k8s нам потребуется сеть, подсеть и сервисный аккаунт. Поэтому, в соответствии с упомянутыми ранее рекомендациями, мы начнём создавать инфраструктуру с сети и её компонентов в отдельном рабочем каталоге network:
mkdir ~/my_project/network
cd ~/my_project/networkДалее мы создадим файл main.tf, в нем пропишем провайдера и доступ к облаку:
my_project/network/main.tf
terraform {
required_providers {
yandex = {
source = "yandex-cloud/yandex"
}
}
required_version = ">= 0.13"
backend "s3" {
endpoint = "storage.yandexcloud.net"
bucket = "test-tfstate"
region = "ru-central1"
key = "my-project-network.tfstate"
shared_credentials_file = "storage.key"
skip_region_validation = true
skip_credentials_validation = true
}
}
provider "yandex" {
service_account_key_file = "key.json"
cloud_id = "b1gq90dgh25bebiu75o"
folder_id = "b1gia87mbaomkfvsleds"
zone = "ru-central1-a"
}Всё, что здесь описано, должно быть знакомо по предыдущему ролику, поэтому не будем останавливаться на этом и перейдем к описанию сети и подсети, их мы опишем в файле vpc.tf:
my_project/network/vpc.tf
resource "yandex_vpc_network" "network-main" {
name = "mynet"
}
resource "yandex_vpc_subnet" "mysubnet-a" {
v4_cidr_blocks = ["10.5.0.0/16"]
zone = "ru-central1-a"
network_id = yandex_vpc_network.network-main.id
}
resource "yandex_vpc_subnet" "mysubnet-b" {
v4_cidr_blocks = ["10.6.0.0/16"]
zone = "ru-central1-b"
network_id = yandex_vpc_network.network-main.id
}
resource "yandex_vpc_subnet" "mysubnet-c" {
v4_cidr_blocks = ["10.7.0.0/16"]
zone = "ru-central1-c"
network_id = yandex_vpc_network.network-main.id
}Это согласно инструкции Яндекса. Давайте на примере кода в main.tf и vpc.tf проведём ряд усовершенствований. Для начала вынесем имя сети и ещё пару параметров в переменные. Создадим файлы terraform.tfvars и variables.tf. Теперь наш рабочий каталог выглядит следующим образом:
my_project/
└── network
├── main.tf
├── terraform.tfvars
├── variables.tf
└── vpc.tfВ файле variables.tf укажем, что хотим создать четыре переменные:
my_project/network/variables.tf
#=========== main ==============
variable "cloud_id" {
description = "The cloud ID"
type = string
}
variable "folder_id" {
description = "The folder ID"
type = string
}
variable "default_zone" {
description = "The default zone"
type = string
default = "ru-cenral1-a"
}
#=========== network ==============
variable "network_name" {
description = "The name of main network"
type = string
}Тут мы можем указать пояснение к переменной и указать тип данных. Также, визуально для эстетичности разграничим содержимое.
Далее, в файле terraform.tfvars мы присвоим значение этим переменным:
my_project/network/terraform.tfvars
#=========== main ==============
cloud_id = "b1gq90dgh25bebiu75o"
folder_id = "b1gia87mbaomkfvsleds"
#=========== network ==============
network_name = "mynet"И в конце концов перепишем в файлах main.tf и vpc.tf соответствующие параметры:
my_project/network/main.tf
terraform {
required_providers {
yandex = {
source = "yandex-cloud/yandex"
}
}
required_version = ">= 0.13"
backend "s3" {
endpoint = "storage.yandexcloud.net"
bucket = "test-tfstate"
region = "ru-central1"
key = "my-project-network.tfstate"
shared_credentials_file = "storage.key"
skip_region_validation = true
skip_credentials_validation = true
}
}
provider "yandex" {
service_account_key_file = "key.json"
cloud_id = var.cloud_id
folder_id = var.folder_id
zone = var.default_zone
}my_project/network/vpc.tf
resource "yandex_vpc_network" "network-main" {
name = var.network_name
}
resource "yandex_vpc_subnet" "mysubnet-a" {
v4_cidr_blocks = ["10.5.0.0/16"]
zone = "ru-central1-a"
network_id = yandex_vpc_network.network-main.id
}
resource "yandex_vpc_subnet" "mysubnet-b" {
v4_cidr_blocks = ["10.6.0.0/16"]
zone = "ru-central1-b"
network_id = yandex_vpc_network.network-main.id
}
resource "yandex_vpc_subnet" "mysubnet-c" {
v4_cidr_blocks = ["10.7.0.0/16"]
zone = "ru-central1-c"
network_id = yandex_vpc_network.network-main.id
}Отлично, с переменными разобрались, теперь перейдём к циклу — зачем нам описывать три подсети, по сути одинаковых ресурса, если можно обойтись одним блоком кода, верно? Добавим в variables.tf описание переменной subnets, только здесь мы обозначим не один параметр, а их набор. У Terraform есть тип map, который нам отлично подходит под задачу (ещё бы, для этого и создавался):
my_project/network/variables.tf
#=========== main ==============
variable "cloud_id" {
description = "The cloud ID"
type = string
}
variable "folder_id" {
description = "The folder ID"
type = string
}
variable "default_zone" {
description = "The default zone"
type = string
default = "ru-cenral1-a"
}
#=========== network ==============
variable "network_name" {
description = "The name of main network"
type = string
}
#=========== subnet ==============
variable "subnets" {
description = "Subnets for k8s"
type = map(list(object(
{
name = string,
zone = string,
cidr = list(string)
}))
)
validation {
condition = alltrue([for i in keys(var.subnets) : alltrue([for j in lookup(var.subnets, i) : contains(["ru-central1-a", "ru-central1-b", "ru-central1-c"], j.zone)])])
error_message = "Error! Zones not supported!"
}
}Тут же, исключительно ради примера, делаю проверку на корректность указываемых значений с помощью блока validation, где в condition пишу условие, а в параметре error_message текст ошибки. Можно делать проверки на всё подряд, но это отдельная и трудоемкая задача. Остановимся на том, что просто упомянули о такой возможности.
Далее, в файле terraform.tfvars мы просто укажем значения:
my_project/network/terraform.tfvars
#=========== main ==============
cloud_id = "b1gq90dgh25bebiu75o"
folder_id = "b1gia87mbaomkfvsleds"
#=========== network ==============
network_name = "mynet"
#=========== subnet ==============
subnets = {
"k8s_masters" = [
{
name = "k8s_master_zone_a"
zone = "ru-central1-a"
cidr = ["10.0.1.0/28"]
},
{
name = "k8s_master_zone_b"
zone = "ru-central1-b"
cidr = ["10.0.2.0/28"]
},
{
name = "k8s_master_zone_c"
zone = "ru-central1-c"
cidr = ["10.0.3.0/28"]
}
],
"k8s_workers" = [
{
name = "k8s_worker_zone_a"
zone = "ru-central1-a"
cidr = ["10.0.4.0/28"]
},
{
name = "k8s_worker_zone_b"
zone = "ru-central1-b"
cidr = ["10.0.5.0/28"]
},
{
name = "k8s_worker_zone_c"
zone = "ru-central1-c"
cidr = ["10.0.6.0/28"]
}
],
}Как вы можете видеть, я добавил ещё 3 подсети для воркер-нод, чтобы всё разграничить.
А теперь создадим файл local.tf, со следующим содержимым:
my_project/network/locals.tf
locals {
subnet_array = flatten([for k, v in var.subnets : [for j in v : {
name = j.name
zone = j.zone
cidr = j.cidr
}
]])
}Выражение перебирает входную переменную var.subnets и с помощью встроенной функции flatten сглаживает полученный вложенный список в единый одномерный список объектов. Каждый объект в результирующем списке имеет три атрибута: name, zone и cidr. При этом, оставляя значение для ключа cidr в списке, что очень важно. Ведь далее в ресурсе нам нужно указывать именно список.
Таким образом, мы можем переписать наш код в vpc.tf:
my_project/network/vpc.tf
resource "yandex_vpc_network" "network-main" {
name = var.network_name
}
resource "yandex_vpc_subnet" "subnet-main" {
for_each = {
for k, v in local.subnet_array : "${v.name}" => v
}
network_id = yandex_vpc_network.network-main.id
v4_cidr_blocks = each.value.cidr
zone = each.value.zone
name = each.value.name
}Здесь мы используем цикл for_each, в котором сопоставляем уникальный идентификатор с каждым элементом списка local.subnet_array. В данном случае, уникальным идентификатором является “name”.
Таким образом, сейчас для Terraform это выглядит как 6 ресурсов, и он создаст отдельные подсети с уникальным именем.
Всё, у нас есть 6 подсетей 🙂
Что ещё. А, ну давайте создадим статические IP-адреса, сколько бы их ни было. Действуем по тому же сценарию, в variables.tf добавляем новую переменную:
my_project/network/variables.tf
#=========== main ==============
variable "cloud_id" {
description = "The cloud ID"
type = string
}
variable "folder_id" {
description = "The folder ID"
type = string
}
variable "default_zone" {
description = "The default zone"
type = string
default = "ru-cenral1-a"
}
#=========== network ==============
variable "network_name" {
description = "The name of main network"
type = string
}
#=========== subnet ==============
variable "subnets" {
description = "Subnets for k8s"
type = map(list(object(
{
name = string,
zone = string,
cidr = list(string)
}))
)
validation {
condition = alltrue([for i in keys(var.subnets) : alltrue([for j in lookup(var.subnets, i) : contains(["ru-central1-a", "ru-central1-b", "ru-central1-c"], j.zone)])])
error_message = "Error! Zones not supported!"
}
}
#=========== external_ip ==============
variable "external_static_ips" {
description = "static ips"
type = map(list(object(
{
name = string,
zone = string
}))
)
}После этого в terraform.tfvars добавляем значения. Сделаю один, но мы сразу закладываем возможность создания нескольких:
my_project/network/terraform.tfvars
#=========== main ==============
cloud_id = "b1gq90dgh25bebiu75o"
folder_id = "b1gia87mbaomkfvsleds"
#=========== network ==============
network_name = "mynet"
#=========== subnet ==============
subnets = {
"k8s_masters" = [
{
name = "k8s_master_zone_a"
zone = "ru-central1-a"
cidr = ["10.0.1.0/28"]
},
{
name = "k8s_master_zone_b"
zone = "ru-central1-b"
cidr = ["10.0.2.0/28"]
},
{
name = "k8s_master_zone_c"
zone = "ru-central1-c"
cidr = ["10.0.3.0/28"]
}
],
"k8s_workers" = [
{
name = "k8s_worker_zone_a"
zone = "ru-central1-a"
cidr = ["10.0.4.0/28"]
},
{
name = "k8s_worker_zone_b"
zone = "ru-central1-b"
cidr = ["10.0.5.0/28"]
},
{
name = "k8s_worker_zone_c"
zone = "ru-central1-c"
cidr = ["10.0.6.0/28"]
}
],
}
#=========== external_ip ==============
external_static_ips = {
ingress_lb = [
{
name = "ingress_lb_zone_ru_central1_a"
zone = "ru-central1-a"
}
]
}Создаём локальную переменную external_ips_array в locals.tf:
my_project/network/locals.tf
locals {
subnet_array = flatten([for k, v in var.subnets : [for j in v : {
name = j.name
zone = j.zone
cidr = j.cidr
}
]])
external_ips_array = flatten([for k, v in var.external_static_ips : [for j in v : {
name = j.name
zone = j.zone
}
]])
}Ну и, наконец, создадим файл static-ip.tf:
my_project/network/static-ip.tf
resource "yandex_vpc_address" "public_addr" {
for_each = {
for v in local.external_ips_array : "${v.name}" => v
}
name = each.value.name
external_ipv4_address {
zone_id = each.value.zone
}
}Всё как и с подсетями.
Что ещё нам потребуется? Конечно же связность подсетей и безопасность, а значит пора заняться описанием security group.
По уже сложившейся традиции, создадим файл security-group.tf, где опишем группы безопасности для мастеров и воркеров:
my_project/network/security-group.tf
resource "yandex_vpc_security_group" "internal" {
name = "internal"
description = "Managed by terraform"
network_id = yandex_vpc_network.mynet.id
labels = {
firewall = "yc_internal"
}
ingress {
protocol = "ANY"
description = "self"
predefined_target = "self_security_group"
from_port = 0
to_port = 65535
}
egress {
protocol = "ANY"
description = "self"
predefined_target = "self_security_group"
from_port = 0
to_port = 65535
}
}
resource "yandex_vpc_security_group" "k8s_master" {
name = "k8s-master"
description = "Managed by terraform"
network_id = yandex_vpc_network.mynet.id
labels = {
firewall = "k8s-master"
}
ingress {
protocol = "TCP"
description = "access to api k8s"
v4_cidr_blocks = var.white_ips_for_master
port = 443
}
ingress {
protocol = "TCP"
description = "access to api k8s from Yandex lb"
predefined_target = "loadbalancer_healthchecks"
from_port = 0
to_port = 65535
}
}
resource "yandex_vpc_security_group" "k8s_worker" {
name = "k8s-worker"
description = "Managed by terraform"
network_id = yandex_vpc_network.mynet.id
labels = {
firewall = "k8s-worker"
}
ingress {
protocol = "ANY"
description = "any connections"
v4_cidr_blocks = ["0.0.0.0/0"]
from_port = 0
to_port = 65535
}
egress {
protocol = "ANY"
description = "any connections"
v4_cidr_blocks = ["0.0.0.0/0"]
from_port = 0
to_port = 65535
}
}Лично я считаю такую организацию групп безопасности более верной для кластера:
internal, для связности мастеров и воркеров, здесь разрешено всё в рамках этой самой группы.
k8s_master исключительно под мастеров где разрешён доступ к 443 порту по переменной, которой мы должны передать вайтлист и служебное правило для балансировщиков.
k8s_worker группа безопасности для воркеров, где мы разрешим вообще всё.
Создадим переменную для вайтлиста и пропишем значение для неё.
my_project/network/variables.tf
#=========== main ==============
variable "cloud_id" {
description = "The cloud ID"
type = string
}
variable "folder_id" {
description = "The folder ID"
type = string
}
variable "default_zone" {
description = "The default zone"
type = string
default = "ru-cenral1-a"
}
#=========== network ==============
variable "network_name" {
description = "The name of main network"
type = string
}
#=========== subnet ==============
variable "subnets" {
description = "Subnets for k8s"
type = map(list(object(
{
name = string,
zone = string,
cidr = list(string)
}))
)
validation {
condition = alltrue([for i in keys(var.subnets) : alltrue([for j in lookup(var.subnets, i) : contains(["ru-central1-a", "ru-central1-b", "ru-central1-c"], j.zone)])])
error_message = "Error! Zones not supported!"
}
}
#=========== external_ip ==============
variable "external_static_ips" {
description = "static ips"
type = map(list(object(
{
name = string,
zone = string
}))
)
}
#=========== security_group ==============
variable "white_ips_for_master" {
type = list(string)
}my_project/network/terraform.tfvars
#=========== main ==============
cloud_id = "b1gq90dgh25bebiu75o"
folder_id = "b1gia87mbaomkfvsleds"
#=========== network ==============
network_name = "mynet"
#=========== subnet ==============
subnets = {
"k8s_masters" = [
{
name = "k8s_master_zone_a"
zone = "ru-central1-a"
cidr = ["10.0.1.0/28"]
},
{
name = "k8s_master_zone_b"
zone = "ru-central1-b"
cidr = ["10.0.2.0/28"]
},
{
name = "k8s_master_zone_c"
zone = "ru-central1-c"
cidr = ["10.0.3.0/28"]
}
],
"k8s_workers" = [
{
name = "k8s_worker_zone_a"
zone = "ru-central1-a"
cidr = ["10.0.4.0/28"]
},
{
name = "k8s_worker_zone_b"
zone = "ru-central1-b"
cidr = ["10.0.5.0/28"]
},
{
name = "k8s_worker_zone_c"
zone = "ru-central1-c"
cidr = ["10.0.6.0/28"]
}
],
}
#=========== external_ip ==============
external_static_ips = {
ingress_lb = [
{
name = "ingress_lb_zone_ru_central1_a"
zone = "ru-central1-a"
}
]
}
#=========== security_group ==============
white_ips_for_master = ["0.0.0.0/0"] # Add your IP ["$YOUR_IP/32"]С network закончили, переносим сюда ключи от сервисного аккаунта и от бакета. Рабочий каталог, после всех наших манипуляций, должен выглядеть следующим образом:
my_project/
└── network
├── external_ip.tf
├── key.json
├── locals.tf
├── main.tf
├── outputs.tf
├── security_group.tf
├── storage.key
├── terraform.tfvars
├── variables.tf
└── vpc.tfМожно запускать terraform init, затем terraform apply.
Теперь переходим к каталогу k8s
mkdir ~/my_project/k8s
cd ~/my_project/k8sВсё по аналогии: создадим файлы main.tf, variables.tf и terraform.tfvars, а также перенесём наши ключи. Кроме того, создадим ещё три конфигурационных файла cluster.tf, node_group.tf и service_account.tf:
my_project/
├── k8s
│ ├── cluster.tf
│ ├── key.json
│ ├── main.tf
│ ├── node_group.tf
│ ├── service_account.tf
│ ├── storage.key
│ ├── terraform.tfvars
│ └── variables.tf
└── network
├── external_ip.tf
├── key.json
├── locals.tf
├── main.tf
├── outputs.tf
├── security_group.tf
├── storage.key
├── terraform.tfvars
├── variables.tf
└── vpc.tfПереносим ресурсы для групп узлов в node_group.tf, описание кластера в cluster.tf, и всё, что относится к сервисным аккаунтам в service_account.tf, сюда же положим и ключ шифрования.
my_project/k8s/cluster.tf
resource "yandex_kubernetes_cluster" "k8s-regional" {
network_id = yandex_vpc_network.mynet.id
master {
version = local.k8s_version
regional {
region = "ru-central1"
location {
zone = yandex_vpc_subnet.mysubnet-a.zone
subnet_id = yandex_vpc_subnet.mysubnet-a.id
}
location {
zone = yandex_vpc_subnet.mysubnet-b.zone
subnet_id = yandex_vpc_subnet.mysubnet-b.id
}
location {
zone = yandex_vpc_subnet.mysubnet-c.zone
subnet_id = yandex_vpc_subnet.mysubnet-c.id
}
}
security_group_ids = [yandex_vpc_security_group.k8s-main-sg.id]
}
service_account_id = yandex_iam_service_account.myaccount.id
node_service_account_id = yandex_iam_service_account.myaccount.id
depends_on = [
yandex_resourcemanager_folder_iam_binding.k8s-clusters-agent,
yandex_resourcemanager_folder_iam_binding.vpc-public-admin,
yandex_resourcemanager_folder_iam_binding.images-puller
]
kms_provider {
key_id = yandex_kms_symmetric_key.kms-key.id
}
}my_project/k8s/service_account.tf
resource "yandex_iam_service_account" "myaccount" {
name = local.sa_name
description = "K8S regional service account"
}
resource "yandex_resourcemanager_folder_iam_binding" "k8s-clusters-agent" {
# Сервисному аккаунту назначается роль "k8s.clusters.agent".
folder_id = local.folder_id
role = "k8s.clusters.agent"
members = [
"serviceAccount:${yandex_iam_service_account.myaccount.id}"
]
}
resource "yandex_resourcemanager_folder_iam_binding" "vpc-public-admin" {
# Сервисному аккаунту назначается роль "vpc.publicAdmin".
folder_id = local.folder_id
role = "vpc.publicAdmin"
members = [
"serviceAccount:${yandex_iam_service_account.myaccount.id}"
]
}
resource "yandex_resourcemanager_folder_iam_binding" "images-puller" {
# Сервисному аккаунту назначается роль "container-registry.images.puller".
folder_id = local.folder_id
role = "container-registry.images.puller"
members = [
"serviceAccount:${yandex_iam_service_account.myaccount.id}"
]
}
resource "yandex_kms_symmetric_key" "kms-key" {
# Ключ для шифрования важной информации, такой как пароли, OAuth-токены и SSH-ключи.
name = "kms-key"
default_algorithm = "AES_128"
rotation_period = "8760h" # 1 год.
}
resource "yandex_kms_symmetric_key_iam_binding" "viewer" {
symmetric_key_id = yandex_kms_symmetric_key.kms-key.id
role = "viewer"
members = [
"serviceAccount:${yandex_iam_service_account.myaccount.id}",
]
}my_project/k8s/node_group.tf
resource "yandex_kubernetes_node_group" "my_node_group_a" {
cluster_id = yandex_kubernetes_cluster.k8s-regional.id
name = "worker-a"
description = "description"
version = local.k8s_version
labels = {
"key" = "value"
}
instance_template {
platform_id = "standard-v1"
name = "worker-a-{instance.short_id}"
network_interface {
nat = true
subnet_ids = [yandex_vpc_subnet.mysubnet-a.id]
security_group_ids = [yandex_vpc_security_group.k8s-main-sg.id]
}
resources {
memory = 2
cores = 2
}
boot_disk {
type = "network-hdd"
size = 32
}
scheduling_policy {
preemptible = false
}
}
scale_policy {
auto_scale {
min = 1
max = 3
initial = 1
}
}
allocation_policy {
location {
zone = "ru-central1-a"
}
}
}
resource "yandex_kubernetes_node_group" "my_node_group_b" {
cluster_id = yandex_kubernetes_cluster.k8s-regional.id
name = "worker-b"
description = "description"
version = local.k8s_version
labels = {
"key" = "value"
}
instance_template {
platform_id = "standard-v1"
name = "worker-b-{instance.short_id}"
network_interface {
nat = true
subnet_ids = [yandex_vpc_subnet.mysubnet-b.id]
security_group_ids = [yandex_vpc_security_group.k8s-main-sg.id]
}
resources {
memory = 2
cores = 2
}
boot_disk {
type = "network-hdd"
size = 32
}
scheduling_policy {
preemptible = false
}
}
scale_policy {
auto_scale {
min = 1
max = 3
initial = 1
}
}
allocation_policy {
location {
zone = "ru-central1-b"
}
}
}
resource "yandex_kubernetes_node_group" "my_node_group_c" {
cluster_id = yandex_kubernetes_cluster.k8s-regional.id
name = "worker-c"
description = "description"
version = local.k8s_version
labels = {
"key" = "value"
}
instance_template {
platform_id = "standard-v1"
name = "worker-c-{instance.short_id}"
network_interface {
nat = true
subnet_ids = [yandex_vpc_subnet.mysubnet-c.id]
security_group_ids = [yandex_vpc_security_group.k8s-main-sg.id]
}
resources {
memory = 2
cores = 2
}
boot_disk {
type = "network-hdd"
size = 32
}
scheduling_policy {
preemptible = false
}
}
scale_policy {
auto_scale {
min = 1
max = 3
initial = 1
}
}
allocation_policy {
location {
zone = "ru-central1-c"
}
}
}Так же, как и в network, создадим переменные:
my_project/k8s/variables.tf
#=========== main ==============
variable "cloud_id" {
description = "The cloud ID"
type = string
}
variable "folder_id" {
description = "The folder ID"
type = string
}
variable "default_zone" {
description = "The default zone"
type = string
default = "ru-cenral1-a"
}Присвоим им значения:
my_project/k8s/terraform.tfvars
#=========== main ==============
cloud_id = "b1gq90dgh25bebiu75o"
folder_id = "b1gia87mbaomkfvsleds"И перепишем main.tf
my_project/k8s/main.tf
terraform {
required_providers {
yandex = {
source = "yandex-cloud/yandex"
}
}
backend "s3" {
endpoint = "storage.yandexcloud.net"
bucket = "test-tfstate"
region = "ru-central1"
key = "my-project-k8s.tfstate"
shared_credentials_file = "storage.key"
skip_region_validation = true
skip_credentials_validation = true
}
}
provider "yandex" {
service_account_key_file = "key.json"
cloud_id = var.cloud_id
folder_id = var.folder_id
zone = var.default_zone
}Не забываем сменить имя файла состояния в параметре key.
Итак, давайте переписывать. Начинаем с service_account.tf, у нас имя сервисного аккаунта было задано через locals, мы это переделаем. Нам нужно имя сервисного аккаунта и ключа шифрования задать через переменные, для этого создаём их:
my_project/k8s/variables.tf
#=========== main ==============
variable "cloud_id" {
description = "The cloud ID"
type = string
}
variable "folder_id" {
description = "The folder ID"
type = string
}
variable "default_zone" {
description = "The default zone"
type = string
default = "ru-cenral1-a"
}
#=========== service_account ==============
variable "service_account_name" {
description = "Name of service account"
type = string
default = null
}
variable "kms_provider_key_name" {
description = "KMS key name."
type = string
default = null
}И определяем:
my_project/k8s/terraform.tfvars
#=========== main ==============
cloud_id = "b1gq90dgh25bebiu75o"
folder_id = "b1gia87mbaomkfvsleds"
#=========== service_account ==============
service_account_name = "myaccount"
kms_provider_key_name = "kms-key"Переписываем service_account.tf:
my_project/k8s/service_account.tf
resource "yandex_iam_service_account" "myaccount" {
name = var.service_account_name
description = "K8S regional service account"
}
resource "yandex_resourcemanager_folder_iam_binding" "editor" {
# Сервисному аккаунту назначается роль "editor".
folder_id = var.folder_id
role = "editor"
members = [
"serviceAccount:${yandex_iam_service_account.myaccount.id}"
]
}
resource "yandex_resourcemanager_folder_iam_binding" "images-puller" {
# Сервисному аккаунту назначается роль "container-registry.images.puller".
folder_id = var.folder_id
role = "container-registry.images.puller"
members = [
"serviceAccount:${yandex_iam_service_account.myaccount.id}"
]
}
resource "yandex_kms_symmetric_key" "kms-key" {
# Ключ для шифрования важной информации, такой как пароли, OAuth-токены и SSH-ключи.
name = var.kms_provider_key_name
default_algorithm = "AES_128"
rotation_period = "8760h" # 1 год.
}
resource "yandex_kms_symmetric_key_iam_binding" "viewer" {
symmetric_key_id = yandex_kms_symmetric_key.kms-key.id
role = "viewer"
members = [
"serviceAccount:${yandex_iam_service_account.myaccount.id}",
]
}Что ж, вот мы и можем, наконец, приступить к оптимизации кода кластера. Давайте подставим наши значения в cluster, попутно прописав переменные для некоторых из них:
my_project/k8s/variables.tf
#=========== main ==============
variable "cloud_id" {
description = "The cloud ID"
type = string
}
variable "folder_id" {
description = "The folder ID"
type = string
}
variable "default_zone" {
description = "The default zone"
type = string
default = "ru-cenral1-a"
}
#=========== service_account ==============
variable "service_account_name" {
description = "Name of service account"
type = string
default = null
}
variable "kms_provider_key_name" {
description = "KMS key name."
type = string
default = null
}
#=========== cluster ==============
variable "cluster_name" {
description = "Name of a specific Kubernetes cluster."
type = string
default = null
}
variable "network_policy_provider" {
description = "Network policy provider for the cluster. Possible values: CALICO."
type = string
default = "CALICO"
}
variable "master_version" {
description = "Version of Kubernetes that will be used for master."
type = string
default = null
}
variable "master_public_ip" {
description = "Boolean flag. When true, Kubernetes master will have a visible ipv4 address."
type = bool
default = true
}
variable "master_region" {
description = "Name of region where cluster will be created. Required for regional cluster, not used for zonal cluster."
type = string
default = null
}Как вы можете видеть, у двух переменных, а именно master_public_ip и network_policy_provider, уже задано дефолтное значение. Нам нужно в terraform.tfvars указать остальные:
my_project/k8s/terraform.tfvars
#=========== main ==============
cloud_id = "b1gq90dgh25bebiu75o"
folder_id = "b1gia87mbaomkfvsleds"
#=========== service_account ==============
service_account_name = "myaccount"
kms_provider_key_name = "kms-key"
#=========== cluster ==============
cluster_name = "cluster"
master_version = "1.22"
master_region = "ru-central1"Вот мы и дошли до важнейшего момента - нам необходимо указать id сети, но её мы поднимали другим манифестом Terraform'а, а значит, из этого манифеста Terraform не может увидеть созданные там ресурсы. как же быть?
Для того, чтобы получить какие-либо данные извне, есть data sources. С помощью data мы можем указать терраформ источник, откуда ему следует взять данные.
Создадим файл data.tf:
my_project/k8s/data.tf
data "yandex_vpc_network" "network" {
name = "mynet"
}Источник данных указывается очень просто: data, и прописываем откуда брать данные, а нужна нам сеть с именем mynet.
Теперь нам достаточно сослаться на этот источник в описании ресурса, обязательно указав что именно нам нужно оттуда забрать - data.yandex_vpc_network.mynet.id:
resource "yandex_kubernetes_cluster" "k8s-regional" {
network_id = data.yandex_vpc_network.mynet.id
[...]
}Можем оставить так, но что, если имя сети поменяется? Переписали мы конфигурацию сети, нам же придётся и в каталоге k8s в data.tf поменять параметр, а ведь мы переписываем код для того, чтобы не лазить больше в конфигурационные файлы. Мы можем вынести этот параметр в переменные и менять его там - скажете вы. А что, если вообще не заморачиваться над тем, как назван ресурс? Что, если мы укажем id сети так, что нам нигде не придётся ничего переписывать при любых изменениях в манифесте network? Для этого нужно ответить на один вопрос - а где ещё хранятся данные о созданных ресурсах любого манифеста? Верно, в файле состояния. Вот мы и укажем Terraform'у сходить и прочитать другой tfstate файл.
Создадим другой источник данных и в нем укажем путь и доступы к чужому файлу состояния.
my_project/k8s/data.tf
data "terraform_remote_state" "network" {
backend = "s3"
config = {
endpoint = "storage.yandexcloud.net"
bucket = var.network_backet_name
region = "ru-central1"
key = var.network_state_key
shared_credentials_file = "storage.key"
skip_region_validation = true
skip_credentials_validation = true
}Как видите, здесь используются переменные, давайте их создадим. И присвоим значения - их мы возьмём из main.tf в каталоге network. Расположил я их после переменных для main.
my_project/k8s/variables.tf
#=========== main ==============
variable "cloud_id" {
description = "The cloud ID"
type = string
}
variable "folder_id" {
description = "The folder ID"
type = string
}
variable "default_zone" {
description = "The default zone"
type = string
default = "ru-cenral1-a"
}
#=========== terraform_remote_state ==============
variable "network_state_key" {
description = "The key of state for the network."
type = string
default = null
}
variable "network_bucket_name" {
description = "The name of bucket for the network."
type = string
default = null
}
#=========== service_account ==============
variable "service_account_name" {
description = "Name of service account"
type = string
default = null
}
variable "kms_provider_key_name" {
description = "KMS key name."
type = string
default = null
}
#=========== cluster ==============
variable "cluster_name" {
description = "Name of a specific Kubernetes cluster."
type = string
default = null
}
variable "network_policy_provider" {
description = "Network policy provider for the cluster. Possible values: CALICO."
type = string
default = "CALICO"
}
variable "master_version" {
description = "Version of Kubernetes that will be used for master."
type = string
default = null
}
variable "master_public_ip" {
description = "Boolean flag. When true, Kubernetes master will have a visible ipv4 address."
type = bool
default = true
}
variable "master_region" {
description = "Name of region where cluster will be created. Required for regional cluster, not used for zonal cluster."
type = string
default = null
}my_project/k8s/terraform.tfvars
#=========== main ==============
cloud_id = "b1gq90dgh25bebiu75o"
folder_id = "b1gia87mbaomkfvsleds"
#=========== terraform_remote_state ==============
network_state_key = "my-project-network.tfstate"
network_bucket_name = "test-tfstate"
#=========== service_account ==============
service_account_name = "myaccount"
kms_provider_key_name = "kms-key"
#=========== cluster ==============
cluster_name = "cluster"
master_version = "1.22"
master_region = "ru-central1"Теперь мы можем читать другой файл состояния и считывать оттуда значения, однако, их там пока нет. Для того, чтобы они появились, нам нужно вернуться в каталог network и оформить outputs. Итак, создаём outputs.tf и описываем то, что хотим вывести:
my_project/network/outputs.tf
output "network_id" {
value = yandex_vpc_network.mynet.id
}А нужно нам id сети. Вот и всё. Обязательно запустите terraform apply, чтобы данные записались в файл состояния.
Теперь, для того, чтобы нам сослаться на какой-либо ресурс из network, потребуется постоянно указывать конструкцию data.terraform_remote_state.network.outputs. и имя того output’а который нам нужен.
Например:
resource "yandex_kubernetes_cluster" "k8s-regional" {
network_id = data.terraform_remote_state.network.outputs.network_id
[...]
}Давайте используем locals, чтобы упростить себе жизнь. Итак, создаём файл locals.tf тут мы создадим переменную:
my_project/k8s/locals.tf
locals {
network_output = data.terraform_remote_state.network.outputs
}Теперь можем всегда указывать просто:
resource "yandex_kubernetes_cluster" "k8s-regional" {
network_id = local.network_output.network_id
[...]
}Думаю так гораздо удобнее.
Давайте для групп безопасности тоже выведем id, т.к. они нам также понадобятся:
my_project/network/outputs.tf
output "network_id" {
value = yandex_vpc_network.mynet.id
}
output "sg_internal" {
value = yandex_vpc_security_group.internal.id
}
output "sg_k8s_master" {
value = yandex_vpc_security_group.k8s_master.id
}
output "sg_k8s_worker" {
value = yandex_vpc_security_group.k8s_worker.id
}Но также нам нужны зоны и id подсетей. Здесь уже сложнее, ведь мы не можем просто указать эти значения, так же, как и для других, поскольку подсети у нас создаются циклом в network и писать output под каждую подсеть мы не можем.
Для нашей задачи мы действительно используем output, но для этого напишем небольшое условие:
my_project/network/outputs.tf
output "network_id" {
value = yandex_vpc_network.mynet.id
}
output "sg_internal" {
value = yandex_vpc_security_group.internal.id
}
output "sg_k8s_master" {
value = yandex_vpc_security_group.k8s_master.id
}
output "sg_k8s_worker" {
value = yandex_vpc_security_group.k8s_worker.id
}
output "k8s_masters_subnet_info" {
value = [for k, v in var.subnets["k8s_masters"] : zipmap(["subnet_id", "zone"], [yandex_vpc_subnet.subnet-main[v.name].id, yandex_vpc_subnet.subnet-main[v.name].zone])]
}
output "k8s_workers_subnet_info" {
value = [for k, v in var.subnets["k8s_workers"] : zipmap(["subnet_id", "zone"], [yandex_vpc_subnet.subnet-main[v.name].id, yandex_vpc_subnet.subnet-main[v.name].zone])]
}Как вы помните, мы создали 6 подсетей, три под мастеров и три под воркеров, вот я и хочу получить их id и zone разными output»ами: первый — под наши требования для кластера, а второй — заранее сделаем для воркеров.
Здесь мы фильтруем значение переменной subnets, чтобы бралась информация только по необходимым подсетям(в данном случае для мастеров). Далее с помощью функции zipmap мы создаём список, где присваиваем ключам subnet_id и zone соответствующие атрибуты из переменной, и так для каждой подсети в k8s_masters.
Аналогично и для подсетей в k8s_workers.
Перезапускаем terraform apply.
Окей, теперь переписываем конфигурацию на переменные, а ID групп безопасности указываем две, internal и k8s_master из output»ов предыдущего манифеста:
my_project/k8s/cluster.tf
resource "yandex_kubernetes_cluster" "k8s-regional" {
network_id = local.network_output.network_id
network_policy_provider = var.network_policy_provider
service_account_id = yandex_iam_service_account.myaccount.id
node_service_account_id = yandex_iam_service_account.myaccount.id
master {
version = var.master_version
public_ip = var.master_public_ip
regional {
region = var.master_region
dynamic "location" {
for_each = local.network_output.k8s_masters_subnet_info
content {
zone = location.value["zone"]
subnet_id = location.value["subnet_id"]
}
}
}
security_group_ids = [local.network_output.sg_internal, local.network_output.sg_k8s_master]
}
kms_provider {
key_id = yandex_kms_symmetric_key.kms-key.id
}
depends_on = [
yandex_resourcemanager_folder_iam_binding.editor,
yandex_resourcemanager_folder_iam_binding.images-puller
]
}Для того, чтобы указать подсети и зоны, мы используем dynamic блок с циклом for_each, указываем, откуда будем брать значения (а берем мы их из нашего нового output»a). Далее мы описываем content, и сюда пишем те параметры, которые нужны этому блоку, а нужны зона и ID, теперь указываем откуда брать значения, а их мы берем из того цикла, который мы передали, т. е. location.value и указываем какой элемент нужен.
Запускаем terraform init и terraform apply в каталоге k8s.
Ну вот, у нас получилось поднять инфраструктуру с помощью двух разных манифестов Terraform. Бежим в Яндекс и проверяем — кластер на месте. Нам осталось решить, как описать группы узлов. Они у нас так же, как и подсети до этого, указаны тремя ресурсами. Давайте исправлять. Как вы наверное уже догадались, делать мы это будем через тот же for_each. Но сначала, создадим переменную:
my_project/k8s/variables.tf
#=========== main ==============
variable "cloud_id" {
description = "The cloud ID"
type = string
}
variable "folder_id" {
description = "The folder ID"
type = string
}
variable "default_zone" {
description = "The default zone"
type = string
default = "ru-cenral1-a"
}
#=========== terraform_remote_state ==============
variable "network_state_key" {
description = "The key of state for the network."
type = string
default = null
}
variable "network_bucket_name" {
description = "The name of bucket for the network."
type = string
default = null
}
#=========== service_account ==============
variable "service_account_name" {
description = "Name of service account"
type = string
default = null
}
variable "kms_provider_key_name" {
description = "KMS key name."
type = string
default = null
}
#=========== cluster ==============
variable "cluster_name" {
description = "Name of a specific Kubernetes cluster."
type = string
default = null
}
variable "network_policy_provider" {
description = "Network policy provider for the cluster. Possible values: CALICO."
type = string
default = "CALICO"
}
variable "master_version" {
description = "Version of Kubernetes that will be used for master."
type = string
default = null
}
variable "master_public_ip" {
description = "Boolean flag. When true, Kubernetes master will have a visible ipv4 address."
type = bool
default = true
}
variable "master_region" {
description = "Name of region where cluster will be created. Required for regional cluster, not used for zonal cluster."
type = string
default = null
}
#=========== node_groups ==============
variable "node_groups" {
description = "Parameters of Kubernetes node groups."
default = {}
}И присвоим значение этой переменной в terraform.tfvars:
my_project/k8s/terraform.tfvars
#=========== main ==============
cloud_id = "b1gq90dgh25bebiu75o"
folder_id = "b1gia87mbaomkfvsleds"
#=========== terraform_remote_state ==============
network_state_key = "my-project-network.tfstate"
network_bucket_name = "test-tfstate"
#=========== service_account ==============
service_account_name = "myaccount"
kms_provider_key_name = "kms-key"
#=========== cluster ==============
cluster_name = "cluster"
master_version = "1.22"
master_region = "ru-central1"
#=========== node_groups ==============
node_groups = {
node-group-a = {
platform_id = "standard-v1",
name = "worker-a-{instance.short_id}",
cores = 2,
memory = 2,
boot_disk_type = "network-ssd",
boot_disk_size = 32,
zone = "ru-central1-a",
auto_scale = {
min = 1,
max = 3,
initial = 1
}
}
node-group-b = {
platform_id = "standard-v1",
name = "worker-b-{instance.short_id}",
cores = 2,
memory = 2,
boot_disk_type = "network-ssd",
boot_disk_size = 32,
zone = "ru-central1-b",
fixed_scale = {
size = 1
}
}
node-group-c = {
platform_id = "standard-v1",
name = "worker-c-{instance.short_id}",
cores = 2,
memory = 2,
boot_disk_type = "network-ssd",
boot_disk_size = 32,
zone = "ru-central1-c",
fixed_scale = {
size = 1
}
}
}Тут мы указываем всё то, что хотим видеть в параметрах ресурса, главное потом это правильно присвоить. Как вы могли заметить, блоки отличаются, а именно для node‑group‑a указан auto_scale, а для остальных групп fixed_scale. Таким образом, я хочу добавить возможность менять тип групп через переменные.
Также, в yandex_kubernetes_node_group нам потребуется указать id подсетей. Вспоминаем о нашем ранее созданном output»е — k8s_workers_subnet_info, но там передаётся не только id, но и зона. В чем проблема? — спросите вы. Ведь можно переписать output, чтобы он выдавал только id. Но нет, в таком случае у нас пропадёт привязка к зоне, ведь мы просто получим набор id, и понять какой из них принадлежит определённой зоне не получится. Да, они у нас сейчас по порядку, первый id будет относится к зоне ru‑cenral1-a, второй — к b и третий — к c. Но это мы в манифесте network нашей переменной так значения по порядку указали, а вот если их поменять местами, получим путаницу с таким подходом, и поднимется у нас, к примеру, группа с именем node‑group‑a в зоне b. Поэтому output мы не трогаем, а сделаем преобразование данных через locals:
my_project/k8s/locals.tf
locals {
network_output = data.terraform_remote_state.network.outputs
worker_subnet_list = zipmap([for subnet in local.network_output.k8s_workers_subnet_info : subnet.zone], [for subnet in local.network_output.k8s_workers_subnet_info : subnet.subnet_id])
}Создаём переменную worker_subnet_list, тут мы создадим список, где каждой зоне присвоится id.
Возвращаемся к нашему ресурсу в файл node_group.tf:
my_project/k8s/node_group.tf
resource "yandex_kubernetes_node_group" "my_node_groups" {
for_each = var.node_groups
cluster_id = yandex_kubernetes_cluster.k8s-regional.id
name = each.key
description = lookup(each.value, "description", null)
version = lookup(each.value, "version", var.master_version)
labels = lookup(each.value, "labels", null)
instance_template {
platform_id = lookup(each.value, "platform_id", null)
name = lookup(each.value, "name", null)
network_interface {
nat = lookup(each.value, "nat", true)
subnet_ids = [lookup(local.worker_subnet_list, each.value["zone"])]
security_group_ids = [local.network_output.sg_internal, local.network_output.sg_k8s_worker]
}
resources {
memory = lookup(each.value, "memory", 2)
cores = lookup(each.value, "cores", 2)
}
boot_disk {
type = lookup(each.value, "boot_disk_type", "network-hdd")
size = lookup(each.value, "boot_disk_size", 64)
}
scheduling_policy {
preemptible = lookup(each.value, "preemptible", false)
}
}
scale_policy {
dynamic "fixed_scale" {
for_each = flatten([lookup(each.value, "fixed_scale", can(each.value["auto_scale"]) ? [] : [{ size = 1 }])])
content {
size = fixed_scale.value.size
}
}
dynamic "auto_scale" {
for_each = flatten([lookup(each.value, "auto_scale", [])])
content {
min = auto_scale.value.min
max = auto_scale.value.max
initial = auto_scale.value.initial
}
}
}
allocation_policy {
location {
zone = each.value["zone"]
}
}
}Конечно же, меняем имя ресурса в Terraform'е.
Объявляем, что хотим использовать for_each и указываем откуда циклу брать значения (а лежат они в переменной node_groups).
name, берет значение из each.key, это у нас имя объекта: node‑group‑a, node‑group‑b и node‑group‑c.
Далее присваиваем значения остальным параметрам, но делаем мы это по условию, для этого используем функция lookup, синтаксис у неё очень прост, мы указываем где искать, что искать, и что присвоить если ничего не нашла (значение по умолчанию).
subnet_ids ставим источник local.worker_subnet_list, указываем что брать, а забирать мы будем id той зоны, которая указана в переменной node_groups, поэтому ставим each.value[«zone»]. Дефолтное значение убираем, т.к. сюда мы по умолчанию ничего не сможем поставить.
security_group_ids — группы безопасности мы указываем без всяких условий, просто указываем нужные output»ы.
scale_policy — как я уже говорил, нужна возможность выбора, либо фиксированная группа узлов, либо с автоскейлингом — для этого добавляем два соответствующих dynamic блока, в них описываем цикл, но, просто указать источник значений не получится, у нас в переменной вложенный список для этих блоков, чтобы вытащить необходимые значения, нужно этот список вытащить из другого, для этого воспользуемся функцией flatten, которая выравнивает вложенные списки. А далее можем использовать lookup — отличие лишь в том, что для блока fixed_scale на месте дефолтного значения мы ставим условие, которое проверяет наличие параметра auto_scale и если он есть, оставляет этот блок fixed_scale без значения, а если нет, то выставляет один фиксированный узел.
В content для этих блоков указываем использовать значения из соответствующего источника: для auto_scale — auto_scale.value.что_берем, для fixed_scale — fixed_scale.value.size
allocation policy: без всяких lookup»ов ссылаемся на нужное значение.
Получившаяся конфигурация должна поднимать для нас региональный кластер Kubernetes, с автоскейлингом нод в зоне ru‑central1-a, а в остальных зонах с 1 фиксированный нодой.
Однако, в процессе подготовки тестового стенда я столкнулся с проблемой, что инфраструктура поднималась и работала с этим кодом, а уже на следующий день — нет. Все необходимые узлы создавались, но не имели связи с мастерами. После проверки, я понял, что правила для группы безопасности не отрабатывают так, как это задумано. Пришлось переписать группу internal:
my_project/network/security-group.tf
resource "yandex_vpc_security_group" "internal" {
name = "internal"
description = "Managed by terraform"
network_id = yandex_vpc_network.mynet.id
labels = {
firewall = "yc_internal"
}
ingress {
protocol = "ANY"
description = "self"
predefined_target = "self_security_group"
from_port = 0
to_port = 65535
}
ingress {
protocol = "ANY"
description = "Правило разрешает взаимодействие под-под и сервис-сервис. Укажите подсети вашего кластера и сервисов. P.s. Правило избыточно и добавлено только потому, что политика self_security_group не функционирует как положено между машинами в разных регионах."
v4_cidr_blocks = flatten([for v in concat(var.subnets["k8s_masters"], var.subnets["k8s_workers"]) : v.cidr])
from_port = 0
to_port = 65535
}
egress {
protocol = "ANY"
description = "self"
predefined_target = "self_security_group"
from_port = 0
to_port = 65535
}
}
resource "yandex_vpc_security_group" "k8s_master" {
name = "k8s-master"
description = "Managed by terraform"
network_id = yandex_vpc_network.mynet.id
labels = {
firewall = "k8s-master"
}
ingress {
protocol = "TCP"
description = "access to api k8s"
v4_cidr_blocks = var.white_ips_for_master
port = 443
}
ingress {
protocol = "TCP"
description = "access to api k8s from Yandex lb"
predefined_target = "loadbalancer_healthchecks"
from_port = 0
to_port = 65535
}
}
resource "yandex_vpc_security_group" "k8s_worker" {
name = "k8s-worker"
description = "Managed by terraform"
network_id = yandex_vpc_network.mynet.id
labels = {
firewall = "k8s-worker"
}
ingress {
protocol = "ANY"
description = "any connections"
v4_cidr_blocks = ["0.0.0.0/0"]
from_port = 0
to_port = 65535
}
egress {
protocol = "ANY"
description = "any connections"
v4_cidr_blocks = ["0.0.0.0/0"]
from_port = 0
to_port = 65535
}
}
Поясню свою мысль. Правило, где мы выставляем predefined_target = «self_security_group», должно разрешать всё в рамках этой самой группы, т. е. хосты, к которым привязана группа internal (а в нашем случае это все мастеры и воркеры), должны свободно общаться друг с другом. Но этого не происходит — по информации от техподдержки, они перерабатывают механизм работы этого правила, и пока оно может «работать неожидаемым образом, когда эндпоинты находятся в разных зонах». Поэтому, мне пришлось добавить другое, которое открывает доступ всем узлам, находящимся в перечисленных в ней подсетях.
Как работает правило:
Нам нужны cidr наших подсетей, они у нас в переменной subnets. Однако, нам не нужно собирать этот параметр со всех подсетей, мы же можем прописать создание и других, не только для кластера и воркеров, как сейчас, — у нас могут появиться другие подсети, и мы не можем позволить трафику с других хостов, которые не относятся к кластеру, ходить к нему. Поэтому отфильтруем только то, что относится к кластеру, — это мастеры и воркеры:
[(var.subnets["k8s_masters"], var.subnets["k8s_workers"])] Но, таким образом, мы получили два списка. Не проблема, вызовем функцию concat, которая объединяет несколько списков в один:
concat(var.subnets["k8s_masters"], var.subnets["k8s_workers"]) Теперь, нужно вытащить только cidr, а у нас в переменной помимо этого ключа ещё name и zone, поэтому напишем условие, что в список мы собираем только значения ключа cidr:
[for v in concat(var.subnets["k8s_masters"], var.subnets["k8s_workers"]) : v.cidr]Мы получили нужные параметры, но, cidr у нас представлен в переменной, как вложенный список, с помощью flatten мы выравниваем этот список:
flatten([for v in concat(var.subnets["k8s_masters"], var.subnets["k8s_workers"]) : v.cidr])Вот теперь, можем запускаем terraform apply и любуемся на нашу инфраструктуру. 🙂
Если есть необходимость в настройке дополнительных параметров, как доступ по ssh к воркер‑нодам, вы это сможете сделать уже самостоятельно, почитав документацию.
Заключение
Можно было ещё много параметров описать, но цель статьи в другом — показать разные методы по написанию кода инфраструктуры и научить способам работы с компонентами Terraform»а. Надеюсь вам это помогло.
Самые внимательные, наверное, заметили, что я говорил о том, что не нужно дублировать ресурсы, если их можно описать одним блоком, но при этом, сам создал подряд три группы безопасности. Так вот, предлагаю вам написать в комментариях, как бы вы описали эти ресурсы.
Спасибо, что дочитали до конца. Постараемся выложить следующую часть, как можно скорее. Благодарю всех за внимание, до скорого!)
