Проверка контроллеров допуска

Эта статья является частью серии. Начните с обзора.

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

Контроллер допуска

Контроллер допуска — это фрагмент кода, перехватывающий запросы на сервер API Kubernetes до сохранения объекта, но после проверки подлинности и разрешения запроса.

Контроллеры допуска могут выполнять проверку, изменение или сочетание обоих. Изменение контроллеров может изменять связанные объекты перед признанием запроса. Валидация контроллеров лишь обеспечивает соответствие запросов определенным предопределённым критериям.

Одной из основных функций контроллеров допуска является регулирование запросов на создание, удаление и изменение объектов. Кроме того, контроллеры допуска могут ограничивать пользовательские команды, например запрашивать подключение к pod через прокси-сервер API. Однако контроллеры допуска не могут блокировать запросы на чтение объектов, включая операции, такие как get, watchили list.

Некоторые компоненты могут повлиять на контроллеры допуска, такие как мутация и проверка вебхуков. При использовании изменяющих и проверяющих веб-перехватчиков в кластере Kubernetes необходимо обеспечить высокий уровень доступности. Неработоспособные узлы не должны блокировать запросы сервера API. Важно отслеживать конвейер управления приемом, чтобы запросы к серверу API не блокировались. Нездоровые контроллеры допуска могут повлиять на возможность изменения и валидность веб-перехватчиков. Контроллеры допуска на основе веб-перехватчиков, которые следует мониторить, включают:

Надстройка политики Azure для кластеров Службы Azure Kubernetes (AKS), которая расширяет Gatekeeper. Gatekeeper — это веб-перехватчик для контроллера допуска Open Policy Agent.
Kyverno, который выполняется в качестве динамического контроллера допуска в кластере Kubernetes. Kyverno получает обратные вызовы на валидацию и модификацию через веб-перехватчики HTTP от API сервера Kubernetes и применяет соответствующие политики для возврата результатов, обеспечивающих соблюдение политик допуска или отклонение запросов. См. справочник по устранению неполадок (например, вызовы веб-перехватчика APIServer) в документации Kyverno по устранению неполадок.

Кроме того, контроллеры допуска, которые не работают должным образом, могут повлиять на различные компоненты, такие как сетки служб. Сетки служб, такие как Istio и Linkerd, используют контроллеры допуска для автоматизации внедрения контейнеров боковинок внутри модуля pod, помимо других функций. Важно оценить и проверить правильность работы контроллеров допуска для обеспечения согласованной работы сетки службы.

Проверка состояния надстройки политики Azure для кластеров AKS

При установке надстройки политики Azure для AKS можно использовать следующие команды kubectl для проверки установки и функциональности контроллеров допуска политик Azure в кластере:

# Verify that Azure Policy pods are running.
kubectl get pod -n gatekeeper-system

# Sample output
...
NAME                                     READY   STATUS    RESTARTS   AGE
gatekeeper-audit-65844778cb-rkflg        1/1     Running   0          163m
gatekeeper-controller-78797d4687-4pf6w   1/1     Running   0          163m
gatekeeper-controller-78797d4687-splzh   1/1     Running   0          163m
...

Выполните предыдущую команду, чтобы проверить доступность модулей pod агента политики Azure в пространстве имен шлюза системы . Если выходные данные не соответствуют вашим ожиданиям, это может указывать на проблему с анализатором допуска, службой API или пользовательским определением ресурса (CRD).

# Check that all API resources are working correctly. Use the following command to list all API resources.
kubectl api-resources

# Sample output
...
NAME                                     SHORTNAMES    APIGROUP                       NAMESPACED   KIND
bindings                                                                              true         Binding
componentstatuses                        cs                                           false        ComponentStatus
configmaps                               cm                                           true         ConfigMap
...

Предыдущая команда помогает убедиться, что все ресурсы API работают правильно. Убедитесь, что выходные данные включают ожидаемые ресурсы без ошибок или отсутствующих компонентов. Используйте команды kubectl get pod и kubectl api-resources, чтобы проверить состояние надстройки Azure Policy для AKS и работоспособность контроллеров допуска в кластере Kubernetes. Регулярно отслеживайте контроллеры допуска, чтобы обеспечить правильную работу, чтобы обеспечить общую работоспособность и стабильность кластера.

Используйте следующую kubectl get команду, чтобы убедиться, что назначения политик применяются к кластеру:

kubectl get constrainttemplates

Замечание

Назначения политик могут занять до 20 минут для синхронизации с каждым кластером.

Выходные данные должны быть похожи на следующий пример:

NAME                                     AGE
k8sazureallowedcapabilities              23m
k8sazureallowedusersgroups               23m
k8sazureblockhostnamespace               23m
k8sazurecontainerallowedimages           23m
k8sazurecontainerallowedports            23m
k8sazurecontainerlimits                  23m
k8sazurecontainernoprivilege             23m
k8sazurecontainernoprivilegeescalation   23m
k8sazureenforceapparmor                  23m
k8sazurehostfilesystem                   23m
k8sazurehostnetworkingports              23m
k8sazurereadonlyrootfilesystem           23m
k8sazureserviceallowedports              23m

Дополнительные сведения см. в следующих ресурсах:

Проверка вебхуков

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

Выполните следующую команду, чтобы получить список валидационных вебхуков в кластере.
```
kubectl get ValidatingWebhookConfiguration -o wide
```
Выходные данные должны быть похожи на следующий пример:
```
NAME                         WEBHOOKS   AGE
aks-node-validating-webhook   1          249d
azure-policy-validating-webhook-configuration   1          249d
gatekeeper-validating-webhook-configuration     1          249d
```
Просмотрите результат, чтобы убедиться, что проверяющие веб-перехватчики присутствуют и их конфигурации такие, как ожидается. Выходные данные включают имя каждого проверяющего веб-перехватчика, количество веб-перехватчиков и возраст каждого веб-перехватчика.
Выполните следующую команду, чтобы вывести список мутационных веб-перехватчиков в кластере:
```
kubectl get MutatingWebhookConfiguration -o wide
```
Выходные данные должны быть похожи на следующий пример:
```
NAME                         WEBHOOKS   AGE
aks-node-mutating-webhook    1          249d
azure-policy-mutating-webhook-configuration    1          249d
gatekeeper-mutating-webhook-configuration      1          249d
```
Проверьте выходные данные, чтобы убедиться, что изменяющие вебхуки указаны правильно, и их конфигурации соответствуют требуемым параметрам. Выходные данные включают имя каждого мутировающего веб-перехватчика, количество веб-перехватчиков и возраст каждого веб-перехватчика.
Выполните следующую команду, чтобы получить конкретные сведения для определенного контроллера допуска:
```
kubectl get MutatingWebhookConfiguration <mutating-webhook-name> -o yaml
```
Замените <mutating-webhook-name> именем мутирующего веб-перехватчика, для которого требуется получить сведения. Выходные данные этой команды отображают YAML-представление указанной конфигурации мутирующего веб-перехватчика.

Выполните команды, приведённые в этом разделе, и просмотрите выходные данные, чтобы убедиться, что валидирующие и изменяющие вебхуки в кластере Kubernetes присутствуют и настроены должным образом. Эта проверка необходима для обеспечения правильного функционирования. Кроме того, важно убедиться, что вебхуки соблюдают политики проверки и изменения ресурсов в кластере.

Соавторы

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

Основные авторы:

Паоло Сальватори | Главный инженер клиента

Другие участники:

Фрэнсис Сими Назарет | Старший технический специалист

Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.

Проверка подключения к реестру контейнеров

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2025-04-22