Kubernetes без AWS, Google Cloud і Azure: як ми шукали європейський cloud для клієнта

Вітаю! Мене звати Віталій Лук’яненко, я Cloud Architect в компанії Infinity Technologies.

Коли ми говоримо про cloud-міграції, зазвичай перше, що приходить на думку, це вартість, продуктивність, availability zones, managed services, якість документації та зручність для DevOps-команди. Але в європейському контексті останніми роками дедалі частіше з’являється ще один критерій, який може переважити всі інші, цифровий суверенітет.

Під час одного з нещодавніх проєктів ми допомагали європейському клієнту спроєктувати другу production-інстанцію в європейському cloud-провайдері. Ситуація зараз досить типова: компанія вже мала cloud-native продукт, побудований навколо Kubernetes, і хотіла зменшити залежність від hyperscalers, зберігши при цьому зрілий managed Kubernetes experience.

Завдання не звучало як «давайте просто переїдемо з Google Cloud / AWS / Azure кудись дешевше». Воно було складнішим: потрібно було зрозуміти, чи можна побудувати production-ready Kubernetes-платформу в європейському cloud так, щоб customer data, backups, disaster recovery copies, audit logs, load balancing і secrets залишалися в межах ЄС.

Чому це взагалі стало темою

Google Cloud, AWS і Microsoft Azure залишаються дуже сильними платформами. У них велика кількість сервісів, глобальна присутність, зріла екосистема, хороша документація та зрозумілі enterprise-процеси. Для багатьох компаній це все ще найраціональніший вибір.

Але для частини європейських бізнесів цього вже недостатньо.

Через геополітичну ситуацію, посилення уваги до data sovereignty та вимоги регуляторів компанії дедалі частіше ставлять собі незручні, але правильні запитання:

• де фізично знаходяться дані;
• де обробляється трафік;
• куди потрапляють backups і disaster recovery copies;
• хто має доступ до metadata;
• які subprocessors залучені;
• де працює support;
• чи може частина операцій неочевидно вийти за межі ЄС.

На рівні application hosting усе може виглядати просто: «ми обрали EU region». Але на практиці цього недостатньо. Треба дивитися не лише на compute, а й на load balancers, object storage, container registry, CI runners, backup locations, DR regions, TLS certificates, vulnerability feeds і навіть місце, де зберігається source code.

Особливо це важливо для продуктів, які працюють із security-sensitive data: secrets, credentials, identity-related data, audit logs, фінансовими або медичними даними.

Чому Kubernetes ускладнює вибір

Якщо вам потрібні просто віртуальні машини в Європі, варіантів багато. Але якщо продукт уже побудований на Kubernetes і команді потрібен саме managed Kubernetes-as-a-Service, список кандидатів різко скорочується.

На ранньому етапі ми також дивилися на Hetzner. Це сильний європейський провайдер із дуже привабливою вартістю raw compute, storage і networking. Але для нашого кейсу він не підійшов через одну принципову причину: Hetzner не надає native managed Kubernetes-as-a-Service.

Так, Kubernetes на Hetzner можна запустити. Наприклад, через self-managed підхід або third-party managed Kubernetes поверх Hetzner infrastructure. Але це вже інший тип рішення: з додатковим постачальником або з додатковою операційною відповідальністю на стороні команди. А в нашому випадку клієнт хотів саме managed Kubernetes із provider-operated control plane, а не власну платформну команду навколо etcd, upgrades, HA, hardening та incident response.

Тому після первинного аналізу реальний вибір звузився до двох провайдерів: Scaleway Kapsule та OVHcloud Managed Kubernetes Service.

Якими були критерії вибору

Ми не шукали «найкращий cloud взагалі». Такого, швидше за все, не існує. Ми шукали найкращий варіант під конкретний набір обмежень.

Ці критерії одразу прибрали частину провайдерів із розгляду. Бо «є сервери в Європі» і «є production-ready managed Kubernetes для sovereignty-sensitive workload» це різні речі.

Scaleway і OVHcloud на першому рівні порівняння

На першому рівні обидва провайдери виглядали релевантно. Обидва є європейськими, обидва мають managed Kubernetes, обидва дають можливість побудувати cloud-native stack без надмірного lock-in.

Але їхні сильні сторони різні.

Саме ця різниця стала головною в подальшому аналізі. Scaleway виглядав простішим з точки зору EU data residency. OVHcloud сильнішим там, де критичним стає control-plane resilience.

Scaleway Kapsule: коли важлива простота sovereignty

У Scaleway головна перевага для такого сценарію не окрема функція Kubernetes, а загальна простота cloud footprint. Якщо cloud-платформа не має non-EU regions, команді не потрібно постійно контролювати, щоб хтось випадково не створив object storage, backup target, load balancer або DR copy поза межами ЄС.

Це звучить як дрібниця, але на практиці це суттєво зменшує ризик помилки. Особливо коли інфраструктурою користуються різні команди, змінюється конфігурація, з’являються нові середовища, додаються backup jobs або експериментальні deployment-и.

Scaleway Kapsule дає managed Kubernetes, підтримку Cilium і Calico, інтеграцію з managed Load Balancer, block storage, Private Network/VPC, Container Registry та S3-compatible Object Storage. Для portable Kubernetes-архітектури цього достатньо.

Водночас треба чесно зафіксувати компроміс: free mutualized control plane не має contractual SLA. Для PoC або early build це нормально. Для production, де потрібен формальний SLA, треба дивитися на dedicated control plane.

У нашому аналізі Scaleway був найкращим кандидатом, якщо головна мета зменшити операційну складність навколо EU sovereignty і не будувати зайві guardrails проти випадкового використання non-EU region.

OVHcloud MKS: коли важливіша production HA-історія

OVHcloud виглядає сильніше в іншому сценарії: коли головний пріоритет production-grade managed Kubernetes control plane, особливо для high-availability workloads.

OVHcloud MKS має Free і Standard плани. Free може бути достатнім для PoC або раннього build. Але якщо ми говоримо про production із вимогами до resilience, тоді потрібно дивитися на MKS Standard.

Саме Standard дає сильнішу історію з control-plane resilience в 3-AZ regions. Це важливо не лише «для галочки» в архітектурному документі. Availability control plane може впливати на автоматизовані операції в Kubernetes, включно з failover для database operators.

OVHcloud має ширший compliance portfolio і добре виглядає для enterprise-сценаріїв. Але його sovereignty-модель вимагає більшої дисципліни. Якщо у провайдера є non-EU regions, то cluster, load balancer, object storage, registry, backups і DR copies треба явно прив’язувати до EU-регіонів і перевіряти це в IaC, під час deployment-ів, backup restore tests і DR simulation.

Інакше можна отримати ситуацію, коли Kubernetes працює в ЄС, але частина supporting services ні.

Free tier: чому PoC-ready не означає production-ready

Для старту обидва провайдери виглядають зручно. І Scaleway, і OVHcloud дають безкоштовний provider-operated control plane. Для PoC це нормальний варіант: можна швидко підняти кластер, перевірити deployment pipeline, ingress, storage, backup, observability і базові security controls.

Але важливо не переплутати PoC-ready із production-ready.

Для PoC ці відмінності, швидше за все, не будуть критичними. Але рішення про production upgrade треба приймати окремо. Воно має залежати від SLA, RTO / RPO, audit log requirements, etcd limits, database failover design і очікуваного навантаження.

Data sovereignty: юридична і практична частина

Тут важливо не перебільшувати. Те, що провайдер європейський, не означає автоматично, що всі юридичні ризики зникають. Коректніше говорити так: європейський провайдер без direct US parent-company exposure може бути кращим fit для sovereignty-sensitive use case, але фінальну оцінку мають проходити legal, security і compliance команди.

Окрім юрисдикції, потрібно дивитися на subprocessors, support locations, contract terms, DPA, audit logs, emergency access process і фактичну конфігурацію сервісів.

Практично це означає, що Scaleway зменшує ризик помилки через EU-only footprint. OVHcloud дає сильні enterprise-можливості, але вимагає більш строгого governance навколо region selection.

Орієнтовна вартість: дивитися треба не лише на control plane

Коли ми порівнюємо Kubernetes-провайдерів, легко сфокусуватися на ціні control plane. Але в реальному budget це тільки частина вартості.

Вартість формують worker nodes, storage, load balancers, traffic, backups, monitoring, log retention, managed databases або self-managed DB, security tooling і DR strategy.

Для benchmark-сценарію ми дивилися на невелике production-like середовище: три worker nodes, managed load balancer, block storage і S3-compatible object storage для backups.

Це не фінальна комерційна оцінка, а лише benchmark. У реальному проєкті точну вартість Kubernetes-as-a-Service складно порахувати без доступу до cloud console і розуміння поточного usage pattern.

На практиці навіть невеликі зміни в node size, storage retention, traffic або observability можуть суттєво змінити monthly bill. Тому procurement-рішення краще приймати після PoC, а не лише на основі list pricing.

Чому Kubernetes це не вся історія

Одна з найважливіших речей у таких міграціях: винести Kubernetes у європейський cloud недостатньо.

Можна мати production cluster у ЄС, але залишити CI runners за межами ЄС. Або використовувати global container registry. Або зберігати backup у неправильному region. Або не перевірити, куди потрапляють logs. У результаті формально Kubernetes буде в Європі, але data path залишиться неповним з точки зору sovereignty.

Тому ми дивилися на весь delivery та runtime ланцюжок.

Саме тут часто ховаються неочевидні ризики. Cloud sovereignty це не тільки region у Kubernetes cluster. Це весь шлях даних.

Portable cloud-native stack

Щоб не замінити lock-in одного hyperscaler на lock-in іншого провайдера, ми рекомендували будувати платформу максимально portable.

Ідея була проста: Kubernetes має залишатися Kubernetes. Provider-specific частина повинна бути мінімальною: cluster, networking, DNS, load balancer, object storage. Усе інше краще тримати на open-source або provider-agnostic компонентах.

Такий підхід залишає можливість у майбутньому перейти між європейськими провайдерами без повного переписування delivery model.

Database failover: деталь, яку не можна ігнорувати

Окремо хочу зупинитися на PostgreSQL у Kubernetes.

Якщо використовувати CloudNativePG, він взаємодіє з Kubernetes API server для автоматизованих операцій, включно з failover. Це не означає, що SLA control plane автоматично гарантує конкретний database RTO. Але availability control plane стає важливим фактором.

Саме тут OVHcloud MKS Standard виглядає сильніше, якщо automated failover під час AZ-level incident є контрактно важливою вимогою. Його Standard control plane має cross-AZ resilience у 3-AZ regions.

Scaleway теж може бути прийнятним варіантом, але тоді потрібно уважно продумати replication strategy і чесно зафіксувати ризик: рідкісна проблема з control plane може затримати автоматизований failover до моменту, коли Kubernetes API знову стане доступним.

Це не означає, що Scaleway поганий, а OVHcloud хороший. Це означає, що вибір залежить від того, що саме ви оптимізуєте: sovereignty simplicity чи control-plane HA.

Backup і DR: backup без restore test це лише надія

Для security-sensitive workload недостатньо просто налаштувати backups. Треба регулярно перевіряти, що restore справді працює.

Ми рекомендували daily automated restore tests: відновлення в isolated namespace або ephemeral cluster з автоматичною перевіркою health checks.

Для Kubernetes-рівня можна використовувати Velero. Для PostgreSQL native backup / PITR механізми CloudNativePG. Але головне питання залишається не в інструментах, а в data residency: де фізично лежить DR copy.

У Scaleway cross-region DR простіший з точки зору операційного контролю, бо footprint є EU-only. В OVHcloud це теж можливо, але target region треба явно обмежити EU-регіоном і перевіряти це в backup, restore та DR simulation.

Як ми б формулювали decision logic

У підсумку вибір між Scaleway і OVHcloud не виглядає як «один правильний, інший неправильний». Це два різні профілі ризику.

Для нашого кейсу Scaleway виглядав як найкращий overall fit, якщо ваги розставити так: sovereignty-first, cost-conscious, portability-driven. OVHcloud залишався сильним альтернативним варіантом, якщо на перше місце поставити production HA control plane.

Висновок

Європейські cloud-провайдери вже можуть бути реалістичною альтернативою AWS, Google Cloud і Azure для Kubernetes workloads. Але вибір потрібно робити не за принципом «де дешевше» або «де більше сервісів», а відштовхуючись від конкретної моделі ризику.

Якщо компанія хоче максимально просту EU-only sovereignty story, Scaleway Kapsule виглядає дуже логічно. Його головна перевага не тільки Kubernetes, а й те, що platform footprint зменшує ризик випадково вивести частину data path за межі ЄС.

Якщо компанії важливі production-grade control-plane resilience, 3-AZ сценарії та формальні SLA для high-availability workloads, тоді OVHcloud MKS Standard може бути сильнішим вибором.

Але головний урок із цього кейсу не в тому, що один провайдер «кращий» за іншого. Головний урок у тому, що cloud sovereignty не закінчується вибором Kubernetes cluster.

Потрібно дивитися на весь шлях даних: Git, CI, container registry, load balancers, object storage, backups, logs, secrets, support access і disaster recovery. Лише тоді міграція з hyperscaler у європейський cloud буде не косметичною зміною provider logo, а справді архітектурним рішенням про data residency, operational maturity і довгострокову portability.

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті