Ping-Monitoring bleibt wichtig, weil Managed Cloud und Kubernetes Netzwerkausfälle nur verlagern, statt sie zu beseitigen. Eine geänderte Security Group, eine defekte NAT-Route oder ein fehlerhafter DNS-Eintrag kann gesunde Workloads unerreichbar machen, während jeder Pod als Ready gemeldet wird. Kontinuierliche ICMP- und TCP-Erreichbarkeitsprüfungen von außerhalb und innerhalb Ihrer Umgebung erkennen solche Ausfälle, bevor Ihre Nutzer sie bemerken.
Auch verwaltete Infrastruktur hat ein Netzwerk
Der Provider betreibt die Hardware, aber die Konfiguration des virtuellen Netzwerks liegt bei Ihnen – und genau dort beginnen die meisten Erreichbarkeitsprobleme:
- Security Groups und Network ACLs. Eine einzige zu restriktive Regel, ausgerollt per Infrastructure as Code, kann eine ganze Schicht unbemerkt abschneiden.
- NAT-Gateways. Private Workloads ohne NAT-Route erreichen weder Registries noch Payment-APIs oder SaaS-Abhängigkeiten.
- VPC-Peering und Transit Gateways. Änderungen an Routing-Tabellen oder ein getrenntes Attachment unterbrechen den Verkehr zwischen VPCs und Accounts.
- DNS. Private Zonen und Resolver-Regeln fallen auf eine Weise aus, die wie ein kompletter Ausfall aussieht.
- Latenz zwischen AZs und Regionen. Nach einem Failover kann Verkehr über Zonen oder Regionen hinweg umgeleitet werden und zusätzliche Dutzende Millisekunden kosten.
Nichts davon zeigt sich in CPU-Graphen, bis Anfragen in Timeouts laufen.
ICMP ist oft blockiert – nutzen Sie TCP-Ping
Klassischer Ping schlägt in der Cloud häufig absichtlich fehl. Bei AWS erlaubt die Standard-Security-Group eingehenden Verkehr nur von Mitgliedern derselben Gruppe; ICMP aus dem Internet wird also verworfen, bis Sie eine explizite Regel hinzufügen. Azure Network Security Groups enden mit der Standardregel DenyAllInBound. Das automatisch erstellte Default-Netzwerk von Google Cloud enthält zwar eine Regel, die ICMP erlaubt, benutzerdefinierte VPC-Netzwerke blockieren jedoch jeglichen eingehenden Verkehr, bis Sie ihn freigeben. Verwaltete Load Balancer antworten in der Regel überhaupt nicht auf ICMP.
Die praktische Lösung ist TCP-Ping: Messen Sie die Dauer des TCP-Handshakes zu einem Port, der ohnehin erreichbar sein muss. Gute Ziele:
- Load-Balancer-Listener auf Port 443 oder 80
- Endpunkte des Kubernetes-Ingress-Controllers
- NodePort-Services (Standardbereich 30000-32767), sofern Sie diese bereitstellen
- Bastion-Hosts und VPN-Gateways auf ihren Service-Ports
Ein TCP-Check prüft genau den Pfad, den echter Verkehr nimmt – inklusive Security Groups und Listener –, ohne ICMP für die ganze Welt zu öffnen. Behalten Sie ICMP intern dort bei, wo es erlaubt ist, etwa für Checks zwischen Nodes und über hybride Verbindungen.
Was Kubernetes-Probes bereits abdecken – und was nicht
Liveness-, Readiness- und Startup-Probes werden vom Kubelet auf dem Node des jeweiligen Containers ausgeführt. Sie beantworten, ob der Container aus Sicht dieses Nodes gesund ist – nicht, ob ihn irgendjemand sonst erreichen kann.
| Problem | Kubelet-Probes | Ping-/TCP-Monitoring |
|---|---|---|
| Container-Prozess hängt | Ja | Nein |
| Pod aus Service-Endpunkten entfernt | Ja | Indirekt |
| Ingress oder Load Balancer nicht erreichbar | Nein | Ja |
| Node hat Netzwerkverbindung verloren | Nein | Ja |
| Externe Abhängigkeit oder NAT-Pfad ausgefallen | Nein | Ja, von innen |
| Regionaler Latenzanstieg | Nein | Ja |
Eine fehlschlagende Liveness-Probe startet den Container neu, statt Sie zu alarmieren. Pingen Sie Nodes, Ingress-Endpunkte und kritische externe Abhängigkeiten; die Gesundheit der Container überlassen Sie den Probes. ClusterIP-Adressen antworten im iptables-Modus von kube-proxy meist nicht auf ICMP, testen Sie Services daher per TCP.
Externe Messpunkte vs. interne Probes
Sie brauchen beides. Interne Checks, etwa ein Deployment des Prometheus Blackbox Exporter, prüfen East-West-Pfade, den NAT-Egress und privates DNS. Externe Checks prüfen, was Ihre Kunden erleben: DNS, Routing, Load Balancer und Ingress.
UpScanX Ping-Monitoring führt ICMP-, TCP- und UDP-Checks von über 15 globalen Standorten aus, sodass regionale Probleme sofort auffallen: Wenn Frankfurt und Singapur einen Sprung um 120 ms sehen, während Virginia stabil bleibt, liegt der Verdacht beim Routing, nicht bei Ihrem Cluster. Ein typisches Setup nutzt ein Intervall von 30-60 Sekunden und alarmiert nach zwei oder drei aufeinanderfolgenden Fehlschlägen von mehr als einem Standort.
Hybride und Multi-Cloud-Verbindungen
Site-to-Site-VPNs, Direct-Connect- oder ExpressRoute-Leitungen und Tunnel zwischen Clouds sind klassische blinde Flecken. Ein Tunnel kann in der Konsole als „up“ erscheinen, während BGP die Routen längst zurückgezogen hat oder der Paketverlust bei 3-5 % liegt. Pingen Sie auf jeder Seite jeder Verbindung einen stabilen Host und alarmieren Sie bei anhaltender Verschlechterung, nicht erst beim Totalausfall. Die Grundlagen zu Latenz, Paketverlust und Jitter finden Sie unter So funktioniert Ping-Monitoring.
Die wichtigsten Punkte
- Cloud und Kubernetes verlagern das Netzwerkrisiko in Konfigurationen, die Sie selbst verantworten: Security Groups, NACLs, NAT, Peering und DNS.
- Rechnen Sie in den meisten Umgebungen damit, dass ICMP standardmäßig blockiert ist; nutzen Sie TCP-Ping gegen Load Balancer, Ingress und Service-Ports.
- Kubelet-Probes prüfen die Gesundheit von Containern, nicht die Erreichbarkeit. Überwachen Sie Nodes, Ingress und Abhängigkeiten separat.
- Kombinieren Sie interne Probes mit externen Checks von mehreren Standorten, um Cluster-Probleme von Routing-Problemen zu unterscheiden.
- Senden Sie Alerts dorthin, wo Ihr Team ohnehin hinschaut; UpScanX unterstützt E-Mail, Slack, Telegram, Microsoft Teams und Webhook.