Ping-мониторинг по-прежнему важен, потому что управляемое облако и Kubernetes не устраняют сетевые сбои, а лишь переносят их в другое место. Изменённая security group, сломанный маршрут NAT или неверная DNS-запись могут сделать исправные рабочие нагрузки недоступными, хотя каждый под при этом показывает статус Ready. Непрерывные проверки доступности по ICMP и TCP — снаружи и изнутри вашей среды — выявляют такие сбои раньше, чем их заметят пользователи.
У управляемой инфраструктуры тоже есть сеть
Провайдер отвечает за оборудование, но конфигурация виртуальной сети остаётся за вами — и именно с неё начинается большинство инцидентов с доступностью:
- Security groups и сетевые ACL. Одно слишком строгое правило, выкаченное через infrastructure as code, может незаметно отрезать целый уровень приложения.
- NAT-шлюзы. Приватные нагрузки, потерявшие маршрут через NAT, больше не достают до реестров, платёжных API и внешних SaaS-зависимостей.
- VPC peering и transit gateway. Правка таблицы маршрутизации или отключённый attachment обрывают трафик между VPC и аккаунтами.
- DNS. Приватные зоны и правила резолвера отказывают так, что это выглядит как полный простой.
- Задержки между зонами доступности и регионами. После failover трафик может пойти через другие зоны или регионы и прибавить десятки миллисекунд.
Ничего из этого не видно на графиках загрузки CPU, пока запросы не начнут падать по таймауту.
ICMP часто заблокирован, поэтому используйте TCP ping
Классический ping в облаке часто не работает — и это сделано намеренно. В AWS security group по умолчанию разрешает входящий трафик только от участников той же группы, поэтому ICMP из интернета отбрасывается, пока вы не добавите явное правило. Network security groups в Azure заканчиваются правилом по умолчанию DenyAllInBound. Автоматически создаваемая сеть default в Google Cloud содержит правило, разрешающее ICMP, но пользовательские VPC-сети запрещают любой входящий трафик, пока вы его не откроете. Управляемые балансировщики нагрузки, как правило, вообще не отвечают на ICMP.
Практичное решение — TCP ping: измерять время TCP-рукопожатия с портом, который и так должен быть доступен. Хорошие цели:
- Листенеры балансировщика нагрузки на портах 443 или 80
- Эндпоинты ingress-контроллера Kubernetes
- Сервисы NodePort (диапазон по умолчанию 30000-32767), если вы их публикуете
- Bastion-хосты и VPN-шлюзы на их сервисных портах
TCP-проверка проходит тем же путём, что и реальный трафик, включая security groups и листенеры, и не требует открывать ICMP всему миру. Внутри сети сохраните ICMP там, где он разрешён, — для проверок между нодами и гибридных каналов.
Что уже покрывают пробы Kubernetes, а что — нет
Пробы liveness, readiness и startup выполняет kubelet на той же ноде, где работает контейнер. Они отвечают на вопрос, здоров ли контейнер с точки зрения этой ноды, но не на вопрос, может ли до него достучаться кто-то ещё.
| Проблема | Пробы kubelet | Ping/TCP-мониторинг |
|---|---|---|
| Процесс контейнера завис | Да | Нет |
| Под исключён из эндпоинтов Service | Да | Косвенно |
| Ingress или балансировщик недоступен | Нет | Да |
| Нода потеряла сетевую связность | Нет | Да |
| Отказ внешней зависимости или пути через NAT | Нет | Да, изнутри |
| Рост задержки в регионе | Нет | Да |
Упавшая liveness-проба перезапускает контейнер, а не отправляет вам алерт. Пингуйте ноды, ingress-эндпоинты и критичные внешние зависимости, а здоровье контейнеров оставьте пробам. Адреса ClusterIP в режиме iptables у kube-proxy обычно не отвечают на ICMP, поэтому сервисы проверяйте по TCP.
Внешние точки наблюдения и внутренние пробы
Нужно и то и другое. Внутренние проверки, например развёрнутый Prometheus Blackbox Exporter, контролируют east-west-трафик, выход через NAT и приватный DNS. Внешние проверки показывают то, что видят клиенты: DNS, маршрутизацию, балансировщик и ingress.
Ping-мониторинг UpScanX выполняет проверки по ICMP, TCP и UDP из более чем 15 точек по всему миру, поэтому региональные проблемы сразу бросаются в глаза: если Франкфурт и Сингапур видят скачок на 120 мс, а Вирджиния остаётся стабильной, подозревайте маршрутизацию, а не свой кластер. Типичная настройка — интервал 30-60 секунд и алерт после двух-трёх подряд неудачных проверок из нескольких точек.
Гибридные и мультиоблачные каналы
Site-to-site VPN, каналы Direct Connect или ExpressRoute и туннели между облаками — классические слепые зоны. Туннель может отображаться в консоли как «up», хотя BGP уже отозвал маршруты или потери пакетов держатся на уровне 3-5%. Пингуйте стабильный хост на каждой стороне каждого канала и поднимайте алерт при устойчивой деградации, а не только при полном обрыве. Основы измерения задержки, потерь пакетов и джиттера описаны в статье как работает ping-мониторинг.
Главное
- Облако и Kubernetes переносят сетевые риски в конфигурацию, за которую отвечаете вы: security groups, NACL, NAT, peering и DNS.
- В большинстве сред рассчитывайте на то, что ICMP по умолчанию заблокирован; используйте TCP ping для балансировщиков, ingress и сервисных портов.
- Пробы kubelet проверяют здоровье контейнеров, а не доступность. Ноды, ingress и зависимости мониторьте отдельно.
- Сочетайте внутренние пробы с внешними проверками из нескольких точек, чтобы отличать проблемы кластера от проблем маршрутизации.
- Отправляйте алерты туда, куда команда и так смотрит; UpScanX поддерживает Email, Slack, Telegram, Microsoft Teams и Webhook.