Задать вопрос

saimon26

Лайки

  • Нужно ли указывать путь к приватному registry на нодах kubernet?

    vabka
    @vabka
    Токсичный шарпист
    https://kubernetes.io/docs/tasks/configure-pod-con...
    Ответ написан
    Комментировать
    Комментировать

  • Можно ли через node_exporter отправлять данные на указанный prometheus server?

    @Stqs
    senior software developer
    gremlintv2,

    вообще чисто идеологически prometheus работает через pull данных
    но, бывает так что сущности которые мы собираемся мониторить:
    1) являются эфемерными, то есть, являются смертными сущностями, которые могут восстать позже, в другом месте и с другим адресом например
    2) могут быть просто job'ами которые естественно живут какой-то определенный промежуток времени
    3) просто не доступны для prometheus сервера

    Хороших вариантов на самом деле 2 как по мне
    1) если промитеус сидит внутри того же кластера - то мы просто добавляем в конфиг секцию типа такой
    job_name: ${appName}
kubernetes_sd_configs:
- role: pod
relabel_configs:
- action: keep
  regex: ${appName}
  source_labels:
  - __meta_kubernetes_pod_container_name
metrics_path: ${path}
scrape_interval: ${interval}s

    тогда промитеус через нативный кубернет DNS сможет получить информацию о подах, отфильтрует по __meta_kubernetes_pod_container_name все нужные и все будет заебись

    2) этот вариант подойдет для обоих вариантов когда промитеус сидит внутри или снаружи кластера
    https://github.com/prometheus/pushgateway
    если вкратце то 1) вы создаете пушгейтвей эндпоинт для вашего сервиса, 2) туда по хттп пушите свои метрики 3) в конфиге промитеус-сервер вы добавляете `scrape_configs` секцию как обычно, которая пулит данные с пушгейтвей эндпоинта

    PS
    node_exporter в этом случае не особо помогает потому что по сути создает эндпоинт который должен мониторить промитеус, если само приложение не доступон для промитеуса то и node_exporter тоже не будет доступен что очевидно
    Ответ написан
    Комментировать
    Комментировать

  • Как организовать docker-compose для микросервисов на локальной машине для разработки?

    trapwalker
    @trapwalker
    Программист, энтузиаст
    Основное отличие микросервисов от монолита в том, что они более автономны и изолированны друг от друга. Общаться между собой они, кстати, могут не только по http, чаще это происходит через очереди RMQ или кафку какую-нибудь.
    Если несколько микросервисов у вас будут хранить данные в одной БД или вообще в одной таблице, то это несколько ухудгает изоляцию и ваша микросервисаня архитектура снова начинает пахнуть монолитом, только затейливым таким монолитом, поскольку, возможно, вы на следующих этапах захотите вынести общий код из микросервисов в какие-то библиотеки, начнете импортировать одни и те же модели разными "микросервисами". И получите в итоге тот же монолит со всеми его недостатками, а достоинства микросервисной архитектуры потеряете, приобретя при этом её недостатки.

    Кроме того, простые по своему устройству микросервисы положено при необходимости масштабировать горизонтально, с чем будут проблемы у докера с его компоузом.
    амое правильное развёртывать микросервсиную архитектуру в кубернете.
    При этом очень часто, если конечно вы не живёте в монорепозитории, конфигурация развёртывания настраивается вообще в отдельном проекте.

    Для разработки и отладки вы обычно изолированы в своём микросервисе, вам может быть достаточно для девелоперских нужд докер-компоуза, который поднимет вам БД, nginx, очереди и что вам там еще надо для нужд локальной отладки и тестирования.
    Ответ написан
    Комментировать
    Комментировать