Ping monitoring still matters because managed cloud and Kubernetes move network failures around rather than eliminating them. A changed security group, a broken NAT route or a bad DNS record can make healthy workloads unreachable while every pod reports Ready. Continuous ICMP and TCP reachability checks, run from outside and inside your environment, catch these failures before users do.
Managed Infrastructure Still Has a Network
Providers run the hardware, but you own the virtual network configuration, where most reachability incidents start:
- Security groups and network ACLs. One overly tight rule pushed through infrastructure-as-code can silently cut off a tier.
- NAT gateways. Private workloads that lose their NAT route can no longer reach registries, payment APIs or SaaS dependencies.
- VPC peering and transit gateways. Route table edits or a detached attachment break traffic between VPCs and accounts.
- DNS. Private zones and resolver rules fail in ways that look like outages.
- Cross-AZ and cross-region latency. After a failover, traffic can hairpin across zones or regions, adding tens of milliseconds.
None of these appear in CPU graphs until requests start timing out.
ICMP Is Often Blocked, So Use TCP Ping
Classic ping often fails in the cloud by design. On AWS, the default security group allows inbound traffic only from members of the same group, so ICMP from the internet is dropped until you add an explicit rule. Azure network security groups end with a default DenyAllInBound rule. Google Cloud's auto-created default network ships with a rule allowing ICMP, but custom VPC networks deny all ingress unless you open it. Managed load balancers generally do not answer ICMP at all.
The practical answer is TCP ping: time a TCP handshake to a port that must be reachable anyway. Good targets:
- Load balancer listeners on 443 or 80
- Kubernetes ingress controller endpoints
- NodePort services (default range 30000-32767) where you expose them
- Bastion hosts and VPN gateways on their service ports
A TCP check validates the path real traffic takes, including security groups and listeners, without opening ICMP to the world. Keep ICMP internally where allowed for node-to-node and hybrid link checks.
What Kubernetes Probes Already Cover, and What They Don't
Liveness, readiness and startup probes are run by the kubelet on the container's own node. They answer whether the container is healthy from that node, not whether anyone else can reach it.
| Concern | Kubelet probes | Ping / TCP monitoring |
|---|---|---|
| Container process hung | Yes | No |
| Pod removed from Service endpoints | Yes | Indirectly |
| Ingress or load balancer unreachable | No | Yes |
| Node lost network connectivity | No | Yes |
| External dependency or NAT path down | No | Yes, from inside |
| Regional latency increase | No | Yes |
A failing liveness probe restarts the container rather than alerting you. Ping nodes, ingress endpoints and critical external dependencies; let probes handle container health. ClusterIP addresses usually do not answer ICMP in kube-proxy's iptables mode, so test services with TCP.
External Vantage Points vs Internal Probes
You need both. Internal checks, such as a Prometheus Blackbox Exporter deployment, verify east-west paths, NAT egress and private DNS. External checks verify what customers experience: DNS, routing, the load balancer and the ingress.
UpScanX ping monitoring runs ICMP, TCP and UDP checks from 15+ global locations, so regional problems stand out: if Frankfurt and Singapore see a 120 ms jump while Virginia stays flat, suspect routing, not your cluster. A typical setup uses a 30-60 second interval and alerts after two or three consecutive failures from more than one location.
Hybrid and Multi-Cloud Links
Site-to-site VPNs, Direct Connect or ExpressRoute circuits and inter-cloud tunnels are classic blind spots. A tunnel can look "up" in the console while BGP has withdrawn routes or loss sits at 3-5%. Ping a stable host on each side of every link and alert on sustained degradation, not just total failure. For the basics of latency, loss and jitter, see how ping monitoring works.
Key Takeaways
- Cloud and Kubernetes shift network risk to configuration you control: security groups, NACLs, NAT, peering and DNS.
- Expect ICMP to be blocked by default in most setups; use TCP ping against load balancers, ingress and service ports.
- Kubelet probes check container health, not reachability. Monitor nodes, ingress and dependencies separately.
- Combine internal probes with external multi-location checks to separate cluster issues from routing issues.
- Send alerts where your team already looks; UpScanX supports Email, Slack, Telegram, Microsoft Teams and Webhook.