Linux Networking & TCP/IP for Developers · Lektion

Service Discovery und DNS in Kubernetes

Lernen Sie, wie Container einander finden: Cluster-DNS, Service-Objekte und den Auflösungsablauf, der Microservices unter ihrem Namen erreichbar macht.

Lektion 4 von 413 Schritte

Service Discovery und DNS in Kubernetes ist eine kostenlose Linux Networking & TCP/IP for Developers-Lektion auf CoddyKit. Dies ist Lektion 4 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des Linux Networking & TCP/IP for Developers-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der Linux Networking & TCP/IP for Developers-Kurs umfasst insgesamt 4 Lektionen.

Teile dieser Lektion wurden noch nicht übersetzt und werden auf Englisch angezeigt.

The Discovery Problem

Container IPs are ephemeral — pods restart and get new addresses constantly. Hardcoding IPs is impossible.

Service discovery lets workloads find each other by stable names instead of changing IPs.

The Service Abstraction

A Kubernetes Service provides a stable virtual IP (ClusterIP) and DNS name that load-balances across a set of pods selected by labels.

apiVersion: v1
kind: Service
metadata:
  name: orders
spec:
  selector:
    app: orders
  ports:
    - port: 80

Cluster DNS

Every cluster runs a DNS server (CoreDNS). It automatically creates records for each Service so workloads can resolve them by name.

The DNS Naming Scheme

Services follow a predictable FQDN pattern:

service.namespace.svc.cluster.local

Within the same namespace, just orders works. Across namespaces use orders.payments.

curl http://orders.payments.svc.cluster.local

How a Pod Resolves Names

Each pod's /etc/resolv.conf points at the cluster DNS and includes search domains, so short names expand to full Service FQDNs automatically.

cat /etc/resolv.conf

ClusterIP Load Balancing

A ClusterIP is virtual — kube-proxy programs iptables or IPVS rules so traffic to it is distributed across the healthy backing pods. Clients never see individual pod IPs.

Headless Services

Set clusterIP: None for a headless Service. DNS then returns the individual pod IPs directly, which is ideal for stateful sets and client-side load balancing.

spec:
  clusterIP: None
  selector:
    app: db

Endpoints and EndpointSlices

Behind each Service, Kubernetes maintains EndpointSlices listing the ready pod IPs. As pods come and go, these update so DNS and routing stay current.

kubectl get endpointslices

Resolving from Inside a Pod

You can debug discovery by running nslookup from a pod to verify a Service name resolves to its ClusterIP.

kubectl exec -it shell -- nslookup orders

External Name Services

An ExternalName Service maps a cluster DNS name to an outside hostname via a CNAME, letting you reference external systems with cluster-internal names.

spec:
  type: ExternalName
  externalName: api.example.com

Common Discovery Failures

When name resolution fails, check:

  • Label selector mismatch (no endpoints)
  • Wrong namespace in the FQDN
  • CoreDNS pods unhealthy
  • NetworkPolicy blocking DNS (port 53)

Quick Check

Test your service discovery knowledge.

Recap

You now understand container service discovery:

  • Services give stable ClusterIPs and DNS names
  • CoreDNS resolves service.namespace.svc.cluster.local
  • EndpointSlices track ready pods
  • Headless and ExternalName Services for special cases
  • Debug with nslookup from inside pods

This builds on your Docker network modes and Kubernetes networking basics.

Kostenlos starten

Lerne Linux Networking & TCP/IP for Developers mit einem KI-Tutor — kostenlos

Schreibe und führe echten Code in deinem Browser aus, bekomme sofortige Hilfe von einem 24/7 KI-Tutor und setze dein Lernen im Web oder in der App fort.

Kurse
12
Lektionen
48

Häufig gestellte Fragen

Ist die Lektion „Service Discovery und DNS in Kubernetes“ kostenlos?

Ja — der vollständige Text von „Service Discovery und DNS in Kubernetes“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des Linux Networking & TCP/IP for Developers-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der Linux Networking & TCP/IP for Developers-Kurs umfasst insgesamt 4 Lektionen.

Was lerne ich in „Service Discovery und DNS in Kubernetes“?

Lernen Sie, wie Container einander finden: Cluster-DNS, Service-Objekte und den Auflösungsablauf, der Microservices unter ihrem Namen erreichbar macht. Du übst Linux Networking & TCP/IP for Developers mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.

Brauche ich Erfahrung, um Linux Networking & TCP/IP for Developers zu starten?

Keine Vorkenntnisse erforderlich. Linux Networking & TCP/IP for Developers auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 4 von 4.

Wie lange dauert die Lektion „Service Discovery und DNS in Kubernetes“?

Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.

Kann ich in dieser Linux Networking & TCP/IP for Developers-Lektion Code schreiben und ausführen?

Ja. Jede Linux Networking & TCP/IP for Developers-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.

Alle Lektionen in diesem Kurs

  1. Docker-Netzwerkmodi
  2. Grundlagen der Kubernetes-Netzwerke
  3. Netzwerkrichtlinien in Containern
  4. Service Discovery und DNS in Kubernetes
← Zurück zu Linux Networking & TCP/IP for Developers