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

Последовательность выполнения#

• Последовательность выполнения

• Предусловия

• Правила эксплуатации

• Описание механизмов безопасности

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

  • API-server

  • Etcd

  • Kube-scheduler

  • Kubelet

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

  • Controller-manager

  • CoreDNS

• Компоненты узла

  • Kube-proxy

  • Pause

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

• Результат

Предусловия#

Предварительными условиями выполнения сценариев является развернутый кластер DropApp. Развертывание кластера описано в разделе Установка документа Руководство по установке.

Правила эксплуатации#

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

Описание механизмов безопасности#

Дополнительных механизмов безопасности, относящихся к сценариям администрирования, и рекомендаций по эффективной настройке механизмов безопасности, помимо указанных в документации не требуется.

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

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

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

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

API-server#

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

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

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

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

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

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

Etcd#

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

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

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

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 — это компонент управляющего слоя, с его помощью необходимо отслеживать созданные pod без привязанного узла и осуществлять выбор узла, на котором pod должны работать. При развертывании pod на узлах, учитывается множество факторов, включая требования к ресурсам, ограничения, связанные с аппаратными/программными политиками, принадлежности (affinity) и непринадлежности (anti-affinity) узлам/pod, местонахождения данных, предельных сроков.

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

Kubelet#

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

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

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

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

Kubelet текущих версий DropApp и запускает контейнеры внутри pod последовательно (в том порядке, в котором они указаны в манифесте). При этом последовательность запуска блокируется на 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 Controller): уведомляет и реагирует на сбои;

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

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

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

CoreDNS#

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

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

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

Компоненты узла#

Компоненты узла работают на каждом узле, поддерживая работу pod и среды выполнения 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 создает пространство имен для каждого pod, к которому он принадлежит. Это обеспечивает изоляцию и безопасность работы контейнеров внутри pod, так как они могут выполняться в собственных пространствах имен. Также контейнер pause предоставляет сетевой интерфейс для всех остальных контейнеров, запущенных внутри pod, и задает статический IP-адрес, чтобы они могли взаимодействовать между собой.

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

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

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

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

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

Результат#

Результатом изучения раздела является получение ознакомительной информации об основных инструментах DropApp.