Прочитав этот пост, вы получите четкое представление о преимуществах использования kubernetes PODS.

Прежде чем мы перейдем к пониманию POD, предположим, что следующее уже настроено:

  • Приложение уже разработано и встроено в образы Docker, и оно доступно в репозитории Docker, таком как Docker hub, поэтому Kubernetes может его загрузить.
  • Кластер Kubernetes уже настроен и работает, это может быть настройка с одним узлом или настройка с несколькими узлами,
  • Все службы должны быть в рабочем состоянии.

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

Однако kubernetes не развертывает контейнеры непосредственно на рабочих узлах.

Контейнеры инкапсулируются в объект Kubernetes, известный как POD. POD - это отдельный экземпляр приложения.

POD - это самый маленький объект, который вы можете создать в кубернетах.

Пример

Проиллюстрируем простейшие случаи, когда у вас есть кластер Kubernetes с одним узлом и один экземпляр вашего приложения, работающий в одном контейнере докера, инкапсулированном в POD:

Что делать, если количество пользователей, обращающихся к вашему приложению, увеличивается и вам необходимо масштабировать приложение?

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

А где бы вы развернули дополнительные экземпляры?

Вызываем ли мы новый экземпляр контейнера в том же POD?

No.

Мы создаем новый POD вместе с новым экземпляром того же приложения.

Теперь у нас есть два экземпляра нашего веб-приложения, работающие на разных POD в одной системе или узле Kubernetes.

Что, если база пользователей продолжит расти, а ваш текущий узел не будет иметь достаточной емкости?

В этом случае вы всегда можете развернуть дополнительные POD на новом узле кластера.

К кластеру будет добавлен новый узел, чтобы увеличить физическую емкость кластера.

Итак, я пытаюсь проиллюстрировать, что POD обычно имеют взаимно однозначные отношения с контейнерами, в которых выполняется ваше приложение.

  • Чтобы увеличить масштаб, вы создаете новые POD
  • Чтобы уменьшить масштаб, вы удаляете существующие POD.

Вы не добавляете дополнительные контейнеры к существующему модулю для масштабирования приложения.

Мы обсудим, как мы реализуем балансировку нагрузки между контейнерами, в более поздней публикации. Пока мы только пытаемся понять основные концепции.

Ограничены ли мы наличием одного контейнера в одном POD?

No.

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

Как мы уже обсуждали ранее, если мы намеревались масштабировать наше приложение, нам нужно было бы создать дополнительные POD.

Но иногда у вас может быть сценарий, когда у вас есть вспомогательный контейнер, который может выполнять какую-то вспомогательную задачу для нашего веб-приложения, например:

  • обработка введенных пользователем данных
  • обработка файла, загруженного пользователем

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

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

Поскольку они являются частью одного POD. Два контейнера также могут связываться друг с другом напрямую, называя друг друга «localhost», поскольку они совместно используют одно и то же сетевое пространство имен.

Кроме того, они могут легко использовать одно и то же пространство для хранения.

Давайте на мгновение исключим кубернетов из нашего обсуждения и поговорим о простых контейнерах докеров.

Предположим, мы разрабатываем процесс или сценарий для развертывания нашего приложения на хосте докеров. Затем мы сначала просто развернем наше приложение с помощью команды:

docker run python-app

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

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

docker run python-app 
docker run python-app
docker run python-app

Это прекрасно работает, и мы все счастливы.

Когда-нибудь в будущем наше приложение будет развиваться и претерпевать архитектурные изменения, расти и усложняться.

Теперь у нас есть новый вспомогательный контейнер, который помогает нашему веб-приложению обрабатывать или подбирать данные из других источников.

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

  • Нам нужно будет самостоятельно установить сетевое соединение между этими контейнерами, используя ссылки и настраиваемые сети.
  • Нам нужно будет создать общие тома и разделить их между контейнерами.
  • Нам также нужно будет сохранить карту этого. И, что наиболее важно, нам нужно будет отслеживать состояние контейнера приложения и, когда он умирает, вручную убить вспомогательный контейнер, так как он больше не нужен.
  • Когда будет развернут новый контейнер, нам также потребуется развернуть новый вспомогательный контейнер.

С помощью POD Kubernetes делает все это за нас автоматически.

Нам просто нужно определить, из каких контейнеров состоит POD, и контейнеры в POD по умолчанию будут иметь доступ к одному и тому же хранилищу, одному и тому же сетевому пространству имен и той же судьбе, что и они, будут создаваться вместе и уничтожаться вместе.

Даже если бы наше приложение не было таким сложным и мы могли бы жить с одним контейнером, kubernetes по-прежнему требует, чтобы вы создавали POD.

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

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

Ранее мы узнали о команде kubectl run.

kubectl run nginx

На самом деле эта команда развертывает контейнер докеров, создавая POD. Поэтому сначала он автоматически создает POD и развертывает экземпляр образа докера nginx.

Но откуда он получает изображение приложения?

Для этого вам нужно указать имя изображения с помощью параметра - image.

kubectl run nginx --image nginx

Образ nginx загружается из репозитория Docker Hub. Docker hub - это общедоступный репозиторий, в котором хранятся последние образы Docker различных приложений.

Вы можете настроить kubernetes для извлечения образа из общедоступного центра докеров или частного репозитория в организации.

Теперь, когда у нас есть созданный POD, как мы можем увидеть список доступных POD?

kubectl get pods

Команда kubectl get PODs помогает нам увидеть список модулей в нашем кластере.

Также помните, что мы на самом деле не обсуждали концепции того, как пользователь может получить доступ к веб-серверу nginx.

Итак, в текущем состоянии мы не сделали веб-сервер доступным для внешних пользователей.

Однако вы можете получить к нему доступ изнутри узла.

Пока мы просто посмотрим, как развернуть POD, а в расширенном посте мы узнаем, как сделать сервис доступным для конечных пользователей.

Изначально опубликовано в Моем блоге.