Инструкции

Клиенты часто спрашивают, как построить геораспределенный и катастрофоустойчивый Kubernetes. Так, чтобы при отказе целого дата-центра нагрузка переключалась на резервную площадку без смены IP-адресов сервисов. Можно возразить, что проще изменить DNS-запись и направить трафик на инстанс в другом дата-центр. Но есть риск: кэширование на рекурсорах некоторых провайдеров может негативно повлиять на доступность. Они иногда игнорируют TTL и хранят старые данные неопределенный срок. Поэтому в таких сценариях крайне желательно сохранить IP-адрес. Один из элементов «мозаики» такой геораспределенной системы — балансировщик нагрузки с возможностью использования адресов из anycast-подсети, которую выделяет поставщик услуг. В этой инструкции мы не будем затрагивать вопрос передачи данных и их консистентность на двух разных площадках — разберем только сетевую составляющую. Сетевая схема Общая сетевая схема. Многовато на первый взгляд, правда? Схема описывает распределенную отказоустойчивую конфигурацию на основе кластеров Managed Kubernetes (MKs), которая развернута в двух регионах. Bravo — BissoTwo, регион Москва, пул ru-7. Alfa — UnaOne, регион Санкт-Петербург, пул ru-3. Инфраструктура использует внутренних и внешний BGP-пиринг для маршрутизации трафика между узлами, облачными роутерами, балансировщиками и маршрутизаторами Selectel (на схеме — Betelgeuse и Antares). Дата-центр Bravo Характеристики кластера MKs Мастер-нода: 192.168.147.111 — управляющая нода кластера. Рабочая нода 1: 192.168.147.25 Рабочая нода 2: 192.168.147.26 Балансировщик MetalLB: 203.0.113.67 — внешний IP для сервисов в кластере. Сеть и маршрутизация Служебная сеть MKs — связывает мастер-ноды кластера и используется для доступа к kube API, мониторинга и обслуживания со стороны провайдера. Облачная сеть Bravo: 192.168.147.0/24 — подключена к облачному роутеру Bravo (192.168.147.1), который используется для резервного доступа в интернет и публичных IP-адресов вне anycast-пула. gateway-bravo-bissotwo (192.168.147.254) — шлюз, через который трафик по умолчанию выходит в интернет и на котором развернуто ПО, обеспечивающее работу BGP (забегая вперед — frrouting); на этой машине также настраивается трансляция сетевых адресов с использованием netfilter/nftables. IBGP peering между рабочими нодами и шлюзом gateway-bravo-bissotwo. EBGP peering между шлюзом и роутером Betelgeuse (198.19.51.230/29). Дата-центр Alfa Характеристики кластера MKs Мастер-нода: 192.168.247.211 Рабочая нода 1: 192.168.247.101 Рабочая нода 2: 192.168.247.102 Балансировщик MetalLB: 203.0.113.66 Сеть и маршрутизация Служебная сеть MKs — связывает мастер-ноды кластера и используется для доступа к kube API, мониторинга и обслуживания со стороны провайдера. Облачная сеть Alfa: 192.168.247.0/24 — подключена к облачному роутеру Alfa (192.168.247.1). gateway-alfa-unoone (192.168.247.254) – шлюз. IBGP peering между рабочими нодами и шлюзом gateway-alfa-unoone. EBGP peering между шлюзом и роутером Antares (198.51.100.9). Межрегиональное взаимодействие Глобальный роутер не участвует в организации BGP и anycast. Он необходим для обмена трафиком внутри сетевого периметра без использования интернета — например, чтобы настроить репликацию баз данных или организовать Hot Standby между регионами. Также обеспечена отказоустойчивость: при недоступности одного региона трафик перенаправляется в другой с использованием anycast-маршрутизации. Разумеется, если балансировщики MetalLB работают с общими для двух кластеров внешними IP-адресами. Типы пиринга В схеме используются два типа пиринга. Внутри каждого региона между рабочими нодами и виртуальным шлюзом в соответствующем пуле облака настраивается iBGP (Internal BGP). Это обеспечивает корректное распространение маршрутов внутри автономной системы (AS). Связь с внешними сетями и маршрутизаторами Selectel (Betelgeuse, Antares) реализуется через eBGP (External BGP). Этот уровень отвечает за обмен маршрутами между шлюзами и глобальной сетевой инфраструктурой. Безопасность и отказоустойчивость Отказоустойчивость системы обеспечивается работой в двух независимых регионах облачной платформы. Динамическое перенаправление трафика между ними реализовано с помощью BGP-пиринга: внешние IP-адреса (203.0.113.64–203.0.113.71) анонсируются из обоих регионов одновременно. Это позволяет использовать anycast-схемы или быстрое переключение (failover) при сбоях. За балансировку нагрузки на уровне L4 внутри кластеров отвечает MetalLB. IP-адресация КомпонентIP-адресПримечаниеBravo Master192.168.147.111Bravo Worker 1192.168.147.25Bravo Worker 2192.168.147.26Bravo Gateway192.168.147.254Внутренний IPBravo Gateway198.19.51.230Внешний IPBravo Router192.168.147.1Alfa Master192.168.247.211Alfa Worker 1192.168.247.101Alfa Worker 2192.168.247.102Alfa Gateway192.168.247.254Внутренний IPAlfa Gateway198.51.100.14Внешний IPAlfa Router192.168.247.1Cloud Router Bravo192.0.2.56Внешний IP облачного роутера. Выделяется при создании.Cloud Router Alfa192.0.2.31Внешний IP облачного роутера. Выделяется при создании.MetalLB Bravo203.0.113.67Внешний IP для сервисов в k8sMetalLB Alfa203.0.113.66Внешний IP для сервисов в k8sBetelgeuse (EBGP)198.19.51.23025/29IP роутера Selectel в линковочной сетиAntares (EBGP)198.51.100.9/29IP роутера Selectel в линковочной сети Взаимодействие по BGP Сетевые переключения. Как в такой схеме организован обмен маршрутами? В примере используются три автономные системы: две принадлежат провайдеру (AS 64600 и AS 65101), а одна — частная (например, AS 64859). Номер частной AS необходимо заранее согласовать с инженерами Selectel. Провайдер передает нам маршрут по умолчанию (default route), а мы анонсируем в ответ сеть 203.0.113.64/29. При этом виртуальный шлюз может транслировать и более специфичные маршруты (с маской больше /29), если они появятся в таблице маршрутизации. Для этого в конфигурации BGP-демона должны быть активны опции redistribute static или redistribute connected. Маршруты, полученные по iBGP от других «соседей», будут перераспределяться автоматически. Специфичные маршруты, например /32 для конкретных IP, шлюз получает от балансировщика MetalLB, когда в Kubernetes-кластере создается сервис типа LoadBalancer. Далее шлюз анонсирует их через пиринг с роутерами Selectel «в мир». Такой подход и обеспечивает региональную отказоустойчивость. Настройка схемы 1. Заказываем две публичные подсети. В панели управления Selectel это можно сделать в разделе Продукты → Облачные серверы → Сеть → Публичные сети. Эти подсети будут использованы как линковочные. 2. Заказываем BGP + anycast-подсеть. Потребуются линковочные подсети из п.1. один. Процесс описан в документации. В примере используются: подсеть 198.19.51.224/29 — для Bravo, подсеть 198.51.100.8/29 — для Alfa. Не забываем указать в тикете, что при настройке BGP-соседства будет использоваться bidirectional forwarding detection. 3. Выбираем по адресу из каждой линковочной подсети. Эти адреса следует сообщить в тикете для настройки BGP peering-а. В примере взяты: 198.19.51.230 – для Bravo, 198.51.100.14 – для Alfa. 4. Создаем две приватные облачные сети в каждом из пулов. В панели управления Selectel это можно сделать в разделе Продукты → Облачные серверы → Сеть → Приватные сети. В каждой сети будет по одной частной подсети. В этих сетях также будут созданы рабочие ноды Managed Kubernetes. На схеме эти сети обозначены как «Облачная сеть Alfa» и «Облачная сеть Bravo» с подсетями 192.168.247.0/24 и 192.168.147.0/24 соответственно. В качестве шлюза по умолчанию для подсетей указываем будущие частные адреса ВМ. На схеме используются 192.168.247.254 и 192.168.147.254. 5. Разворачиваем по одной виртуальной машине в каждом выбранном пуле, как это описано в документации. Для внешнего интерфейса используем IP-адрес из тех, что были выбраны во п.2 для настройки BGP-соседства (BGP Neighbor) в соответствующем регионе. В качестве ОС используем AlmaLinux 9 с актуальными обновлениями. Не забываем включить на ВМ передачу трафика транзитно, через интерфейсы (forwarding): 6. Добавляем для внутренних портов двух ВМ все IPv4-адреса. Так как ВМ используется как шлюз, то без данной настройки работа невозможна. Выполняем на управляющей машине: Не забываем поменять IP-адрес на свой. Подробнее о настройке можно прочитать в документации. 7. На ВМ устанавливаем и настраиваем ПО с поддержкой протокола BGP.В примере будет использован frrouting. Задействуем запуск bgpd и bfdd при старте frr: Приводим конфигурацию каждого из frr (/etc/frr/frr.conf) к следующему виду: frr в region alfa frr в region bravo Не забываем заменить номер AS (в примере – 64859) на свой, согласованный с технической поддержкой. Запускаем сервис и задействуем запуск при перезагрузке ВМ: 8. Если ВМ-шлюз предполагается использовать для NAT и фильтрации, то не забываем настроить netfilter через iptables/nftables. 9. Разворачиваем два управляемых кластера Kubernetes. Проще сделать это, используя Terraform. Пример части манифеста: Если интересует полностью готовый вариант, он представлен в репозитории. 10. Разрешаем anycast-подсеть на всех сетевых портах рабочих нод двух созданных кластеров в разных пулах. Если кластер создан в панели управления Selectel, то в «разрешенные» подсеть можно добавить через тот же интерфейс или CLI. Если вы выбрали второй вариант, то выполните в терминале управляющей машины следующий блок кода: Не забудьте заменить переменную, задающую подсеть ANYCAST_CIDR в скрипте, на свою. 11. Устанавливаем MetalLB в оба кластера MKs: 12. Добавляем профиль BFD, который будет использоваться для пиринга с нашим шлюзом: 13. Добавляем ВМ-шлюз как BGP peer для MetalLB. Afla Bravo Снова не забываем заменить номер AS (в примере — 64859) на свой, согласованный с технической поддержкой. Проверяем, что peer добавился: Пример вывода: 14. Добавляем выделенный провайдером пул anycast-адресов в назначаемые для балансировщиков MetalLB: 15. Добавляем анонсирование для адресов из пула для балансировщиков MetalLB: 16. Отключаем создание облачных балансировщиков (Octavia), так как будет использоваться MetalLB. Этап настройки завершен. Теперь следует проверить работоспособность решения. Применение решения Посмотрим, как работает настроенный MetalLB. Мы будем проверять только функциональность, без нагрузочного тестирования. 1. Разворачиваем простой echoserver в двух кластерах в разных пулах: Проверяем: 2. Публикуем сервис. Применяем для двух кластеров: Проверяем: 3. Запрашиваем данные от echo-сервера: Запросы на anycast-адрес проходят. В примере нам отвечает под в кластере Alfa. Манифесты для развертывание стенда При прочтении возникает впечатление, что развертывание подобной конфигурации можно (и нужно) автоматизировать. Это действительно так — есть даже специальное решение. В репозитории доступны готовые Terraform-манифесты — с их помощью можно быстро развернуть всю описанную инфраструктуру. Главное — внимательно прочитать README при применении, так как оно происходит в три этапа. Впоследствии представленный код можно легко модифицировать для создания собственной продуктивной инсталляции. После применения конфигурации экспортируем конфигурационные файлы K8s: Затем между конфигурациями можно удобно переключаться, задавая контекст: Switchover: плановые переключения Вы развернули кластеры, приложения в них и начали тестовую эксплуатацию. Как же переключиться между дата-центрами?Предположим, что вы опубликовали сервис с одинаковыми публичными IP. Конфигурацией это не возбраняется. Для этого при создании сервиса в манифесте должна присутствовать аннотация metallb.io/loadBalancerIPs или спецификация spec.loadBalancerIP. Пример манифеста, который применен в двух кластерах: Куда попадет клиентский запрос при обращении к IP? В сервис в каком кластере? И как переключить клиентский трафик на другой кластер? Давайте разбираться. Обратим внимание на конфигурацию frrouting. На ВМ gateway-alfa-unoone мы имеем следующую карту маршрутов (route-map): А на gateway-bravo-bissotwo — такой route-map: Вспоминаем: нас есть два основных метода «ухудшения» маршрутов для анонсируемых префиксов, а именно AS-Path prepend и MED. Очевидно, что в своей конфигурации мы используем первый метод. «Хитрости» с community не рассматриваем — это выходит за рамки данной статьи. Сами же себе отвечаем на первый вопрос. Если адрес анонсируется из двух кластеров K8s одновременно, то трафик будет направлен туда, где AS Path короче, то есть на ВМ Alfa. А для переключения достаточно добавить в AS Path больше ASN, чем присваивается при анонсе anycast-подсети с ВМ в другом дата-центре. Теперь представим что у нас штатное переключение нагрузки и Alfa в Bravo. Как его сделать? 1. Для начала убедимся, что запрос приходит в тот кластер, нагрузку с которого планируем снять: Запрос пришел на под в кластере Alfa. 2. Заходим по SSH на ВМ в gateway-alfa-unoone и запускаем vtysh, в котором выполняем следующие команды: То есть мы добавляем к пути еще дополнительно четыре приватных номера автономной системы. 3. Проверяем количество ASN, добавленных к пути. В том же открытом vtysh выполняем: Пример вывода: 4. Выполняем запрос и убеждаемся, что он приходит на балансировщик в другом кластере (k8s-bravo-bissotwo): Мы добились желаемого. Как видно, трафик на 203.0.113.65 по прежнему идет через балансировщик в кластере Alfa, потому что подсеть анонсируется только при появлении адреса в таблице маршрутизации по iBGP. Это удобно и гибко. Failover: аварийные переключения Хороший провайдер IT-инфраструктуры в первую очередь заботится о надежности своих сервисов, но ситуации бывают разные. Давайте сымитируем «падение» одного из дата-центров и посмотрим, как поведет себя система. Для этого «вредного» действия принудительно выключим рабочие ноды K8s и машину-шлюз в Bravo. Но сначала установим и запустим утилиту для тестирования locust и соберем статистику, сколько запросов пропадает при выключении и автоматическом переключении ВМ. Напишем простой locustfile: Запускаем locust: Теперь выключаем ВМ с помощью OpenStack CLI, но не возбраняется сделать это и через панель управления. Получаем следующую картину при выключении: Данные из системы мониторинга. Данные из системы мониторинга. Как видим, «пропало» всего 96 запросов при RPS в 127. Неплохой результат! Понятно, что echoserver возвращает контент небольшого размера, но тем не менее. Выводы Чего же мы добились? В первую очередь, получили основу для отказоустойчивого или даже геораспределенного инфраструктурного решения на базе Managed Kubernetes. Реализованная схема подходит и для Kubernetes-кластера, развернутого собственными силами. Отработка отказа на уровне сети происходит быстро и позволяет с минимумом «боли» пережить даже такой серьезный инцидент, как выход из строя целого дата-центра. Конечно, схему можно улучшить. Одна ВМ в облаке может выглядеть как точка отказа. Можно создать еще одну ВМ с frr и настроить дополнительный пиринг как с провайдером, так и для MetalLB. Кроме того, можно поставить и настроить shell-operator, чтобы не добавлять вручную allowed address pairs для сетевых портов в облачных сетях.