Как операторы работают в Kubernetes
Операторы Kubernetes поначалу могут показаться сложными, но если вы понимаете Kubernetes, вы можете легко распространить эти знания на операторов Kubernetes. В первой части этой серии был представлен обзор операторов Kubernetes и того, что они делают. В этой статье объясняются аспекты работы кластера Kubernetes, включая структуру кластера, способы управления рабочими нагрузками и процесс согласования.
Структура операторов Kubernetes
Кластер Kubernetes рассматривает оператора как приложение, развернутое в качестве рабочей нагрузки. Это специализированное приложение управляет другим ресурсом, например другим приложением, размещенным в Kubernetes.
Оператор управляет операндом , используя набор управляемых ресурсов :
- Операнд : Управляемый ресурс, который оператор предоставляет как услугу.
- Управляемые ресурсы : объекты Kubernetes, которые оператор использует для создания операнда.
По умолчанию Kubernetes хорошо справляется с рабочими нагрузками без сохранения состояния. Они настолько похожи, что Kubernetes использует одинаковую логику для управления ими всеми. Рабочие нагрузки с отслеживанием состояния более сложны, и каждая из них отличается друг от друга и требует индивидуального управления. Здесь на помощь приходят операторы.
Базовый оператор состоит из компонентов, изображенных на рисунке 1.
Следующие компоненты образуют три основные части привода:
- API : данные, описывающие конфигурацию операнда. API включает в себя:
- Определение пользовательского ресурса (CRD) , которое определяет схему параметров, доступных для настройки операнда.
- Programmatic API , который определяет ту же схему данных, что и CRD, и реализуется с использованием языка программирования оператора, такого как Go.
- Пользовательский ресурс (CR) , который указывает значения параметров, определенных CRD; эти значения описывают конфигурацию операнда.
- Контроллер : Мозги оператора. Контроллер создает управляемые ресурсы на основе описания в пользовательском ресурсе; контроллеры реализованы с использованием языка программирования оператора, например Go.
- Учетные записи ролей и служб : ресурсы управления доступом на основе ролей (RBAC) Kubernetes с разрешениями, которые позволяют контроллеру создавать управляемые ресурсы.
Конкретный оператор может быть намного сложнее, но он по-прежнему будет содержать эту базовую структуру.
Архитектура Kubernetes
Кластер Kubernetes состоит из плана управления, рабочих узлов и API облачного провайдера, как показано на рис. 2.
Рисунок 2: Архитектура Kubernetes.Следующие компоненты образуют две основные части кластера:
- Рабочие узлы : Компьютеры, на которых выполняются рабочие нагрузки.
- Плоскость управления : Компоненты, управляющие кластером, его узлами и рабочими нагрузками.
- API-сервер : API для плоскости управления, которую клиенты используют для управления кластером.
- Диспетчер контроллера : Запускает процессы контроллера; каждый контроллер несет определенную ответственность в рамках управления кластером.
Операторы используют только рабочие узлы и компоненты плоскости управления.
Операторы работают в рабочих узлах. Однако операторы реализуют контроллеры, работающие в плоскости управления. Поскольку операторы запускают контроллеры на рабочих узлах, они фактически расширяют плоскость управления на рабочие узлы.
Кластер всегда имеет два состояния: желаемое и текущее. Желаемое состояние представляет объекты, которые должны существовать в кластере. Текущее состояние представляет реально существующие объекты. Контроллеры управляют состоянием кластера, согласовывая текущее состояние с желаемым. Контроллеры Kubernetes работают в плоскости управления.
Почти каждый объект Kubernetes включает в себя два вложенных поля объекта, в которых хранится желаемое и текущее состояние объекта — спецификация (представленная в YAML разделом спецификации) и статус (представленный в YAML разделом состояния). Эти два поля используются контроллером оператора для согласования своих операндов. Когда вы хотите обновить желаемое состояние, вы обновляете настройки в поле спецификации в пользовательском ресурсе. После того как кластер обновит операнд, контроллер сохранит текущее наблюдаемое состояние управляемых ресурсов в поле состояния, тем самым сохранив представление текущего состояния пользовательского ресурса.
Развертывание рабочих нагрузок в Kubernetes
Способ, которым оператор развертывает рабочие нагрузки и управляет ими, аналогичен тому, как администратор развертывает рабочие нагрузки и управляет ими. Базовая рабочая нагрузка, развернутая в кластере Kubernetes, имеет структуру, показанную на рис. 3.

Рабочая нагрузка состоит из развертывания
, на котором выполняется набор реплик Pod
, каждая из которых запускает дубликат Container
. Развертывание
предоставляется как служба
, которая предоставляет клиентам единую фиксированную конечную точку для вызова поведения в наборе реплик.
Как операторы развертывают рабочую нагрузку
Оператор развертывает рабочую нагрузку почти так же, как это делает человек-администратор (или конвейер сборки). В конце концов, операторы предназначены для автоматизации задач, выполняемых ИТ-администраторами.
Как показано на рис. 4, API Kubernetes не знает, является ли клиент администратором или оператором, поэтому кластер развертывает рабочую нагрузку одинаковым образом. Все, что происходит в плоскости управления, то же самое.
Рисунок 4. Как развертываются рабочие нагрузки.Развертывания рабочей нагрузки Kubernetes
Администратор использует клиентские инструменты, такие как kubectl
CLI и файлы YAML, чтобы указать кластеру, какие ресурсы создавать, например, для развертывания рабочей нагрузки. Когда администратор запускает команду типа
kubectl apply -f my-manifest.yaml
, что на самом деле происходит?
- Клиентский инструмент взаимодействует с Kube API, который является интерфейсом плоскости управления.
- API выполняет свои команды, изменяя желаемое состояние кластера, например добавляя новый ресурс, описанный в
мой-манифест.yaml
. - Контроллеры в плоскости управления вносят изменения в текущее состояние кластера, чтобы привести его в соответствие с желаемым состоянием.
Вуаля! Рабочая нагрузка развернута.
Развертывание рабочей нагрузки оператора
Когда оператор развертывает рабочую нагрузку, он делает почти то же самое:
- CR действует как файл YAML администратора, предоставляя абстрактное описание ресурса, который должен быть развернут.
- Контроллер использует свой API для чтения CR и использует API Kubernetes для создания ресурса, описанного CR, так же, как администратор, выполняющий команды
kubectl
.
API Kubernetes не знает, является ли его клиент администратором, использующим клиентские инструменты, или оператором, работающим с контроллером. В любом случае он выполняет команды клиента, обновляя желаемое состояние, которое контроллеры Kubernetes используют для обновления текущего состояния. Таким образом, оператор делает то же, что и администратор, но автоматизированным способом, инкапсулированным в реализации его контроллера.
Как операторы согласовывают состояния кластера Kubernetes
Помните, что кластер Kubernetes всегда имеет два состояния. Желаемое состояние представляет объекты, которые должны существовать в кластере, а текущее состояние представляет объекты, которые действительно существуют.
В операторах Kubernetes контроллеры управляют состоянием кластера, согласовывая текущее состояние, чтобы оно соответствовало желаемому состоянию. Контроллеры Kubernetes работают в плоскости управления. В следующем разделе рассматривается, как происходит согласование в обычных рабочих нагрузках Kubernetes, а затем как операторы Kubernetes распространяют это согласование на рабочие узлы.
Цикл согласования в плоскости управления
В типичном кластере Kubernetes диспетчер контроллеров запускает контроллеры в цикле согласования в плоскости управления. Каждый контроллер отвечает за управление определенной частью поведения кластера. Диспетчер контроллеров запускает цикл управления, который позволяет запускать каждый контроллер, вызывая его метод Reconcile()
.
Когда контроллер выполняет согласование, его задачей является корректировка текущего состояния, чтобы оно соответствовало желаемому состоянию. Поэтому контур управления в диспетчере контроллеров является циклом согласования, как показано на схеме на рис. 5.
Рисунок 5: Цикл согласования Kubernetes.Цикл согласования в рабочих узлах
В то время как контроллеры Kubernetes работают в плоскости управления, контроллеры операторов работают в рабочих узлах. Это связано с тем, что оператор развертывается в кластере Kubernetes в качестве рабочей нагрузки. Как и любая другая рабочая нагрузка, в кластере размещается рабочая нагрузка оператора на рабочих узлах.
Каждый оператор расширяет цикл согласования, добавляя свой пользовательский контроллер в список контроллеров диспетчера контроллеров (см. рис. 6).
Рисунок 6: Цикл согласования с операторами.Когда диспетчер контроллеров запускает цикл согласования, он делает две вещи:
- Приказывает каждому контроллеру в плоскости управления согласовать себя.
- Указывает пользовательскому контроллеру каждого оператора согласовать себя.
Как и в случае со стандартным контроллером, Reconcile()
позволяет пользовательскому контроллеру реагировать на любые изменения с момента последнего согласования.
Согласование состояний
До сих пор мы рассмотрели взаимосвязь между желаемым состоянием кластера и его текущим состоянием, а также то, как контроллер согласовывает эти два состояния для ресурсов, которыми он управляет.
Способ согласования контроллеров Kubernetes и пользовательских контроллеров оператора аналогичен, как показано на рис. 7.
Контроллеры операторов работают на один уровень абстракции выше, чем контроллеры Kubernetes. Контроллеры Kubernetes согласовывают встроенные , тип
, аналогичный Развертывание
и Работа
на нижнем уровне , вид
, аналогичный Pod
. Пользовательские контроллеры согласовывают CRD, такие как Memcached
и Etcd
, с рабочей нагрузкой типа
, например Deployment
и Service
. Таким образом, текущее состояние пользовательского контроллера становится желаемым состоянием контроллера Kubernetes.
Оба контроллера типа типа
согласовывают желаемое и текущее состояние, но для развертывания рабочей нагрузки для пользовательского ресурса оператора требуется два этапа преобразования:
- Контроллер оператора преобразует пользовательский ресурс в набор управляемых ресурсов (то есть рабочую нагрузку), которые являются текущим состоянием оператора, но также являются желаемым состоянием плоскости управления.
- Контроллеры Kubernetes преобразуют управляемые ресурсы в работающие модули ( или — операнд) в текущем состоянии плоскости управления.
Резюме
В этой статье показано, как вы можете расширить свое понимание Kubernetes на их операторов. Операторы работают как Kubernetes в нескольких отношениях:
- Мозг оператора — это контроллер, обязанности которого аналогичны обязанностям типичного контроллера Kubernetes в плоскости управления.
- Способ, которым оператор развертывает рабочую нагрузку, аналогичен тому, как администратор развертывает рабочую нагрузку. Плоскость управления не знает разницы.
- Плоскость управления реализует цикл согласования, который позволяет каждому контроллеру согласовывать себя, и операторы добавляют свои контроллеры в этот цикл.
- В то время как контроллеры Kubernetes и настраиваемые контроллеры настраиваются между своим желаемым состоянием и их текущим состоянием, операторы управляют желаемым состоянием как настраиваемым ресурсом и согласовывают его с текущим состоянием, которое представляет собой набор управляемых ресурсов, которые контроллеры Kubernetes используют в качестве желаемого состояния.
Обладая этими знаниями, вы будете лучше подготовлены к написанию собственных операторов и поймете, как они работают в составе Kubernetes.
Последнее обновление: 24 августа 2022 г.
Справочник по синтаксису поисковых запросов для Resource Explorer
AWS Resource Explorer поможет вам найти отдельные ресурсы AWS в ваших аккаунтах AWS. Помочь вы найдете именно те ресурсы, которые ищете, Resource Explorer принимает строки поискового запроса, которые поддерживают синтаксис, описанный в этом разделе. Например, запросы, демонстрирующие использование функции, описанные здесь, см. в разделе Примеры поисковых запросов Resource Explorer.
Как работают запросы в обозревателе ресурсов
Поисковые запросы всегда используют представление. Если вы не укажете его явно, обозреватель ресурсов использует
представление, назначенное по умолчанию для региона AWS, в котором вы работаете.
Представления определяют, какие ресурсы доступны для запроса. Вы можете создать разные представления, каждое из которых возвращает различный набор ресурсов.
Например, можно создать представление, включающее только те ресурсы, которые
отмечен ключом Окружающая среда
и значение Производство
.
Затем вы можете предоставить доступ к этому представлению только тем пользователям, у которых есть
деловая причина для просмотра этих ресурсов. Отдельное представление, включающее
Доступ к ресурсам среды Alpha
или Beta
может осуществляться
разных пользователей, которым необходимо просматривать эти ресурсы. Для получения информации о том, кто контролирует
получает доступ к каким представлениям, см. Предоставление доступа к представлениям Resource Explorer для
поиск.
Синтаксис строки запроса
В этом разделе содержится информация об основных аспектах синтаксиса запроса, фильтров и
операторы фильтрации.
Основы
По своей сути, QueryString
представляет собой набор текстовых ключевых слов в произвольной форме.
которые неявно соединены логическим ИЛИ
оператор. Разделите каждый
ключевое слово от других с помощью пробела, как показано в следующем примере:
EC2 Test Test Gamma
Resource Explorer оценивает этот список ключевых слов, среднее:
EC2 или BILLING или Тест или Gamma Precema
Test или Gamma Precema
Test или Gamma Precema
Test или Gamma Precema
. ресурсы, которые
соответствовать большему количеству условий поиска. Ресурсы, не соответствующие одному или нескольким
терминов не исключаются из результатов. Однако Resource Explorer считает их
снижает релевантность и отодвигает их дальше в результатах поиска.
Если указать пустую строку для параметра QueryString
, ваш
запрос возвращает первую 1000 ресурсов, доступных через представление
используется для операции. Максимальное количество ресурсов, которое может быть возвращено любым
запрос 1000.
Примечание
AWS оставляет за собой право обновлять логику сопоставления и алгоритмы релевантности для оценки ключевых слов в текстовом формате произвольной формы, чтобы мы могли предоставить клиентам наиболее релевантные результаты. Таким образом, результаты возвращаются для тех же запросов с использованием текстовые ключевые слова в свободной форме могут меняться со временем. Где вам нужно больше детерминированные результаты, мы рекомендуем вам использовать фильтры. Логика сопоставления фильтров не меняется со временем.
Фильтры
Вы можете более строго ограничить результаты своего запроса, включив фильтры . В отличие от текста
ключевые слова, фильтры оцениваются в запросе с оператором И . Например, рассмотрим следующий запрос, который
состоит из двух ключевых слов произвольной формы и двух фильтров:
сервис тестового экземпляра: регион EC2: us-west-2
Этот запрос оценивается следующим образом:
(тест ИЛИ экземпляр ) AND service:EC2 AND region:us-west-2
Фильтры всегда оцениваются с использованием логических AND операторы. Если ресурс не соответствует фильтру, этот ресурс не включается в результаты. Результаты примера запроса включают любые ресурсы, которые связаны с Amazon EC2 и находятся в регионе AWS Запад США (Орегон) и имеют по крайней мере один из ключевые слова, прикрепленные каким-либо образом.
Примечание
Из-за неявного И
можно успешно использовать только один
фильтр для атрибута, который может иметь только одно значение, связанное с
ресурс. Например, ресурс может быть частью только одного региона AWS.
Поэтому следующий запрос не возвращает результатов.
region:us-east-1 region:us-west-1
Это ограничение , а не применяется к фильтрам для атрибутов, которые могут
иметь несколько значений одновременно, например тег:
, tag.key:
и tag.value:
.
В следующей таблице перечислены доступные имена фильтров, которые можно использовать в обозревателе ресурсов. поисковый запрос.
Имя фильтра | Описание и пример |
---|---|
| Идентификатор отдельного ресурса, выраженный в виде
Имя ресурса Amazon (ARN). |
| Учетная запись AWS, которой принадлежит ресурс. Обозреватель ресурсов включает в себя выдает только те ресурсы, которые принадлежат указанному учетная запись. |
| Регион AWS, в котором находится ресурс. Примечание Ввод только кода региона (без фильтра, такого как |
| Особый случай для региона Примечание Ввод только ключевого слова |
| Служба AWS, связанная с типом ресурс. Обозреватель ресурсов включает в результаты только те ресурсы, которые создаются и управляются указанной службой. |
| Тип ресурса в |
| Пара ключ/значение тега, выраженная как |
| Частный случай тега Примечание Ресурсы с AWS созданные сервисом теги по-прежнему отображаются в результатах для этого фильтра. |
| Ключ тега. Resource Explorer включает в результаты только ресурсы которые имеют тег с совпадающим ключом, независимо от значения. |
| Значение тега. |
Операторы фильтра
Вы можете изменить свои ключевые слова и фильтры, включив один из показанных операторов в следующей таблице как часть строки.
Оператор | Описание и пример |
---|---|
или » | Окружите фразу из нескольких слов, которую следует рассматривать как
одиночное ключевое слово с символами двойных кавычек ( Если не использовать двойные кавычки, Resource Explorer разбивается фразу на ее компоненты с помощью пробелов или дефисов, и включает ресурсы, соответствующие отдельным компонентам, даже если они не вместе или в другом порядке. |
| Соответствие подстановочным знакам префикса. Вы можете поместить подстановочный знак
(звездочка Важно Единый поиск автоматически вставляет оператор подстановочного знака ( Поиск, выполненный текстовым полем Query на странице поиска ресурсов в
Консоль Resource Explorer делает , а не автоматически добавлять подстановочный знак. Вы можете вставить |
| Важно Если вы используете команду AWS CLI aws resource-explorer-2 search --query-string "-tag:none region:us-east-1" Следующая исправленная строка запроса с aws resource-explorer-2 search --query-string Если изменить порядок фильтров в строке запроса
так что aws resource-explorer-2 search --query-string "region:us-east-1 -tag:none" |
\ | Вы можете экранировать специальные символы, которые должны быть включены
именно так, как показано, а не интерпретировано. Если ваш текст содержит
один из специальных символов ( Кроме того, чтобы предотвратить разбиение выражения Resource Explorer на
дефисы на три отдельных ключевых слова, вы можете окружить
вся фраза в двойных кавычках. Чтобы вставить буквальную обратную косую черту, вставьте два символа обратной косой черты. в ряд. Первая обратная косая черта интерпретируется как экранирование и вторая обратная косая черта — это буквальный символ для вставки. |
Примечание
Если представление включает теги, прикрепленные к ресурсам, то Операция поиска
не выдает ошибки проверки для поиска
строки, потому что недопустимый фильтр также может быть интерпретирован как произвольная форма
текстовый поиск. Например, хотя cat:blue
выглядит как
фильтр, обозреватель ресурсов не может проанализировать его как единое целое, потому что cat:
не является одним из
действительные, определенные фильтры.