В типе кластера, который копс создает, сервер apisver (упоминаемый выше как api, компонент мастера Kubernetes, также называемый плоскостью управления) может не иметь статического IP-адреса. Кроме того, копы могут создать плоскость управления HA (реплицированную), что означает, что будет с несколькими IP-адресами, на которых доступен аписервер.
Apiserver функционирует как центральный соединительный узел для всех других компонентов Kubernetes, например, все узлы подключаются к нему, но также операторы подключаются к ним через kubectl. Во-первых, эти файлы конфигурации не поддерживают несколько IP-адресов для сервера apiserver (чтобы использовать настройку HA). Плюс обновление файлов конфигурации каждый раз, когда изменение IP-адреса (ов) сервера будет затруднено.
Таким образом, балансировщик нагрузки функционирует как фронт для сервера (ов) с одним статическим IP-адресом (произвольный IP-адрес с AWS / GCP). Этот IP-адрес балансировщика нагрузки указывается в файлах конфигурации компонентов Kubernetes вместо фактических IP-адресов apiserver.
На самом деле, эту программу также можно решить, используя DNS-имя, которое разрешает IP-адрес (а) сервера (-ов) в сочетании с механизмом, который поддерживает эту запись обновленной. Это решение не может реагировать на изменения базовых IP-адресов так быстро, как это может сделать балансировщик нагрузки, но оно экономит пару долларов, плюс вероятность его сбоя немного меньше и создает меньшую зависимость от поставщика облачных вычислений. Это можно настроить так:
spec:
api:
dns: {}
См. спецификацию для получения более подробной информации.