Control plane (управляющий слой)#

Компоненты управляющего слоя#

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

Минимальный набор таких компонентов: etcd, API-server, Kube-scheduler, Controller manager.

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

API-server#

API-server — это центральный компонент кластера DropApp. Он является связывающим компонентом для всех остальных сервисов. Все взаимодействие как самих компонентов, так и обращение извне к кластеру проходит через Kube-apiserver и проверяется им.

Это единственный компонент кластера DropApp, который общается с базой данных etcd, где хранится состояние кластера DropApp.

В самом API-Server нет бизнес-логики. API-Server не принимает решения, например, за то, на каком node запустить тот или иной сервис.

В нем существует логика проверки формата запросов, аутентификации, проверки прав и т.д.

Еще одной функцией API-Server является рассылка изменений конфигураций и состояния кластера DropApp.

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

Etcd#

Etcd — это высоконадежное распределенное хранилище данных. DropApp хранит в нем информацию о состоянии существующих кластеров DropApp, сервисах, сети и т. д.

Доступ к данным осуществляется через REST API. При изменениях записей вместо поиска и изменения предыдущей копии, все предыдущие записи помечаются как устаревшие, а новые значения записываются в конец. Позже устаревшие значения удаляются специальным процессом. В небольших временных кластерах etcd можно запускать в единственном экземпляре и на одном node с ведущими компонентами.

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

API-Server является основной точкой управления всего кластера DropApp. API-Server обрабатывает операции REST, проверяет их и обновляет соответствующие объекты в etcd. API-Server обслуживает DropApp API и задуман как простой сервер, с большей частью бизнес-логики, реализованной в отдельных компонентах или в плагинах. Ниже приведены некоторые примеры API, доступных на API-Server:

# pods
api/v1/pods

# services
api/v1/services

# deployments
api/v1/deployments

Когда происходит работа с кластером DropApp с использованием kubectl интерфейса командной строки, взаимодействие осуществляется с основным серверным компонентом API. Команды kubectl преобразуются в HTTP-вызовы REST и вызываются на API-Server.

API-Server также отвечает за механизм аутентификации и авторизации. Все клиенты API должны быть аутентифицированы для взаимодействия с сервером API. Возможно написание клиентских библиотек/приложений DropApp, используя API-Server (например аналог kubectl, chaos engineering system и т.д.).

Kube-scheduler#

Kube-scheduler — это компонент управляющего слоя, с его помощью необходимо отслеживать созданные pods без привязанного node и осуществлять выбор node, на котором pods должны работать. При развертывании pods на nodes, учитывается множество факторов, включая требования к ресурсам, ограничения, связанные с аппаратными/программными политиками, принадлежности (affinity) и непринадлежности (anti-affinity) nodes/pods, местонахождения данных, предельных сроков.

Используя механизм оповещения об изменениях API-Server, Kube-scheduler получает сообщения от управляющего слоя, когда необходимо запустить экземпляр сервиса и принимает решение о том, на каком node он должен быть запущен, и через API-Server обновляет состояние кластера DropApp. Сам Kube-scheduler ничего не запускает.

Kubelet#

Kubelet - это сервис, который управляет pods, основываясь на их спецификации, является главным сервисом для Worker node. Сервис взаимодействует с API-server.

Для запуска полезной нагрузки на nodes используется агент Kubelet. В отличие от компонентов управляющего слоя, Kubelet запущен на каждом node: Master node и Worker node. Kubelet читает событие с помощью API-Server, что экземпляр сервиса распределен посредством Kube-scheduler на node, на котором он работает, и запускает экземпляр сервиса.

Для изоляции сервисов друг от друга они запускаются Kubelet в контейнерном окружении CRI-O. Также c использованием Kubelet возможно отслеживание работоспособности контейнеров, которые были запущены с его помощью.

Особенности последовательности запуска контейнеров в Kubelet#

Kubelet текущих версий DropApp и запускает контейнеры внутри pods последовательно (в том порядке, в котором они указаны в манифесте). При этом последовательность запуска блокируется на postStart Hook (то есть пока webhook не будет выполнен, следующий контейнер не запустится). Порядок старта не должен работать, потому что K8S postStart hook не гарантирует порядок старта, а влияет лишь на lifecycle контейнера (где указан) и на его readinessProbe. Для избежания ошибок проектирования, например, когда прикладной контейнер стартует раньше sidecar и возникают ошибки доступа к внешним ресурсам, следует применять отдельные средства для соблюдения строгой последовательности запуска контейнеров.

Используйте флаг HoldApplicationUntilProxyStarts для добавления перехватчика для задержки запуска приложения до тех пор, пока прокси-сервер pod не будет готов принять трафик, что смягчает некоторые условия конкуренции при развертывании:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello
spec:
  replicas: 1
  selector:
    matchLabels:
      app: hello
      tier: backend
      track: stable
  template:
    metadata:
      labels:
        app: hello
        tier: backend
        track: stable
      annotations:
        proxy.istio.io/config: '{ "holdApplicationUntilProxyStarts": true }'
    spec:
      containers:
      - name: hello
        image: "fake.docker.io/google-samples/hello-go-gke:1.0"
        ports:
        - name: http
          containerPort: 80
        livenessProbe:
          httpGet:
            port: http
        readinessProbe:
          httpGet:
            port: 3333

Значение по умолчанию — false.

Controller-manager#

Controller-manager - это компонент, отвечающий за запуск контроллеров, которые определяют текущее состояние системы.

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

Контроллеры включают:

  • контроллер node (Node Controller): уведомляет и реагирует на сбои node;

  • контроллер репликации (Replication Controller): поддерживает правильное количество pods для каждого объекта контроллера репликации в системе;

  • контроллер конечных точек (Endpoints Controller): заполняет объект конечных точек (Endpoints), то есть связывает сервисы (Services) и pods;

  • контроллеры учетных записей и токенов (Account & Token Controllers): создают стандартные учетные записи и токены доступа API для новых namespaces.

CoreDNS#

CoreDNS - это сервер имен, который выступает в качестве ключевого компонента инфраструктуры кластера DropApp, предоставляя расширяемый механизм для разрешения имен внутри кластера DropApp.

Благодаря своей распределенной архитектуре и возможности использования нескольких источников данных, таких как файлы конфигурации, etcd или сетевые службы за пределами кластера DropApp, CoreDNS обеспечивает устойчивость и надежность DNS-сервиса в кластере DropApp.

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

Компоненты node#

Компоненты node работают на каждом node, поддерживая работу pods и среды выполнения DropApp.

Kube-proxy#

Kube-proxy — это сетевой прокси-сервер, который выполняет маршрутизацию сетевого трафика и управляет сервисами в кластере DropApp. Kube-proxy позволяет отслеживать изменения в конфигурации сервисов и управляет правилами iptables для маршрутизации трафика. Kube-proxy может работать в нескольких режимах: userspace, iptables и ipvs.

Также Kube-proxy может поддерживать балансировку нагрузки и высокую доступность для сервисов в кластере DropApp. Kube-proxy является необходимым компонентом для надежной и безопасной работы приложений.

Pause#

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

Контейнер Pause в DropApp создает namespace для каждого pod, к которому он принадлежит. Это обеспечивает изоляцию и безопасность работы контейнеров внутри pod, так как они могут выполняться в собственных namespaces. Также контейнер pause предоставляет сетевой интерфейс для всех остальных контейнеров, запущенных внутри pods, и задает статический IP-адрес, чтобы они могли взаимодействовать между собой.

Контейнер pause в DropApp является неотъемлемой частью инфраструктуры, и пользователи обычно не должны взаимодействовать с ним напрямую.

Среда выполнения контейнера#

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

CRI-O - это реализация CRI DropApp (Container Runtime Interface), позволяющая использовать среды выполнения, совместимые с OCI (Open Container Initiative). Это облегченная альтернатива Docker в качестве среды выполнения для DropApp.

DropApp позволяет использовать любую среду выполнения, совместимую с OCI, в качестве среды выполнения контейнера для запуска pods.