Налаштування гібридної хмарної інфраструктури

Налаштування гібридної хмарної інфраструктури (Hybrid Cloud)

Уявіть: у вас legacy-система в датацентрі з десятками залежностей від заліза та ліцензій. Перенести її в хмару — ризик на кілька місяців. Але нові мікросервіси ви хочете запускати в Kubernetes на AWS. Вихід — гібридна інфраструктура. Ми налаштовуємо її під ключ так, щоб on-premise та хмара працювали як єдиний кластер із загальним мережевим, DNS та IAM контуром.

Як налаштувати гібридну хмарну інфраструктуру? — налаштування гібридної хмарної

Типовий запит: «у нас legacy-система в датацентрі, її не перенести в хмару — надто багато залежностей від заліза та ліцензій. Але нові сервіси хочемо запускати в Kubernetes в хмарі». Саме для такого сценарію і будується гібрид. Нижче розберемо ключові етапи та підводні камені.

Де зазвичай все ламається

Найчастіша проблема — неузгодженість мережевих адрес. On-premise мережа живе в 10.0.0.0/8, хмарна VPC — в 172.16.0.0/12, і на перший погляд все добре. Але коли додається Transit Gateway, пірінгові з'єднання до кількох VPC та корпоративний VPN — починаються overlapping CIDR, які маршрутизатор мовчки ігнорує. Пакети зникають, сервіс недоступний, і жодна зі сторін не бачить помилки на своєму рівні.

Друга точка болю — DNS. У гібридному середовищі потрібно, щоб db.internal.company.com із хмарного пода резолвився в IP-адресу on-premise бази, а api.svc.cluster.local з on-premise додатку — в ClusterIP кубернетес-сервісу. Це вирішується через Route 53 Resolver з forwarding rules у бік on-premise DNS, та Conditional Forwarder на стороні on-premise у бік Route 53. Якщо не налаштувати обидва напрямки — половина резолюцій буде падати з NXDOMAIN.

Автентифікація також нетривіальна. Додатки в хмарі повинні отримувати credentials для доступу до on-premise систем, і навпаки. IAM Roles for Service Accounts (IRSA) в EKS працює чудово всередині AWS, але для on-premise ресурсів потрібен або Vault з AWS auth backend, або секрети через AWS Secrets Manager з реплікацією в кластер через External Secrets Operator.

Direct Connect чи VPN: що обрати?

Для production-навантажень із критичною latency обираємо Direct Connect. Для dev/staging або малих обсягів — VPN.

Як будуємо гібридну мережу

Мережева зв'язність — перше, що проєктуємо. Використовуємо Transit Gateway як центральний хаб. Всі VPC підключаються до нього, а не через пірінг одна з одною. Це масштабується: додаєш нову VPC — прикручуєш до TGW, маршрути до інших з'являються автоматично.

Топологія мережі для середнього проєкту:

On-Premise (10.10.0.0/16) │
│ Direct Connect / VPN ▼ AWS Transit Gateway
├── Production VPC (10.20.0.0/16)
│   ├── Private Subnet (10.20.1.0/24) — EKS nodes
│   └── Private Subnet (10.20.2.0/24) — RDS
├── Staging VPC (10.30.0.0/16)
└── Shared Services VPC (10.40.0.0/16)
    ├── Route 53 Resolver Inbound Endpoint
    └── Route 53 Resolver Outbound Endpoint

Управління конфігурацією через Terraform

Вся мережева інфраструктура — в коді. Приклад Terraform для Route 53 Resolver:

resource "aws_route53_resolver_endpoint" "outbound" {
  name = "hybrid-outbound-resolver"
  direction = "OUTBOUND"
  security_group_ids = [aws_security_group.resolver.id]

  ip_address {
    subnet_id = aws_subnet.shared_services_a.id
  }

  ip_address {
    subnet_id = aws_subnet.shared_services_b.id
  }
}

resource "aws_route53_resolver_rule" "onprem" {
  domain_name = "internal.company.com"
  name = "forward-to-onprem"
  rule_type = "FORWARD"
  resolver_endpoint_id = aws_route53_resolver_endpoint.outbound.id

  target_ip {
    ip = "10.10.0.53"
    port = 53
  }

  target_ip {
    ip = "10.10.0.54"
    port = 53
  }
}

Маршрути в Transit Gateway Route Table теж декларативні — жодних ручних кліків у консолі, які ніхто не задокументував.

Kubernetes у гібридному середовищі

EKS кластер з node group у приватних підмережах не має прямого доступу до інтернету. Для pull образів з ECR потрібен VPC Endpoint для ECR та S3 (шари образів зберігаються в S3). Для доступу до on-premise ресурсів — маршрути через TGW. CoreDNS в кластері налаштовується через ConfigMap з Corefile:

---
apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns
  namespace: kube-system
data:
  Corefile: |
    .:53 {
        errors
        health
        kubernetes cluster.local in-addr.arpa ip6.arpa {
            pods insecure
            fallthrough in-addr.arpa ip6.arpa
        }
        forward internal.company.com 10.10.0.53 10.10.0.54
        forward . /etc/resolv.conf
        cache 30
        loop
        reload
        loadbalance
    }