Зачем нам нужен порт /containerPort в определении развертывания / контейнера Kuberntes?

Question

Когда я определяю, например, развертывание в kubernetes, есть раздел со списком контейнеров, и каждый из них содержит массив портов, например:

apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      containers:
      - name: my-nginx
        image: nginx
        ports:
        - containerPort: 80

Теперь в документации явно сказано, что это не влияет на связь:

Список портов для выставления из контейнера. Предоставление здесь порта дает системе дополнительную информацию о сетевых подключениях, которые использует контейнер, но в основном носит информационный характер. Не указание порта здесь НЕ препятствует открытию этого порта. Любой порт, который прослушивает адрес по умолчанию "0.0.0.0" внутри контейнера, будет доступен из сети. Не может быть обновлено.

Теперь кажется, что это не влияет ни на что, а только на информацию, но что это на самом деле означает, где это используется?

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

Это или есть какие-то другие применения для этой спецификации?

Answer 1

Как вы цитируете документацию,

Список портов для выставления из контейнера. Предоставление здесь порта дает системе дополнительную информацию о сетевых подключениях, которые использует контейнер, но в основном носит информационный характер. Не указание порта здесь НЕ препятствует открытию этого порта. Любой порт, который прослушивает адрес по умолчанию "0.0.0.0" внутри контейнера, будет доступен из сети. Не может быть обновлено.

цель определения containerPorts чисто для документации. Он используется только другими разработчиками для понимания порта, который слушает контейнер. Kubernetes заимствует эту идею из докера, который делает то же самое с EXPOSE Команда, как указано здесь.

Answer 2

(Я знаю, что вы упоминаете услуги в своем вопросе, но я просто хочу привести несколько примеров того, как они выглядят.)

Если вы определяете службу, она может использовать имя порта вашего контейнера для ссылки на это значение порта.

Например, это определение вашего модуля:

      apiVersion: v1
kind: Pod
metadata:
  name: some-pod-name
  labels:
    app: some-label-name
spec:
  containers:
    - name: some-container-name
      image: some-container-image
      ports:
        - containerPort: 8080
          name: some-image-http

Позже, когда вы определите определение службы, вместо указанияtargetPortв качестве номера порта вы можете вместо этого ссылаться на имя контейнера:

      apiVersion: v1
kind: Service
metadata:
  name: some-service-name
spec:
  selector:
    app: some-label-name
  ports:
  - port: 4080
    protocol: TCP
    targetPort: some-image-http #this will use port 8080 as defined in the pod.

См. документацию по этому вопросу здесь.

Answer 3

Один из примеров, когда это используется сторонними продуктами, — istio и kiali.

Для более окончательного решения вы можете сделать так, чтобы эти конечные точки (такие как /health или /metrics) отображались на другом порту и сервере, отличном от вашего основного приложения, и не объявлять этот порт в определении контейнера вашего пода как containerPort. Таким образом, запросы будут полностью игнорироваться прокси-сервером Istio, как указано в документации Istio (внизу этой страницы).

Answer 4

Контейнер в модуле разделяет сетевое пространство имен, что означает IP,Routes и т. Д. Порты не распределяются между контейнерами. Каждый контейнер должен иметь определенный порт, чтобы предоставить его сервис.

Когда контейнер предоставляет более двух портов, ему нужно использовать имя порта, чтобы другие абстракции k8, такие как service, могли найти правильный порт.

IP-адреса Kubernetes существуют в области Pod - контейнеры внутри Pod совместно используют свои сетевые пространства имен - включая их IP-адреса. Это означает, что все контейнеры в модуле Pod могут достигать портов друг друга на localhost. Это также означает, что контейнеры внутри Pod должны координировать использование порта, но это ничем не отличается от процессов в VM. Это называется моделью "IP-per-pod". kubernetes-сети модель

Answer 5

К сожалению, ответ Малати неверен.

В определении развертывания Kubernetes это поле используется для указания номера порта, на котором контейнеры внутри модулей будут прослушивать входящий сетевой трафик. Это поле является важной частью определения способа доступа к вашему приложению в кластере Kubernetes.

Например:

1. Обнаружение служб. Когда вы определяете порт контейнера с помощью , вы разрешаете другим модулям и службам в кластере обнаруживать ваш модуль и взаимодействовать с ним. Kubernetes может маршрутизировать трафик к нужным подам на основе указанного порта .

2. Балансировка нагрузки: Службы Kubernetes могут балансировать нагрузку трафика на модули на основе . Несколько модулей могут предоставлять один и тот же файл , что позволяет легко распределять нагрузку.

3. Проверки работоспособности. Kubernetes может выполнять проверку работоспособности вашего приложения, отправляя запросы в порт контейнера. Если приложение не отвечает должным образом, Kubernetes может автоматически перезапустить модуль или выполнить другие действия в зависимости от вашей конфигурации.

4. Контроллеры входящего трафика. При настройке контроллеров входящего трафика или настройке ресурсов входящего трафика для управления внешним доступом к вашему приложению вы часто указываете целевой порт (который соответствует ) для правильной маршрутизации трафика.

5. Сетевые политики. Если вы определяете сетевые политики для управления связью между модулями, вам может потребоваться указать, разрешать или запрещать трафик на определенные порты.

6. Тип службы LoadBalancer: при использовании службы с типом LoadBalancer определяет, какой порт внешний балансировщик нагрузки должен прослушивать и пересылать трафик внутри кластера.

7. Открытие нескольких портов. Если ваш контейнер предоставляет несколько портов, вы можете указать каждый из них отдельно, используяполе, чтобы различать их и контролировать их поведение индивидуально.