Настройка гибридной облачной инфраструктуры (Hybrid Cloud)

Настройка гибридной облачной инфраструктуры (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
    }