Налаштування мультихмарної інфраструктури (Multi-Cloud)

terraform {
  required_providers {
    aws = {
      source = "hashicorp/aws"
      version = "~> 5.0"
    }
    google = {
      source = "hashicorp/google"
      version = "~> 5.0"
    }
    azurerm = {
      source = "hashicorp/azurerm"
      version = "~> 3.0"
    }
  }
}

provider "aws" {
  region = var.aws_region
  assume_role {
    role_arn = var.aws_role_arn
  }
}

provider "google" {
  project = var.gcp_project_id
  region = var.gcp_region
}

Remote state — в S3 з DynamoDB locking, або в Terraform Cloud. State має бути один — інакше outputs одного провайдера не зможуть стати inputs іншого.

Структура проєкту ділиться за провайдерами:

infrastructure/
  shared/ # спільні змінні, data sources
  aws/
    networking/
    compute/
    databases/
  gcp/
    networking/
    storage/
  ml-platform/
  global/
    dns/ # Cloudflare або Route 53 як глобальний DNS
    monitoring/

Мережа мультихмарної інфраструктури: як з'єднати?

Пряме з'єднання AWS та GCP — через Dedicated Interconnect (GCP) + Direct Connect (AWS) із спільною точкою обміну на нейтральному co-location (Equinix, Digital Realty). Це дорого, але дає передбачувану latency.

Для більшості проєктів — VPN mesh через WireGuard або Tailscale. Tailscale особливо зручний: агент встановлюється на ноди в обох хмарах, формує mesh-мережу, всі ноди бачать одна одну за IP. Конфігурація — декларативна через Terraform Tailscale провайдер.

Якщо трафік між хмарами йде тільки через API (HTTP/gRPC) — достатньо публічних ендпоїнтів з mTLS. Cert-manager видає сертифікати, SPIFFE/SPIRE забезпечує identity для сервісів незалежно від хмари.

Kubernetes у мультихмарі: GitOps та управління

Управління кількома кластерами — через fleet management. ArgoCD з ApplicationSet та cluster generators розгортає одні й ті ж застосунки в EKS та GKE з єдиного git-репозиторію. Різниця між кластерами — у values-aws.yaml та values-gcp.yaml.

Приклад ApplicationSet:

---
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: backend-service
  namespace: argocd
spec:
  generators:
    - clusters:
        selector:
          matchLabels:
            environment: production
  template:
    metadata:
      name: '{{name}}-backend'
    spec:
      project: default
      source:
        repoURL: https://github.com/company/k8s-configs
        targetRevision: main
        path: apps/backend
        helm:
          valueFiles:
            - values.yaml
            - 'values-{{metadata.labels.cloud}}.yaml'
      destination:
        server: '{{server}}'
        namespace: backend
"}

Note: The original flattened code had a missing newline after "spec:"? Actually the original had "spec: generators:" but I inserted a newline after "spec:" and indented generators properly. Also the template is under spec, but in the original it was "spec: generators: ... template:" which is ambiguous. I assumed the structure as per typical ApplicationSet: spec has generators and template. So I placed template at same level as generators under spec. But the original had "spec: generators: - clusters: ... template:" without a clear separation. I added a newline before template and indented it under spec. However, to strictly not alter tokens, I should not add or remove tokens, only newlines and indentation. The original had "spec: generators: - clusters: selector: matchLabels: environment: production template: metadata: ..." So the token sequence is: spec, :, generators, :, -, clusters, :, selector, :, matchLabels, :, environment, :, production, template, :, metadata, :, ... So template is a sibling of generators? Actually in YAML, after "generators:" there is a list item "- clusters:" and then after that "template:" is at the same indentation as "generators"? But the original had no indentation, so we need to infer. Typically ApplicationSet spec has generators and template as separate keys. So I placed template at same level as generators. But the original had "spec: generators: - clusters: ... template:" so after the list item, template is a new key under spec. So I did that. Also note that the original had "spec: generators: - clusters: selector: matchLabels: environment: production template: metadata: ..." So I put template after the list item, but it should be at the same indentation as generators. So my output has template at same level as generators (both under spec). That is correct.

Also note that the original had "helm: valueFiles:" and then list items. I did that.

I also added a newline after "---" and at the end.

I did not change any tokens, only added newlines and spaces for indentation. The original had no spaces after colons? Actually it had spaces after colons, like "apiVersion: argoproj.io/v1alpha1" so I preserved that. I added newlines and indentation.

I think this is correct.<｜end▁of▁thinking｜>{"code": "---
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: backend-service
  namespace: argocd
spec:
  generators:
    - clusters:
        selector:
          matchLabels:
            environment: production
  template:
    metadata:
      name: '{{name}}-backend'
    spec:
      project: default
      source:
        repoURL: https://github.com/company/k8s-configs
        targetRevision: main
        path: apps/backend
        helm:
          valueFiles:
            - values.yaml
            - 'values-{{metadata.labels.cloud}}.yaml'
      destination:
        server: '{{server}}'
        namespace: backend

Velero для бекапів між хмарами — снапшоти PVC з AWS EBS реплікуються в GCS як додатковий DR-шар.

Моніторинг та observability: єдина картина

Метрики з кількох хмар збираються в єдину систему. Prometheus federation або VictoriaMetrics з remote_write з кожного кластера в центральний Thanos. Grafana з datasources на обидві хмари — в дашбордах видно стан всієї інфраструктури.

Для distributed tracing — OpenTelemetry Collector у кожному кластері, експорт у Jaeger або Grafana Tempo. Trace проходить через сервіси в AWS та GCP — видно повний ланцюжок.

Мультихмарна інфраструктура: ключові аспекти

Типові помилки та як їх уникнути

Спроба зробити інфраструктуру повністю ідентичною в обох хмарах — пастка. AWS та GCP мають різні примітиви: Load Balancer Controller в EKS vs GKE Ingress, EBS vs Persistent Disk, Security Groups vs VPC Firewall Rules. Намагаючись зробити один-в-один, витрачаєш час на боротьбу з відмінностями, замість того щоб використовувати сильні сторони кожного.

Абстракції на кшталт Crossplane допомагають — але додають свій рівень складності та operational overhead.

Що входить у роботу

1. Архітектурний воркшоп: визначаємо сценарій (Active/Passive, Active/Active або спеціалізація), обираємо провайдерів, фіксуємо вимоги до RTO/RPO.
2. Проєктування мережі: вибір типу з'єднання (VPN, Direct Connect) та топології.
3. Розгортання IaC: Terraform-модулі для всіх провайдерів, репозиторій коду, pipeline.
4. Налаштування GitOps: ArgoCD/Flux для синхронізації k8s-конфігів.
5. Реплікація даних: налаштування CDC, моніторинг лагу, план відновлення.
6. Моніторинг та логи: централізований Prometheus/Grafana/Loki, алерти за SLO.
7. Документація runbook та навчання команди.

GitOps-підхід скорочує час відновлення після збою на 50% порівняно з традиційним адмініструванням. Понад 95% клієнтів обирають Active/Passive як оптимальне співвідношення ціни та стійкості. Використання GitOps у 2 рази прискорює розгортання.

Орієнтири за термінами

Вартість базового проекту починається від $15,000, а середня економія за рахунок оптимізації хмарних ресурсів сягає 40% (що може становити $10,000+ на місяць). Архітектурний воркшоп коштує $500-1000, і ця сума зараховується в оплату основного проекту. Гарантія на безперебійну роботу — 3 місяці після здачі.

Починаємо з архітектурного воркшопу — визначаємо реальне завдання та обираємо мінімально складну архітектуру, яка його вирішує. Оцінимо ваш проєкт за 2 дні — просто зв'яжіться з нами. 5+ років досвіду в мультихмарних архітектурах, 30+ реалізованих проєктів — ми знаємо, як обійти типові пастки. Пишіть, щоб отримати консультацію та детальний план.