DNS-Management für Microservices: Meine Strategie für Service Discovery.

Service Discovery: Wie finden sich meine Microservices?

In einer klassischen Architektur haben Server feste IP-Adressen. In einer modernen Microservice-Landschaft hingegen kommen und gehen Instanzen ständig – sie skalieren horizontal, werden neu gestartet oder auf andere Knoten verschoben. Ein Service kann seine IP-Adresse jederzeit ändern. Die große Frage lautet: Woher weiß Service A, unter welcher Adresse er Service B erreichen kann? Die Antwort ist ein intelligentes DNS-Management und Service Discovery. In diesem Beitrag zeige ich Ihnen meine Strategien.

1. Das Problem mit statischem DNS

Klassisches DNS (Domain Name System) hat eine Cache-Zeit (TTL – Time to Live). Wenn ein Microservice stirbt und unter einer neuen IP wiederkommt, würde das klassische DNS oft noch minutenlang auf die alte, tote IP zeigen. Für hochverfügbare Systeme ist das inakzeptabel.

2. Internes DNS in Kubernetes (CoreDNS)

Wenn Sie Kubernetes nutzen, ist Service Discovery bereits eingebaut.

• ClusterIP: Kubernetes erstellt für jeden Dienst eine stabile virtuelle IP und einen DNS-Namen (z.B. my-service.namespace.svc.cluster.local).
• Vorteil: CoreDNS aktualisiert diese Einträge sofort, wenn Pods hinzugefügt oder entfernt werden. Die Anwendung muss sich nur den Namen merken, Kubernetes kümmert sich um das Load Balancing.

3. Service Discovery ohne Kubernetes: Consul oder Etcd

Falls Sie Ihre Go-Services direkt auf virtuellen Maschinen oder Bare-Metal betreiben, nutze ich oft HashiCorp Consul.

• Registration: Beim Start meldet sich jeder Go-Dienst beim Consul-Agenten an.
• Health Checks: Consul prüft regelmäßig, ob der Dienst noch antwortet. Wenn nicht, wird er automatisch aus dem DNS-Register entfernt.
• DNS-Interface: Consul bietet ein DNS-Interface an. Eine Abfrage nach backend.service.consul liefert immer die IP-Adressen der gesunden Instanzen zurück.

4. Client-Side vs. Server-Side Service Discovery

• Server-Side: Der Client ruft einen Load Balancer (oder Ingress) an, der weiß, wo die Instanzen sind. Dies ist das einfachste Modell für den Client.
• Client-Side (gRPC): Bei Hochleistungs-Systemen mit gRPC nutzt der Go-Client oft Bibliotheken, die direkt beim Service Registry (z.B. Consul) nachfragen und die Verbindung selbst balancieren. Das spart einen Netzwerk-Hop über den zentralen Load Balancer.

Fazit: Namensauflösung als dynamischer Prozess

DNS-Management für Microservices ist weit mehr als das Eintragen von A-Records. Es ist ein dynamisches System, das eng mit dem Health-Monitoring und der Orchestrierung verknüpft sein muss. Ob über das integrierte CoreDNS in Kubernetes oder über externe Lösungen wie Consul – eine robuste Service Discovery ist die Voraussetzung für eine skalierbare und resiliente Infrastruktur.

Haben Sie Kommunikationsprobleme in Ihrer verteilten Architektur?
Ich helfe Ihnen bei der Planung und Implementierung von effizienten Service-Discovery-Lösungen für Ihre Go- und Cloud-Infrastruktur. Lassen Sie uns Ihre Service-Kommunikation optimieren.