Модуль 5.1: Архітектура та Control Plane EKS
Складність: [MEDIUM] | Час на виконання: 2.5 год | Передумови: Основи AWS, Архітектурні патерни хмар
Чому цей модуль важливий
Розділ «Чому цей модуль важливий»У грудні 2021 року фінтех-стартап із 340 мікросервісами на Amazon EKS зазнав каскадного збою, який зупинив усю платіжну платформу на чотири години. Причиною був не баг у коді і не помилка в маніфесті Kubernetes. Команда розгорнула кластер EKS з публічним ендпоінтом API-сервера і без приватного. Коли в регіоні AWS стався збій лімітів (throttling), їхні робочі вузли в приватних підмережах перестали бачити API-сервер, бо шлях до нього йшов через NAT Gateway, який був перевантажений іншим трафіком. Вузли втратили зв’язок із “мозком”, поди почали падати, і вся система пішла в піке. Наявність приватного ендпоінта залишила б трафік всередині мережі VPC, і цього збою просто не сталося б.
Ця історія ілюструє істину: в EKS хмара керує площиною управління (control plane), але ви відповідаєте за те, як ваші сервери до неї підключаються. Помилка тут створює “єдину точку відмови”, яка може покласти весь ваш бізнес.
У цьому модулі ви дізнаєтеся, як насправді працює EKS “під капотом”, як правильно налаштувати доступ до API (Public vs Private), коли обирати керовані групи вузлів замість Fargate, та як назавжди забути про незручний aws-auth ConfigMap, перейшовши на сучасну систему Access Entries.
Архітектура EKS Control Plane
Розділ «Архітектура EKS Control Plane»Коли ви створюєте кластер EKS, AWS запускає для вас високонадійний Kubernetes, який ви ніколи не бачите напряму.
Що AWS робить за вас
Розділ «Що AWS робить за вас»AWS запускає мінімум два екземпляри API-сервера і три вузли etcd, розподілені між трьома зонами доступності (AZ). Ви платите за це фіксовано $0.10 за годину, незалежно від кількості ваших серверів.
Cross-Account ENIs: Міст між світами
Розділ «Cross-Account ENIs: Міст між світами»Це найважливіша деталь архітектури. AWS вставляє свої мережеві інтерфейси (ENI) прямо у ваші підмережі. Саме через ці “проводи” площина управління спілкується з вашими вузлами.
- Ви не можете їх видаляти.
- Вони мають тег
kubernetes.io/cluster/ім'я-кластера. - Для них потрібні вільні IP-адреси у ваших підмережах.
Доступ до API: Public, Private або обидва
Розділ «Доступ до API: Public, Private або обидва»Це головне рішення при створенні кластера.
- Public Only (Дефолт): API-сервер доступний з інтернету. Ваші сервери в приватних мережах мають ходити через NAT Gateway, щоб спитати щось у Kubernetes. Це небезпечно і дорого.
- Private Only: API доступний тільки всередині вашої VPC (або через VPN). Максимальна безпека, але ви не зможете запустити
kubectlзі свого ноутбука без налаштування тунелів. - Public + Private (Рекомендовано): Ваші сервери спілкуються з API всередині мережі (швидко і безкоштовно), а ви можете керувати кластером через інтернет, обмеживши доступ тільки для вашого офісного IP.
Варіанти обчислень (Compute)
Розділ «Варіанти обчислень (Compute)»| Тип | Хто керує сервером | Коли обирати |
|---|---|---|
| Managed Node Groups | AWS (оновлення ОС, злив подів) | Стандарт для 90% задач |
| Self-Managed Nodes | ВИ (AMI, патчі, скрипти) | Коли треба кастомне залізо або GPU |
| AWS Fargate | AWS (серверів немає взагалі) | Пакетні задачі, легкі API, дешевше в управлінні |
EKS Add-ons: Керування компонентами
Розділ «EKS Add-ons: Керування компонентами»Раніше ми ставили мережу (VPC CNI) та DNS (CoreDNS) вручну через Helm. Тепер AWS пропонує Add-ons. Це як магазин додатків: ви обираєте версію, натискаєте кнопку “Оновити”, і AWS сам піклується про те, щоб мережа працювала стабільно після оновлення версії Kubernetes.
Автентифікація: Перехід на Access Entries
Розділ «Автентифікація: Перехід на Access Entries»Довгі роки EKS використовував ConfigMap aws-auth. Один неправильний пробіл у цьому файлі — і всі адміни втрачали доступ до кластера.
EKS Access Entries — це нова система, де ви керуєте правами доступу через API AWS.
- Ніяких ConfigMap.
- Логування кожної зміни в CloudTrail.
- Можливість дати права адміна через IAM-роль однією командою.
Типові помилки
Розділ «Типові помилки»| Помилка | Чому це стається | Як виправити |
|---|---|---|
| Тільки Public Endpoint | Простота на старті | Увімкніть Private access, щоб сервери не залежали від інтернету |
| Видалення ENI вручну | ”Бачу якісь дивні інтерфейси в VPC” | Ніколи не видаляйте ENI з тегом kubernetes.io/cluster |
Редагування aws-auth без бекапу | Швидка правка “на колінці” | Мігруйте на Access Entries; це безпечніше і зручніше |
| Маленькі підмережі (/28) | Економія IP | EKS споживає IP для ENI та подів. Використовуйте мінімум /24 для кластера |
Тест
Розділ «Тест»1. Чому наявність Private Endpoint у кластері EKS економить гроші?
Тому що трафік від ваших серверів до API-сервера залишається всередині мережі VPC і не проходить через NAT Gateway. Плата за обробку даних у NAT Gateway (~$0.045/ГБ) є однією з найбільших прихованих витрат в AWS.
2. У чому головна проблема використання Fargate для всього підряд?
Fargate не підтримує DaemonSets. Ви не зможете запустити агенти логування (FluentBit), моніторингу (Datadog) або мережеві плагіни, які мають працювати на кожному вузлі.
Практична вправа: Створення приватного кластера
Розділ «Практична вправа: Створення приватного кластера»- Створіть VPC із двома приватними підмережами (використовуйте знання з Модуля 1.2).
- Запустіть кластер EKS з налаштуванням
endpointPrivateAccess=trueтаendpointPublicAccess=true. - Обмежте публічний доступ тільки своєю поточною IP-адресою (
publicAccessCidrs). - Створіть Access Entry для своєї IAM-ролі, щоб отримати доступ
cluster-admin.
Наступний модуль
Розділ «Наступний модуль»Тепер, коли фундамент архітектури закладено, час розібратися, як поди отримують адреси. Переходьте до Модуля 5.2: Мережа EKS (VPC CNI), щоб опанувати Prefix Delegation та врятувати свій кластер від вичерпання IP-адрес.