Kubernetes компоненты: мастер компоненты

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

Мастер компоненты (Master Components)

Мастер компоненты предоставляют уровень управления кластером. Мастер компоненты принимают глобальные решения о кластере (например, планирование (scheduling)), и они обнаруживают и реагируют на события кластера (например, запускают новый pod (Наименьший и простейший Kubernetes объект. Pod представляет набор запущенных контейнеров в кластере.), когда поле replicas развертывания (deployment) не удовлетворено).

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

kube-apiserver

Компонент на мастере, который предоставляет API Kubernetes. Это фронтенд для уровня управления Kubernetes.

Он спроектирован с возможностью горизонтального масштабирования, то есть он масштабируется путем развертывания большего количества его экземпляров.

etcd

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

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

kube-scheduler

Компонент на мастере, который наблюдает за вновь созданными pod'ами, которым не назначен узел (node), и выбирает узел, на котором они будут работать.

Факторы, принимаемые во внимание при планировании решений, включают индивидуальные и коллективные требования к ресурсам, аппаратные/программные/по политикам ограничения (hardware/software/policy constraints), спецификации сходства и различия, локальность данных, помехи между нагрузками и предельные сроки.

kube-controller-manager

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

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

Эти контроллеры включают в себя:

  • Контроллер узла (Node Controller): Отвечает за уведомление и реагирование при выходе из строя узлов.
  • Контроллер репликации (Replication Controller): отвечает за поддержание правильного количества pod'ов для каждого объекта контроллера репликации в системе.
  • Контроллер конечных точек (Endpoints Controller): заполняет объект конечных точек (то есть присоединяется к службам и модулям).
  • Контроллеры учетных записей и токенов службы (Service Account & Token Controllers): создание учетных записей по умолчанию и токенов доступа API для новых пространств имен.

cloud-controller-manager

cloud-controller-manager запускает контроллеры, которые взаимодействуют с базовыми облачными провайдерами. Бинарный файл cloud-controller-manager - это альфа-функция, представленная в выпуске Kubernetes 1.6.

cloud-controller-manager запускает только циклы контроллера, относящиеся к облачному провайдеру (cloud-provider-specific). Вы должны отключить эти циклы контроллера в kube-controller-manager. Вы можете отключить циклы контроллера, установив флаг --cloud-provider на external при запуске kube-controller-manager.

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

Следующие контроллеры имеют зависимости поставщика облака:

  • Контроллер узла (Node Controller): для проверки поставщика облака, чтобы определить, был ли удален узел в облаке после того, как он перестал отвечать
  • Route Controller: для настройки маршрутов в базовой облачной инфраструктуре
  • Service Controller: для создания, обновления и удаления балансировщиков нагрузки облачного провайдера
  • Volume Controller: для создания, подключения и подключения томов, а также взаимодействия с облачным провайдером для организации томов

Читайте также:


Комментарии

Отправить комментарий

Популярные сообщения из этого блога

Контроллеры в Kubernetes: DaemonSet

Изображение
DaemonSet гарантирует, что все (или некоторые) узлы запускают копию Pod. Когда узлы добавляются в кластер, к ним добавляются Pod'ы. Когда узлы удаляются из кластера, эти Pod'ы удаляются. Удаление DaemonSet приведет к очистке созданных им Pod'ов. Некоторые типичные применения DaemonSet : запуск демона кластерного хранилища, такого как glusterd, ceph, на каждом узле. запуск демона сбора журналов на каждом узле, таком как fluentd или logstash. запуск демона мониторинга узла на каждом узле, таком как экспортер узлов Prometheus, агент Sysdig, collectd, Dynatrace OneAgent, агент AppDynamics, агент Datadog, агент New Relic, агент Ganglia gmond или агент Instana. В простом случае один DaemonSet, охватывающий все узлы, будет использоваться для каждого типа демона. Более сложная установка может использовать несколько DaemonSets для одного типа демона, но с разными флагами и/или разными запросами памяти и процессора для разных типов оборудования. Написание спецификации Daemon...
Далее...

Контроллеры в Kubernetes: ReplicaSet

Изображение
Цель контроллера ReplicaSet - поддерживать стабильный набор реплик (экземпляров) Pod'ов, работающих в любой момент времени. Как таковой, он часто используется, чтобы гарантировать наличие определенного количества идентичных Pod'ов. Как работает ReplicaSet ReplicaSet задается полями , включая селектор (selector) , который указывает, как идентифицировать Pod'ы, которые он может приобрести, количество реплик (replicas) , указывающих, сколько Pod'ов он должен поддерживать, и шаблон (template) Pod'ов , указывающий данные новых Pod'ов, которые он должен создать для соответствия критерию количества реплик. Затем ReplicaSet выполняет свое предназначение, создавая и удаляя Pod'ы по мере необходимости для достижения желаемого числа. Когда ReplicaSet нуждается в создании новых Pod'ов, он использует свой шаблон Pod'ов для их создания. Ссылка, которую ReplicaSet имеет на свои Pod'ы, осуществляется через поле metadata.ownerReferences Pod'ов, которое у...
Далее...

Контроллеры в Kubernetes: StatefulSet

Изображение
StatefulSet - это объект workload API, используемый для управления приложениями с отслеживанием состояния. Управляет развертыванием и масштабированием набора Pod'ов, а также предоставляет гарантии относительно порядка и уникальности этих Pod'ов. Подобно Deployment, StatefulSet управляет Pod'ами, основанными на идентичной спецификации контейнера. В отличие от Deployment, StatefulSet поддерживает липкую (sticky) идентификацию для каждого из своих Pod'ов. Эти Pod'ы созданы из одной и той же спецификации, но не являются взаимозаменяемыми: у каждого есть постоянный идентификатор, который он поддерживает при любом перепланировании. StatefulSet работает по тому же шаблону, что и любой другой контроллер. Вы определяете желаемое состояние в объекте StatefulSet, а контроллер StatefulSet делает все необходимые обновления, чтобы получить его из текущего состояния. Использование StatefulSet StatefulSet полезны для приложений, которым требуется одно или несколько из следующ...
Далее...