Make. Build. Break. Reflect.

#одинденьизжизни #longread #kubernetes

Импровизация.
Лонгрид.

Да-да, часть моей работы это импровизация.
Зачастую бывает ситуация, что мне надо что-то решить, а я ну воообще не понимаю что это такое.

Сложилась такая ситуация, что у нас перестал работать стабильно некий сервис.
Пользователи/коллеги жалуются: "при работе с фронтенд приложением видим ошибку ****, помогает рестарт нескольких подов в кубере".
Речь идёт про DEV, но потенциально может аффектить и PROD часть.
Продакшн нам нельзя ломать, иначе меня уволят и мне нечем будет хвастать в интернетах успехами своих успехов.

Идём разбираться.
Какая ошибка? Ошибка в вебе звучит примерно так

{
    “errorCode”: “ERR_DIRECT_INVOKE”,
    “message”: “failed to invoke, id: REPLACEMESERVICENAME, err: failed to resolve address for ‘REPLACEMESERVICENAME-dapr.REPLACEMENAMESPACE.svc.cluster.local’: lookup REPLACEMESERVICENAME-dapr.REPLACEMENAMESPACE.svc.cluster.local on 10.0.12.10:53: no such host”
}

Я честно говоря хер знает что такое инвоук, что такое дапр и уж тем более не знаю почему такая ошибка возникает.
И почему тут вообще ресолв, с*ка. Причем тут внутренний DNS. Вы поехавшие что-ли?

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

Ок, смотрим что такое DAPR.
Читаем официальную документацию. https://dapr.io/
На основании документации выносим для себя определение что это.
DAPR (Distributed Application Runtime) - это фреймворк для упрощения разработки микросервисов, предоставляющий готовые решения для обмена сообщениями, управления состоянием и взаимодействия сервисов. Используется для создания масштабируемых и устойчивых распределённых приложений.
Ага, нихера не понятно. Очередная всратость для кубернетеса.
Что-то должна упростить, осталось понять кому она упрощает и как.
Смотрим, а что же у нас есть.

У нас есть отдельный неймспейс, в котором стоит
- dapr оператор
- dapr dashboard
- dapr-sidecar-injector
- dapr-scheduler
и всякое подобное.
Почитал логи, порестартил поды, посмотрел ивенты. Ничего не понятно.
Не понимаю чем это должно мне помочь, читаю дальше и разбираюсь по коду.

А как деплоится этот проблемный сервис?

>ky pods REPLACEMESERVICENAME-7766b4d5c-w66vc
apiVersion: v1
kind: Pod
metadata:
  annotations:
    dapr.io/app-id: REPLACEMESERVICENAME
...
    dapr.io/enabled: "true"
...
  labels:
    app: REPLACEMESERVICENAME
...
    dapr.io/app-id: REPLACEMESERVICENAME
    dapr.io/metrics-enabled: "true"
    dapr.io/sidecar-injected: "true"
...
    metrics_scrape_enabled: "true"
    metrics_scrape_from_pods: "true"
    pod-template-hash: 7766b4d5c
    release: REPLACEMESERVICENAME
    tier: web
    track: stable

По аннотациям видно, что генерация манифеста идёт через хелмчарт.
Ага, дошёл до helm чарта, у нас есть параметр-аннотация для дапра.
Понимаю, что при добавлении

dapr:
  enabled: true

Для каждого сервиса, где включен этот параметр, добавляется сайдкар.
Круто, хоть куда то сдвинулся в понимании что есть что.

👍5❤1

675 viewsedited 14:47