Всё о DevOps
Для связи - @raz_raz
Заказать рекламу через биржу: https://telega.in/c/devops_memops
Post #7829
1.43K
DE @devops_memops
Showing posts older than #7831 · Back to latest
Стандартная (для многих) история. Отдаём какие‑то данные в реальном времени через server‑side web‑gRPC стримы. Цепочка: балансировщик, дальше Envoy с grpc‑web, дальше бэкенд.
Все проверки зелёные: TCP поднят, хендшейк проходит, /healthz отвечает 200, в графане/slack'e тишина. А фронтенд у клиентов замёрз. И узнали мы об этом от клиентов, а не от мониторинга.
В статье описание механизма работы демона, который по расписанию подгружает.proto на лету через proto‑loader, открывает server‑side RPC как обычный клиент, ждёт кадров (например 3) в бюджет времени и валидирует каждый кадр.

Центр управления инцидентами с открытым исходным кодом. Весь жизненный цикл инцидента, графики дежурств и страницы состояния — на одной мощной платформе.
OpsKnight — это альтернатива с открытым исходным кодом PagerDuty и OpsGenie, разработанная для команд, которые хотят получить полный контроль над своей системой управления инцидентами без затрат на SaaS-сервисы.
Легковесный, расширяемый оператор Kubernetes, который проверяет любой эндпоинт — HTTP/JSON, TCP, DNS, ICMP, Trino, OpenSearch и другие — и направляет оповещения в Slack или по электронной почте.
Сетевое взаимодействие Kubernetes не должно быть черным ящиком. В этом руководстве мы разбираем его, начиная с основ сетевого взаимодействия Linux и изоляции контейнеров. Затем мы углубляемся в полную модель Kubernetes, объясняя все: от IP-адресов подов и плагинов CNI до сервисов, NetworkPolicy и Ingress, предоставляя четкую карту от начала до конца того, как работает связность в вашем кластере.
Модульная роль и плейбук Ansible, выполняющие автоматическое обновление операционной системы и техническое обслуживание узлов кластера K3s с семантикой нулевого времени простоя.
В классическом SRE инженер получает алерт, открывает консоль, гоняет диагностику и правит по ранбуку. Агент ИИ может съесть тот же алерт, коррелировать его с недавним деплоем и выполнить рутинное исправление самостоятельно.
Это меняет роль SRE: из «делающего вручную» в «менеджера команды агентов», которые накапливают операционную память и снижают зависимость от одного эксперта. Но работает только при одном условии — выбираете один целевой сценарий, а не натягиваете «ИИ-слой» на всё подряд.
kube-scheduler не выбирает ноду случайно. Сначала Pod попадает в ActiveQueue и сортируется по приоритету — PriorityClass здесь решает, кто пойдёт первым. Потом идёт фильтрация: какие ноды вообще подходят по ресурсам, taint’ам и affinity. Оставшиеся кандидаты проходят scoring, где учитываются запрошенные ресурсы, topology spread и affinity.
Если Pod не запланировался, смотрите kubectl describe pod: в Events увидите, на каком шаге отсеялись ноды и почему. Иногда причина в resource requests, иногда в taints или anti-affinity. Разбор на devops.dev проходит путь от очереди до binding и preemption.

docker run nginx? На первый взгляд кажется, что Nginx становится вашим foreground-процессом в терминале – он перехватывает stdio-потоки и реагирует на сигналы, когда вы нажимаете Ctrl+C или меняете размер окна терминала.
Но в реальности терминалом управляет процесс Docker-клиента, а сам Nginx работает в фоне или вообще на удалённой машине. При этом между docker CLI, dockerd (основным Docker-демоном) и containerd (низкоуровневым container runtime) происходит довольно сложная проксировка данных и сигналов — из-за чего всё ощущается как простой локальный запуск.
Почему это важно? Понимание того, как работает docker run под капотом — ключ к пониманию Kubernetes и других продакшн-рантаймов. В продакшене контейнеризованные приложения обычно работают в фоне, но Kubernetes и похожие системы позволяют стримить логи приложений и даже переподключаться к процессам в контейнерах, используя те же самые трюки, что и Docker.
Подробнее о магии за командой docker run — в подробном разборе (с кучей практических упражнений):