Свідомо розгортаємо кластер AWS EKS

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Привіт, IT-спільното. Мене звати Дмитро Сірант, я — СТО у компанії OpsWorks Co. вже 4 роки, і за цей час ми стали AWS Advanced Consulting Partner, розширили свою експертизу та зміцнили команду. У минулому я DevOps-інженер, тож добре знаю з досвіду, з якими труднощами мають справу навіть досвідчені спеціалісти.

У компанії ми практикуємо внутрішнє навчання з метою обміну досвідом. Розбираємо кейси, шукаємо спільні рішення. Віднедавна почали викладати відео для загального доступу на каналі @DevOpsTalksAtOpsworks в YouTube. Підписуйтесь, ми завжди раді поспілкуватися під час Live-трансляцій і відповісти на ваші питання.

Нещодавно ми з колегою, DevOps-інженером Сергієм Кайдаловим, розповідали про AWS EKS на нашому каналі. Для тих, хто пропустив вебінар, ділюсь корисною інформацією у цій статті.

Ця публікація буде корисна DevOps та Clouds-інженерам, а також всім, хто цікавиться сучасними технологіями та прагне постійного розвитку.

Що таке Amazon EKS

Elastic Kubernetes Service — це Managed Service, який дозволяє запускати Kubernetes на AWS без необхідності встановлювати та налаштовувати не тільки Control Plane, але навіть і звичайні Worker ноди.

Amazon EKS:

• Запускає Control Plane в декількох AZ для забезпечення високої доступності і масштабує мастер-ноди у разі необхідності;
• Надає можливість автоматичного оновлення версії;
• Інтегрується з різноманітними AWS-сервісами;
• Працює на open-source kubernetes, що дозволяє використовувати всі існуючі плагіни та утиліти, доступні в kubernetes community.
  Простими словами, — це дозволяє легко мігрувати існуючі Kubernetes-кластери в AWS Cloud.

Ми маємо досвід управління кластерами EKS з понад 4000 нод, тому можемо впевнено рекомендувати це рішення для використання Kubernetes на платформі AWS.

VPC, мережі, ліміти та обмеження

Перше, що потрібно для створення кластера, — VPC. Проєктуючи VPC для кластера, переконайтеся, що вам вистачить IP-адрес для Control Plane та для ваших робочих нод.

Кожна підмережа Control Plane має містити як мінімум 16 IP-адрес. Вони потрібні для elastic network interfaces які створює Amazon для доступу до Control Plane(API).

Ви можете деплоїти робочі ноди у підмережу з Control Plane, але це не обовʼязково і, як правило, не рекомендується. Проєктуючи сабнети для робочих нод, ви маєте переконатися, що вам вистачить IP-адрес для всіх ваших нод і контейнерів.

За замовчуванням AWS EKS використовує нетворк плагін, який призначає IP-адреси для контейнерів з вашої підмережі для робочих подів. Тому є сенс створювати підмережі /20 або навіть /19. У разі, якщо і цього виявиться недостатньо, ви можете додати ще один CIDR до вашого VPC і розгорнути додаткові ноди у цих підмережах.

Необхідної вимогою для VPC є використання DNS hostname (enableDnsHostnames) та увімкнута підтримка резолвінгу через DNS (enableDnsSupport). Без цього ваші робочі ноди не зможуть приєднатися до кластера.

Важливо памʼятати, що IAM principal, який створює кластер, назавжди буде являтись єдиним адміністратором за замовчуванням і не буде відображатись у конфігураційних файлах кластера.

Тільки він має доступ до кластера за допомогою Kubectl безпосередньо, без додаткового налаштування в AWS-node config map. Рекомендуємо використовувати IAM Roles для створення кластерів, а не IAM User, який може змінитися з часом.

Ще одним аспектом, який ви можете вказати при створенні кластера і змінити який пізніше вже неможливо, є Cluster Security Groups. AWS EKS автоматично створює Security Group для кластера, яка забезпечує комунікацію між кластером та вашою VPC. Ви можете додати додаткові Security Groups при створенні кластера.

Безпека

Прийшов час поговорити про безпеку. Під час створення кластера EKS створюється ендпоінт до Kubernetes API-сервера, який використовується для комунікації з кластером (наприклад, за допомогою kubectl).

За замовчуванням, API-сервер має публічний endpoint, який доступний через інтернет і захищений за допомогою IAM, нативного RBAC. Бажано зробити його приватним. Таким чином вся комунікація між нодами буде залишатись лише у межах VPC, що є додатковою перевагою з точки зору безпеки.

Також є можливість лімітувати доступ до публічного endpoint або повністю його вимкнути.

Вмикаємо шифрування секретів, які зберігаються в etcd за допомогою KMS envelope encryption. Це шифрування є необхідним, бо інакше дані config maps та secrets будуть зберігатися на shared etcd кластері під керуванням Amazon.

З погляду безпеки використання Kubernetes Secrets Store CSI Driver є корисним, оскільки він дозволяє передавати секрети з Secrets Manager або Parameter Store як файли в середину контейнера, уникнувши зберігання їх в Kubernetes Secrets, які не забезпечують належного шифрування.

Коли ми говоримо про безпеку мережі, то часто маємо на увазі два аспекти: контроль трафіку і шифрування.

У EKS контроль трафіку здійснюється за допомогою Security Groups та Network Policies. За замовчуванням в EKS всі контейнери можуть комунікувати один з одним, а потрібний компонент для роботи Network Policies — Calico Policy Engine треба встановлювати окремо.

Якщо потрібно контролювати комунікацію сервісів усередині EKS із сервісами, які працюють ззовні щодо кластера (наприклад RDS, DynamoDB), то на мою думку, варто подивитись у сторону налаштування Security Groups для pods.

На сьогодні шифрування даних під час передачі мережею є нормою, тим паче якщо є необхідність відповідати таким безпековим стандартам як PCI DSS, HIPPA чи іншим. Тут у пригоді може стати cert-manager, який автоматично буде генерувати SSL-сертифікати для ваших application.

Якщо ж з якихось причин ваш застосунок не вміє працювати з TLS, в такому випадку на допомогу приходять Service Mesh, такі як: LInkerd, App Mesh, Istio та інші.

Ми підійшли до безпеки самої операційної системи. І тут варто згадати AWS Shared Responsibility Model. При використанні Fargate оновлення, встановлення патчів безпеки і таке інше AWS бере на себе. У випадку Self Managed нод ви несете відповідальність за безпеку операційної системи.

Якщо ви використовуєте Managed Nodegroup, то це дещо дискусійне питання і потребує додаткового аналізу.

Керуючись досвідом, я б радив наступне:

1. Використовуйте оптимізовану OS для запуску контейнерів: EKS Optimized AMI (amazon linux2) або bottlerocket.
2. Оновлюйте операційні системи. У випадку, якщо є нова версія AMI, яка містить патчі безпеки, не рекомендую встановлювати патчі окремо, краще замінити worker ноду на нову.
3. Варто обмежити доступ до воркер нод. Замість SSH використовуйте SSM Session Manager. Для цього достатньо додати відповідну IAM полісі, щоб у разі потреби зайти на ноду.
4. Не розміщуйте воркер ноди в паблік підмережах, якщо це не є єдиним вирішенням вашої задачі. Завжди використовуйте приватні підмережі.
5. Додаткового використовуйте Amazon Inspector для сканування нод на вразливості.

Останнім розглянемо питання безпеки контейнерів. Насправді тут можна робити окрему доповідь, пишіть у коментарях, якщо це буде цікаво, поділимось досвідом.

Якщо коротко, то є такі основні рекомендації:

1. Pod Security Standards (PSS) and Pod Security Admission (PSA). Це список вимог, яким повинен відповідати pod, перед тим як він буде створений у кластері. За замовчуванням, все дозволено.
2. Не запускайте процеси в контейнері від користувача root.
3. Контейнери, які працюють як привілейовані, успадковують усі Linux Capabilities, призначені для root на хості. (securityContext: privileged: false).

Масштабування та оптимізація вартості

Автоскейлінг моніторить навантаження та регулює ресурси, щоб підтримувати стабільну роботу, а також оптимізувати витрати. Є два види автоматичного масштабування: pod-based та node-based(compute).

Node-based: змінює кількість worker node, на яких запускаються поди (CA, Karpenter).

Pod-based: як очевидно з назви, змінює кількість подів (Horizontal Pod Autoscaler, Cluster

Proportional Autoscaler), або ресурсів, які виділяються для поду (Vertical Pod Autoscaling).

Поговоримо про Node-based скейлінг. У випадку Fargate, скейлінг робиться автоматично. У випадку managed або self-manager node group, використовується cluster-autoscaler. Він моніторить ситуацію в кластері і приймає рішення: додавати нові ноди чи видаляти, якщо вони не потрібні.

Cluster-autoscaler працює на основі AWS Auto Scaling Groups і може оперувати тільки конкретними ASG. Він безпосередньо не запускає нові ноди, а лише відправляє API-запит до ASG.

Існує інший підхід — Karpenter, який був розроблений AWS і працює напряму з EC2, що дозволяє йому набагато швидше додавати нові ноди до кластера. Karpenter дозволяє міксувати типи інстансів без необхідності створювати ASG.

Кілька слів про Pod-based скейлінг:

• HPA або Horizontal Pod Autoscaler скейлить кількість контейнерів в Deployment або ReplicaSet на основі метрик.
• CPA або Cluster Proportional Autoscaler скейлить кількість контейнерів на основі розміру кластера (в залежності від кількості код).
• VPA або Vertical Pod Autoscaler змінює реквести CPU та Memory контейнеру відповідно до реального навантаження.

Ви можете використовувати сторонні застосунки, наприклад, KEDA (Kubernetes Event Driven Autoscaler). Цікавий проєкт, який реалізує скейлінг job та deployments на основі зовнішніх (Prometheus, SQS, RabbitMQ, MySQL, etc.) та внутрішніх (CPU, Memory, etc.) метрик.

Автоскейлінг дозволяє нам заощаджувати кошти на інфраструктурі завдяки тому, що додає ресурси тільки коли вони потрібні.

Якщо ми можемо прогнозувати навантаження на проєкті щонайменше на рік — варто розглянути придбання Reserved Instances або Compute Saving Plan.

Хочете більше економії? Розгляньте використання Spot Instances. Spot-інстанси дешевші за on-demand і вигідніші, ніж застосування Reserved Instnces або Saving Plans. Але ви маєтесь впевнитися, що ваш застосунок stateless або готовий до зупинення процесу і поновлення його на інші ноді, бо Spot Instance може бути відкликаний AWS з попередженням за 2 хвилини.

Observability

Моніторинг є критично частиною підтримки надійності, доступності та продуктивності EKS-кластера. Моніторинг необхідний для виявлення проблем в кластері, щоб розуміти, чи виникають ці проблеми через ваші програми чи компоненти самого кластера. Без системи моніторингу і сповіщень ви не тільки не будете знати, коли щось трапиться, але потім будете марно витрачати час на те, щоб ідентифікувати місце проблеми.

Одразу після розгортання кластера EKS, навіть без налаштування будь-якої системи моніторингу, AWS дозволяє отримати і переглянути досить багато інформації про кластер в EKS console. EKS console дозволяє переглянути статус самого кластера, нод, програм, які у ньому працюють і таке інше. В цілому, це та сама інформація, яку можна отримати за допомогою утиліти kubectl, але у зручному графічному форматі.

Є три основних компоненти для моніторингу: кластер у цілому, ноди та pods. Допомогти в цьому може, наприклад, Prometheus, Grafana та Alertmanager. Prometheus збирає різні метрики з налаштованих компонентів, Grafana служить для візуалізації з можливістю відправляти оповіщення, й Alertmanager — це сервіс оповіщень.

AWS також пропонує Managed Prometheus та Grafana Services, які підтримують автоматичний скейлінг, високу доступність і зберігання метрик до 150 днів. Варто зазначити, що звичайно є й інші сервіси, такі як: ContainIQ, Dynatrace, NewRelic, Datadog і т.і.

Як і моніторинг, логінг може бути умовно поділений на три типи: control plane логінг, node логінг та application логінг. В EKS можна увімкнути логи Control Plane і надсилати їх в Amazon CloudWatch.

Є 5 типів логів control plane: Kubernetes API log, Audit logs, Authenticator logs, Controller manager logs та Scheduler logs. Після включення логи будуть доступні в AWS CloudWatch з префіксом /aws/eks/.

З ControlPlane варіантів більше немає, а от що стосується логів нод та подів, тут уже є багато реалізацій. AWS надає FluentBit образ з плагінами для CloudWatch та Kinesis Data Firehose. Таким чином ви маєте змогу надсилати всі логи з нод та контейнерів в CloudWatch або Kinesis Data Firehose.

Іншим варіантом є використання ELK-стеку: ElasticSearch + Logstash + Kibana. Останнім часом ми використовуємо Vector від Datadog, який дозволяє швидко й оптимально збирати логи, складати їх в S3 і потім вже в іншому місці парсити, модифікувати та надсилати в ElasticSearch.

Підготовка плану відновлення у разі катастрофи

Аварійне відновлення (Disaster Recovery) — це здатність організації реагувати та відновлюватися після події, яка негативно впливає на бізнес-операції. Ціллю Disaster Recovery є надання можливості організації відновити використання критично важливих систем та інфраструктури якомога швидше після аварії. Щоб цього досягти необхідно створити план, який буде включати всі компоненти та кроки, що нам потрібні для найшвидшого відновлення працездатності системи.

У випадку EKS нам потрібно знайти метод відновлення кластера в іншому регіоні у найкоротші терміни, використовуючи Infrastructure as Code (IaC) або інші методи.

В цілому у нас є три варіанти:

1. Active-active: в цьому випадку маємо два кластери, деплоїмо в них одночасно, підтримуємо і моніторимо обидва, автоматичний failover. Плюси: немає downtime, не потребує додаткових заходів у разі аварії. Мінуси: дуже дорого, реплікація даних може викликати труднощі.
2. Warm standby:тут маємо маленький кластер в іншому регіоні з тими самими програмами, але з мінімальною кількістю робочих нод. У разі аварії, скейлим кластер, переключаєм DNS. Плюси: мінімальний downtime, який вимірюється в хвилинах/ годинах. Мінуси: все ще дорого, реплікація даних може викликати труднощі, потребує додаткових дії.
3. Restore from backup: у разі аварії створюється новий кластер з нуля і відновлюється все з резервної копії. Плюси: дешево, не потребує реплікації даних. Мінуси: важко підтримувати, downtime вимірюється годинами/ днями, реплікація бекапів, можлива втрата частини даних.

З реалізацією будь-якого варіанту у пригоді стане підхід IaC (Infrastructure as Code). Infrastructure as Code — це підхід, при якому ресурси описані у вигляді програмного коду.

Такий підхід дозволяє зменшити або взагалі нівелювати помилки при створенні ресурсів, що дозволяє заощадити час. Є багато засобів, які можна використати для реалізації цього підходу, наприклад: AWS CDK, AWS CloudFormation, Terraform, etc.

Ми рекомендуємо використовувати Terraform, тому що він має велику підтримку в open source community, а якщо говорити про EKS, то AWS відносно нещодавно створила проєкт під назвою aws-eks-blueprints, який призначений для швидкого і простого розгортання EKS кластера.

З власного досвіду хочу попередити, що наявність плану не гарантує відновлення, тому обовʼязково тестуйте та вдосконалюйте план хоча б раз на пів року. За цей час змінюються версії компонентів, додаються або видаляються залежності, міняються люди на проєкті. Як результат — те, що працювало раніше, більше не працює.

Як ви бачите, попри те, що AWS EKS — це managed-сервіс, ви маєте подбати про багато речей, щоб використовувати його відповідно до безпекових стандартів, ефективно та без головного болю у майбутньому.

Саме в цьому і полягає експертиза інженерів, які обслуговують сотні кластерів різного розміру у своїй роботі та вже напрацювали ефективні підходи до їх побудови та моніторингу. Ми завжди готові надати допомогу і відповісти на ваші питання щодо AWS EKS. Пишіть у коментарях, а також долучайтесь до моєї мережі в LinkedIn.