Как работает Kubernetes
Успешность настройки установки Kubernetes зависит от хорошего понимания архитектуры системы Kubernetes. Здесь вы посмотрите на все компоненты, составляющие установку Kubernetes.
Что такое кластер компьютеров?
Кластер — это набор компьютеров, настроенных для совместной работы и представленных в виде единой системы. Компьютеры, настроенные в кластере, обрабатывают те же задачи. Например, на всех них размещаются веб-сайты, программные интерфейсы (API) или выполняются ресурсоемкие операции.
Кластер использует централизованное программное обеспечение, ответственное за планирование этих задач и управление ими. Компьютеры в кластере, где выполняются задачи, называются узлами, а компьютеры, на которых выполняется программное обеспечение для планирования, — уровнями управления.
Архитектура Kubernetes
Как вы помните, оркестратор — это система, которая развертывает приложения и управляет ими. Вы также узнали, что кластер — это набор компьютеров, которые работают вместе и рассматриваются как единая система. Kubernetes используется в качестве программного обеспечения оркестрации и кластера для развертывания приложений и реагирования на изменения потребности в ресурсах вычислений.
Кластер Kubernetes содержит по крайней мере один уровень управления и один узел или несколько. Уровень управления и экземпляры узлов могут быть физическими устройствами, виртуальными машинами или экземплярами в облаке. Операционной системой сервера виртуальных машин в Kubernetes по умолчанию является Linux с поддержкой по умолчанию для рабочих нагрузок на основе Linux.
Вы также можете запускать рабочие нагрузки Майкрософт с помощью Windows Server 2019 или более поздней версии на узлах кластера. Например, предположим, что служба обработки данных в приложении отслеживания дронов записывается как приложение .NET 4.5, использующее определенные вызовы API ОС Windows. Эта служба может выполняться только на узлах, работающих под управлением ОС Windows Server.
Теперь рассмотрим как плоскости управления, так и рабочие узлы и программное обеспечение, которое выполняется на каждом из них более подробно. Понимание роли каждого компонента и того, где каждый компонент работает в кластере, помогает при установке Kubernetes.
Уровень управления Kubernetes
Главный узел Kubernetes, также известный как уровень управления в кластере Kubernetes, запускает набор сервисов, управляющих функциональностью оркестрации в Kubernetes.
С точки зрения обучения имеет смысл использовать один уровень управления в тестовой среде при изучении функций Kubernetes. Однако в рабочих и облачных развертываниях, таких как Служба Azure Kubernetes (AKS), вы обнаружите, что предпочтительная конфигурация — это высокодоступное развертывание с тремя до пяти реплика плоскостей управления.
Примечание.
Тот факт, что главный узел запускает конкретное программное обеспечение для поддержания состояния кластера, не исключает выполнение других вычислительных рабочих нагрузок на нем. Однако, как правило, на нем не следует выполнять некритические и пользовательские рабочие нагрузки приложений.
Узел Kubernetes
Узел в кластере Kubernetes — это место выполнения вычислительных рабочих нагрузок. Каждый узел взаимодействует с уровнем управления через сервер API, чтобы сообщить об изменениях состояния на узле.
Службы, работающие на уровне управления
Kubernetes полагается на несколько административных сервисов, работающих на плоскости управления. Эти службы управляют такими аспектами, как связь с компонентом кластера, планирование рабочей нагрузки и сохраняемость состояния кластера.
Следующие службы составляют плоскость управления кластера Kubernetes:
- Сервер API
- Резервное хранилище
- Планировщик
- Диспетчер контроллеров
- Диспетчер облачных контроллеров
Что такое сервер API?
Сервер API можно рассматривать как внешний интерфейс в плоскости управления кластера Kubernetes. Все взаимодействия между компонентами в Kubernetes осуществляются через этот API.
Например, в качестве пользователя используется приложение kubectl командной строки, которое позволяет выполнять команды на сервере API кластера Kubernetes. Компонент, предоставляющий этот API, называется kube-apiserver, и можно развернуть несколько экземпляров этого компонента для поддержки масштабирования в кластере.
Этот API предоставляет RESTful API, который позволяет публиковать команды или файлы конфигурации на основе YAML. YAML — это понятный человеку стандарт сериализации данных для языков программирования. Файлы YAML используются для определения предполагаемого состояния всех объектов в кластере Kubernetes.
Пусть, например, необходимо увеличить количество экземпляров приложения в кластере. Вы определяете новое состояние с помощью файла на основе YAML и отправляете этот файл на сервер API. Сервер API проверяет конфигурацию, сохраняет его в кластере и, наконец, принимает настроенное увеличение развертываний приложений.
Что такое резервное хранилище?
Резервное хранилище — это постоянное хранилище, в котором кластер Kubernetes сохраняет завершенную конфигурацию. Kubernetes использует распределенное, высокодоступное и надежное хранилище пар "ключ-значение", которое называется etcd. В этом хранилище пар "ключ-значение" хранится текущее состояние, а также требуемое состояние всех объектов в кластере.
В рабочем кластере Kubernetes официально рекомендуется наличие от трех до пяти реплицируемых экземпляров базы данных etcd для обеспечения высокой доступности.
Примечание.
etcd не отвечает за резервное копирование данных. Вы несете ответственность за обеспечение наличия эффективного плана для резервного копирования данных etcd.
Что такое планировщик?
Планировщик — это компонент, отвечающий за назначение рабочих нагрузок на всех узлах. Планировщик отслеживает кластер для вновь созданных контейнеров и назначает их узлам.
Что такое диспетчер контроллеров?
Диспетчер контроллеров запускает и отслеживает контроллеры, настроенные для кластера через сервер API.
Kubernetes использует контроллеры для отслеживания состояний объектов в кластере. Каждый контроллер выполняется в нетерминирующий цикл при просмотре и реагировании на события в кластере. Например, есть контроллеры для мониторинга узлов, контейнеров и конечных точек.
Контроллер взаимодействует с сервером API, чтобы определить состояние объекта. Если текущее состояние отличается от требуемого состояния объекта, контроллер принимает меры для обеспечения требуемого состояния.
Предположим, что один из трех контейнеров, работающих в кластере, перестает отвечать на запросы и завершается сбоем. В этом случае контроллер решает, требуется ли запустить новые контейнеры, чтобы обеспечить доступность приложений. Если нужно, чтобы всегда работало три контейнера, будет запланирован запуск нового.
Что такое диспетчер облачных контроллеров?
Диспетчер облачных контроллеров интегрируется с базовыми облачными технологиями в кластере, если кластер работает в облачной среде. Этими службами, например, могут быть подсистемы балансировки нагрузки, очереди и хранилище.
Службы, выполняющиеся в узле
На узле Kubernetes запущено несколько служб, которые управляют выполнением рабочих нагрузок.
Следующие службы выполняются на узле Kubernetes:
- kubelet
- kube-proxy
- Среда выполнения контейнера
Что такое kubelet?
kubelet — это агент, который выполняется на каждом узле в кластере и отслеживает рабочие запросы с сервера API. Он гарантирует, что запрошенная единица работы запущена и работоспособна.
kubelet выполняет мониторинг узлов и гарантирует, что контейнеры, запланированные на каждом узле, выполняются должным образом. Kubelet управляет только контейнерами Kubernetes. Он не несет ответственности за повторное планирование заданий на других узлах, если текущий узел не может выполнить работу.
Что такое kube-proxy?
Компонент kube-proxy отвечает за локальную сеть кластера и выполняется на каждом узле. Он гарантирует, что каждый узел имеет уникальный IP-адрес. Он также реализует правила для управления маршрутизацией и балансировкой нагрузки трафика с помощью iptables и IPVS.
Эта прокси-служба сама не предоставляет службу DNS. Рекомендуется использовать установленную по умолчанию надстройку кластера DNS на основе CoreDNS.
Что такое среда выполнения контейнера?
Среда выполнения контейнера — это базовое программное обеспечение, которое выполняет контейнеры в кластере Kubernetes. Среда выполнения отвечает за получение, запуск и остановку образов контейнеров. Kubernetes поддерживает несколько сред выполнения контейнеров, в том числе Docker, containerd, rkt, CRI-O и frakti. Поддержка многих типов среды выполнения контейнеров основана на интерфейсе среды выполнения контейнеров (CRI). CRI — это конструкция подключаемого модуля, которая позволяет kubelet взаимодействовать с доступной средой выполнения контейнеров.
Среда выполнения контейнеров по умолчанию в AKS является контейнерной средой выполнения контейнера, стандартной для отрасли.
Взаимодействие с кластером Kubernetes
Kubernetes предоставляет программу командной строки kubectl для управления кластером. kubectl можно использовать для отправки команд на уровень управления кластера или получения сведений обо всех объектах Kubernetes через сервер API.
kubectl использует файл конфигурации, который содержит следующие сведения о конфигурации.
- Конфигурация Cluster определяет имя кластера, сведения о сертификате и конечную точку API службы, связанную с кластером. Это определение позволяет подключаться с одной рабочей станции к нескольким кластерам.
- Конфигурация User определяет пользователей и их уровни разрешений при доступе к настроенным кластерам.
- Конфигурация Context обединяет кластеры и пользователей в группы с понятным именем. Например, вы можете назвать кластер разработки и рабочий кластер dev-cluster и prod-cluster соответственно.
Можно настроить kubectl для подключения к нескольким кластерам, указав правильный контекст в качестве части синтаксиса командной строки.
Модули pod Kubernetes
Модуль pod представляет отдельный экземпляр приложения, работающего в Kubernetes. Рабочие нагрузки, выполняемые в Kubernetes, являются контейнерными приложениями. В отличие от среды Docker вы не можете запускать контейнеры непосредственно в Kubernetes. Контейнер упаковывается в объект Kubernetes, который называется pod. Модуль pod является наименьшим объектом, который можно создать в Kubernetes.
Один модуль pod также может содержать группу из одного или нескольких контейнеров. Однако обычно модуль pod не содержит несколько экземпляров одного приложения.
Модуль pod содержит сведения о конфигурации общего хранилища и сети и спецификации о том, как запускать упакованные контейнеры. Шаблоны модулей pod используются для определения сведений о модулях, которые выполняются в кластере. Шаблоны модулей pod — это файлы YAML, которые можно использовать повторно и включать в другие объекты для управления развертываниями pod.
Например, предположим, что вы хотите развернуть веб-сайт в кластере Kubernetes. Вы создаете файл определения pod, в котором указаны образы и конфигурация контейнера приложения. Затем вы развертываете файл определения pod в Kubernetes.
Вряд ли веб-сайт будет единственным компонентом веб-приложения в решении. Веб-приложение обычно имеет хранилище данных и другие вспомогательные элементы. Модули pod Kubernetes также могут содержать несколько контейнеров.
Предположим, что сайт использует базу данных. Веб-сайт упаковывается в основной контейнер, а база данных — во вспомогательный контейнер. Несколько контейнеров взаимодействуют друг с другом через среду. Контейнеры включают службы для ос узла, сетевого стека, пространства имен ядра, общего объема памяти и хранилища. Модуль pod — это изолированная среда, которая предоставляет все эти службы приложению. Она также позволяет контейнерам совместно использовать свой назначенный IP-адрес.
Так как вы потенциально можете создать множество модулей pod, которые выполняются на многих узлах, найти их бывает трудно. Вы можете распознавать и группировать модули pod с помощью строковых меток, которые указываются при определении модуля pod.
Жизненный цикл модуля pod в Kubernetes
Модули pod Kubernetes имеют четкий жизненный цикл, который влияет на способ их развертывания, запуска и обновления. Сначала вы отправляете файл YAML с манифестом модуля pod в кластер. После отправки и сохранения файла манифеста в кластере он определяет желаемое состояние модуля pod. Планировщик планирует модуль pod на работоспособном узле, который имеет достаточное количество ресурсов для запуска модуля.
Ниже приведены этапы жизненного цикла модуля pod.
| Этап | Description |
|---|---|
| Ожидает | Модуль pod принимает кластер, но не все контейнеры в кластере настроены или готовы к выполнению. Состояние ожидания указывает время, в течение которого ожидается планирование модуля pod и время загрузки образов контейнеров. |
| Выполняется | Модуль pod переходит в состояние выполнения после того, как все ресурсы в нем будут готовы. |
| Выполнено успешно | Модуль pod переходит в состояние успешного выполнения, когда завершает свою задачу. |
| Неудачно | Сбои модулей pod могут возникать по различным причинам. Контейнер в модуле pod может завершиться сбоем, что приведет к завершению всех остальных контейнеров или, возможно, образ не найден во время подготовки контейнеров pod. В таких случаях модуль pod может перейти к состоянию сбоем. Модули Pod могут переходить в состояние сбоя из состояния ожидания или состояния выполнения. Определенный сбой также может вернуть модуль pod в состояние ожидания. |
| Неизвестно | Если состояние модуля pod не удается определить, модуль pod находится в неизвестном состоянии. |
Модули pod хранятся в кластере, пока контроллер, уровень управления или пользователь явно не удалят их. При удалении модуля pod создается новый модуль сразу после удаления. Новый модуль pod считается совершенно новым экземпляром, основанным на манифесте pod, не является точной копией, поэтому она отличается от удаленного модуля pod.
Кластер не сохраняет состояние pod или динамически назначенную конфигурацию. Например, он не сохраняет идентификатор или IP-адрес модуля pod. Этот аспект влияет на развертывание модулей pod и разработку приложений. Например, нельзя полагаться на заранее назначенные IP-адреса для модулей pod.
Состояния контейнеров
Помните, что этапы представляют собой общие сведения о том, где находится модуль pod в жизненном цикле. При проверке модулей pod кластер использует три состояния для отслеживания контейнеров внутри модуля.
| State | Description |
|---|---|
| Ожидает | Состояние по умолчанию контейнера и состояние, в котором находится контейнер, если не выполняется или не завершен. |
| Выполняется | Контейнер выполняется так, как ожидалось, без проблем. |
| Завершен | Контейнер больше не выполняется. Причина перехода в это состояние в том, что все задачи завершены или по какой-либо причине произошел сбой контейнера. Код причины и выхода доступен при отладке обоих вариантов. |