#azure #aks
Просто сохраню это тут, мои мессаджи с другого телеграм канала.

* я до конца не уверен, что я на 100% верно и корректно описал всё происходящее во время проблемы, но я на 100% решил проблему на всех кластерах с данным уровнем понимания.

#kubernetes #azure #aks #troubleshooting #argo #dapr #api

Ныряем в 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

Да камон.

#kubernetes #azure #aks #troubleshooting #argo #dapr #api

Часть 2 из 2.

Думаю ну может я дурак, Меняю снова, уже не иду в логи, А проверяю на месте.
И картина там такая:

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

Бррр, как такое возможно.
Иду в гугл, нейронку, мне говорят "а ты посмотри - кто последний то меняет объект?".
Смотрю

kubectl get crd subscriptions.dapr.io -o jsonpath='{.metadata.managedFields[*].manager}' | tr ' ' '\n' | sort | uniq -c
      1 argocd-controller
      1 kube-apiserver
      1 kubectl-edit
      1 operator

Пффф, а арго то тут причем?
Снова меняю, снова смотрю - да, арго меняет обратно неймспейс на дефолт.
Иду в репозиторий арго, но там просто

---
name: dapr
namespace: dapr-system
repoURL: https://dapr.github.io/helm-charts/
targetRevision: 1.14.2
chart: dapr

Ну и applicationset есть.
А больше мы ничего не меняем.
Снова документация, гугл.
Оказалось вот что:
- арго выкачивает ВЕСЬ чарт, внутри есть директория CRD и там внутри дефолт(путь к чарту был выше, внутри есть CRD директория с манифестами).

Промежуточное описание проблемы:
каждый N период времени оператор DAPR меняет namespace в CRD, тут же сам applicationset DAPR переходит в OutOfSync, арго начинает резко синкать, подтягивает весь чарт, видит, что поменялся CRD и меняет на дефолт. И так по кругу. Насилие ради насилия.

Я и коллега начали фиксить это несколькими вариантами через applicationset, типа

---
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
...
  template:
...
    spec:
...
      ignoreDifferences:
...
        - group: apiextensions.k8s.io
          kind: CustomResourceDefinition
          name: subscriptions.dapr.io
          jqPathExpressions:
            - .spec.conversion.webhook.clientConfig.service.namespace

Затем снова руками меняю неймспейс, смотрю - ура.
Неймспейс больше не ревратится, в аудит логе АПИ ошибки(этой) больше нет.
Да, арго больше не меняет.

Нагрузку снизили на ... на 4%. Мало, но уже что-то.
Выключаю аудит лог(он оооооооооочень дорогой), закрываю одну из саб-тасок касательно АПИ.

Ещё раз описание ишшуи:
- задеплоили арго аппликейшнсет через сторонний чарт с DAPR
- арго создаёт все сущности через хелмп темплейт (даже те, о которых мы в явном виде не знали)
- затем вебхук от оператора дапр переписывает CRD
- арго при синке видит дифф по CRD и переписывыает его снова
- и так по кругу
Пока не глянешь в кишки и не добавишь в игнор - насилие над апи кубера, так как весь функционал арго и дапра - через кубер апи.

Итог:
- я научился смотреть в логи аудита по Azure AKS API
- сгорел от дурости DAPR оператора и ArgoCD оператора в попытках переписать друг за другом CRD
- узнал про игноры в арго (вообще есть и иные решения для проблемы, но игнор самый простой)
- снизил нагрузку на 4% лишь с одним фиксом

Впереди ещё несколько подходов к апи, есть десятки других ошибок, буду с каждой разбираться отдельно.
Это оказалось интересно.

#eks #aks #kubernetes

Апгрейд кластера кубернетис.
С чего начинать?

Начать сперва с проверки совместимости.
Время от времени некоторые ресурсы меняют версию API.
- что-то становится deprecated, например PSP
- что-то меняет версию с alpha, вырастая до v1
- что-то несёт с собой breaking changes

У AWS EKS есть собственные механизмы EKS Upgrade Insights/preflight‑checks, которые дают подсказки по deprecated API и аддонам прямо перед апгрейдом.
https://aws.amazon.com/blogs/containers/accelerate-the-testing-and-verification-of-amazon-eks-upgrades-with-upgrade-insights/

В OpenShift есть свои "pre‑update" проверки и рекомендации, но они более завязаны на платформу.
Значительная часть логики проверки касается операторов, etcd, сети и прочих специфичных для OpenShift компонентов.
https://docs.redhat.com/en/documentation/openshift_container_platform/4.14/html/updating_clusters/preparing-to-update-a-cluster

У Azure есть AKS Upgrade Readiness Check. AKS автоматически блокирует апгрейд, если обнаружены deprecated API. Так же проверяет не только deprecated API, но и всякие PDB, квоты, серты, IP адреса в сабнете​ и так далее.
https://learn.microsoft.com/en-us/azure/aks/upgrade-cluster

Это всё облачные куберы и их вендорлок решения.

Для bare-metal кластеров и для клауд куберов есть более универсальные решения:
- консольные утилиты для проверки всех сущностей куба (локально или в CICD):
- - https://github.com/doitintl/kube-no-trouble
- - https://github.com/kubepug/kubepug
- github action для CI/CD
- - https://github.com/FairwindsOps/pluto
- проверки аутдейт/депрекейтед helm чартов (НЕ связана с API/апгрейд, опциональная проверка)
- - https://github.com/FairwindsOps/Nova

Крайне важно понимать, что AKS проверяет deprecated API в течение 12 часов перед апгрейдом, а EKS использует 30-дневное окно, что важно для планирования процесса upgrade. То есть даже если вы исправили deprecated API, ошибка может оставаться в течении указанного времени. Планируйте заранее.

Всё эти проверки необходимо сделать ДО обновления кластера, иначе у вас будут весёлые часы после апгрейда.