Политика как код для Kubernetes с Kyverno

Применяйте передовые практики Kubernetes в своей организации с помощью CRD

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

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

Как работает Kyverno?

Kyverno работает с использованием контроллера динамического доступа, который проверяет каждый запрос, который вы отправляете через Kubectl на сервер Kube API. Если запрос соответствует политике, Kyverno применяет ее. В противном случае он отклоняет запрос с определенным сообщением.

Таким образом, это позволяет Kyverno предоставлять такие функции, как:

Проверка ограничений ЦП и памяти.
Обеспечение того, чтобы пользователи не меняли сетевые политики по умолчанию.
Проверка соответствия имени ресурса определенному шаблону.
Обеспечение того, чтобы определенные ресурсы всегда содержали определенную метку.
Запрещение удалений и изменений для определенных ресурсов.
Автоматически менять imagePullPolicy на Always, если тег изображения - latest.
Создайте сетевую политику по умолчанию для каждого нового пространства имен.

Kyverno использует пользовательские определения ресурсов для определения политик, и писать политики так же просто, как применять их с помощью kubectl.

Kyverno выполняет три основные функции:

Проверка
Мутация
Поколение

Давайте посмотрим на несколько примеров манифестов для каждого из них.

Проверка

Отличный вариант использования для этого - убедиться, что у всех модулей должен быть запрос ресурсов и установлен лимит. Следующий пример прекрасно это объясняет:

Хотя по большей части это не требует пояснений, validationFailureAction указывает, применять ли это требование (с помощью enforce) или только проверять его (с помощью audit) и сообщать о нарушениях.

Мутация

Мутация означает изменение ресурсов, если они соответствуют определенному сценарию. Отличным примером этого является изменение imagePullPolicy на Always, если тег изображения - latest.

Генерировать

Generate, как следует из названия, генерирует ресурс для определенного события. Например, если кто-то создает новое пространство имен, мы можем захотеть применить сетевую политику по умолчанию.

Практика

Теперь давайте посмотрим на Киверно в действии. Мы установим Kyverno, а затем применим политику валидации для проверки наличия определенной метки. Если метка не существует, Kyverno отклонит запрос. В противном случае он его применит.

Предпосылки

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

Установить Kyverno

Установить Kyverno несложно. Вы можете применить манифест Kyverno Kubernetes, доступный на GitHub, или установить последнюю версию Helm Chart.

Использование манифеста

kubectl create -f https://raw.githubusercontent.com/kyverno/kyverno/master/definitions/release/install.yaml

Использование диаграммы Helm

helm repo add kyverno https://kyverno.github.io/kyverno/
kubectl create ns kyverno
helm install kyverno --namespace kyverno kyverno/kyverno

Чтобы проверить, успешно ли мы установили Kyverno, перечислите все ресурсы в пространстве имен kyverno:

# kubectl get all -n kyverno
NAME                           READY   STATUS    RESTARTS   AGE
pod/kyverno-5f7769d697-x8lkj   0/1     Running   0          21s
NAME                  TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)   AGE
service/kyverno-svc   ClusterIP   10.96.167.8   <none>        443/TCP   21s
NAME                      READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/kyverno   0/1     1            0           21s
NAME                                 DESIRED   CURRENT   READY   AGE
replicaset.apps/kyverno-5f7769d697   1         1         0       21s

Применение политик

Теперь мы подошли к вопросу о политике. Давайте применим политику, которая гарантирует, что все пакеты должны содержать метку app. Создайте файл с именем require-app-label.yaml со следующим содержимым:

Если вы посмотрите на YAML, мы увидим, что есть раздел соответствия, который содержит типы ресурсов, которые мы должны сопоставить. В этом сценарии мы видим стручок. Раздел проверки определяет сообщение, которое мы должны вывести, если проверка не удалась, и шаблон, объясняющий, что нам нужно сопоставить.

Поскольку это CRD, мы можем применить его напрямую и получить желаемый результат:

kubectl apply -f require-app-label.yaml

Тестирование

Итак, время для тестирования! Давайте создадим пакет без ярлыка и посмотрим, что у нас получится:

kubectl run nginx --image=nginx

Итак, как мы видим, проверка не удалась по следующей причине:

Error from server: admission webhook "nirmata.kyverno.resource.validating-webhook" denied the request:
resource Deployment/default/nginx was blocked due to the following policies
require-app-label:
  autogen-check-for-app-label: 'Validation error: label `app` is required; Validation rule autogen-check-for-app-label failed at path /spec/template/metadata/labels/app/'

Это работает должным образом, поскольку мы еще не предоставили ярлык. Теперь давайте попробуем использовать ярлык name=nginx:

kubectl run nginx --image=nginx --labels="name=nginx" --generator=run-pod/v1

Это тоже не работает, поскольку ярлык приложения все еще отсутствует. Давайте создадим модуль NGINX с меткой app=nginx:

kubectl run nginx --image=nginx --labels="app=nginx" --generator=run-pod/v1

Как видим, контейнер успешно создан. Теперь давайте воспользуемся kubectl для получения модуля и меток:

kubectl get pod nginx --show-labels

Модуль запущен и содержит метку app=nginx.

Заключение

Kyverno - превосходный инструмент «политика как код», который очень эффективен в применении передовых практик на организационном уровне. Поскольку он является родным для Kubernetes, его легко писать и использовать, и для его обслуживания не требуются специализированные разработчики.

Спасибо за прочтение! Надеюсь, вам понравилась статья.