Сеть в кластере
Сервер CoreDNS внутри кластера используется в качестве замены kube-dns. Этот сервер обеспечивает обнаружение сервисов в кластере и дает возможность обращения к ним по DNS-именам.
Также CoreDNS экспортирует метрики в Prometheus, что позволяет отслеживать его работу через инструменты мониторинга кластера.
Кластеры Kubernetes используют Calico для организации внутрикластерной сети. Calico взаимодействует с платформой VK Cloud с помощью OpenStack Neutron API. Сама платформа использует программно-определяемую сеть (software-defined network) Neutron.
При использовании OpenStack Neutron в больших облачных сетях (порядка десятка тысяч сетевых портов на сеть) есть проблемы со скоростью сходимости при выходе из строя хотя бы нескольких участников сети. Синхронизация изменений топологии сети такого размера занимает много времени, что негативно влияет на ее производительность.
Поэтому в VK Cloud была разработана собственная программно-определяемая сеть Sprut. Она полностью совместима с Neutron API, но работает по другим принципам, что позволяет использовать ее совместно с Calico в облачных сетях большого размера, не испытывая при этом описанных проблем. Подробнее о Sprut читайте в статье Как устроены облачные сети и чем они отличаются от On-premise и в видео на YouTube.
Кластер Kubernetes интегрируется с балансировщиками нагрузки платформы VK Cloud. Это касается и обычных балансировщиков нагрузки Kubernetes (LoadBalancer), и Ingress-контроллеров (IngressController): и к одним, и другим при создании будет привязан выделенный TCP-балансировщик VK Cloud. Это касается в том числе и Ingress-контроллера, который устанавливается в виде аддона.
При необходимости можно использовать HTTP-балансировщик нагрузки. Подробнее об этом рассказано в примере для Ingress-контроллера.
Балансировщик нагрузки платформы VK Cloud построен на базе OpenStack Octavia, который в своей основе имеет HAProxy и поддерживает:
- проксирование и балансировку HTTP- и TCP-соединений (последние — в том числе с поддержкой proxy-протокола);
- проксирование и балансировку HTTP/2-соединений в дополнение к HTTP/1.1;
- терминирование SSL-соединений на балансировщике.
Для отказоустойчивости поддерживаются два экземпляра балансировщика, один из которых находится в режиме active, а другой — в режиме standby. Синхронизация состояний и переключение трафика между этими балансировщиками происходят с помощью протокола VRRP. Кластер воспринимает такую отказоустойчивую конфигурацию как один балансировщик.
Иногда при использовании Ingress-контроллера поду в кластере необходимо видеть реальный IP-адрес пользователя, который прислал исходный запрос на балансировщик, а не IP-адрес самого балансировщика. Это может быть важно для некоторых видов сетевых приложений.
Чтобы под, который работает через Ingress-контроллер, мог видеть реальный IP-адрес пользователя, используйте один из вариантов:
-
Ingress-контроллер с поддержкой proxy-протокола.
Если планируется работать с HTTPS-трафиком, настройте терминирование SSL-соединений на этом Ingress-контроллере, т.к. TCP-балансировщик, который будет создан для контроллера, не может сам терминировать SSL-соединения.
Ingress-контроллер на базе NGINX, предоставляемый VK Cloud, поддерживает proxy-протокол и уже настроен на работу с ним.
-
Отдельный HTTP\HTTPS-балансировщик с дополнительными настройками:
- Если планируется работать с HTTPS-трафиком, настройте терминирование SSL-соединений на этом балансировщике.
- Активируйте на Ingress-контроллере политику
ExternalTrafficPolicy: Local.
В этом случае на Ingress-контроллер будет поступать только HTTP-трафик, в котором будут видны все заголовки, в том числе IP-адрес отправителя (если он есть).
При создании кластера Kubernetes для него создается несколько сетевых объектов.
Для каждого кластера создается выделенный TCP-балансировщик нагрузки, который обрабатывает входящие запросы к API Kubernetes для всех master-узлов. Через этот балансировщик происходит подключение к кластеру и управление им.
Для каждого кластера создаются три группы правил:
<имя кластера>-base: обеспечивают возможность коммуникации между master-узлами и группами worker-узлов.<имя кластера>-master: обеспечивают возможность коммуникации с master-узлам.<имя кластера>-minion: обеспечивают возможность коммуникации между группами worker-узлов.