Сеть в кластере
Сервер CoreDNS внутри кластера используется в качестве замены kube-dns. Этот сервер обеспечивает обнаружение сервисов в кластере и дает возможность обращения к ним по DNS-именам.
Также CoreDNS экспортирует метрики в Prometheus, что позволяет отслеживать его работу через инструменты мониторинга кластера.
Для организации внутрикластерной сети в сервисе Cloud Containers поддерживаются две сетевых подсистемы (CNI, Container Network Interface):
-
Calico реализует сетевую маршрутизацию на уровне L3 с помощью стандартных сетевых протоколов и iptables. Calico хорошо масштабируется и оптимально подходит для средних и крупных кластеров.
-
Cilium использует eBPF (Linux eXpress Data Path) для реализации сетевых политик и маршрутизации непосредственно в ядре ОС, минуя iptables. Cilium поддерживает фильтрацию трафика на уровнях L3, L4 и L7 (например, по HTTP-заголовкам), а также предоставляет расширенные возможности мониторинга (например, через встроенный инструмент Hubble). Cilium оптимально подходит для очень больших кластеров с высокой нагрузкой и микросервисных архитектур.
Обе CNI взаимодействует с платформой VK Cloud с помощью программно-определяемой сети собственной разработки SDN Sprut. Чтобы подключить SDN Sprut к вашему проекту, обратитесь в техническую поддержку.
Кластер 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(S)-балансировщик с дополнительными настройками:
- Если планируется работать с HTTPS-трафиком, настройте терминирование SSL-соединений на этом балансировщике.
- Активируйте на Ingress-контроллере политику
ExternalTrafficPolicy: Local.
В этом случае на Ingress-контроллер будет поступать только HTTP-трафик, в котором будут видны все заголовки, в том числе IP-адрес отправителя (если он есть).
При создании кластера Kubernetes для него создается несколько сетевых объектов.
Для каждого кластера создается выделенный TCP-балансировщик нагрузки, который обрабатывает входящие запросы к API Kubernetes для всех master-узлов. Через этот балансировщик происходит подключение к кластеру и управление им.
Для каждого кластера создаются три группы правил:
<ИМЯ_КЛАСТЕРА>-base: обеспечивают возможность коммуникации между master-узлами и группами worker-узлов.<ИМЯ_КЛАСТЕРА>-master: обеспечивают возможность коммуникации с master-узлам.<ИМЯ_КЛАСТЕРА>-minion: обеспечивают возможность коммуникации между группами worker-узлов.