Ныряем в Azure AKS API.
Часть 1 из 2.
У нас болел кубернетис апи.
Болел долго, со вкусом.
Словно мужчина 30+ лет с температурой 37.2, с опекой рядом кудахтающей супруги.
Мы честно хотели его вылечить, но у меня лично никогда не было глубокого опыта дебага апи, часть команды было просто пофиг. Вроде работает? Хорошо. Бизнес, само собой, такими вещами и не интересуется.
Это вызывало массу сайд эффектов: 4 или 5 из моих историй это следствие загрузки K8S API.
Работа операторов, работа кеды и dcs демоушн.
Однажды мне
Путь первый. Невежественность.
В кластере много компонентов, которые работают с кубернетес апи.
ArgoCD, Kyverno, десятки операторов. Много всего.
Первый мой шаг - поэтапно вырубать контроллеры
То есть я тупо один за одним вырубал какие-то компоненты.
kubectl scale --replicas 0 sts/name
kubectl scale --replicas 0 deploy/name
и ждал. 30-60 минут, есть ли эффект.
Конечно же предупреждая коллег, и в случае необходимости тут же скейлил вверх.
Эта идея была тупая, я убил несколько часов/дней.
Никакого результата.
Путь второй. Наивность.
Дальше я выбрал путь наивности - ходил по приложениям, операторам и где мог, подкручивал параметры, чтобы обращения к АПИ был реже. Всякие реконсилейшн у арго, демоушн патрони, частота запросов кеда оператора и так далее.
Помогло ли это? Нет. Стало ли лучше? Глобально - да, ведь я просто оттюнил к лучшему.
К пункту наивности я бы добавил все мои попытки разобраться "что не так с апи по метрикам".
Метрики никак и никогда не дают информации кто же даёт основную нагрузку.
Путь третий. Просветление.
Очевидно предыдущие попытки были унылы и тупы.
Почитал интернет, нейронки, документацию.
Первым делом включаю аудит-лог.
Azure-Kubernetes-Monitoring-Diagnostic settings.
Дальше включаю для Kubernetes API и сохранение в Log Analytics workspace.
Сохраняю, иду в
Log Analytics workspace.Там выбираю Logs и ищу сперва все ошибки.
AKSControlPlane
| where Category == "kube-apiserver" and Level == "ERROR"
| limit 40
| project TimeGenerated, Level, Message
Вижу кучу ошибок.
Ок, начнем с рандом частой ошибки:
cacher (subscriptions.dapr.io): unexpected ListAndWatch error: failed to list dapr.io/v1alpha1, Kind=Subscription: conversion webhook for dapr.io/v2alpha1, Kind=Subscription failed: Post "https://dapr-webhook.replaceme.svc:443/convert?timeout=30s": service "dapr-webhook" not found; reinitializing...
Не заостряю внимание на продукте, мне он знаком (можно почитать на https://github.com/dapr/dapr/).
По ошибке проблема сервиса(хоть и странный адрес), а есть ли он?
kubectl get svc -n dapr-system | grep webhook
dapr-webhook ClusterIP 10.0.12.141 <none> 443/TCP
Он есть.
Почему возникает эта ошибка?Сперва смотрю валуес
helm show values dapr/dapr --version 1.14.2
Нет ничего интересно, как и в нашем values файле.
Иду в чарт и качаю его к себе https://github.com/dapr/helm-charts/blob/master/dapr-1.14.2.tgz
Вижу кучу темплейтов, хелперсов, CRD.
В CRD указано, что сам оператор реплейсит CRD.
---
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
...
spec:
group: dapr.io
conversion:
strategy: Webhook
webhook:
clientConfig:
service:
namespace: replaceme # Patched by post-install webhook
То есть оператор время от времени должен реплейсить неймспейс внутри CRD с
replaceme на реальный dapr-system.А он не реплейсит. Хорошо, меняю сам руками, смотрю результат.
kubectl edit crd subscriptions.dapr.io
customresourcedefinition.apiextensions.k8s.io/subscriptions.dapr.io edited
kubectl get crd subscriptions.dapr.io -o yaml | grep namespace
namespace: dapr-system
Радуюсь, иду в логи - а там снова ошибка.
Непонятно. Возвращаюсь обратно а там
kubectl get crd subscriptions.dapr.io -o yaml | grep namespace
namespace: replaceme
Да камон.