Сетевая модель Kubernetes изначально поддерживает кластерную сеть с несколькими хостами. Поды могут взаимодействовать друг с другом по умолчанию, независимо от того, на каком хосте они развернуты. Kubernetes полагается на то, что проект CNI соответствует следующим требованиям:
В кластере Kubernetes каждый под получает свой собственный IP адрес. Это означает, что приложения способны взаимодействовать друг с другом на уровне подов. Вся прелесть такой архитектуры состоит в том, что он предлагает чистую, обратно совместимую модель, в которой поды действуют как Виртуальные Машины (ВМ) или физические хосты с точки зрения выделения портов, именования, обнаружения службы, балансировки нагрузки, конфигурирования приложения и миграции. Контейнеры внутри одного и того же пода совместно используют один и тот же IP адрес. Маловероятно что аналогичные приложения, которые используют один и тот же порт (Apache и nginx) будут запущены внутри одного и того же самого пода. На практике, упакованные в одном и том же контейнере приложения обладают некой зависимостью или служат разным целям и именно разработчики приложения сверху собирают их воедино. Неким простым примером был бы такой, в котором в одном и том же поде имеется сервер HyperText Transfer Protocol (HTTP), либо некий контейнер nginx для обслуживания статических файлов и основное веб приложение для обслуживания динамического содержимого.
Назначаемые каждому поду IP адреса являются частными IP адресами или IP адресами кластера, которые не имеют открытого доступа. Следовательно, как же некое приложение становится общедоступным без конфликтов с прочими приложениями в этом кластере? Именно служба Kubernetes является тем, что выходит на поверхность из внутреннего приложения в общий доступ. В последующих разделах мы глубже погрузимся в рассмотрение понятия службы Kubernetes.
В нашей предыдущей схеме имеется k8s cluster, в котором присутствуют четыре приложения, запущенные в двух подах: Application A и Application B исполняются в Pod X и они совместно используют один и тот же IP адрес пода - 100.97.240.188 - в то время как они выполняют ожидание соответственно по порту 8080 и 9090. Аналогично, Application C и Application D запущены в Pod Y и выполняют ожидание, соответственно, в портах 8000 и 9000. Все эти четыре приложения общедоступны через следующие развёрнутые в открытый доступ службы Kubernetes: svc.a.com, svc.b.com, svc.c.com и svc.d.com. Такие поды (X и Y в данной схеме) могут быть развёрнуты в одном и том же узле исполнителя или реплицироваться в 1 000 узлов. Тем не менее, это не имеет отличий с точки зрения пользователя или службы. Хотя такое приведённое на схеме развёртывание совершенно не обычно, всё ещё требуется развёртывать более одного контейнера внутри одного и того же пода. Теперь настало время взглянуть на взаимодействие контейнеров внутри одного и того же пода.
Контейнеры внутри одного и того же пода совместно применяют тот же самый IP адрес пода. Обычно именно разработчики приложения сверху пакуют соответствующие образы контейнеров воедино и разрешают все возможные конфликты использования ресурсов, например, ожидание по порту.
Пространства имён выступают главной фундаментальной стороной современной технологии контейнеров. Хотя каждое их этих пространств имён является мощным и служит целям изоляции в различных ресурсах, не все из них приспособлены для контейнеров внутри одного и того же пода. Контейнеры внутри одного и того же пода совместно используют по крайней мере одно и то же пространство имён IPC и сетевое пространство имён; в результате, K8S требуется разрешать потенциальные конфликты при использовании портов. Будет иметься созданным интерфейс обратной петли (loopback), а также интерфейс виртуальной сети, причём с неким IP адресом, назначенным этому поду.
На этой схеме имеется один контейнер Pause, запущенный внутри этого пода помимо контейнеров A и B. Когда вы подключитесь через Secure Shell (SSH) к некому узлу кластера Kubernetes, и запустите внутри этого узла команду docker ps, вы обнаружите по крайней мере один контейнер, который был запущен при помощи команды pause. Эта команда pause приостанавливает данный текущий процесс вплоть до получения некого сигнала. В целом этот контейнер не выполняет ничего кроме пребывания в спящем состоянии. Несмотря на отсутствие активности этот контейнер Pause играет важную роль в своём поде. Он служит заполнителем для удержания пространства сетевых имён под все прочие контейнеры в одном и том же поде. Тем временем, контейнер Pause получает IP адрес для своего виртуального сетевого интерфейса, который будет применяться всеми прочими контейнерами для связи друг с другом и с внешним миром.