Конечная точка доступа Kubernetes API
При наличии нескольких control-plane (управляющих) узлов возникает вопрос обеспечения высокой доступности, когда конечная точка API-сервера Kubernetes может связаться со всеми узлами плоскости управления. Вот два распространенных способа настройки для production сред:
- выделенный балансировщик нагрузки, который будет направлять трафик на control-plane узлы.
- создание нескольких DNS-записей, указывающих на все control-plane узлы.
С помощью этих параметров можно указать один IP-адрес или DNS-имя во время настройки, которое будет маршрутизировать трафик ко всем управляющим узлам.
Выделенный балансировщик нагрузки
Если используется облачный провайдер или собственный балансировщик нагрузки (например, HAProxy, обратный прокси NGINX или балансировщик нагрузки F5), то настройка выделенного балансировщика нагрузки — это естественный выбор. Настройте интерфейс для прослушивания TCP-порта 6443 и направления трафика на адреса управляющих узлов. Конечной точкой Kubernetes будет IP-адрес или DNS-имя интерфейса балансировщика нагрузки с добавлением порта, например, https://myK8s.example.com:6443.
Примечание: не используйте балансировщик нагрузки HTTP, поскольку сервер API Kubernetes обрабатывает завершение TLS и взаимную аутентификацию TLS.
DNS-записи
Можно настроить конечную точку доступа Kubernetes с помощью DNS имен. Добавьте к DNS-имени несколько записей типа A или AAAA, по одной для каждого уровня управления. Например, вы можете добавить:
kube.example.com IN A 192.168.0.10 kube.example.com IN A 192.168.0.11 kube.example.com IN A 192.168.0.12
Тогда вашей конечной точкой будет:
Примечание: схожие функции позволяет выполнять виртуальный IP (VIP), однако этот вариант больше подходит для test- и dev-кластеров.