Make. Build. Break. Reflect.

#aws #eks #kubernetes #troubleshooting #одинденьизжизни #argocd

"Алекс, у нас что-то приложение не раскатывается, деплой завис. Кластер новый, вроде ты деплоил, посмотри плиз".

Ну раз я, значит мне и смотреть.
Смотрю в арго что там зависло, перехожу в аппликейшнсет - вижу процессинг.
Processing, что же ты за зверь такой?
Это означает, что ArgoCD обнаружил разницу между желаемым состоянием (в гите) и текущим состоянием (в кластере) и активно пытается синхронизировать ресурсы.
Есть проблема, которая мешает завершить развертывание (например, нехватка ресурсов, неправильная конфигурация, ожидание завершения работы пода или борьба между контроллерами).

На самом деле самый дебильный статус, потому что в практике это может быть что угодно 🐒.
Ладно, надо чинить.

Смотрю сперва "а не может ли кто сражаться за ресурсы?"
Вдруг опять арго и оператор вцепились как два деда.
Я как-то выше писал старый пример про #dapr.

Смотрю:

kubectl get applicationsets APPSET1 \
  -n NAMESPACE \
  -o jsonpath='{.metadata.managedFields[*].manager}' \
  | tr ' ' '\n' | sort | uniq -c

      1 argocd-applicationset-controller
      1 helm

А тут всё нормально:
- helm один раз создал/обновил сам ApplicationSet
- argocd-applicationset-controller дальше управляет этим ApplicationSet и генерит Application(ы)
Значит дело не в конфликте.

Иду дальше, что с самим аппликейшн

kubectl get applications -n NAMESPACE \
  -o wide | grep APP1

APP1             Synced        Progressing

И нет ли там конфликтов

kubectl get applications APP1 -n NAMESPACE \
  -o jsonpath='{.metadata.managedFields[*].manager}' \
  | tr ' ' '\n' | sort | uniq -c

      1 argocd-application-controller
      1 argocd-applicationset-controller

Конфликтов нет, ведь:
- argocd-applicationset-controller следит за соответствием шаблону ApplicationSet.
Он не ходит в кластерные ресурсы (Deployment, Service и т.д.), только создаёт/обновляет/удаляет сами Application CR.
- argocd-application-controller следит за тем, чтобы ресурсы в кластере совпадали с Git, и считает health (если хоть один дочерний ресурс не равен Healthy, приложение остаётся Progressing).

Идём дальше. Так какие же ресурсы генерируются и какой у них статус?

kubectl get applications APP1 -n NAMESPACE -o json \
  | jq '.status.resources[] | select(.health.status != "Healthy")'

...
{
  "kind": "ConfigMap",
  "name": "CM1",
  "namespace": "NAMESPACE",
  "status": "Synced",
  "version": "v1"
}
...
{
  "health": {
    "status": "Progressing"
  },
  "kind": "Service",
  "name": "SVC1",
  "namespace": "NAMESPACE",
  "status": "Synced",
  "version": "v1"
}
...

Ага! Попался!
Какой-то service в процессинге.

Что там с тобой:

kubectl get service SVC1 -o yaml -n NAMESPACE
...
  type: LoadBalancer
status:
  loadBalancer: {}

Визуально вроде ок,
Стоп, нет,не ок.
Ведь это означает, что контроллер, отвечающий за provision (создание) AWS Load Balancer, не смог выполнить свою работу, и поэтому поле status.loadBalancer.ingress не заполнено IP-адресом или Hostname.
* У нас LoadBalancer создаётся контроллером AWS.

Ещё раз проверяю в дескрайб:

kubectl describe service SVC1 -n NAMESPACE
...
Events:
  Type    Reason                Age   From                Message
  ----    ------                ----  ----                -------
  Normal  EnsuringLoadBalancer  55m   *****               Ensuring load balancer

Ладно, иду в неймспейс, где обычно лежит AWS Load Balancer, логи смотреть.
А там нет ничего! Удивляюсь, смотрю

kubectl get pods -A | grep -i load

Нет ничего!
Спрашиваю коллег, а мне ехидно говорят "да ты же сам не задеплоил лоадбалансер в этом новом кластере".
https://github.com/kubernetes-sigs/aws-load-balancer-controller

Смотрю свои коммиты, MR - и правда, именно в этом кластере я забыл добавить AWS LB.🐒
Пилю новый MR, добавляю LB, жду, когда всё поднимется - всё, проблема решена!
У проблемного applicationsset статус стал Healthy.

Добавляю в документацию по кластеру, что "не забыть про LB и иду работать дальше".
Ну хорошо, хоть это не продуктовый кластер, без клиентского ворклоада 🤡

Please open Telegram to view this post

VIEW IN TELEGRAM

👍18

975 views18:10