"Алекс, у нас что-то приложение не раскатывается, деплой завис. Кластер новый, вроде ты деплоил, посмотри плиз".
Ну раз я, значит мне и смотреть.
Смотрю в арго что там зависло, перехожу в аппликейшнсет - вижу процессинг.
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 и иду работать дальше".
Ну хорошо, хоть это не продуктовый кластер, без клиентского ворклоада 🤡