kubernetes pods что это
Знакомство с Kubernetes. Часть 3: Поды (Pods)
May 14, 2018 06:17 · 776 words · 4 minute read kubernetes pod
Чаще всего в Pod’ ах используются docker-контейнеры (что и не удивительно), но можно использовать и другие контейнеры (например, rkt от CoreOS).
Важно Kubernetes управляет Pod’ ами, а не контейнерами напрямую.
В кластере Kubernetes Pod’ ы используются двумя способами:
Pod’ ы спроектированы для поддержки множества взаимодействующих процессов (например, контейнеров), которые образуют отдельный сервис (единицу обслуживания). Контейнеры внутри Pod’ а автоматически размещаются и управляются на одной и той же физической (или виртуальной) ноде кластера. Контейнеры в Pod’ е могут совместно использовать ресурсы и зависимости, взаимодействовать друг с другом и определять, когда и как они будут завершаться.
К слову, группировка и запуск нескольких контейнеров в Pod’ е считается “продвинутым” вариантом использования, и применять этот шаблон нужно только при реальной необходимости. Например, у вас может быть контейнер с web-сервером, использующий файлы из общего (относительно Pod’ а) хранилища, и отдельный контейнер, который обновляет эти файлы из удаленного источника.
Pod’ ы предоставляют запущенным внутри контейнерам два типа общих ресурсов: сеть и хранилище.
Сеть
Каждому Pod’ у присваивается уникальный IP-адрес. Внутри Pod’ а каждый контейнер использует общее пространство имен (namespace) сети, включая IP-адрес и сетевые порты. Между собой внутри Pod’ а контейнеры взаимодействуют через localhost. При взаимодействии с объектами, находящимися за пределами Pod’ а, контейнеры “договариваются” между собой и координируют использование общих сетевых ресурсов (таких как порты).
Хранилище
Pod может определить набор общих томов (volumes) для хранения данных. Контейнеры внутри Pod’ а могут работать с этими томами и, таким образом, обмениваться данными между собой. Благодаря использованию томов, можно сохранить данные, если один из контейнеров Pod’ а (которому нужны эти данные для корректной работы) должен быть перезапущен. Время жизни томов совпадает с временем жизни самого Pod’ а.
Примечание Перезапуск контейнера внутри Pod’ а не следует путать с перезапуском самого Pod’ а.
Предложенный манифест (спецификацию) можно сохранить в файле single-example-pod.yml и запустить Pod с помощью утилиты командной строки kubectl :
Что такое Pods, Nodes, Containers и Clusters в Kubernetes
Kubernetes (k8s) очень стремительно становится новым стандартом для деплоймента и менеджмента вашего кода в клауде. Вместе с тем, сколько фич предоставляет k8s, для новичка наступает высокий порог входа в новую технологии.
Документация по k8s достаточно обширна и довольно сложно пройти ее всю. Именно по этому эта статья служит неким обобщением для того, чтобы разобрать основные модули kubernetes.
Hardware
Nodes
Если обсуждать про машину как «ноду», можем разбавить это слоем абстракции, мы можем представлять ее как некий набор CPU, RAM ресурсов которые можно использовать. Таким образом любая такая машина может заменить любую другую машину как k8s кластер.
Cluster
Хотя работа с отдельными нодами может быть полезной, это не путь kubernetes. В общем, вы должны думать о кластере в целом, а не беспокоиться о состоянии отдельных нодов.
В Kubernetes ноды объединяют свои ресурсы для формирования более мощной машины. Когда вы развертываете программы в кластере, он балансирует нагрузку по индивидуальным нодам для вас. Если какие-либо nodes добавляются или удаляются, кластер будет перемещаться по мере необходимости. Для программы или девелопера не должно быть важно, на каких машинах выполняется код в k8s. Можно сравнить такую систему с улием.
Persistent Volumes
Поскольку программы, работающие в вашем кластере, не гарантированно выполняются на определенной ноде, данные не могут быть сохранены в любом произвольном месте в файловой системе. Если программа пытается сохранить данные в файл, но затем перемещается на новую ноду, файл больше не будет там, где программа ожидает его. По этой причине традиционное локальное хранилище, связанное с каждой нодой, рассматривается как временный кэш для хранения программ, но нельзя ожидать, что любые данные, сохраненные локально, сохранятся.
Software
Контейнеры
Программы, работающие на Kubernetes, упаковуются в контейнеры. Контейнеры являются общепринятым стандартом, поэтому уже есть много готовых образов, которые можно развернуть в Kubernetes.
Контейнеризация позволяет вам создавать self-contained environments. Любая программа и все ее зависимости могут быть объединены в один файл и затем опубликованы в Интернете. Любой может загрузить контейнер и развернуть его в своей инфраструктуре с минимальными настройками. Создание контейнера может быть сделано и скриптом, позволяя строить CI/CD пайплайны.
Несколько программ могут быть развернуты в одном контейнере, но вы должны ограничить себя одним процессом на контейнер, если это вообще возможно. Лучше иметь много маленьких контейнеров, чем один большой. Если каждый контейнер имеет четкую направленность, обновления легче развертывать, а проблемы легче диагностировать.
В отличие от других систем, которые вы, возможно, использовали в прошлом, Kubernetes не запускает контейнеры напрямую; вместо этого он упаковывает один или несколько контейнеров в структуру более высокого уровня, называемую pod. Любые контейнеры в одном pod’e будут использовать одни и те же ресурсы и локальную сеть. Контейнеры могут легко связываться с другими контейнерами в том же pod’e, как если бы они находились на одной машине, сохраняя степень изоляции от других pod’ов.
Pod’ы используются как единица репликации в Kubernetes. Если ваше приложение становится слишком популярным, и один экземпляр модуля не может нести нагрузку, Kubernetes можно настроить для развертывания новых реплик вашего модуля в кластере по мере необходимости. Даже если не под большой нагрузкой, в продакшинев любое время можно запустить несколько копий модуля в любое время, чтобы обеспечить балансировку нагрузки и устойчивость к сбоям.
Pod’ы могут содержать несколько контейнеров, но вы должны ограничивать их количество, когда это возможно. Поскольку контейнеры масштабируются как единое целое, все контейнеры в паке должны масштабироваться вместе, независимо от их индивидуальных потребностей. Это приводит к потраченным впустую ресурсам и дорогому счету. Чтобы решить эту проблему, Pod’ы должны оставаться меньше на сколько это возможно, обычно вмещая только основной процесс и его тесно связанные вспомогательные контейнеры (эти вспомогательные контейнеры обычно называют Side-cars).
Deployments
Основная цель юзать подход с deployment состоит в том, чтобы настроить, сколько реплик pod’а должно работать одновременно. Когда развертывание добавляется в кластер, оно автоматически деплоит требуемое количество pod’ов и отслеживает их. Если pod умирает, deployment автоматически пересоздает его.
Используя deployment, вам не нужно иметь дело с подами вручную. Вы можете просто объявить желаемое состояние системы, и оно будет управляться автоматически.
Ingress
Используя описанные выше концепции, вы можете создать кластер нодов и запустить деплоймент подов в кластере. Однако есть еще одна проблема, которую необходимо решить: разрешить внешний трафик вашему приложению. По умолчанию Kubernetes обеспечивает изоляцию между модулями и внешним миром. Если вы хотите общаться с сервисом, работающим в pod, вам нужно открыть канал для связи. Это называется Ingress.
Есть несколько способов добавить ingress в ваш кластер. Наиболее распространенными способами являются добавление либо ingress controller, либо LoadBalancer. Описание различий и что лучше выбрать выходит за рамки этой статьи, но вы должны держать в голове что вам нужно разобратся с доступом к сервису, если вы хотите работать с k8s.
Сети Kubernetes: поды
Материал, перевод которого мы сегодня публикуем, посвящён особенностям сетевого взаимодействия подов Kubernetes. Он предназначен для тех, у кого уже есть некоторый опыт работы с Kubernetes. Если вы пока не очень хорошо разбираетесь в Kubernetes, то вам, вероятно, прежде чем читать этот материал, полезно будет взглянуть на это руководство по Kubernetes, где работа с данной платформой рассматривается в расчёте на начинающих.
Контейнер Docker, запущенный на локальной машине
Два контейнера Docker, запущенные на локальной машине
Всё это хорошо, но это не описывает пока то, что мы, в применении к подам Kubernetes, называем «разделяемым сетевым стеком». К счастью, пространства имён отличаются большой гибкостью. Docker может запустить контейнер, и, вместо того, чтобы создавать для него новый виртуальный сетевой интерфейс, сделать так, чтобы он использовал бы, совместно с другими контейнерами, существующий интерфейс. При таком подходе нам придётся изменить вышеприведённую схему так, как показано ниже.
Контейнеры используют общий сетевой интерфейс
Контейнеры в гипотетическом поде
Сеть подов
Один под, полный контейнеров, это строительный блок некоей системы, но пока ещё не сама эта система. В основе архитектуры Kubernetes лежит требование, в соответствии с которым у подов должна быть возможность взаимодействовать с другими подами вне зависимости от того, выполняются ли они на одном и том же компьютере или на разных машинах. Для того чтобы узнать о том, как всё это устроено, нам нужно перейти на более высокий уровень абстракции и поговорить о том, как в кластере Kubernetes работают узлы. Здесь мы затронем тему сетевой маршрутизации и маршрутов. Данной темы в материалах, подобных этому, нередко избегают, считая её слишком сложной. Непросто найти понятное и не слишком длинное руководство по IP-маршрутизации, но если вам хочется взглянуть на краткий обзор этой проблемы — можете взглянуть на этот материал.
Кластер Kubernetes состоит из одного узла или из большего количества узлов. Узел — это хост-система, физическая или виртуальная, которая содержит разные программные средства и их зависимости (речь идёт, в основном, о Docker), а также несколько системных компонентов Kubernetes. Узел подключён к сети, что позволяет ему обмениваться данными с другими узлами кластера. Вот как может выглядеть простой кластер, состоящий из двух узлов.
Простой кластер, состоящий из двух узлов
В целом же можно отметить, что вам, обычно, не придётся размышлять о том, как именно работает сеть подов. Когда под обменивается данными с другим подом, чаще всего это происходит посредством сервисов Kubernetes. Это — нечто вроде программно определяемых прокси. Но сетевые адреса подов появляются в логах. В некоторых ситуациях, в частности, при отладке, вам может понадобиться явным образом задавать правила маршрутизации в сетях подов. Например, трафик, покидающий под Kubernetes, привязанный к любому адресу в диапазоне 10.0.0.0/8, не обрабатывается по умолчанию с помощью NAT. Поэтому если вы взаимодействуете с сервисами, находящимися в другой частной сети, имеющей тот же диапазон адресов, вам может понадобиться настроить правила маршрутизации, которые позволят организовать правильную доставку пакетов.
Итоги
Сегодня мы поговорили о подах Kubernetes и об особенностях их сетевого взаимодействия. Надеемся, этот материал поможет вам сделать правильные шаги в направлении реализации сложных сценариев взаимодействия подов в сетях Kubernetes.
Уважаемые читатели! Эта статья является первым материалом цикла, посвящённого сетям Kubernetes. Вторая часть этого цикла уже переведена. Мы размышляем о том, нужно ли переводить третью часть. Просим вас высказаться об этом в комментариях.
Так что же такое pod в Kubernetes?
Прим. перев.: Эта статья продолжает цикл материалов от технического писателя из Google, работающего над документацией для Kubernetes (Andrew Chen), и директора по software engineering из SAP (Dominik Tornow). Их цель — доступно и наглядно объяснить основы организации Kubernetes. В прошлый раз мы переводили статью про high availability, а теперь речь пойдет про такое базовое понятие в Kubernetes, как pod.
Kubernetes — движок оркестровки контейнеров, созданный для запуска контейнеризированных приложений на множестве узлов, которые обычно называют кластером. В этих публикациях мы используем подход системного моделирования с целью улучшить понимание Kubernetes и его нижележащих концепций. Читающим рекомендуется уже иметь базовое представление о Kubernetes.
Pods (Поды) — базовые строительные блоки Kubernetes, однако даже опытные пользователи Kubernetes не всегда могут объяснить, что же это такое.
Данная публикация предлагает лаконичную мысленную модель, которая проливает свет на определяющие характеристики pod’ов Kubernetes. Ради этой краткости пришлось опустить некоторые другие особенности Pod’ов, такие как liveness и readiness probes, разделение ресурсов (включая появившееся недавно namespace sharing — прим. перев.), работу с сетью.
Определение
Pod представляет собой запрос на запуск одного или более контейнеров на одном узле.
Pod определяется представлением запроса на запуск (execute) одного или более контейнеров на одном узле, и эти контейнеры разделяют доступ к таким ресурсам, как тома хранилища и сетевой стек.
Однако в обиходе термин «pod» может употребляться и в смысле этого запроса, и в смысле совокупности контейнеров, которые запускаются в ответ на запрос. Поэтому в публикации мы будем использовать слово «pod», когда говорим о запросе, а для второго случая — употреблять выражение «набор контейнеров».
Pod’ы считаются базовыми строительными блоками Kubernetes, потому что все рабочие нагрузки в Kubernetes — например, Deployments, ReplicaSets и Jobs — могут быть выражены в виде pod’ов.
Pod — это один и единственный объект в Kubernetes, который приводит к запуску контейнеров. Нет pod’а — нет контейнера!
Схема 1. Deployment, ReplicaSet, pod и контейнеры
Архитектура Kubernetes
Схема 2. Pod’ы, планировщик (Scheduler) и Kubelet
На этой иллюстрации выделены соответствующие объекты и компоненты. Pod’ы представлены как Kubernetes Pod Objects, а работой с ними занимаются:
Объекты Kubernetes
Схема 3. Объекты Kubernetes
На этой иллюстрации показаны объекты Kubernetes, ответственные за работу с pod’ом:
Binding Object привязывает Pod Object к Node Object, т.е. назначает pod на узел для последующего запуска.
Node Object представляет узел в кластере Kubernetes.
Обработка pod’а
Схема 4. Обработка pod’а
Когда pod создан пользователем или контроллером вроде ReplicaSet Controller или Job Controller, Kubernetes обрабатывает pod в два этапа:
Планирование pod’а
Схема 5. Управляющий цикл планировщика Kubernetes
Задача планировщика (Scheduler) в Kubernetes — запланировать pod, то есть назначить ему подходящий узел в кластере Kubernetes для последующего запуска.
Связывание объекта pod’а с объектом узла
Pod назначается узлу (или связывается с ним) тогда и только тогда, когда есть объект связывания (binding), у которого:
Запуск pod’а
Схема 6. Управляющий цикл Kubelet
Задача Kubelet — запустить pod, что по сути означает запуск набора контейнеров pod’а. Запуск pod’а Kubelet’ом происходит в две фазы: инициализацию и основную стадию.
Как правило, набор контейнеров на фазе инициализации осуществляет подготовительные работы, такие как подготовку необходимой структуры директорий и файлов. А набор контейнеров на основной фазе выполняет уже «самые главные» задачи.
В обиходе же, хотя это и не совсем корректно, термин «pod» зачастую подразумевает набор контейнеров на основной фазе или же ещё более узкое значение «самого главного» контейнера основной фазы.
Схема 7.1. Запуск pod’а, фаза инициализации (init) и основная фаза (main)
Схема 7.2. Запуск pod’а, подробности этого процесса
У политики рестарта pod’а различная семантика для init-контейнеров и основных контейнеров: если запуск init-контейнеров обязан привести к завершению, то основные контейнеры могут и не завершаться.
Политика рестарта для init-контейнера
Init-контейнер будет перезапущен (т.е. повлечёт за собой запуск нового контейнера с такой же спецификацией) при завершении своей работы только при выполнении следующих условий:
Основной контейнер будет перезапущен (т.е. повлечёт за собой запуск нового контейнера с такой же спецификацией) при завершении своей работы только при выполнении следующих условий:
На иллюстрации показана возможная временная шкала запуска pod’а с двумя спецификациями init-контейнеров и двумя спецификациями основных контейнеров. Также она показывает создание (в соответствии с политикой рестарта) нового контейнера Main Container 1.2 после проблемы с запуском Main Container 1.1.
Фазы pod’а
Схема 9. Взаимодействие Kubelet с объектом pod’а и исполняемой средой контейнера (container runtime)
Фаза pod’а — это проекция состояния контейнеров из набора контейнеров, она зависит от:
Ожидание (Pending)
Фаза Pending
Pod находится в фазе ожидания тогда и только тогда, когда:
Работает (Running)
Фаза Running
Pod находится в фазе работы тогда и только тогда, когда:
Успех (Success)
Фаза Success
Pod находится в фазе успеха тогда и только тогда, когда:
Отказ (Failure)
Фаза Failure
Pod находится в фазе отказа тогда и только тогда, когда:
Неизвестно (Unknown)
В дополнение к описанным выше фазам pod может находиться в неизвестной фазе, что свидетельствует о невозможности определить его текущую фазу.
Сбор мусора для pod’ов
Схема 11. Управляющий цикл сборщика мусора для pod’ов (Pod Garbage Collector)
После того, как pod был запланирован и запущен, специальный контроллер в Kubernetes — Pod Garbage Collector Controller — отвечает за удаление объектов pod’ов из хранилища объектов Kubernetes Object Store.
Заключение
Pod — базовый строительный блок Kubernetes: pod определяется как представление запроса на запуск одного или более контейнеров на одном узле. После того, как pod создан, Kubernetes обрабатывает его в два этапа: сначала планировщик (Scheduler) планирует pod, а затем — Kubelet запускает его. На протяжении своего жизненного цикла pod проходит через разные фазы, сообщая о состоянии — или, точнее говоря, о состоянии своего набора контейнеров — пользователю и системе.
Kubernetes (k8s) Tutorial — pod, кластер, node, yaml, helm
Docker и Docker-Compose Tutorial (Контейнеры, install, run, image, daemon, etc.)
Краткое введение в терминологию и архитектуру — Kubernetes (k8s) Tutorial
Kubernetes (или K8S) — это платформа с открытым исходным кодом, которая запускает контейнерные приложения. Kubernetes стал стандартом в сфере devops для масштабного развертывания контейнерных приложений в частных, общедоступных и гибридных облачных средах.
Kubernetes предоставляет базовый ресурс под названием Pod. Pod — это самая маленькая развертываемая единица в Kubernetes, которая на самом деле является оболочкой для контейнеров. Pod может иметь один или несколько контейнеров, и вы можете передать различную конфигурацию контейнеру(-ам), используя конфигурацию модуля, например, передачу переменных среды, монтируемых томов, проверки работоспособности и т.д.
Архитектура Kubernetes
На очень высоком уровне Kubernetes предоставляет набор динамически масштабируемых хостов для выполнения рабочих нагрузок с использованием контейнеров и использует набор управляющих хостов, называемых мастерами, для предоставления API для управления всей контейнерной инфраструктурой. Рабочие нагрузки могут включать в себя долго работающие службы, пакетные задания и демонов, специфичных для контейнеров. Все хосты контейнеров соединены вместе с помощью оверлейной сети для обеспечения маршрутизации от контейнера к контейнеру. Приложения, развернутые в Kubernetes, динамически обнаруживаются в сети кластера и могут быть доступны во внешних сетях с помощью традиционных балансировщиков нагрузки.
Чтобы начать работать с Kubernetes, можно использовать Minikube. Minikube — это упрощённая реализация Kubernetes, которая создает виртуальную машину на вашем локальном компьютере и разворачивает простой кластер с одним узлом. Minikube доступен для Linux, macOS и Windows. В CLI-инструменте Minikube есть основные операции для инициализации кластера, включая запуск, завершение, просмотра состояния и удаления кластера.
Модель развертывания приложений
На приведенном выше рисунке показана модель развертывания приложений высокого уровня в Kubernetes. Он использует ресурс ReplicaSet для оркестровки контейнеров.
ReplicaSet можно рассматривать как файл метаданных на основе YAML или JSON, который определяет образы контейнеров, порты, количество реплик, проверки работоспособности активации, проверки работоспособности, переменные среды, монтирование томов, правила безопасности и т.д.
Контейнеры всегда создаются в Kubernetes как группы, называемые подами (pod), которые являются Kubernetes metadata definition или resource. Каждый pod позволяет совместно использовать файловую систему, сетевые интерфейсы, пользователей операционной системы и т.д.
Основные термины, которые нужны для понимания Kubernetes
master — объект, ответственный за управление состоянием кластера. Он состоит из 3-х основных компонентов:
Kubernetes Helm
Helm — это менеджер пакетов для Kubernetes, аналог NPM или YARN. Однако это не только диспетчер пакетов, это еще и средство управления развертыванием Kubernetes. Для простоты Helm Chart можно сравнить с Docker Image.
Helm chart— это просто набор файлов шаблонов YAML, организованных в определенную структуру каталогов.