Что такое Kubernetes

Инструменты контейнеризации

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

Особенности контейнеров

К характеристикам контейнеров принято относить:

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

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

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

- Гибкость контроля и безопасности. Изоляция позволяет отслеживать угрозы и быстрее на них реагировать. Автоматизация проверок безопасности становится неотъемлемой частью процесса разработки.

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

Всегда ли нужна контейнеризация

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

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

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

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

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

За контейнеризацией будущее

Особенности архитектуры и жизненного цикла, а также богатый набор экосистемных инструментов контейнеров позволяют:

- сократить время разработки приложения;

- значительно ускорить время на тестирование версий в различных условиях;

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

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

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

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

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

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

Контейнеры и экосистема Kubernetes 

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

Предпринималась не одна попытка решить эту проблему: Docker Compose, Docker Swarm, Nomad, но справедливо будет сказать, что по разным причинам лидером стал Kubernetes.

Что такое Kubernetes

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

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

Словарь Kubernetes

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

Итак, рассмотрим инфраструктурную терминологию Kubernetes. На схеме ниже представлен типовой кластер Kubernetes:

На мастере установлен «контрольный пункт» (control plane), несущий на себе обязательные функции по управлению Kubernetes:

- Kubernetes API Server, входящее окно для запросов на сервисные функции: развертывание контейнеров и др.;

- kube-scheduler, который распределяет приложения по воркерам;

- kube-controller-manager, выполняющий сервисные функции, такие как мониторинг рабочих узлов, обработка ошибок и т. д.;

- etcd, распределенное хранилище данных, которое сохраняет конфигурацию кластера.

На каждом воркере установлен набор компонентов, осуществляющих общение с мастером или управление приложениями:

- Docker или другая среда;

- Kubelet — сервис, обменивающийся данными с сервером API и управляющий контейнерами;

- kube-proxy, балансирующий трафик между компонентами приложения.

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

Чтобы развернуть приложение в Kubernetes, необходимо упаковать его в один или несколько образов контейнеров, отправить их в реестр (например, Docker Hub), а затем описать развертывание с помощью файла в специальном формате YAML.

Описание содержит сведения о том:

- откуда брать образы контейнеров;

- сколько выделять ресурсов (RAM, CPU);

- как связывать их друг с другом;

- какие порты открывать;

- кто имеет доступ;

- какие команды выполнять при запуске или остановке контейнера.

Это исчерпывающая инструкция, поддерживающая сложнейшие развертывания.

После отправки YAML в Kubernetes система определит наличие ресурсов на воркерах, развернет контейнеры и обеспечит их беспрерывный мониторинг через Kubelet-сервис на воркере. Если контейнер перестанет реагировать нормально (критерии нормальности также конфигурируются), Kubernetes автоматически переразвернет приложение на другом узле.

Уникальные характеристики Kubernetes

Почему Kubernetes стал популярным? Во многом из-за своих уникальных свойств:

- Эффективное использование оборудования. В Kubernetes приложение отделено от инфраструктуры и определяется отдельно.

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

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

- Автоматическое масштабирование и восстановление. Настраиваемые метрики, на основе которых Kubernetes может вынести решение о выделении дополнительных ресурсов или аварийном восстановлении приложения.

- Активное и дружное сообщество, включающее в себя лидеров индустрии.

Различия IaaS и PaaS Kubernetes: преимущества и вопросы

В предыдущей теме разработчики DST Global обращали внимание на важный момент грамотного использования Kubernetes для повышения эффективности. Долгое время это означало выделение дополнительного времени разработчиков и других специалистов. В том числе инфраструктурных, так как Kubernetes все еще нужно было где-то разворачивать и поддерживать. Для больших компаний или маленьких гибких Cloud-Native-команд такой подход мог быть эффективен. Однако нарастающее использование Kubernetes показало, что есть серьезный спрос на предоставление Kubernetes как сервиса.

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

Введение в Кубернетес

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

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

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

Основные компоненты Kubernetes

Кластер

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

Компонентами плоскости управления являются Kube-APIserver, etcd, kube schedular, kube-controller-manager, cloud-controller-manager.

Некоторые компоненты плоскости управления выполняются на каждом узле. Этими компонентами являются kubelet, kube-proxy,Container-Runtime.

Узел

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

Pod

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

Развертывание

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

Услуга

Поды Kubernetes являются динамическими. Они часто создаются и уничтожаются. Каждый раз, когда создается новый модуль, он получает новое имя и адрес в узле Kubernetes. Таким образом, становится невозможным взаимодействие между модулями, используя физический адрес или IP-адрес модулей. Для решения этой проблемы созданы сервисы Kubernetes. Служба определяет политики доступа к логическому набору модулей.

Секрет

Секреты используются для безопасного хранения конфиденциальной информации. Это может быть что угодно, например учетные данные БД или данные учетной записи службы. Всегда рекомендуется хранить эту информацию в секрете, а не жестко закодировать ее в файлах конфигурации K8.

Постоянный объем

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

Постоянная заявка на объем

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