Kubernetes — это мощная система оркестрации с открытым исходным кодом, изначально разработанная Google, для управления контейнерными приложениями в кластерной среде.
Компоненты — это модули, службы и программы, которые обеспечивают работу всего кластера. Они работают внутри нод, то есть физических или виртуальных серверов, на которых работает Kubernetes — некоторые внутри управляющих Master-нод, некоторые внутри рабочих Worker-нод.
компоненты кластера
- kube-apiserver. Сервер API обеспечивает работу API кластера, обрабатывает REST-операции и предоставляет интерфейс, через который все остальные компоненты взаимодействуют между собой. Также через него проходят все запросы на чтение или изменение состояния кластера. Работает на Master-нодах.
- etcd. Распределенное хранилище формата «ключ-значение», в котором хранится состояние всего кластера. Его основная задача — обеспечить консистентность данных и отказоустойчивость кластера. Etcd — это самостоятельный проект, который развивается отдельно от Kubernetes и используется в разных продуктах. Хранилище использует алгоритм консенсуса Raft, то есть в нем уже заложены механизмы для достижения отказоустойчивости. Чтобы их использовать, нужно создать несколько реплик etcd на отдельных машинах либо на основных нодах кластера. Работает на Master-нодах.
- kube-scheduler. Компонент, который планирует, на каких узлах будут разворачиваться поды. При этом он учитывает множество факторов, включая требования к ресурсам, ограничения, местонахождение данных и так далее. Работает на Master-нодах.
- kube-controller-manager. Компонент, который запускает процессы контроллеров. Работает на Master-нодах.
- kubelet. Cлужба, которая отвечает за управление состоянием ноды: запуск, остановку и поддержание работы подов и контейнеров. Работает на Worker-нодах.
- kube-proxy. Служба, которая управляет правилами балансировки нагрузки. Она конфигурирует правила iptables или IPVS, через которые осуществляется роутинг и проксирование. Работает на Worker-нодах.
объекты кластера
Nodes (Ноды, узлы)
- Master (мастер-нода) — узел, который управляет всем кластером. Он следит за остальными нодами и распределяет между ними нагрузку. Как правило, мастер-нода занимается только управлением и не берет на себя никакие рабочие нагрузки. Для повышения отказоустойчивости мастер-нод должно быть несколько.
- Worker (рабочие ноды) — узлы, на которых и работают контейнеры. На одном узле может работать много контейнеров в зависимости от параметров ноды (объем памяти и CPU) и требований контейнера.
Pods (Поды)
Это абстрактный объект Kubernetes, который представляет собой группу из одного или нескольких контейнеров. Контейнеры внутри пода вместе запускаются и работают, имеют общее хранилище и сетевые ресурсы. Под — минимальная единица, которой оперирует Kubernetes, то есть он не управляет контейнерами напрямую, он «оборачивает» их в поды и управляет ими. Под и все его контейнеры работают на одном узле и остаются там до окончания работы.
Controllers (Контроллеры)
Контроллеры — это общее название класса средств управления, которые следят за кластером и стараются поддерживать желаемое состояние. Есть несколько типов контроллеров, которые следят за ресурсами и делают это немного по-разному, например:
- Deployment — это описание желаемого состояния для подов; указание Kubernetes, как он должен управлять жизненным циклом подов. Поддерживает набор подов с нужной конфигурацией, управляет обновлениями и откатами. Самый распространенный способ разместить приложение в Kubernetes.
- ReplicaSet — создает стабильный набор подов, выполняющих одну и ту же задачу. Гарантирует, что всегда работает указанное число реплик подов. То есть если с каким-то подом что-то случится, Kubernetes запустит новый, чтобы число реплик оставалось заданным. Обычно это служебный объект, который Kubernetes создает сам.
- StatefulSet — используется для управления приложениями с отслеживанием состояния (Stateful-приложениями) с помощью постоянного хранилища.
- DaemonSet — гарантирует, что все или некоторые узлы запускают копию пода. То есть по мере добавления узлов в кластер добавляются поды.
- Job — недолговечные рабочие нагрузки, используемые для выполнения одной задачи. Job создает один или несколько подов и дождется, пока они выполнят свою работу.
- CronJob — создает задачи по расписанию.
Services (Сервисы)
Это абстракция, которая объединяет поды в логическую группу и определяет политику доступа к ним. То есть что-то вроде маршрутизатора и балансировщика нагрузки между подами.
Поды — непостоянные ресурсы. Они могут уничтожаться, пересоздаваться, переезжать на другие ноды и менять IP-адреса. Если внешняя система или сервис захотят обратиться к поду, то они должны постоянно следить за его жизненным циклом и знать, куда обратиться в конкретный момент времени. Это неудобно и неправильно.
Поэтому в Kubernetes существуют сервисы, которые знают:
- сколько всего подов, то есть сколько реплик у деплоймента;
- на каких хостах они работают;
- какие из них сейчас доступны, а какие нет.
Сервис принимает запрос от внешних систем или других сервисов, решает, какому именно поду адресовать запрос, и адресует его. При этом внешней системе не нужно знать о жизненном цикле подов: они обращаются к сервису по DNS-именам, которые всегда постоянны.
Persistent Volumes (Постоянные тома)
Контейнеры по своей природе непостоянные сущности. Они могут быть в любой момент уничтожены или перезапущены. Идея контейнеров в том, что они легко «умирают» и появляются заново при необходимости. Поэтому любые постоянные данные нужно хранить где-то вне контейнера. Но контейнеры изолированы от основной системы — это сделано для безопасности.
Для работы с PV используются два ресурса: PersistentVolume и PersistentVolumeClaim.
- PersistentVolume — это место, где хранятся постоянные данные: раздел на жестком диске, облачное хранилище или распределенная файловая система (CephFS, NFS и др.). Жизненный цикл PV не зависит какого-то отдельного контейнера или пода. Если контейнер или под уничтожается, PV остается.
- PersistentVolumeClaim — это запрос на использование хранилища. Под отправляет этот запрос в PV с просьбой выделить ему место в постоянном хранилище. Storage Provisioner (специальная программа, которую запускает Kubernetes) оценивает запрос и принимает решение, где лучше выделить место, ведь PV может быть несколько и они могут быть разных типов. Когда решение найдено, PVC выделяет место и возвращает результат поду.
Такой подход позволяет приложениям абстрагироваться от конкретной реализации хранилища. Вместо того чтобы запрашивать конкретное хранилище по конкретному адресу, приложения просто запрашивают PVC, как бы говоря: «Мне нужно 1GB для моих данных». А PersistentVolume уже сам определяет, где находится это хранилище, и резервирует место для пода.
Namespaces (пространства имен)
Это возможность разделить один физический кластер Kubernetes на несколько виртуальных, каждый из которых изолирован от других. Подобно тому, как один физический компьютер разбивается на несколько виртуальных машин. Как правило, пространства имен создают для того, чтобы разделить разные проекты, команды или среды развертывания (dev, test, prod).
Ресурсы в пространствах имен скрыты друг от друга, но по умолчанию не изолированы полностью. Сервис из одного Namespace может общаться с сервисом из другого Namespace. При необходимости Namespace можно изолировать полностью, это бывает полезно при разграничении доступа.
В каждом пространстве имен есть свой набор ресурсов: поды, сервисы, развертывания. В одном пространстве имен у ресурсов должны быть уникальные названия, но эти же названия можно использовать в других Namespace. Однако не все ресурсы входят в пространство имен, например, ноды и Persistent Volumes доступны всему кластеру.
НЕОБХОДИМОСТИ
Мониторинг . Часто для мониторинга используется связка Prometheus + Grafana. Первый инструмент собирает метрики, второй визуализирует их. Можно мониторить как инфраструктуру самого Kubernetes, так и свои приложения.
Инструменты для разработки . Например, Jenkins позволяет настроить процесс непрерывной интеграции, а пакетный менеджер Helm помогает создавать единые шаблоны для описания приложений и запускать их.
Инструменты безопасности . Например, Kubesec. Он может обнаруживать избыточные привилегии и разрешения, предоставленные поду, запуск контейнера с Root-полномочиями или опасные монтирования вроде /proc хоста или сокета Docker.
Service Mesh . Например, Istio — это инструмент конфигурации Service Mesh; полноценный фреймворк для подключения, управления и мониторинга микросервисной архитектуры.