Темы

• Узнать, что такое кластер Kubernetes.
• Узнать, что такое Minikube.
• Запуск кластера Kubernetes через онлайн-терминал.

Кластеры Kubernetes

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

Кластер Kubernetes состоит из двух типов ресурса:

• Мастер (ведущий узел) управляет кластером
• Рабочие узлы — машины, на которых выполняются приложения

Схема кластера

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

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

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

Kubernetes-кластер может быть развернут на физических или виртуальных машинах. Чтобы начать работать с Kubernetes, можно использовать Minikube. Minikube — это упрощённая реализация Kubernetes, которая создает виртуальную машину на вашем локальном компьютере и разворачивает простой кластер с одним узлом. Minikube доступен для Linux, macOS и Windows. В CLI-инструменте Minikube есть основные операции для инициализации кластера, включая запуск, завершение, просмотра состояния и удаления кластера. Однако в этом уроке вы будете использовать онлайн-терминал с уже установленным Minikube.

Теперь, когда вы знаете, что такое Kubernetes, можно перейти к онлайн-уроку, где вы запустите ваш первый кластер!

Темы

• Узнать про развёртывания приложения.
• Развернуть первое приложение на Kubernetes с помощью kubectl.

Развёртывания Kubernetes

Как только вы запустили кластер Kubernetes, вы можете развернуть свои контейнеризированные приложения в него. Для этого вам нужно создать конфигурацию развёртывания (Deployment) в Kubernetes. Развёртывание сообщает Kubernetes, как создавать и обновлять экземпляры вашего приложения. После создания развёртывания ведущий узел Kubernetes планирует запустить экземпляры приложения на отдельных узлах в кластере.

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

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

Развёртывание вашего первого приложения на Kubernetes

Вы можете создавать и управлять развёртыванием через командный инструмент Kubernetes под названием Kubectl. Kubectl использует API Kubernetes для работы с кластером. В этом модуле вы узнаете про наиболее используемые команды Kubectl, необходимые для создания развёртываний, которые будут запускать приложения в кластере Kubernetes.

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

В качестве первого развёртывания будем использовать приложение на Node.js, упакованное в Docker-контейнер. Следуя инструкциям в руководстве "Привет, Minikube" вы сможете создать такое приложение Node.js и поместить его в контейнер.

Теперь, когда познакомились с развёртываниями, можно начать онлайн-урок, где вы развернёте своё первое приложение!

Темы

• Узнать про поды Kubernetes.
• Узнать про узлы Kubernetes.
• Диагностика развёрнутых приложений.

Поды Kubernetes

После того, как вы создали развёртывание в модуле 2, Kubernetes создал под (Pod), в котором был размещён экземпляр вашего приложения. Под — это абстрактный объект Kubernetes, представляющий собой группу из одного или нескольких контейнеров приложения (например, Docker или rkt) и совместно используемых ресурсов для этих контейнеров. Ресурсами могут быть:

• Общее хранилище (тома)
• Сеть (уникальный IP-адрес кластера)
• Информация по выполнению каждого контейнера (версия образа контейнера или используемые номера портов)

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

Поды — неделимая единица в платформе Kubernetes. При создании развёртывания в Kubernetes, создаются поды с контейнерами внутри (в отличие от непосредственного создания контейнеров). Каждый Pod-объект связан с узлом, на котором он размещён, и остаётся там до окончания работы (согласно стратегии перезапуска) либо удаления. В случае неисправности узла такой же под будет распределён на другие доступные узлы в кластере.

Схема подов

Узлы

Под всегда работает в узле. Узел — это рабочая машина в Kubernetes, которая в зависимости от кластера может быть либо виртуальной, либо физической. Каждый узел управляется мастером (ведущим узлом). Узел может содержать несколько подов, которые мастер Kubernetes автоматически размещает на разные узлы кластера. Ведущий узел при автоматическом планировании (распределении подов по узлам) учитывает доступные ресурсы на каждом узле.

В каждом узле Kubernetes как минимум работает:

• Kubelet — процесс, отвечающий за взаимодействие между мастером Kubernetes и узлом; он управляет подами и запущенными контейнерами на рабочей машине.
• Среда выполнения контейнера (например, Docker или rkt), отвечающая за получение (загрузку) образа контейнера из реестра, распаковку контейнера и запуск приложения.

Схема узла

Диагностика с помощью kubectl

В модуле 2 вы использовали инструмент командной строки Kubectl. В этом (третьем) модуле вы продолжите его использовать, но для получения информации о развернутых приложениях и окружениях, в которых они работают. Наиболее распространенные операции выполняются с использованием следующих команд kubectl:

• kubectl get — вывод списка ресурсов
• kubectl describe — вывод подробной информации о ресурсе
• kubectl logs — вывод логов контейнера в поде
• kubectl exec — выполнение команды в контейнере пода

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

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

Темы

• Узнать о сервисах в Kubernetes
• Разобраться с тем, как метки и объекты LabelSelector связаны с сервисом
• Открыть доступ к приложению вне кластера Kubernetes через сервис

Обзор сервисов Kubernetes

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

Сервис в Kubernetes — это абстрактный объект, который определяет логический набор подов и политику доступа к ним. Сервисы создают слабую связь между подами, которые от них зависят. Сервис создаётся в формате YAML (рекомендуемый формат) или JSON, как и все остальные объекты в Kubernetes. Как правило, набор подов для сервиса определяется LabelSelector (ниже описано, в каких случаях понадобиться сервис без указания selector в спецификации).

Хотя у каждого пода есть уникальный IP-адрес, эти IP-адреса не доступны за пределами кластера без использования сервиса. Сервисы позволяют приложениям принимать трафик. Сервисы могут по-разному открыты, в зависимости от указанного поля type в ServiceSpec:

• ClusterIP (по умолчанию) - открывает доступ к сервису по внутреннему IP-адресу в кластере. Этот тип делает сервис доступным только внутри кластера.
• NodePort - открывает сервис на одном и том же порту каждого выбранного узла в кластере с помощью NAT. Делает сервис доступным вне кластера, используя <NodeIP>:<NodePort>. Является надмножеством ClusterIP.
• LoadBalancer - создает внешний балансировщик нагрузки в текущем облаке (если это поддерживается) и назначает фиксированный внешний IP-адрес для сервиса. Является надмножеством NodePort.
• ExternalName - открывает доступ к сервису с указанным именем (определённое в поле externalName в спецификации) и возвращает запись CNAME. Прокси не используется. Для этого типа требуется версия kube-dns 1.7 или выше.

Более подробно узнать о различных типах сервисах можно в руководстве Использование IP-порта источника. Также изучите Подключение приложений к сервисам.

Кроме этого, обратите внимание, что в некоторых случаях в сервисах не определяется selector в спецификации. Сервис без selector не будет создавать соответствующий объект конечной точки (Endpoint). Таким образом, пользователь может вручную назначить сервис определённым конечным точкам. Использование type: ExternalName — это другой вариант использования, когда не нужно определять селектор в сервисе.

Сервисы и метки

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

Сервисы для выбора набора подов используют метки и селекторы. Метки — пары ключ-значение, добавленные к объектам; например, они могут использоваться чтобы:

• Идентифицировать объекты для окружений разработки, тестирования и продакшена
• Добавить теги версии
• Классифицировать объекты через теги

Метки могут добавляться во время создания объектов или после этого. Они также могут быть изменены в любое время. Теперь давайте откроем доступ к приложению путём создания сервиса и добавление меток.

Темы

• Масштабирование приложения с помощью kubectl.

Масштабирование приложения

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

Масштабирование осуществляется за счёт изменения количества реплик в развёртывании.

Обзор масштабирования

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

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

Имея несколько работающих экземпляров приложения можно выполнять плавающие обновления (rolling updates) без простоев. С ними мы познакомимся в следующем модуле. А пока перейдём к онлайн-терминалу и промасштабируем наше приложение.

Темы

• Выполнение плавающего обновления с помощью kubectl.

Обновление приложения

Пользователи надеются, что приложения будут работать круглосуточно, а разработчики в свою очередь ожидают развёртывать новые версии приложений по нескольку раз в день. В Kubernetes это возможно благодаря механизму плавающих обновлений (rolling updates). Плавающие обновления позволяет обновить развёртывания без простоев, шаг за шагом заменяя старые поды на новые. Новые поды будут запущены на узлах, имеющих достаточно ресурсов.

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

Обзор плавающих обновлений

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

С помощью плавающих обновлений можно:

• Переводить приложение из одного окружения в другое (через обновления образа контейнера)
• Откатываться к предыдущим версиям
• Осуществлять непрерывную интеграцию и непрерывную доставку приложений без простоев

В следующем интерактивном уроке мы обновим приложение до новой версии, а потом выполним откат, т.е. вернёмся к предыдущей версии