Это неоднозначный выбор слов, но в результате вы не можете получить доступ к initContainer через Сервис.
Сервисы Kubernetes предоставляют доступ к набору модулей, соответствующих их меткам. В этом смысле сервис является агрегатором. Я думаю, что это подразумеваемый смысл.
В модуле также может быть несколько контейнеров, каждый из которых использует свой порт. Если Pod сопоставлен с какой-либо службой, эту службу можно настроить для предоставления доступа к обоим портам. Таким образом, служба также может сделать доступными несколько портов, хотя я бы не назвал это объединением.
Модули не открываются Сервисом, пока не пройдут проверки готовности, и состояние Модуля не будет готово. InitContainer запускается перед зондами при инициализации статуса Pod. Так что логично, что это не может быть достигнуто Сервисом. Также было бы странно хотеть выставить initContainer внешне, поскольку он является временным по своей природе.
Ваша цель - отладка (https://unofficial -kubernetes.readthedocs.io / en / latest / tasks / debug-application-cluster / debug-init-container / ) или разрешить другим Стручки / Контейнеры для доступа? Я полагаю, что при инициализации у модуля Pod был бы IP-адрес, но не тот, который гарантированно был бы стабильным, поэтому я не знаю, сможете ли вы перенаправить порт для отладки https://kubernetes.io/docs/tasks/access-application-cluster/port-forward-access-application-cluster/
Я заметил, что вы говорите, что хотите раскрыть initContainer в Job. Обслуживание трафика на работе было бы необычной целью. Если целью является мониторинг задания, см. Мониторинг задания kubernetes