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

Усі статті, обговорення, новини про DevOps — в одному місці. Підписуйтеся на DOU | 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.

👍ПодобаєтьсяСподобалось11
До обраногоВ обраному12
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Гарна оглядова стаття. Не так багато нового дізнався, але написано якісно і читати приємно.

Ви можете деплоїти робочі ноди у підмережу з Control Plane, але це не обовʼязково і, як правило, не рекомендується.

Чи можете ви дати посилання на цитату щодо цього твердження?

Я бачив таке

Kubernetes worker nodes can run in the cluster subnets, but it is not recommended. You can create new subnets dedicated to run nodes and any Kubernetes resources.

І більше жодних додаткових речень/даних щодо цього.

Те що ви процитували — саме те місце. Control plane/master nodes знаходяться десь у AWS але в cluster subnets створюються ENI для комунікації з ними. Я викривив інформацію чи щось інше?

СТО такі СТО, це його чекліст, але із заголовка «Свідомий» вибір, мабуть кращё почути «ака джуна» який виконує всю брудну роботу. IaS, CI/CD, GitOps — нічого, kubectl — я навіть не пам’ятаю коли я його останній раз юзав))))) Grafana сама по собі — ні про що, як в принципі і пост — Про все і ні про що.

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

Складно зрозуміти вашу претензію. Це оглядова стаття і не більше. Здається, вона такою і планувалась.

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

А що краще свідомо чи на автопілоті ?

Ну і посилання на гіт з робочим тероризмом
чи ще чимось добавив би свідомості

Я навіть якось і не звертав уваги, що AWS-IA має свої модулі, які перетинаються з terraform-aws-modules. Мабудь тому, що сам aws-terraform-eks-blueprints під капотом використовує дуже багато модулів terraform-aws-modules. Треба буде подивитись що в них за terraform-aws-vpc

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

Непогана стисла стаття.
Але я б ще додав інфу про обмеження по максимальній кількості подів, яка залежить від версії інстансу та vpc-cni плагіна. Так, це можна вирішити, використовуючи nitro інстанси і ввімкнувши деякі опції у вже розгорнутому кластері. Або, використовуючи Terraform, підміняти на льоту значення maxPods для kubelet в launch template нод.
Ще не сказано про аддони, які AWS встановлює за замовчуванням і без права відмовитись. А ті що треба, наприклад ebs-csi та LB Controller, чомусь не встановлює.
З Karpenetr’ом не все так просто. Якщо коротко, то він, м’яко кажучи не такий класний як про нього говорять.
До

aws-eks-blueprints

багато питань. На разі я не раджу використовувати цей проект.

А ті що треба, наприклад ebs-csi та LB Controller, чомусь не встановлює.

Якщо не помиляюсь то LB Controller частково присутній.
Тобто Service type: LoadBalancer створить NLB без додаткових умов. А щоб створити та контролювати ALB вже потрібен alb-controller.

Так, проте досить лімітовано. AWS не рекомендує вже років зо два використовувати in-tree контролер, а каже шо краще одразу брати їх aws-lb-controller. I alb ingress це лише одна фіча в ньому.

Погоджуюсь, деякі базові речі просто не працюють з дефолтними анотаціями, те що пам’ятаю — якщо потрібно додати більш ніж 1 ACM сертифікат на NLB через анотації то вже все — не працює, встановлюй alb-controller.

Та не лише. Я б сказав шо якщо треба nlb, то майже нічого не налаштовується «старими» анотаціями тому треба новий контролер і його в eks треба ставить по замовчуванню.

Тобто Service type: LoadBalancer створить NLB без додаткових умов

Classic LB створить.

aws-eks-blueprints зараз суттєво переробляють, воно з чогось корисного перетворилось на монстра і це намагаються виправити.
Карпентер, так, є нюанси але в цілому він працює і розвивається

Или просто перейдите на GKE (Autopilot, если нужно просто ранить контейнеры без выкрутасов) и забудьте этот недоменеджед K8s (EKS) ;)

Раніше головний привід полаяти EKS було його суттєве відставання по версіям. Якщо «просто ранити» то і в EKS можна, але не завжди є потреба запустити echo «Hello world». Не маю досвіду з GKE але напевно і там є «свої нюанси»

Можемо спробувати тоді лаяти по функціоналу. :)
Наприклад в GKE є такий «нюанс» як regional disks — це коли disk має репліку в ще одній availability zone. Так це коштує дорожче ніж звичайний disk, але цей функціонал підтримується одразу «з коробки» — налаштовується в StorageClass.
Тому у вас Stateful App з PVC може працювати в ще одній зоні при рестарті пода, а не тільки там де був створений. Мені здається що це зручно якщо ще є якійсь проблеми з окремою зоною.
Наскільки мені відомо, в EKS немає аналогічної імплементації, так, можно спробувати додати EFS CSI Driver + IRSA, але там звісно більш складна конфігурація, та disk performance може бути значно гіршим.

Наприклад в GKE є такий «нюанс» як regional disks — це коли disk має репліку в ще одній availability zone. Так це коштує дорожче ніж звичайний disk, але цей функціонал підтримується одразу «з коробки» — налаштовується в StorageClass.
Тому у вас Stateful App з PVC може працювати в ще одній зоні при рестарті пода, а не тільки там де був створений. Мені здається що це зручно якщо ще є якійсь проблеми з окремою зоною.

А в чём прикол? В таком случае у тебя всё равно downtime будет пока всё будет в новой зоне подниматься. Тем более что проблемы в AZ редко что вот прям всё упало. То с перформансом сети проблемы, то часть инстансов отвалится. Так что ещё и вполне может получится что руками придется что-то делать. Уж проще сразу идти в сторону полноценного НА.

Кста, а что в GKE по автоскейлингу? Есть какой-то аналог карпентера или типа того?

В таком случае у тебя всё равно downtime будет пока всё будет в новой зоне
подниматься.

ну це час перестворення пода на новій ноді в новій az vs под взагалі не може піднятись.

У нас був кейс коли закінчились compute ресурси в окремій AZ на стороні провайдера — не можливо було створити новий інстанс будь-якої конфігурації (і це тривало майже тиждень), а у нас були спот інстанси під ноди, і коли провайдер їх забрав почалось пекло.
Тому стейтлесс вокрлоуд ще можно було б перекинути без наслідків, а stateful фактично прив’язаний до конкретної az де був створений pvc.

По скейлінгу вже не пам’ятаю, на жаль.

а у нас були спот інстанси під ноди, і коли провайдер їх забрав почалось пекло.

Ну сорян, capacity planning никто не отменял)

Так а як бін він тут допоміг? Це capacity planning зафейлився на стороні cloud provider’a.
Ми зафейлили що не передбачили такий сценарій. Тобто тут звичайний ризик — cloud provider не гарантує що зможе надати тобі нові compute resources коли завгодно. Якщо хочеш більше стабільності — сплачуй більше за клаcичний compute on-demand або pre-paid. Хочеш сплачувати менше — замовляєш spot, але ризики зростають.

Ну так правильно, треба було мати fallback на дорогі інстанси. Спот це чудово, але не дуже надійно.

Ну ты считаешь соотношение on-demand и спотов в своём кластере с таким учётом что даже если все споты отвалятся то критические приложения не уйдут в даунтайм/не будет даже частичной недоступности данных. На самом деле тут даже не играет большой роли есть или нет доступная capacity на стороне клауда, потому как любой скейлинг это время. Пока нода поднимется, пока присоединится к кластеру, пока поды назначаться на эту ноду, пока они поднимутся. А если там что-то с заметным временем старта то вообще беда.
Но в целом согласен, недостаток ресурсов на стороне провайдера может заметно напрягать. У нас такое часто вылазит в AWS во Франкфурте, в одной из AZ. Прикол в том, что почти во всех других регионах имя AZ для разных аккаунтов назначается рандомно для реальных физических ДЦ. А во Франкфурте по какой-то неведомой «исторической причине» этого нет, и во всех аккаунтах одинаковое имя зоны == один и тот же ДЦ, так что первая AZ (которая а) у них очень часто перегружена. Ну и другого совета кроме как «юзайте две другие AZ» нет xD

А в чём прикол? В таком случае у тебя всё равно downtime будет пока всё будет в новой зоне подниматься.

В новой AZ оно будет подыматься ровно столько, сколько времени надо на рестарт пода. Так что это и есть самый настоящий НА.

Кста, а что в GKE по автоскейлингу? Есть какой-то аналог карпентера или типа того?

GKE это 100% менеджед сервис... Там есть и автоскейлинг из коробки, и мониторинг из коробки. И даже обновления на новые версии происходит без седины (в автоматическом режиме, согласно заданым правилам, пока ты спишь). А еще и резервное копирование/репликация между кластерами в том числе в разных регионах (особенно удобно для случаев когда есть аппки в стейтфулсетах), и малтикластерный ингресс, и еще много чего, что включается посредствам проставления галки в соответствующий чекбокс ;)
А еще для «самых ленивых» есть GKE Autopilot — это где твой кластер обслуживает гугл и твоя задача заключается только в том что бы правильные манифесты писать ;)

Цікаво чому при цьому в них настільки незначна ринкова доля порівняно до AWS та Azure?
Памʼятаю там є ще якійсь тип інстансу, який взагалі безкоштовний але ти не можеш його використовувати більше ніж 24 години, але не впевнений чи є ще якісь обмеження.

Потому что так исторически сложилось... «Идем в клауд. Куда? В AWS, его же все знают.»
Плюс индусы (да и не только они, будем откровенны) учат AWS потому как зная его работу найти проще.

Ну и доля низкая у них в APAC регионе (кстати, в Австралии еще ничего, а в Синге или Гонконге — тут вообще беда, наверное только в Индонезии норм из азиатских стран)... в Северной Америке — там уже несколько лет идет тренд съезда с AWS в GCP. Много энтерпрайзов выбирают гугл как более продвинутого облачного провайдера (k8s, bigdata сервисы у них самые продвинутые).

Так, має сенс. Я не маю нічого особистого проти гугла. Памʼятаю, що була проблема зрозуміти як працює неворк у них (роутинг по тегам замість класичного). Але всяко краще ніж Azure :)

В новой AZ оно будет подыматься ровно столько, сколько времени надо на рестарт пода. Так что это и есть самый настоящий НА.

В каком месте это НА если у тебя единая точка отказа?)

А еще для «самых ленивых» есть GKE Autopilot — это где твой кластер обслуживает гугл и твоя задача заключается только в том что бы правильные манифесты писать ;)

Чисто фаргейт, ничего прям вау. Звучит прикольно на бумаге, а как пытаешься хоть что-то более-менее нестандартное сделать так приходится костыли тащить

Ну скажемо що використовувати EFS в принципі так собі ідея якщо не хочете дивні поди в Terminating phase.

Цікавий функціонал, але краще коли за це відповідає сам додаток (наприклад як це робить Percona), тобто в кожній зоні в нас є свій под і диск а за реплікацію даних відповідає сам додаток.

Не маю досвіду з GKE але напевно і там є «свої нюанси»

Ага, есть такое... он кофе не варит ;)
А если серьезно — проблема с ним одна. Люди, кто привыкли страдать с EKS и кому попал в руки GKE начинают натягивать свои шаблоны на него, и в итоге получается помойка, где в 90% случаев есть нативные варианты, но вместо них используют костыли (как с EKS принято) :/

Так відбувається з будь яким інструментом. Якщо не знаєш як користуватися — використовуєш так як до цього інший (схожий). Саме складне це зрозуміти ідеологію, що і для чого було створено і які проблеми має вирішувати. Є великі компанії які ansible використовують для всього, хоча в деяких місцях це не ефективно і є кращі інструменти.

Клауд часто не обирають. Часто логічніше піднімати все в одному, бо наприклад це безпечніше і дешевше, бо скажімо не треба буде платити за зовнішній трафік.

Срач Aws/Gcp выходит за рамки этого топика ;)

Так, згоден, але це коли проект вже великий та має якісь свої «історично склалося». Якщо це стартап чи міграція з on-premise то більший вплив мають вподобання інженера (команди). Отже кожен обирає те, що знає і добре якщо знає декілька і може обізнано обрати найкращий варіант. Це, доречі, стосується вибору будь якого інструменту, і нічого поганого нема в тому, що обирають те що знають, але погано, якщо це не ідеальний вибір.

Підписатись на коментарі