La surveillance ping reste essentielle, car le cloud managé et Kubernetes déplacent les pannes réseau au lieu de les supprimer. Un security group modifié, une route NAT cassée ou un enregistrement DNS erroné peut rendre des workloads sains injoignables alors que chaque pod est signalé Ready. Des vérifications continues de joignabilité ICMP et TCP, lancées depuis l'extérieur comme depuis l'intérieur de votre environnement, détectent ces pannes avant vos utilisateurs.
Une infrastructure managée reste un réseau
Le fournisseur gère le matériel, mais la configuration du réseau virtuel vous appartient, et c'est là que commencent la plupart des incidents de joignabilité :
- Security groups et network ACLs. Une seule règle trop restrictive, déployée via l'infrastructure as code, peut isoler silencieusement tout un tier.
- Passerelles NAT. Des workloads privés qui perdent leur route NAT ne peuvent plus joindre les registries, les API de paiement ni les dépendances SaaS.
- Peering VPC et transit gateways. Une modification de table de routage ou un attachment détaché coupe le trafic entre VPC et comptes.
- DNS. Les zones privées et les règles de résolveur tombent en panne d'une manière qui ressemble à une indisponibilité totale.
- Latence inter-AZ et inter-régions. Après un failover, le trafic peut transiter par d'autres zones ou régions et ajouter des dizaines de millisecondes.
Rien de tout cela n'apparaît dans les graphiques CPU avant que les requêtes ne commencent à expirer.
ICMP est souvent bloqué : utilisez le ping TCP
Le ping classique échoue souvent dans le cloud, et c'est voulu. Sur AWS, le security group par défaut n'autorise le trafic entrant que depuis les membres du même groupe : l'ICMP venant d'Internet est donc rejeté tant que vous n'ajoutez pas de règle explicite. Les network security groups Azure se terminent par une règle par défaut DenyAllInBound. Le réseau « default » créé automatiquement par Google Cloud inclut une règle autorisant l'ICMP, mais les réseaux VPC personnalisés refusent tout trafic entrant tant que vous ne l'ouvrez pas. Quant aux load balancers managés, ils ne répondent généralement pas du tout à l'ICMP.
La solution pratique est le ping TCP : mesurer la durée d'un handshake TCP vers un port qui doit de toute façon être joignable. Bonnes cibles :
- Listeners de load balancer sur les ports 443 ou 80
- Endpoints du contrôleur d'ingress Kubernetes
- Services NodePort (plage par défaut 30000-32767) lorsque vous les exposez
- Bastions et passerelles VPN sur leurs ports de service
Un check TCP valide le chemin emprunté par le trafic réel, security groups et listeners compris, sans ouvrir l'ICMP au monde entier. Conservez l'ICMP en interne là où il est autorisé, pour les vérifications entre nœuds et sur les liaisons hybrides.
Ce que couvrent déjà les probes Kubernetes, et ce qu'elles ne couvrent pas
Les probes liveness, readiness et startup sont exécutées par le kubelet sur le nœud du conteneur. Elles indiquent si le conteneur est sain du point de vue de ce nœud, pas si quelqu'un d'autre peut le joindre.
| Problème | Probes kubelet | Monitoring ping / TCP |
|---|---|---|
| Processus du conteneur bloqué | Oui | Non |
| Pod retiré des endpoints du Service | Oui | Indirectement |
| Ingress ou load balancer injoignable | Non | Oui |
| Nœud ayant perdu sa connectivité réseau | Non | Oui |
| Dépendance externe ou chemin NAT en panne | Non | Oui, depuis l'intérieur |
| Hausse de latence régionale | Non | Oui |
Une probe liveness en échec redémarre le conteneur au lieu de vous alerter. Pinguez les nœuds, les endpoints d'ingress et les dépendances externes critiques ; laissez aux probes la santé des conteneurs. En mode iptables de kube-proxy, les adresses ClusterIP ne répondent généralement pas à l'ICMP : testez donc les services en TCP.
Points de mesure externes ou probes internes
Il vous faut les deux. Les checks internes, par exemple un déploiement de Prometheus Blackbox Exporter, vérifient les flux est-ouest, la sortie via NAT et le DNS privé. Les checks externes vérifient ce que vivent vos clients : DNS, routage, load balancer et ingress.
La surveillance ping UpScanX exécute des checks ICMP, TCP et UDP depuis plus de 15 emplacements dans le monde, si bien que les problèmes régionaux sautent aux yeux : si Francfort et Singapour voient un saut de 120 ms alors que la Virginie reste stable, soupçonnez le routage, pas votre cluster. Une configuration typique utilise un intervalle de 30 à 60 secondes et alerte après deux ou trois échecs consécutifs depuis plus d'un emplacement.
Liaisons hybrides et multi-cloud
Les VPN site-à-site, les circuits Direct Connect ou ExpressRoute et les tunnels inter-cloud sont des angles morts classiques. Un tunnel peut apparaître « up » dans la console alors que BGP a retiré les routes ou que la perte de paquets atteint 3 à 5 %. Pinguez un hôte stable de chaque côté de chaque liaison et alertez en cas de dégradation durable, pas seulement en cas de coupure totale. Pour les bases sur la latence, la perte de paquets et la gigue, consultez le fonctionnement de la surveillance ping.
Points clés
- Le cloud et Kubernetes déplacent le risque réseau vers une configuration que vous maîtrisez : security groups, NACL, NAT, peering et DNS.
- Attendez-vous à ce que l'ICMP soit bloqué par défaut dans la plupart des environnements ; utilisez le ping TCP vers les load balancers, l'ingress et les ports de service.
- Les probes kubelet vérifient la santé des conteneurs, pas la joignabilité. Surveillez séparément les nœuds, l'ingress et les dépendances.
- Combinez probes internes et checks externes multi-emplacements pour distinguer les problèmes de cluster des problèmes de routage.
- Envoyez les alertes là où votre équipe regarde déjà ; UpScanX prend en charge l'e-mail, Slack, Telegram, Microsoft Teams et les webhooks.