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.

В классическом SRE инженер получает алерт, открывает консоль, гоняет диагностику и правит по ранбуку. Агент ИИ может съесть тот же алерт, коррелировать его с недавним деплоем и выполнить рутинное исправление самостоятельно.

Это меняет роль SRE: из «делающего вручную» в «менеджера команды агентов», которые накапливают операционную память и снижают зависимость от одного эксперта. Но работает только при одном условии — выбираете один целевой сценарий, а не натягиваете «ИИ-слой» на всё подряд.

Модульная роль и плейбук Ansible, выполняющие автоматическое обновление операционной системы и техническое обслуживание узлов кластера K3s с семантикой нулевого времени простоя.

Сетевое взаимодействие Kubernetes не должно быть черным ящиком. В этом руководстве мы разбираем его, начиная с основ сетевого взаимодействия Linux и изоляции контейнеров. Затем мы углубляемся в полную модель Kubernetes, объясняя все: от IP-адресов подов и плагинов CNI до сервисов, NetworkPolicy и Ingress, предоставляя четкую карту от начала до конца того, как работает связность в вашем кластере.

Легковесный, расширяемый оператор Kubernetes, который проверяет любой эндпоинт — HTTP/JSON, TCP, DNS, ICMP, Trino, OpenSearch и другие — и направляет оповещения в Slack или по электронной почте.