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

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

Kubernetes используетetcd для хранения данных конфигурации, к которым может получить доступ каждый из узлов кластера. Это может использоваться для обнаружения службы и может помочь компонентам настроить или перенастроить себя в соответствии с актуальной информацией. Это также помогает поддерживать состояние кластера с такими функциями, как выбор лидера и распределенная блокировка. Предоставляя простой HTTP / JSON API, интерфейс для установки или извлечения значений очень прост.

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

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

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

Диспетчер контроллеров - это общая служба, на которую возложены многие обязанности. Прежде всего, он управляет различными контроллерами, которые регулируют состояние кластера, управляют жизненными циклами рабочей нагрузки и выполняют рутинные задачи. Например, контроллер репликации гарантирует, что количество реплик (идентичных копий), определенных для модуля, соответствует числу, развернутому в данный момент в кластере. Подробности этих операций записываются вetcd, где диспетчер контроллера отслеживает изменения через сервер API.

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

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

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

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

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

Первый компонент, который должен иметь каждый узел, - это среда выполнения контейнера. Обычно это требование удовлетворяется путем установки и запускаDocker, но также доступны альтернативы, такие какrkt иrunc.

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

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

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

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

pod - это самая основная единица, с которой имеет дело Kubernetes. Сами контейнеры не назначаются хостам. Вместо этого один или несколько тесно связанных контейнеров заключены в объект, который называется стручком.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Создание рабочих мест составляетcron jobs. Как и обычные демоныcron в Linux и Unix-подобных системах, которые выполняют сценарии по расписанию, задания cron в Kubernetes предоставляют интерфейс для выполнения заданий с компонентом планирования. Задания Cron можно использовать для планирования задания на выполнение в будущем или на регулярной основе. Задания Kubernetes cron - это, в основном, переопределение классического поведения cron с использованием кластера в качестве платформы вместо единой операционной системы.

До сих пор мы использовали термин «сервис» в обычном Unix-подобном смысле: для обозначения долго выполняющихся процессов, часто подключенных к сети, способных отвечать на запросы. Однако в Kubernetesservice - это компонент, который действует как базовый внутренний балансировщик нагрузки и представитель для подов. Служба группирует логические коллекции модулей, которые выполняют одну и ту же функцию, чтобы представить их как единый объект.

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

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

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

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

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

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

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

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

Метки даются в виде простых пар ключ-значение. Каждая единица может иметь более одной метки, но каждая единица может иметь только одну запись для каждой клавиши. Обычно в качестве идентификатора общего назначения используется ключ «имя», но вы можете дополнительно классифицировать объекты по другим критериям, таким как этап разработки, общедоступность, версия приложения и т. Д.

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