Постановка проблеми
Організації, що надають багатоклієнтську підтримку, часто стикаються з проблемами забезпечення безпеки, ізоляції ресурсів та масштабованості. Спільне середовище Kubernetes може призвести до конкуренції за ресурси, уразливостей безпеки та операційних складнощів при управлінні кількома орендарями.
Щоб вирішити ці проблеми, необхідно рішення, при якому кожен клієнт має виділене розгортання Kubernetes з ізольованими каналами зв'язку. Такий підхід забезпечує покращену безпеку, оптимізацію продуктивності та відповідність вимогам щодо захисту даних, зберігаючи при цьому операційну ефективність. Однак управління кількома розгортаннями викликає труднощі в автоматизації, оптимізації витрат та керуванні життєвим циклом.
Як організації можуть ефективно розгортати та підтримувати виділені середовища Kubernetes для кожного клієнта, забезпечуючи безперервну роботу та мінімізуючи витрати на інфраструктуру?
Ця стаття має на меті вирішення цієї проблеми за допомогою AWS та Kubernetes, зокрема з AWS EKS. Для ілюстрації рішення ми розглянемо приклад продукту, який використовує базу даних RDS, EFS для зберігання файлів та Redis ElastiCache для кешування, з API-сервісами, розгорнутими в EKS.
Як можна забезпечити ізоляцію клієнтів?
У цій статті ми не будемо розглядати підхід створення виділених VPC або кластерів EKS. Натомість увага буде зосереджена на досягненні ізоляції клієнтів в межах одного кластера EKS та VPC, при цьому забезпечуючи безпеку та операційну ефективність. Запропонований підхід для розгортання сервісів полягає в створенні виділеного простору імен для кожного клієнта в одному кластері Kubernetes. Це гарантує, що сервіси кожного клієнта будуть логічно ізольовані, що дозволить покращити безпеку, розподіл ресурсів і спростити керування їхніми робочими навантаженнями, все це залишаючись в одному кластері EKS та VPC.
Рішення 1
Перший підхід — використання EKS Pod Security Groups[1]. Ця функція, що базується на можливостях EKS Pod ENI, забезпечує, щоб кожен pod отримував унікальний Elastic Network Interface (ENI) та IP-адресу. Кожен pod може бути призначений до конкретної групи безпеки на основі свого ENI. Це дозволяє ретельно контролювати доступ до компонентів даних, забезпечуючи доступ лише через визначені групи безпеки і тільки для відповідних pod.
Проблеми, які можуть виникнути з часом.
Якщо ваші робочі навантаження працюють як завдання, що часто створюють та видаляють pod у відповідь на трафік, ви можете зіткнутися з затримками при плануванні pod через проблеми з призначенням IP-адрес. Це може призвести до того, що pod залишатиметься в стані “ContainerCreating” на кілька хвилин, очікуючи на IP. Також ви можете побачити попереджувальне повідомлення в pod, яке описує цю затримку.
Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox "1ef50790f21342bbcd88fc5456b480119e162ca3755f05b0bb5ac4a7432f1fb8": plugin type="aws-cni" name="aws-cni" failed (add): add cmd: failed to assign an IP address to container"
Причиною цієї затримки є те, як працює AWS VPC CNI при увімкненій функції POD ENI. Коли pod завершується, CNI не відразу звільняє призначені йому IP-адреси. Замість цього він утримує їх приблизно 60 секунд, перш ніж зробити їх знову доступними. В результаті нові pod можуть чекати на звільнення раніше призначених IP-адрес, що викликає затримки при запуску pod.
Pod Security Groups не дуже підходять для робочих навантажень з частим створенням та видаленням pod.
Оскільки IP-адреси динамічно асоціюються з pod, постійне створення та видалення pod може призвести до затримок, що впливають на продуктивність і надійність.
Альтернативи використанню Security Groups з частим створенням pod
Якщо ви хочете продовжувати використовувати Security Groups, вирішуючи проблеми з частим створенням та видаленням pod, AWS Fargate може стати життєздатним рішенням. Fargate усуває обмеження на кількість ENI, які можуть бути використані, і дозволяє ефективно запускати робочі навантаження з використанням Security Groups.
Можливі підходи:
- AWS Batch з Fargate і ECS — використовуйте AWS Batch для запуску робочих навантажень на Fargate-задньому ECS, який автоматично масштабується та керує обчислювальними ресурсами, забезпечуючи виконання правил безпеки.
- Fargate з EKS — запускайте робочі навантаження Kubernetes на EKS з Fargate, забезпечуючи, щоб кожен pod працював в ізольованому середовищі з виділеними групами безпеки, що дозволяє уникати затримок при призначенні IP.
Ці варіанти допомагають зберегти мережеву ізоляцію на основі груп безпеки, покращуючи масштабованість і зменшуючи витрати на керування призначеннями IP для pod.
Рішення 2
Наступний підхід — це поєднання виділених підмереж для даних з Kubernetes Network Policies. У цьому підході кожному клієнту призначається виділена підмережа для даних в межах VPC. Потім у просторі імен кожного клієнта застосовуються мережеві політики, щоб обмежити egress трафік виключно для конкретного діапазону CIDR цього клієнта. Це забезпечує ізоляцію трафіку між сервісами клієнтів, надаючи додаткові рівні безпеки та контролю доступу до даних.
На діаграмі нижче я показую налаштування для однієї зони доступності (AZ). Для мультізонального розгортання цю архітектуру потрібно реплікувати на всі зони доступності, що використовуються. Це забезпечує високу доступність і стійкість до відмов, розподіляючи сервіси та дані по кількох AZ, що забезпечує стійкість у випадку відмови AZ.
Висновок
Для робочих навантажень, які працюють як завдання, Pod Security Groups можуть бути не найкращим підходом для ізоляції каналів зв'язку. Використання окремих підмереж для зовнішніх компонентів дозволяє легше ізолювати канали зв'язку з Kubernetes Network Policies, при цьому все ще розгортаючи сервіси в тому ж кластері. Така настройка є більш економічно вигідною та безпечною для цього типу рішення.
Посилання
[1]https://docs.aws.amazon.com/eks/latest/userguide/security-groups-for-pods.html
[3] https://docs.aws.amazon.com/batch/latest/userguide/fargate.html
[4] https://docs.aws.amazon.com/eks/latest/userguide/fargate.html
Перекладено з: Multi-Customer Support with Dedicated Kubernetes Deployments with Isolated Channels