Краткий обзор Kubernetes
Kubernetes – это производительная система для управления контейнерными приложениями в кластерной среде, разработанная Google. Kubernetes предоставляет более эффективные способов управления связанными распределенными компонентами в разнообразных инфраструктурах.
В этой статье вы найдете основные понятия Kubernetes, прочитаете об архитектуре системы, узнаете о проблемах, которые она решает, и о модели, которую она использует для обработки контейнерных развертываний и масштабирования.
Требования
Эта статья предполагает наличие базовых знаний о современных кластерных технологиях. Статья предлагает примеры на основе систем типа CoreOS.
Читайте также: Компоненты системы CoreOS: вступление
Что такое Kubernetes?
Kubernetes на базовом уровне представляет собой систему управления контейнерными приложениями в кластере нод. Во многих отношениях система Kubernetes была разработана для устранения конфликта между методами построения современных кластерных инфраструктур и некоторыми особенностями сред большинства приложений и сервисов.
Большинство технологий кластеризации стремятся обеспечить единую платформу для развертывания приложений. Пользователь не должен заботиться о том, где запланирована работа. Задача, представленная пользователю, находится на уровне сервиса и может быть выполнена любой нодой.
Однако во многих случаях вид базовой инфраструктуры имеет значение. При масштабировании приложения администратор заботится о том, чтобы разные экземпляры сервиса не были присвоены одному хосту.
С другой стороны, многие распределенные приложения, основанные на масштабировании, фактически состоят из небольших компонентов. В простой настройке эти сервисы должны быть запланированы на том же хосте, что и связанные компоненты. Это становится еще более важным, когда их взаимодействие зависит от конкретных сетевых условий.
Хотя большинство программ кластеризации поддерживают разные типы планирования, работа на уровне отдельных сервисов не идеальна. В большинстве случаев приложения, состоящие из разных сервисов, по-прежнему должны восприниматься как одно приложение. Kubernetes обеспечивает дополнительный уровень над инфраструктурой, чтобы предоставить этот тип управления.
Компоненты мастера
Системы уровня инфраструктуры, такие как CoreOS, стремятся создать единую среду, в которой каждый хост будет одноразовым и взаимозаменяемым. Kubernetes работает с определенным уровнем специализации хоста.
Управляющими компонентами в кластере Kubernetes являются компоненты мастера (master). Они работают в качестве основных точек управления для администраторов, а также предоставляют множество кластерных систем для относительно простых рабочих нод. Эти сервисы можно установить на одной машине или распределить между несколькими машинами.
Серверы, на которых работают эти компоненты, имеют ряд уникальных сервисов, которые используются для управления рабочей нагрузкой кластера и прямой связи по всей системе. Теперь рассмотрим эти компоненты более подробно.
etcd
Одним из основных компонентов Kubernetes является глобально доступный магазин конфигурации. Проект etcd, разработанный командой CoreOS, представляет собой легкое распределенное хранилище «ключ-значение», которое можно использовать между несколькими нодами.
Kubernetes использует etcd для хранения данных конфигурации, которые могут использоваться каждой нодой кластера. Это можно использовать для обнаружения сервисов. Эти данные представляют состояние кластера, на которое может ссылаться каждый компонент для настройки или перенастройки. Для установки или получения значений используется очень простой HTTP/JSON API.
Как и большинство других компонентов управления, etcd можно настроить на одном главном сервере или распределить между несколькими машинами с помощью сценариев. Единственное требование – это доступность сети для каждой из машин Kubernetes.
API-сервер
Одним из важнейших сервисов является сервер API. Это основная точка управления всего кластера, поскольку она позволяет пользователю настраивать рабочие нагрузки и единицы Kubernetes. Также этот сервер несет ответственность за взаимодействие хранилища etcd и параметров обслуживания развернутых контейнеров. Он действует как мост между различными компонентами для поддержания рабочего состояния кластера и распространения информации и команд.
Сервер API реализует интерфейс RESTful, что означает, что с ним можно легко обмениваться множеством различных инструментов и библиотек. Вместе с инструментами на стороне сервера поставляется клиент kubecfg, который можно использовать с локального компьютера для взаимодействия с кластером Kubernetes.
Контроллер-менеджер
Контроллер-менеджер – это общий сервис, который имеет много обязанностей. Он отвечает за несколько контроллеров, которые регулируют состояние кластера и выполняют обычные задачи. Например, контроллер репликации гарантирует, что количество реплик соответствует числу нод, развернутых в настоящее время в кластере. Детали этих операций записываются в etcd, где контроллер-менеджер наблюдает за изменениями через сервер API.
Когда контроллер замечает изменение, он считывает новую информацию и выполняет процедуру, которая реализует требуемое состояние.
Планировщик
Планировщик – это процесс, который фактически назначает рабочие нагрузки определенным узлам в кластере. Он читает требования сервиса, анализирует текущую инфраструктуру и передает задачи тем или иным нодам.
Планировщик отвечает за отслеживание использования ресурсов на каждом хосте, чтобы убедиться, что рабочие нагрузки не превышают лимит доступных ресурсов. Планировщик должен знать общий объем ресурсов на каждом сервере, а также ресурсы, выделенные для тех или иных рабочих нагрузок.
Компоненты ноды
В Kubernetes рабочие серверы называются нодами. У нод есть несколько требований, что обеспечивает взаимодействие с основными компонентами, настраивает сеть для контейнеров и выполняет назначенные им рабочие нагрузки.
Docker на выделенной подсети
Первым требованием каждой ноды является docker. Сервис docker используется для запуска контейнеров приложений в относительно изолированной, но легкой операционной среде. Каждая элемент работы на базовом уровне реализуется как серия контейнеров, которые нужно развернуть.
Kubernetes предполагает, что выделенная подсеть доступна каждому рабочему серверу. Но это не касается многих стандартных кластерных развертываний. Например, CoreOS для этой цели необходима отдельная сетевая структура, flannel. Docker нужно настроить таким образом, чтобы он мог правильно открывать порты.
kubelet
Основной точкой контакта каждой ноды с группой кластера является небольшой сервис под названием kubelet. Он отвечает за передачу информации от сервисов управления, а также за взаимодействие с хранилищем etcd для чтения деталей конфигурации или записи новых значений.
Сервис kubelet связывается с основными компонентами для приема команд и их выполнения. Задачи передаются в виде «манифеста», который определяет рабочую нагрузку и рабочие параметры. Затем процесс kubelet берет на себя ответственность за поддержку рабочего состояния ноды.
Сервис проксирования
Для работы отдельной подсети хоста и для поддержки сервисов для внешних сторон на каждой ноде используется небольшой прокси-сервис. Этот процесс отправляет запросы в правильные контейнеры, может выполнять примитивную балансировку нагрузки и обычно отвечает за простоту, доступность и изолированность сетевой среды.
Рабочие элементы Kubernetes
В этом разделе вы ознакомитесь с основными типами задач Kubernetes.
Pod
Pod – это базовый элемент работы Kubernetes. Сами по себе контейнеры не присваиваются хостам. Вместо этого тесно связанные контейнеры группируются в один контейнер. Контейнер обычно представляет собой один или несколько контейнеров, которые должны работать как единое «приложение».
Такая группировка позволяет запланировать все необходимые контейнеры на одном хосте. Они работают как единое целое и имеют общую среду. Это означает, что они могут обмениваться томами и IP-пространством и их можно развернуть и масштабировать как одно приложение. Контейнеры следует воспринимать как единый виртуальный компьютер, чтобы лучше понять, как должны работать ресурсы и планирование.
Общая конструкция pod-ов состоит из основного контейнера и, возможно, нескольких вспомогательных контейнеров, которые облегчают выполнение соответствующих задач. Как правило, это программы, которые выигрывают от работы в собственном контейнере, но сильно привязаны к основному приложению.
Горизонтальное масштабирование на уровне pod-ов обычно непродуктивно, потому что есть другие элементы, более подходящие для этой задачи.
Сервисы
В этой статье термин «сервис» используется в довольно широком значении, но на самом деле Kubernetes имеет очень специфическое определение сервиса при описании рабочих элементов. В контексте Kubernetes сервис представляет собой элемент, который действует как базовый балансировщик нагрузки и представитель других контейнеров. Сервис группирует логические коллекции модулей, которые выполняют одну и ту же функцию, и представляет их как единый объект.
Это позволяет развернуть сервис, который знает обо всех контейнерах бэкэнда, для передачи трафика. Внешним приложениям нужна только единая точка доступа, но они сильно выигрывают благодаря масштабируемому бэкэнду (или, по крайней мере, бэкэнду, который в случае необходимости можно поменять). IP-адрес сервиса остается стабильным, игнорируя любые изменения IP-адресов pod-а, которые происходят при сбое нод или перепланировке модулей.
Сервисы – это интерфейс для групп контейнеров, что предоставляет пользователям единую точку доступа к ним. Развернув сервис, вы можете упростить управление контейнерами.
Контроллер репликации
Реплицированный pod – это более сложная версия обычного pod-а. Реплицированными pod-ами управляет специальный контроллер репликации.
Контроллер репликации является фреймворком для определения контейнеров, предназначенных для горизонтального масштабирования. Рабочий элемент, по существу, является вложенным элементом. Этот контроллер предоставляет шаблон, который в основном являет собой полное определение контейнера. Он также получает дополнительные сведения о репликации, которая должна быть выполнена.
Контроллер репликации несет ответственность за поддержку необходимого количества копий. Это означает, что если контейнер временно прекращает работу, контроллер репликации может запустить другой контейнер. Если первый контейнер возвращается в сеть, контроллер уничтожит один из контейнеров.
Метки
Метка – это, как правило, произвольный тег, который может быть помещен на вышеуказанные рабочие элементы, чтобы отметить их как часть группы. Затем расставленные метки можно использовать в управлении и определении действий.
Метки имеют основополагающее значение в работе сервисов и контроллеров репликации. Чтобы получить список серверов бэкэнда, которым сервис должен передавать трафик, Kubernetes обычно выбирает контейнеры по метке.
Аналогично, контроллеры репликации выдают всем контейнерам, порожденным их шаблонами, одну и ту же метку. Это позволяет контроллеру управлять каждым отдельным экземпляром. Контроллер или администратор могут управлять всеми экземплярами в группе, независимо от того, сколько контейнеров было создано.
Метки указываются как пары «ключ-значение». Каждый элемент может иметь более одной метки, но только одну запись для каждого ключа. Вы можете присваивать pod-ам как общий идентификатор имена. Также их можно классифицировать по различным критериям (таким как этап разработки, доступ, версия приложения и т. п.).
Чтобы иметь тонкий контроль над инфраструктурой, нужно присвоить много меток.
Заключение
Kubernetes – замечательный проект, который значительно улучшает функции кластерной инфраструктуры.
Tags: CoreOS, Kubernetes