нам действительно нужен порт для безголового сервиса?

Question

Это может быть вопрос, основанный на любопытстве, который не может найти помощь в Google.

Рассмотрим эту часть yaml для службы без головы:

ports:
 - port: abcd  --> this line

Я сомневаюсь, что, когда кластерный ip для службы без заголовка уже отсутствует (поскольку это набор модулей, на которые он указывает), какая польза от наличия порта для службы? Запись DNS из документации для сервисов гласит:

«Безголовый» (без IP-адреса кластера) Службам также назначается запись DNS A для имени в форме my-svc.my-namespace.svc.cluster.local. В отличие от обычных Сервисов, это разрешает набор IP-адресов модулей, выбранных Сервисом. Ожидается, что клиенты будут использовать набор или использовать стандартный циклический выбор из набора.

Следовательно, если dns, который выделен для служб без заголовка, используется исключительно для того, чтобы иметь конечные точки в модулях, есть ли какой-либо вариант использования функциональности порта в службе без заголовка?

Я видел проблемы, с которыми люди сталкивались при исключении значения порта из определения службы без заголовка ( здесь ). Кажется, это было исправлено. Но тогда, действительно ли у нас есть сценарий использования для функциональности порта безголовой службы?

Answer 1

Но тогда, действительно ли у нас есть сценарий использования для функции порта службы безголового доступа?

ИМХО, да: потому что сама идея Service не является "случайным IP-адресом" - иначе он будет называться DHCPIPAddress. Идея Service в kubernetes заключается в том, что вы можете использовать некоторые сетевые функции, используя один или несколько наборов (address, protocol, port), как в мире, не связанном с kubernetes.

Так что может быть хорошо, если вас не волнует порт безголового Service, в этом случае добавьте ports:\n- port: 80\n и назовите это ничьей, но преимущество безголового Service - раскрытие внекластерного сетевого ресурса способом, которым сам kubernetes не может управлять. Я использовал этот трюк, чтобы помочь нам перейти от одного кластера к другому, создав безголовый Service, имя которого было тем, что ожидал предыдущий Deployment, с именем ports:, которое ожидал предыдущий Deployment, но указав на IP-адрес, которым я управлял, а не в SDN.

При этом все традиционные инъекции kubernetes kube-dns и $(SERVICE_THING_HOST) и $(SERVICE_THING_PORT) работали, как ожидалось, но абстрагировались от того факта, что _HOST временно жил вне кластера.