Was sind Services in Kubernetes, und was ist der Unterschied zwischen ClusterIP, NodePort und LoadBalancer?

Question

IT Interview Practice · Accepted Answer

Ein **Service** gibt einer *Menge von Pods*, die über Labels ausgewählt werden, eine stabile Netzwerkidentität (eine virtuelle IP und einen DNS-Namen). Da Pods ephemeral sind und ihre IPs wechseln, ist der Service die dauerhafte Adresse, die Clients verwenden, und er **verteilt die Last (load-balances)** über die gesunden Pods dahinter.

## Warum es Services gibt

```text
Pods kommen und gehen (jedes Mal eine neue IP). Clients brauchen einen STABILEN Endpunkt.
Ein Service:
  → wählt Pods per Label aus  (selector: app=web)
  → bekommt eine feste virtuelle IP + DNS-Namen (web.default.svc.cluster.local)
  → verteilt Requests über die passenden, READY Pods
```

## Die drei wichtigsten Service-Typen

```text
ClusterIP    (default)  → nur INNERHALB des Clusters erreichbar
                          für pod-to-pod / interne Service-Kommunikation
NodePort               → öffnet einen Port auf JEDEM Node (30000-32767)
                          externer Traffic trifft nodeIP:nodePort → Service → Pods
LoadBalancer           → provisioniert einen externen Cloud-Load-Balancer
                          gibt eine öffentliche IP, die zum Service routet
```

```text
       Internet
          │
   ┌──────┴───────┐
   │ LoadBalancer │  (cloud LB, public IP)   ← for public services
   └──────┬───────┘
          │
   ┌──────┴───────┐
   │  NodePort    │  (node:30080)            ← exposes on each node
   └──────┬───────┘
          │
   ┌──────┴───────┐
   │  ClusterIP   │  (10.96.x.x, internal)   ← the base building block
   └──────┬───────┘
       Pods (app=web)
LoadBalancer builds on NodePort, which builds on ClusterIP.
```

## ClusterIP (intern)

```yaml
apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  type: ClusterIP          # default; kann weggelassen werden
  selector:
    app: web               # passt auf Pods mit Label app=web
  ports:
    - port: 80             # Port des Service
      targetPort: 8080     # Port des Containers
```

Andere Pods erreichen ihn per DNS: `http://web` (gleicher Namespace) oder `http://web.default.svc.cluster.local`.

## NodePort und LoadBalancer

```yaml
# NodePort — jeder Node lauscht auf nodePort und leitet an den Service weiter
spec:
  type: NodePort
  selector: { app: web }
  ports:
    - port: 80
      targetPort: 8080
      nodePort: 30080      # optional; 30000-32767
---
# LoadBalancer — Cloud provisioniert einen externen LB mit öffentlicher IP
spec:
  type: LoadBalancer
  selector: { app: web }
  ports:
    - port: 80
      targetPort: 8080
```

```bash
kubectl get svc            # Typen, cluster IPs und external IPs ansehen
kubectl get endpoints web  # die tatsächlichen Pod-IPs hinter dem Service
```

## Warum es wichtig ist

Services sind die Art, wie Networking in Kubernetes funktioniert, daher ist das Verständnis von ihnen und der Typ-Hierarchie essenzielles Alltagswissen. Weil Pods ephemeral sind und bei jeder Neuerstellung neue IPs bekommen, kannst du Clients nicht direkt auf Pod-IPs zeigen lassen; ein **Service** löst dies, indem er eine **stabile virtuelle IP und einen DNS-Namen** vor eine per Label ausgewählte Menge von Pods stellt und Traffic **nur über die Pods verteilt, die Ready sind**. Die drei Typen bilden eine geschichtete Progression: **ClusterIP** (der default) gibt eine nur intern erreichbare Adresse für pod-to-pod- und service-to-service-Kommunikation und ist der Basisbaustein; **NodePort** öffnet einen festen Port auf jedem Node, damit externer Traffic den Service erreichen kann; und **LoadBalancer** geht weiter, indem er einen externen Cloud-Load-Balancer mit öffentlicher IP provisioniert — jeder Typ baut auf dem darunterliegenden auf. Zu wissen, wonach man greift — ClusterIP für internen Microservice-Traffic, NodePort für einfachen externen Zugriff oder on-prem-Setups, LoadBalancer, um einen öffentlichen Endpunkt in einer Cloud freizugeben (und in der Praxis Ingress vor ClusterIP-Services für HTTP-Routing) — ist zentral für das Design, wie Komponenten miteinander und mit der Außenwelt sprechen. Da fast jeder reale Workload stabile Konnektivität und load balancing braucht, ist das Verständnis von Services und ihren Typen grundlegendes Kubernetes-Networking-Wissen, das ständig sowohl im Design als auch beim Debugging auftaucht.

Warum es Services gibt

Die drei wichtigsten Service-Typen

ClusterIP (intern)

NodePort und LoadBalancer

Warum es wichtig ist

Ähnliche Fragen