Проверка контроллеров допуска
Этот материал входит в цикл статей. Начните с обзора.
Контроллеры приема редко вызывают проблемы, но важно обеспечить их правильную функциональность. В этой статье описывается, как контроллеры допуска могут влиять на другие компоненты, если они не работают должным образом. В нем также описываются команды, которые можно использовать для проверки производительности контроллера допуска.
Контроллер допуска
Контроллер допуска — это фрагмент кода, перехватывающий запросы на сервер API Kubernetes до сохранения объекта, но после проверки подлинности и разрешения запроса.
Контроллеры допуска могут выполнять проверку, изменение или сочетание обоих. Изменение контроллеров может изменять связанные объекты перед признанием запроса. Проверка контроллеров гарантирует, что запросы соответствуют определенным предопределенным критериям.
Одной из основных функций контроллеров допуска является регулирование запросов на создание, удаление и изменение объектов. Кроме того, контроллеры допуска могут ограничивать пользовательские команды, например запрашивать подключение к pod через прокси-сервер API. Однако контроллеры допуска не могут блокировать запросы на чтение объектов, включая операции, такие как get
, watch
или list
.
Некоторые компоненты могут повлиять на контроллеры допуска, такие как изменение и проверка веб-перехватчиков. При включении мутации и проверки веб-перехватчиков в кластере Kubernetes необходимо обеспечить высокий уровень доступности. Неработоспособные узлы не должны блокировать запросы сервера API. Важно отслеживать конвейер управления приемом, чтобы запросы к серверу API не блокировались. Неработоспособные контроллеры допуска могут повлиять на изменение и проверку веб-перехватчиков. Контроллеры допуска на основе веб-перехватчиков, которые следует отслеживать, выполните следующие действия.
Надстройка Политика Azure для кластеров Служба Azure Kubernetes (AKS), которая расширяет Gatekeeper. Gatekeeper — это веб-перехватчик контроллера допуска для агента Open Policy.
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 в пространстве имен gatekeeper-system. Если выходные данные не нужны, это может указывать на проблему с контроллером допуска, службой 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 для 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.