Як створити кластер EKS, готовий до виробництва, на AWS за допомогою Terraform (Частина 1: VPC) - javascript.org.ua

Якщо ви плануєте розгорнути Kubernetes на AWS, важливо почати з міцної основи. Хребтом кластера EKS є його VPC, і Terraform значно спрощує управління цією інфраструктурою як кодом. У цій статті ми розглянемо налаштування VPC, готового до продакшн-режиму, для кластера EKS за допомогою Terraform.

Наприкінці цього посібника ви отримаєте масштабовану, безпечну VPC, адаптовану під EKS. Масштабованість досягається через використання кількох зон доступності та динамічного підмережування для обробки змінних навантажень, а безпека забезпечується за допомогою приватних підмереж, NAT-шлюзів і правильно налаштованих таблиць маршрутів. Це перший крок у двочастинному серії статей; у наступній частині ми зосередимося на налаштуванні самого кластера EKS.

Чому Terraform?

Terraform є інструментом вибору для багатьох, оскільки він пропонує декларативний підхід до управління інфраструктурою. Це означає, що ви визначаєте бажаний стан вашої інфраструктури, а Terraform бере на себе створення, оновлення чи видалення ресурсів для того, щоб відповідати цьому стану. Завдяки Terraform можна забезпечити узгодженість, відслідковувати зміни та ефективно масштабувати інфраструктуру. Для EKS це природний вибір, оскільки AWS має комплексний провайдер Terraform, що дозволяє визначати все — від VPC до кластерів EKS.

Перед тим як почати, переконайтеся, що у вас є наступне:

Встановлений Terraform на вашій машині
Базові знання Terraform та його концепцій
Базові знання мережевих концепцій AWS (підмережі, таблиці маршрутів тощо)

Тепер давайте розпочнемо.

Крок 1: Визначення конфігурації VPC

VPC, готова до продакшн-режиму для EKS, повинна містити:

Приватні підмережі для робочих вузлів (для безпеки та відповідності вимогам).
Публічні підмережі для ресурсів, що доступні через інтернет, таких як балансувальники навантаження.
NAT-шлюзи для надання доступу приватним підмережам до інтернету.
Правильні таблиці маршрутів для керування трафіком.

Ми використаємо популярний Terraform AWS VPC модуль, щоб спростити налаштування. Цей модуль надає попередньо налаштовані конфігурації для VPC, підмереж і супутніх ресурсів.

Створіть наступні файли Terraform:

.pre-commit-config.yaml  
└── components  
 └── vpc  
 ├── init.tf  
 ├── locals.tf  
 ├── main.tf  
 ├── outputs.tf  
 ├── variables.tf  
 └── version.tf

Ось як структуровані ці файли:

init.tf

Цей файл налаштовує конфігурацію бекенду для Terraform, визначаючи місце зберігання файлу стану. Він також визначає конфігурацію провайдера AWS.

terraform {  
 backend "s3" {  
 bucket = "terraform-state-304643094051"  
 key = "vpc/terraform.tfstate"  
 region = "us-east-1"  
 }  
}  

provider "aws" {  
 region = var.region  
}

main.tf

Основний конфігураційний файл Terraform використовує AWS VPC модуль для визначення VPC та її супутніх ресурсів, таких як підмережі, таблиці маршрутів і NAT-шлюзи.
Цей блок включає всі параметри, необхідні для налаштування VPC.

module "vpc" {  
 source = "terraform-aws-modules/vpc/aws"  
 version = "5.17.0"  

 name = var.name  
 cidr = var.cidr  

 azs = ["${var.region}a", "${var.region}b", "${var.region}c"]  
 private_subnets = [for i in [0, 1, 2] : cidrsubnet(var.cidr, 4, i)]  
 public_subnets = [for i in [50, 51, 52] : cidrsubnet(var.cidr, 8, i)]  
 database_subnets = [for i in [60, 61, 62] : cidrsubnet(var.cidr, 8, i)]  
 elasticache_subnets = [for i in [70, 71, 72] : cidrsubnet(var.cidr, 8, i)]  
 intra_subnets = [for i in [1280, 1281, 1282] : cidrsubnet(var.cidr, 12, i)]  

 create_database_subnet_group = true  
 create_elasticache_subnet_group = true  
 create_redshift_subnet_group = false  

 map_public_ip_on_launch = true  
 enable_nat_gateway = true  
 single_nat_gateway = true  
 enable_dns_hostnames = true  
 manage_default_network_acl = true  

 public_subnet_tags = {  
 "SubnetType" = "Public"  
 "kubernetes.io/cluster/main" = "shared"  
 "kubernetes.io/role/alb-ingress" = "1"  
 "kubernetes.io/role/elb" = "1"  
 }  

 private_subnet_tags = {  
 "SubnetType" = "Private"  
 "kubernetes.io/cluster/main" = "shared"  
 "kubernetes.io/role/internal-elb" = "1"  
 "kubernetes.io/role/alb-ingress" = "1"  
 }  

 tags = local.tags  
}

variables.tf

Цей файл визначає вхідні змінні для конфігурації Terraform, такі як регіон AWS, CIDR-блок для VPC і назва VPC. Ці змінні дозволяють зробити конфігурацію гнучкою та багаторазовою.

variable "region" {  
 type = string  
 description = "Регіон за замовчуванням"  
 default = "eu-west-2"  
}  

variable "cidr" {  
 description = "CIDR-блок для VPC"  
 type = string  
 default = "10.11.0.0/16"  
}  

variable "name" {  
 type = string  
 description = "Назва VPC"  
 default = "main"  
}

outputs.tf

Цей файл визначає виходи конфігурації Terraform. Він надає інформацію про створені ресурси, такі як ID підмереж, зони доступності та ID VPC.
Ці виходи не лише необхідні для ідентифікації створених ресурсів, але й полегшують подальше посилання на цей модуль в інших модулях, коли ви будете розгортати EKS або іншу залежну інфраструктуру.

output "azs" {  
 description = "Список зон доступності"  
 value = module.vpc.azs  
}  

output "name" {  
 description = "Назва VPC"  
 value = module.vpc.name  
}  

output "database_subnets" {  
 description = "Список ID підмереж для баз даних"  
 value = module.vpc.database_subnets  
}  

output "database_subnet_group_name" {  
 description = "Назва групи підмереж для баз даних"  
 value = module.vpc.database_subnet_group_name  
}  

output "database_subnets_cidr_blocks" {  
 description = "Список CIDR-блоків підмереж для баз даних"  
 value = module.vpc.database_subnets_cidr_blocks  
}  

output "elasticache_subnets" {  
 description = "Список ID підмереж для Elasticache"  
 value = module.vpc.elasticache_subnets  
}  

output "elasticache_subnets_cidr_blocks" {  
 description = "Список CIDR-блоків підмереж для Elasticache"  
 value = module.vpc.elasticache_subnets_cidr_blocks  
}  

output "intra_subnets" {  
 description = "Список ID внутрішніх підмереж"  
 value = module.vpc.intra_subnets  
}  

output "intra_subnets_cidr_blocks" {  
 description = "Список CIDR-блоків внутрішніх підмереж"  
 value = module.vpc.intra_subnets_cidr_blocks  
}  

output "private_subnets" {  
 description = "Список ID приватних підмереж"  
 value = module.vpc.private_subnets  
}  

output "private_subnets_cidr_blocks" {  
 description = "Список CIDR-блоків приватних підмереж"  
 value = module.vpc.private_subnets_cidr_blocks  
}  

output "public_subnets" {  
 description = "Список ID публічних підмереж"  
 value = module.vpc.public_subnets  
}  

output "public_subnets_cidr_blocks" {  
 description = "Список CIDR-блоків публічних підмереж"  
 value = module.vpc.public_subnets_cidr_blocks  
}  

output "vpc_cidr_block" {  
 description = "CIDR-блок VPC"  
 value = module.vpc.vpc_cidr_block  
}  

output "vpc_id" {  
 description = "ID VPC"  
 value = module.vpc.vpc_id  
}

locals.tf

Цей файл містить локальні значення, які є константами або виразами, що використовуються повторно в конфігурації. Наприклад, він визначає теги, які будуть застосовані до всіх ресурсів, створених модулем.

locals {  
 tags = {  
 ManagedBy = "Terraform"  
 }  
}

version.tf

Цей файл вказує на необхідну версію Terraform та постачальників. Це гарантує сумісність і запобігає неочікуваним змінам через оновлення постачальників.

terraform {  
 required_version = ">= 1.3.0"  
 required_providers {  
 aws = {  
 source = "hashicorp/aws"  
 version = "5.65.0"  
 }  
 }  
}

Як підмережі обчислюються за допомогою `cidrsubnet`

Функція cidrsubnet в Terraform є потужним інструментом для поділу CIDR-блоку на менші, не перекриваючі підмережі. Такі підмережі критично важливі для забезпечення незалежної роботи різних частин мережі без конфліктів IP-адрес, що є необхідним для підтримки масштабованої та організованої мережевої архітектури. Вона приймає три аргументи:

base_cidr: Батьківський CIDR-блок, який ви хочете поділити (наприклад, 10.11.0.0/16).
newbits: Кількість додаткових бітів для маски підмережі. Це визначає кількість створених підмереж.
3.
netnum: Індекс підмережі, яку ви хочете отримати з згенерованого діапазону.

Припустимо, у вас є CIDR-блок VPC 10.11.0.0/16, і ви хочете створити менші підмережі:

Публічні підмережі: Додайте 8 бітів (newbits = 8), щоб поділити CIDR-блок на 256 підмереж, кожна з маскою /24.
cidrsubnet("10.11.0.0/16", 8, 0) дає 10.11.0.0/24
cidrsubnet("10.11.0.0/16", 8, 1) дає 10.11.1.0/24
Приватні підмережі: Додайте 4 біти (newbits = 4), щоб поділити CIDR-блок на 16 підмереж, кожна з маскою /20.
cidrsubnet("10.11.0.0/16", 4, 0) дає 10.11.0.0/20
cidrsubnet("10.11.0.0/16", 4, 1) дає 10.11.16.0/20

Використання cidrsubnet забезпечує:

Відсутність перекриття: Підмережі не перекриваються в межах батьківського CIDR-блоку.
Автоматизація: Динамічно обчислює CIDR підмереж на основі індексів.
Масштабованість: Легко коригувати розміри підмереж, змінюючи newbits.

У нашій конфігурації cidrsubnet допомагає автоматизувати створення публічних, приватних, баз даних та інших спеціалізованих підмереж без необхідності вручну проводити обчислення.

Чому додаються теги до підмереж?

Теги відіграють важливу роль у інтеграції підмереж з AWS EKS. Вони також спрощують усунення несправностей і покращують організацію ресурсів в AWS. Теги, які ви додаєте до своїх підмереж, дозволяють AWS ідентифікувати, які підмережі підходять для конкретних ресурсів Kubernetes. Це необхідно для правильного функціонування EKS, що вказано в вимогах до мережі AWS EKS (станом на січень 2025).

kubernetes.io/cluster/: Маркує підмережу як частину спільного кластера Kubernetes.
kubernetes.io/role/alb-ingress: Ідентифікує підмережі для AWS Application Load Balancers.
kubernetes.io/role/elb: Вказує, що підмережу можна використовувати для AWS Elastic Load Balancers.
kubernetes.io/role/internal-elb: Вказує, що підмережа призначена для внутрішніх балансувальників навантаження.

Використання цих тегів гарантує, що ваші підмережі будуть правильно розпізнані AWS EKS, що зменшує помилки конфігурації та спрощує розгортання ресурсів Kubernetes.

Pre-Commit Hooks для якості коду

Щоб підтримувати якість коду та послідовність, корисною практикою є використання pre-commit hooks. У цій конфігурації ми використовуємо файл .pre-commit-config.yaml для визначення хуків для Terraform та інших перевірок. Pre-commit hooks автоматично виконують перевірки і форматують код перед комітом змін, що забезпечує чистоту та безпомилковість вашого репозиторію.

Основні хуки у файлі .pre-commit-config.yaml

End-of-File Fixer: Забезпечує наявність нової строки в кінці кожного файлу.
Trailing Whitespace: Видаляє зайві пробіли в кінці рядків.
Large File Check: Запобігає додаванню надмірно великих файлів до репозиторію.
Merge Conflict Check: Виявляє не вирішені конфлікти злиття.
Terraform Hooks (від antonbabenko/pre-commit-terraform):

terraform_fmt: Автоматично форматирує код Terraform.
terraform_validate: Перевіряє конфігурації Terraform.
terraform_docs: Оновлює документацію модуля з змінними вводу та виводу.
terraform_tflint: Запускає tflint для виявлення проблем у конфігураціях Terraform.

Ось приклад файлу .pre-commit-config.yaml, який використовується в цій конфігурації:

repos:  
 - repo: https://github.com/pre-commit/pre-commit-hooks  
 rev: v5.0.0  
 hooks:  
 - id: end-of-file-fixer  
 - id: trailing-whitespace  
 - id: check-added-large-files  
 - id: check-merge-conflict  
 - repo: https://github.com/antonbabenko/pre-commit-terraform  
 rev: v1.96.2 # Остання версія: https://github.com/antonbabenko/pre-commit-terraform/releases  
 hooks:  
 - id: terraform_fmt  
 - id: terraform_docs  
 args:  
 - --hook-config=--add-to-existing-file=true  
 - --hook-config=--create-file-if-not-exist=true  
 - id: terraform_validate  
 - id: terraform_tflint

Щоб дізнатися більше про встановлення та використання pre-commit, зверніться до офіційного сайту.
Інтегруючи pre-commit hooks, ви можете автоматизувати перевірки якості коду і зосередитися на написанні конфігурацій Terraform, не турбуючись про стилістичні проблеми чи непомічені помилки.

Тестування вашої конфігурації

Виконайте наступні команди, щоб протестувати і розгорнути ваш VPC:

Ініціалізуйте Terraform: terraform init
Перевірте конфігурацію: terraform validate
Плануйте та застосуйте: terraform plan, terraform apply

Зверніть увагу, як 40 рядків коду створюють 44 нові ресурси в AWS!

Після створення VPC давайте візуалізуємо його структуру. Ця карта дає загальний огляд ресурсів і того, як вони пов'язані між собою, що спрощує налагодження та розширення конфігурації VPC. Нижче ви можете побачити карту ресурсів вашого створеного VPC, яка показує його компоненти:

Наступні кроки

В другій частині цієї серії ми використаємо створений вами VPC для розгортання кластера EKS. Залишайтеся з нами!

Перекладено з: How to Create a Production-Ready EKS Cluster on AWS Using Terraform (Part 1: VPC)