Что такое под в кубере

Что такое Pods, Nodes, Containers и Clusters в Kubernetes

Kubernetes (k8s) очень стремительно становится новым стандартом для деплоймента и менеджмента вашего кода в клауде. Вместе с тем, сколько фич предоставляет k8s, для новичка наступает высокий порог входа в новую технологии.

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

Hardware

Nodes

Node — это самая маленькая единица ‘computing hardware в k8s. Это представление одной машины в вашем кластере. В большинстве производственных систем нодой, корее всего, будет либо физическая машина в датацентре, либо виртуальная машина, размещенная на облачном провайдере, таком как Google Cloud Platform, Azure, AWS. Однако, вы можете сделать ноду практически из чего угодно (например Rasbery PI).

Если обсуждать про машину как «ноду», можем разбавить это слоем абстракции, мы можем представлять ее как некий набор CPU, RAM ресурсов которые можно использовать. Таким образом любая такая машина может заменить любую другую машину как k8s кластер.

Cluster

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

В Kubernetes ноды объединяют свои ресурсы для формирования более мощной машины. Когда вы развертываете программы в кластере, он балансирует нагрузку по индивидуальным нодам для вас. Если какие-либо nodes добавляются или удаляются, кластер будет перемещаться по мере необходимости. Для программы или девелопера не должно быть важно, на каких машинах выполняется код в k8s. Можно сравнить такую систему с улием.

Persistent Volumes

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

Для постоянного хранения данных Kubernetes использует Persistent Volumes. Хотя ресурсы ЦП и ОЗУ всех нодов эффективно объединяются и управляются кластером, постоянного хранение файлов — нет. Вместо этого локальные или облачные диски могут быть подключены к кластеру как постоянный том (Persistent Volumes). Это можно рассматривать как подключение внешнего жесткого диска к кластеру. Persistent Volumes предоставляют файловую систему, которая может быть подключена к кластеру без привязки к какому-либо конкретному ноду.

Software

Контейнеры

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

Контейнеризация позволяет вам создавать self-contained environments. Любая программа и все ее зависимости могут быть объединены в один файл и затем опубликованы в Интернете. Любой может загрузить контейнер и развернуть его в своей инфраструктуре с минимальными настройками. Создание контейнера может быть сделано и скриптом, позволяя строить CI/CD пайплайны.

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

Pods

В отличие от других систем, которые вы, возможно, использовали в прошлом, Kubernetes не запускает контейнеры напрямую; вместо этого он упаковывает один или несколько контейнеров в структуру более высокого уровня, называемую pod. Любые контейнеры в одном pod’e будут использовать одни и те же ресурсы и локальную сеть. Контейнеры могут легко связываться с другими контейнерами в том же pod’e, как если бы они находились на одной машине, сохраняя степень изоляции от других pod’ов.

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

Pod’ы могут содержать несколько контейнеров, но вы должны ограничивать их количество, когда это возможно. Поскольку контейнеры масштабируются как единое целое, все контейнеры в паке должны масштабироваться вместе, независимо от их индивидуальных потребностей. Это приводит к потраченным впустую ресурсам и дорогому счету. Чтобы решить эту проблему, Pod’ы должны оставаться меньше на сколько это возможно, обычно вмещая только основной процесс и его тесно связанные вспомогательные контейнеры (эти вспомогательные контейнеры обычно называют Side-cars).

Deployments

Хотя в Kubernetes pod являются базовой единицей вычислений, они, как правило, не запускаются напрямую в кластере. Вместо этого pod обычно менеджится еще одним уровнем абстракции — deployment.

Основная цель юзать подход с deployment состоит в том, чтобы настроить, сколько реплик pod’а должно работать одновременно. Когда развертывание добавляется в кластер, оно автоматически деплоит требуемое количество pod’ов и отслеживает их. Если pod умирает, deployment автоматически пересоздает его.

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

Ingress

Используя описанные выше концепции, вы можете создать кластер нодов и запустить деплоймент подов в кластере. Однако есть еще одна проблема, которую необходимо решить: разрешить внешний трафик вашему приложению. По умолчанию Kubernetes обеспечивает изоляцию между модулями и внешним миром. Если вы хотите общаться с сервисом, работающим в pod, вам нужно открыть канал для связи. Это называется Ingress.

Есть несколько способов добавить ingress в ваш кластер. Наиболее распространенными способами являются добавление либо ingress controller, либо LoadBalancer. Описание различий и что лучше выбрать выходит за рамки этой статьи, но вы должны держать в голове что вам нужно разобратся с доступом к сервису, если вы хотите работать с k8s.

Так что же такое 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, а работой с ними занимаются:

• планировщик (Scheduler),
• Kubelet.

Объекты Kubernetes

Схема 3. Объекты Kubernetes

На этой иллюстрации показаны объекты Kubernetes, ответственные за работу с pod’ом:

• собственно объект pod’а (Pod Object);
• объект связывания (Binding Object);
• объект узла (Node Object).

Binding Object привязывает Pod Object к Node Object, т.е. назначает pod на узел для последующего запуска.

Node Object представляет узел в кластере Kubernetes.

Обработка pod’а

Схема 4. Обработка pod’а

Когда pod создан пользователем или контроллером вроде ReplicaSet Controller или Job Controller, Kubernetes обрабатывает pod в два этапа:

• Scheduler планирует pod,
• Kubelet запускает pod.

Планирование pod’а

Схема 5. Управляющий цикл планировщика Kubernetes

Задача планировщика (Scheduler) в Kubernetes — запланировать pod, то есть назначить ему подходящий узел в кластере Kubernetes для последующего запуска.

Связывание объекта pod’а с объектом узла

Pod назначается узлу (или связывается с ним) тогда и только тогда, когда есть объект связывания (binding), у которого:

• пространство имён равняется пространству имён pod’а,
• название равняется названию pod’а,
• тип цели равняется Node ,
• название цели равняется названию узла.

Запуск pod’а

Схема 6. Управляющий цикл Kubelet

Задача Kubelet — запустить pod, что по сути означает запуск набора контейнеров pod’а. Запуск pod’а Kubelet’ом происходит в две фазы: инициализацию и основную стадию.

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

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

Схема 7.1. Запуск pod’а, фаза инициализации (init) и основная фаза (main)

Во время инициализации Kubelet последовательно запускает контейнеры в соответствии со спецификациями pod’а .Spec.InitContainers и в заданном в списке порядке. Для успешного запуска pod’а и с учётом политики рестарта, его init-контейнеры должны запуститься и успешно завершиться.

Во время основной фазы Kubelet одновременно запускает контейнеры в соответствии со спецификациями pod’а .Spec.Containers . Здесь уже для успешного запуска pod’а и с учётом политики рестарта, его основные (main) контейнеры должны быть запущены и либо успешно завершиться, либо работать неограниченное время.

Схема 7.2. Запуск pod’а, подробности этого процесса

В случае сбоя у контейнера, когда контейнер прекращает работу с отличным от нуля (0) кодом возврата (exit code), Kubelet может перезапустить контейнер в соответствии с политикой рестарта pod’а. Эта политика имеет одно из следующих значений: Always , OnFailure , Never .

У политики рестарта pod’а различная семантика для init-контейнеров и основных контейнеров: если запуск init-контейнеров обязан привести к завершению, то основные контейнеры могут и не завершаться.

Политика рестарта для init-контейнера

Init-контейнер будет перезапущен (т.е. повлечёт за собой запуск нового контейнера с такой же спецификацией) при завершении своей работы только при выполнении следующих условий:

• exit-код контейнера сообщает об ошибке и
• политика рестарта pod’а имеет значение Always или OnFailure .

Политика рестарта для основного (main) контейнера

Основной контейнер будет перезапущен (т.е. повлечёт за собой запуск нового контейнера с такой же спецификацией) при завершении своей работы только при выполнении следующих условий:

• политика рестарта определена как Always или
• политика рестарта определена как OnFailure и exit-код контейнера сообщает об ошибке.

Схема 8. Пример временной шкалы с красной точкой, символизирующей сбой у контейнера

На иллюстрации показана возможная временная шкала запуска pod’а с двумя спецификациями init-контейнеров и двумя спецификациями основных контейнеров. Также она показывает создание (в соответствии с политикой рестарта) нового контейнера Main Container 1.2 после проблемы с запуском Main Container 1.1.

Фазы pod’а

Схема 9. Взаимодействие Kubelet с объектом pod’а и исполняемой средой контейнера (container runtime)

Kubelet получает спецификации pod’а .Spec.InitContainers и .Spec.Containers , запускает указанный набор контейнеров и соответствующим образом обновляет значения pod’а .Status.InitContainerStatuses и .Status.ContainerStatuses .

Kubelet сворачивает .Status.InitContainerStatuses и .Status.ContainerStatuses pod’а в одно значение — .Status.Phase .

Фаза pod’а — это проекция состояния контейнеров из набора контейнеров, она зависит от:

• состояний и exit-кодов init-контейнеров,
• состояний и exit-кодов основных контейнеров.

Схема 10. Фазы pod’а

Ожидание (Pending)

Фаза Pending

Pod находится в фазе ожидания тогда и только тогда, когда:

• ни один из init-контейнеров pod’а не находится в состоянии Terminated с ошибкой ( Failure );
• все основные контейнеры pod’а находятся в состоянии Waiting .

Работает (Running)

Фаза Running

Pod находится в фазе работы тогда и только тогда, когда:

• все init-контейнеры pod’а находятся в состоянии Terminated с успехом ( Success );
• хотя бы один основной контейнер pod’а находится в состоянии Running ;
• ни один из основных контейнеров pod’а не находится в состоянии Terminated с ошибкой ( Failure ).

Успех (Success)

Фаза Success

Pod находится в фазе успеха тогда и только тогда, когда:

• все init-контейнеры pod’а находятся в состоянии Terminated с успехом ( Success );
• все основные контейнеры pod’а находятся в состоянии Terminated с успехом ( Success ).

Отказ (Failure)

Фаза Failure

Pod находится в фазе отказа тогда и только тогда, когда:

• все контейнеры pod’а находятся в состоянии Terminated ;
• хотя бы один из контейнеров pod’а находятся в состоянии Terminated с ошибкой ( Failure ).

Неизвестно (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 проходит через разные фазы, сообщая о состоянии — или, точнее говоря, о состоянии своего набора контейнеров — пользователю и системе.

P.S. от переводчика

Читайте также в нашем блоге:

• «Kubernetes: жизнь пода»;
• «Как обеспечивается высокая доступность в Kubernetes»;
• «Как на самом деле работает планировщик Kubernetes?»;
• «Что происходит в Kubernetes при запуске kubectl run?» Часть 1 и часть 2;
• «Наш опыт с Kubernetes в небольших проектах» (видео доклада, включающего в себя знакомство с техническим устройством Kubernetes).

Kubernetes

Kubernetes (K8s) — это программная платформа для автоматического управления контейнеризованными приложениями. Она предлагает базовые механизмы для их развертывания, масштабирования и поддержки. Система имеет открытый исходный код и быстро растущую экосистему.

«IT-специалист с нуля» наш лучший курс для старта в IT

Kubernetes разработала компания Google на основе более ранней системы управления кластерами Borg. Первое название — Project Seven, в честь героини сериала Star Trek. Аллюзией на нее также являются семь ручек на штурвале логотипа проекта. Современное название отсылает к греческому слову «рулевой». Исходный код системы был представлен в 2014 году. После выхода версии 1.0 в 2015 году Google в сотрудничестве с Linux Foundation основала фонд Cloud Native Computing Foundation (CNCF) и передала ему Kubernetes в рамках начального технологического вклада.

Что представляет собой контейнеризация

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

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

Виртуальная машина. Это программная или аппаратная эмуляция работы одной или нескольких гостевых платформ (quest) на платформе-хозяине (host). Виртуальная машина имитирует компоненты аппаратного обеспечения или целый ПК с отдельной ОС. Это позволило эффективнее разграничить ресурсы физического сервера между ВМ и масштабировать их работу.

Контейнер. По сути, это усовершенствованный вариант виртуальной машины с максимальной изоляцией в рамках одной операционной системы. В отличие от обычной ВМ, он не связан с базовой аппаратной инфраструктурой и может легко переноситься между облаками и несколькими ОС.

Преимущества контейнеризации:

• простота и гибкость развертывания приложений по сравнению с ВМ;
• непрерывность создания, интеграции и развертывания контейнера с возможностью быстро откатить изменения;
• создание контейнеров приложений в процессе сборки/релиза и отделение приложения от аппаратной инфраструктуры;
• идентичность среды разработки и тестирования на сервере и терминалах разработчика (ноутбуках, ПК);
• возможность переносить приложения между облаками и ОС — Ubuntu, RHEL, CoreOS, on-prem, Google Kubernetes Engine и т.д.;
• разделение приложений на изолированные, распределенные, гибкие микросервисы с динамическим развертыванием и управлением.

Профессия / 8 месяцев
IT-специалист с нуля

Попробуйте 9 профессий за 2 месяца и выберите подходящую вам

Как работает Kubernetes

Сами по себе контейнеры — это способ развертывания и запуска приложений на сервере. Если контейнеров несколько, важно настроить их совместную работу так, чтобы они не отбирали друг у друга ресурсы аппаратной платформы и эффективно их расходовали. Кроме развертывания и запуска контейнеров, разработчику нужно периодически исправлять ошибки. Делать это вручную очень сложно. Kubernetes позволяет автоматизировать большинство процессов. Это называется «оркестрация контейнеров». Платформа может масштабировать приложения и обрабатывать возникающие ошибки, распределять ресурсы, поддерживать баланс между контейнерами и т.д. Но K8s работает не один. Чтобы он мог запустить приложения и службы в контейнерах, каждый должен быть оснащен средой выполнения. Это может быть Docker, rkt или runc.

Kubernetes действует на уровне логики, а не аппаратного обеспечения, по принципу «ведущий — ведомый». Управление системой основано на двух подходах:

• декларативном — разработчик задает цели, а не пути их достижения, которые система автоматически выбирает сама;
• императивном — разработчик может распоряжаться ресурсами с помощью команд «Создать», «Изменить», «Удалить».

Возможности Kubernetes

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

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

Оркестрация хранилища. С помощью Kubernetes разработчик может выбрать систему хранения: локальное хранилище, облако и т.д. Платформа автоматически создаст ее и настроит под потребности проекта.

Курс для новичков «IT-специалист
с нуля» – разберемся, какая профессия вам подходит, и поможем вам ее освоить

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

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

Безопасность и конфиденциальность. Kubernetes может сохранять и контролировать конфиденциальные данные (пароли, ключи SSH, OAuth-токены), распределять права доступа к системе. Обновление и развертывание приложений не затрагивает образы контейнеров и не раскрывает секретные сведения в конфигурации стека.

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

Основные объекты кластера Kubernetes

Объекты — сущности, которые в архитектуре Kubernetes используются для представления состояния кластера.

Nodes (ноды, узлы)

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

Nodes бывают двух типов:

1. Master (мастер-нода) — узел, управляющий всем кластером. Он следит за остальными нодами и распределяет между ними нагрузку с помощью менеджера контроллеров (controller manager) и планировщика (scheduler). Как правило, мастер-нода занимается только управлением и не берет на себя рабочие нагрузки. Для повышения отказоустойчивости существует несколько мастер-нод.
2. Worker (рабочие ноды) — узлы, на которых работают контейнеры. В зависимости от параметров ноды (объема памяти и центрального процессора) на одном узле может работать много контейнеров. Чем больше рабочих узлов, тем больше приложений можно запустить. Также количество влияет на отказоустойчивость кластера, потому что при выходе из строя одной ноды нагрузка переносится на другие.

Pods (Поды)

Это абстрактный объект Kubernetes, представляющий собой «обертку» для одного или группы контейнеров. Контейнеры в поде запускаются и работают вместе, имеют общие сетевые ресурсы и хранилище. Kubernetes не управляет контейнерами напрямую, он собирает их в поды и работает с ими.

DevOps-инженер

Помогайте компаниям быстрее выпускать качественный продукт

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

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

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

Обычно Kubernetes сам создает поды. Для этого он должен знать образы, требования к узлам и пр. В этом помогают контроллеры, например Deployments.

Controllers (контроллеры)

Контроллеры — это общее название средств управления, следящих за кластером и поддерживающих желаемое его состояние. Существует несколько типов контроллеров:

• Deployment (развертывание). Набор алгоритмов и директив, описывающих поды, число их экземпляров, порядок их замены при изменении характеристик. С его помощью разработчик декларирует изменения нодов и наборов реплик. Это самый популярный способ разместить приложение в Kubernetes.
• ReplicaSet(набор реплик). Описывает и управляет работой нескольких подов на кластере. Чем больше таких реплик, тем выше устойчивость системы к отказам и лучше масштабируются приложения.
• StatefulSet(набор состояния). Контроллер применяется для управления приложениями с отслеживанием состояния (stateful-приложениями) с использованием постоянного хранилища.
• DaemonSet(набор «демонов»). Представляет собой совокупность «демонов» (фоновых программ, работающих без взаимодействия с пользователем) и отвечает за запуск одной реплики выбранного пода на каждом отдельном узле. То есть по мере добавления узлов в кластер добавляются и поды.
• Job(задание). Контроллер, отвечающий за однократный запуск выбранного пода и завершающий его работу. CronJob — его разновидность, запускающая группу заданий по заданному расписанию.

Читайте также 5 сложных задач на логику для айтишников

Services (сервисы)

Сервисы объединяют поды в логическую группу и определяют политику доступа к ним. По функционалу они напоминают маршрутизатор и балансировщик нагрузки между подами.

Поды могут пересоздаваться, уничтожаться, переезжать на другие ноды и изменять IP-адреса. Если внешней системе или сервису будет нужно обратиться к поду, они должны быть в курсе его жизненного цикла и понимать, куда обращаться в конкретный момент времени. Это неудобно. Поэтому в Kubernetes есть сервисы, которые знают количество подов, хосты, на которых они работают, и пр. Сервис получает запрос от внешних систем или сервисов, определяет, какому именно поду его адресовать, и делает это.

Persistent Volumes (постоянные тома)

Это способ хранения данных между перезапусками контейнеров.

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

Для решения этих проблем в Kubernetes есть Persistent Volumes. Это постоянные тома, жизненный цикл которых не связан с подами и контейнерами. Самостоятельные ресурсы создаются и управляются отдельно.

Namespaces (пространства имен)

Это возможность разделить физический кластер Kubernetes на виртуальные, каждый из которых изолирован от других. Обычно пространства имен создаются для того, чтобы разделить команды, разные проекты или среды развертывания (dev, test, prod).

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

В каждом Namespaces есть свои ресурсы: сервисы, поды, развертывания. В одном пространстве имен они должны иметь уникальные названия, но эти же названия допустимо использовать в других пространствах. В Namespaces входят не все ресурсы: например, Persistent Volumes и ноды доступны всему кластеру.

Основные компоненты кластера

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

Кластер Kubernetes включает следующие компоненты:

• kube-apiserver. С помощью сервера API обеспечивается работа API кластера, обрабатываются REST-операции и предоставляется интерфейс, через который остальные компоненты взаимодействуют друг с другом. Также через него проходят запросы на изменение состояния или чтение кластера. Работает на master-нодах;
• kube-scheduler. Компонент, планирующий, на каких узлах разворачивать поды. Он учитывает такие факторы, как ограничения, требования к ресурсам, местонахождение данных и пр. Работает на master-нодах;
• etcd. Распределенное хранилище в формате «ключ-значение». В нем хранится состояние всего кластера. Главная задача etcd — обеспечить отказоустойчивость кластера и консистентность данных. Etcd — самостоятельный проект. Он развивается отдельно от Kubernetes и применяется в разных продуктах. Работает на master-нодах;
• kube-proxy. Служба, которая управляет правилами балансировки нагрузки. Она конфигурирует правила IPVS или iptables, через которые выполняются проксирование и роутинг. Работает на worker-нодах;
• kube-controller-manager. Компонент запускает работу контроллеров. Работает на master-нодах;
• kubelet. Cлужба, которая управляет состоянием ноды: запуском, остановкой и поддержанием работы контейнеров и подов. Работает на worker-нодах.

Преимущества и недостатки Kubernetes

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

Портативность и гибкость

Kubernetes не зависит от аппаратного обеспечения. Работающую платформу можно переносить на другой сервер, в частное или общедоступное облако. Главное требование — операционная система хоста должна иметь подходящую версию ОС Linux и Windows.

Экономичность

Крупным компаниям Kubernetes помогает уменьшить расходы на ИТ-инфраструктуру благодаря группировке приложений в пакеты. Это оптимизирует использование средств, инвестированных в инфраструктуру и оборудование. K8s дает много возможностей для масштабирования приложения и делает процесс более доступным. Одновременно он сокращает нагрузку на персонал, позволяет сотрудникам направить силы на решение других задач, повышает эффективность использования ресурсов инфраструктуры.

Поддержка мультиоблачности

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

Эффективное распределение задач

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

Наличие развитой экосистемы

Kubernetes поддерживает много крупных корпораций, но это свободное ПО. Фонд CNCF только контролирует его развитие, но не владеет им. Поэтому сторонние разработчики могут создавать дополнения, расширяющие функционал системы, обмениваться опытом друг с другом. Большое количество справочных материалов и широкое комьюнити энтузиастов делают решаемой любую проблему, возникающую при работе с Kubernetes. Также можно пройти интерактивные уроки на официальном сайте.

Надежность

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

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

DevOps-инженер

Станьте DevOps-инженером и помогайте командам фокусироваться на создании качественного продукта. Профессия отлично подойдет разработчикам, тестировщикам и сисадминам

Статьи по теме:

Подборка на любой вкус для питонистов, программистов на JavaScript, тестировщиков и игровых разработчиков

Почему для больших проектов обычно выбирают Java, средних — PHP, а быстро развивающихся стартапов — Ruby или Go

Что такое Pod?

Kubernetes содержит свои собственные абстракции, “наименьшей” из них является Pod — это объединение одного или несколько контейнеров. Возьмем для примера небольшое приложение ожидающие HTTP запросы, исходный код приложения:

const http = require('http');
const os = require('os');
console.log("Kubia server starting. ");
var handler = function(request, response) console.log("Received request from " + request.connection.remoteAddress);
response.writeHead(200);
response.end("You've hit " + os.hostname() + "\n");
>;
var www = http.createServer(handler);
www.listen(8080);

Самым простым способом развернуть что либо в кубернетес является использование CLI (Command Line Interface), запустим приложение исходный код которого находится выше:

kubectl run my-pod --image=luksa/kubia --port=8080

Совет: Если у вас не работает “автодоплнение”, добавить его можно командой echo «source <(kubectl completion bash)" >> ~/.bashrc и обновить окружение через с использованием команды source ~/.bashrc , теперь при нажатии на TAB вам будет доступно “автодолнение”.

kubectl — Вызвает исполняемый файл.

run — Команда для создания разного рода сущностей.

my-pod — Имя нашего первого “пода”, внутри которого раходится контейнер.

—image — Указываем на то какой “образ” мы ходим запустить внутри пода.

luksa/kubia — Репозиторий в dockerhub который содержит образ.

—port=8080 — Сообщаем кубернетес что наше приложение прослушывает порт 8080 (Не пытайтесь проверить работу приложения локально, сейчас мы лишь сообщили куберу что для приложения необходим порт)

Теперь убедимся что создали “под” командой kubectl get pod :

NAME READY STATUS RESTARTS AGE
my-pod 0/1 ContainerCreating 0 3s

Что все это значит? Каждый из этих “столбцов” несет полезную нагрузку, а именно:

Name — Имя запущеных подов. (Помните мы использовали в качества названия my-pod?)

Ready — Статус подов сообщает нам что ожидается 1 под, на текущий момент запущено 0 подов.

Status — Текущий статус пода (Если вы только запустили, кубернетесу нужно время чтобы “загрузить” образ из хранилища и запустить из него под)

Restarts — Колличество перезагрузок пода, как правило это происходит если что то идет не так (нет доступа к приватному репозиторию, не проходят какие либо проверки и т.п.)

AGE — Время жизни пода.

Спустя какое то время(это зависит от скорости соединения для загрузки образа), выполнив команду вновь мы можем увидеть что статус “пода” изменился:

NAME READY STATUS RESTARTS AGE
my-pod 1/1 Running 0 3m

Поздравляю, вы запустили свой первый под в кубернетесе! Но наше приложение все еще недоступно “локально”, если вы попытаетесь запустить и открыть в браузере http://localhost:8080/ увидите ошибку. Так происходит потому что кубернетес имеет микросервисную архитектуру в которой каждая абстракция(сущность) выполняет только выделеную для нее задачу. Сущность “под” НЕ отвечает за сеть и доступность ее внутри кластера, для этого имеется отдельная абстракция “сервис” (service), давайте сделаем доступным наш под для доступа “снаружи”, для этого мы используем CLI команду:

kubectl expose pod my-pod --name=my-service --type=NodePort --port=8080

kubectl — Вызваем исполняемый файл.

expose — Команда для работы с абстракциями отвечающими за “сеть” и “доступность” других сущностей в kubernetes.

pod — Указываем сущность которую мы хотим сделать доступной.

my-pod — Имя нашего “пода” который хотим сделать доступным.

—name=my-service — Имя для нашего сервиса который отвечает за доступность.

—type=NodePort — Указываем типа доступа, сейчас мы используем NodePort он вполне подойдет для локальных тестов, далее я познакомлю вас с иными типами доступа и различиях между ними.

—port=8080 — Порт внутри пода который мы ходим сделать доступным.

Теперь наш pod доступен для просмотра и ответа “снаружи”, напирмер для запросов через браузер или curl, но какой у него порт? Для этого необходимо убедиться что все прошло успешно и сервис действительно доступен командой kubectl get svc которая вернет нам такой ответ:

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
my-service NodePort 10.105.131.60 8080:30366/TCP 23s

Видим некоторые похожие колонки из предыдущего ответа, когда мы смотрели запущеные поды, уточним:

Name — Имя сущности в нашем случае сервиса созданого нами my-service .

TYPE — Тип сервиса который мы создали NodePort (о типах поговорим в другой статье).

CLUSTER-IP — Это виртуальный IP адрес внутри кубернетес кластера, зачем и как он используется я объясню позже.

EXTERNAL-IP — Внешний IP который используется для доступа к указаным сервисам, например если мы использовали бы тип сервиса LoadBalancer доступный лишь в облачных системах (Например AWS), тут появился бы адрес балансировкщика который нам выделил AWS.

PORTS — Используемые порты, левая часть сообщает что внутри пода мы перенаправляем все данные на порт 8080,а “снаружи” мы используем 30366 порт для доступа к поду.

AGE — Время жизни этого сервиса.

Теперь вы можете открыть этот адрес на своей локальной машине и убедиться что ваш первый под работает и отвечает на запросы! (Проверьте внимательно порт который используется для доступа снаружи, кубернетес генерирует их случайным образом каждый раз при создании, в диапозоне от 30000 до 32767).

Пример запроса к поду из примера:

$ curl http://localhost:30366/
You've hit my-pod