Как использовать приложение на стороне сервера в операторах K8S

Узнайте о преимуществах SSA по сравнению с CSA

Операторы — это программные расширения для Kubernetes, которые используют «пользовательские ресурсы для управления приложениями и их компонентами».

https://kubernetes.io/docs/concepts/extend-kubernetes/operator/

Шаблон оператора — это то, на что мы можем положиться, когда есть задачи, которые родные ресурсы, такие как Deployment и Pod, не могут выполнить: CRD позволяет добавлять различные поля; webhook выполняет проверку и мутацию, в полной мере используя возможности APIserver; цикл управления поддерживает согласованность ресурсов в конечном итоге, что является одной из лучших функций Kubernetes.

Сообщество продемонстрировало сильную поддержку разработки операторов и поделилось несколькими способами реализации операторов. Если вы используете такие вспомогательные инструменты, как kubebuilder, kube-rsили Kopr, но не используете декларативные методы, такие как очарование или KUDO, при разработке операторов, вы можете настроить оператор, определив CRD и контроллер.

Звучит легко, верно?

Большое «нет», если вы принимаете во внимание производительность. Операторы иногда нестабильны после развертывания. Например, частые согласования влияют на производительность всего кластера, когда количество ресурсов достигает определенного масштаба, подвергая риску стабильность платформы. Как видно из следующего мониторинга оператора workqueue, задачи накапливались из-за медленной логики согласования и слишком частых требований к обновлению ресурсов.

Get-Modify-Put не идеален

Как и kubectl apply, Get/List-Modify-Action является наиболее распространенным приложением на стороне клиента (CSA), в котором Action может быть create, update и delete. Этот метод Список заданий Cron, затем обновите ресурсы по-прежнему демонстрируется в последнем руководстве по kubebuilder, хотя его дефекты остаются нерешенными.

Операции Get/List и Action не являются атомарными, что означает, что несколько модулей операторов могут согласовывать один и тот же ресурс с увеличением нагрузки и масштаба, что приводит к ошибкам конфликта. Затем требуется дальнейшая обработка ошибок или повторная попытка.
Операции Get/List создают огромную нагрузку на APIServer, когда в кластере десятки тысяч ресурсов, увеличивая среднее время работы, накапливая запросы и замедляя согласование.
Каждое обновление action затрагивает все объекты, не обеспечивая точного контроля разрешений на ресурсы.
Устаревшее обновление контроллера вызовет несоответствия в ресурсах и последующие логические проблемы, которые раздражают, даже если они в конечном итоге восстановятся благодаря функции Kubernetes.

Применение на стороне сервера (SSA)

Поскольку SSA становится методом apply по умолчанию в Kubernetes, мы также должны идти в ногу со временем. В следующем списке показано, как SSA может компенсировать все недостатки CSA:

Нет необходимости Get/List. SSA позволяет владельцам операторов применять ресурсы и систему для определения правильного порядка запросов, значительно повышая производительность APISever. Этот тип контроллера также называют реконструктивным контроллером.
Меньшее количество неудачных попыток — положительный результат, когда разработчики перестают использовать анатомический шаблон Get-Modify-Put.
Легче повторить попытку при возникновении конфликта. Хотя конфликты могут указывать на неправильную передачу права собственности, вы все равно можете повторить попытку с более информативными сообщениями об ошибках.
Легко кодировать. Это более независимый от языка способ применения объектов без использования kubectl. клиентские примеры.
Легко изменить с помощью действия thepatch. Если не считать создания полей с нуля, SSA с patch более естественна, фокусируясь на нужных вам полях и пропуская те, которые вам не нужны.

Упражняться

«Разговоры дешевы; покажи мне код».

Создайте оператор kubebuilder(v4).

Инициировать проект

kubebuilder init --domain slaise.domain --repo slaise.domain/user --plugins=go/v4-alpha

Определите ресурс и создайте контроллер

kubebuilder create api --group identify --version v1 --kind User

Затем мы получаем большую часть кода фреймворка и конфигурацию YAML.

Теперь речь идет о реализации CRD и контроллера. В качестве теста наша задача — включить только два поля id и balance в информацию User, и смоделировать логику обновления balance после ее получения из внешнего интерфейса.

Реализация CRD

Реализация контроллера в режиме `Get-Modify-Put`

Затем протестируйте их в кластере видов.

# create cluster
kind create cluster --image kindest/node:v1.25.3 --config prometheus_kind_cluster.yaml --name prometheus-cluster
# install prometheus
helm upgrade --install --wait --timeout 15m \
                                --namespace monitoring --create-namespace \
                                --repo https://prometheus-community.github.io/helm-charts \
                                kube-prometheus-stack kube-prometheus-stack --values prometheus_kubeetcd.yaml
# port-forward
kubectl port-forward -n monitoring  svc/kube-prometheus-stack-prometheus 9090:9090

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

SSA в контроллере

Это непростая задача для SSA в контроллере из-за ограниченной поддержки со стороны kubebuilder. Основная причина заключается в том, что CRD kubebuilder зависит от поля JSON, поэтому значение по умолчанию будет введено во время повторного исправления, если полей omiempty. Во-вторых, SSA требует, чтобы каждое поле указывало явное fieldmanager комплексное обновление. Кроме того, вышестоящие controller-gen и controller-tools не реализовали соответствующий код формирования.

Таким образом, в настоящее время существует только два способа реализации SSA в контроллере.

Внедрив applyconfigurations. Для собственных ресурсов вы можете обратиться к этой статье (Применение на стороне сервера), чтобы увидеть поддержку в клиенте.
С client.patch. Вам необходимо получить Get и выполнить patch после этого, за исключением операции создания, в которой объект может быть сконструирован напрямую.

Вот пример с client.patch:

Этот подход все еще не является полной реализацией SSA, и не все проблемы, упомянутые выше, решены. В идеальной ситуации не обязательно получать ресурс, а применять его непосредственно в конечном состоянии. И мы принудительно обновляем все поля с помощью одного диспетчера полей, что противоречит намерению настройки диспетчера полей. В любом случае, patch действие само по себе является значительным скачком в производительности.

Снова установите его в кластер и откройте Prometheus, чтобы увидеть количество действий в секунду.

Заключение

SSA значительно повысила производительность операторов и становится более стандартизированным способом применения ресурсов, постепенно вытесняя CSA из истории. Тем не менее, нам по-прежнему нужны дополнительные инвестиции в платформу и инструменты для всего сообщества, чтобы облегчить ее применение.