Java Interview Questions

Home / All Answers / Docker Kubernetes

Question 11 · Section 14

What is Service in Kubernetes?

A Service is not a container or a process. It's an abstract network route that K8s maintains automatically. Pods die and are recreated with new IPs, but the Service remains.

English Docker Kubernetes Source Markdown
Language versions: English Russian Ukrainian

Junior Level

Simple Explanation

Service is a stable address for accessing a group of Pods.

A Service is not a container or a process. It’s an abstract network route that K8s maintains automatically. Pods die and are recreated with new IPs, but the Service remains.

Simple Analogy

Imagine Pods are employees in an office who can change desks. A Service is the company’s main phone number that always stays the same. Whoever answers the call, callers dial one number.

Why Do We Need a Service?

Without a Service:

  • Pod crashed → new Pod → new IP → need to update configuration
  • How to find the right application among hundreds of Pods?

With a Service:

  • Service always has one IP and DNS name
  • Kubernetes knows which Pods are behind it
  • If a Pod crashes — the Service simply stops sending traffic there

Simple Example

apiVersion: v1
kind: Service
metadata:
  name: myapp-service
spec:
  selector:
    app: myapp        # Finds Pods with this label
  ports:
  - port: 80          # Port the Service listens on
    targetPort: 8080  # Port traffic is forwarded to in the Pod

// port: 80 — port the Service listens on. // targetPort: 8080 — port traffic is forwarded to in the Pod. // selector: app=my-app — finds Pods with this label and routes traffic to them.

Now other applications connect: http://myapp-service:80

How Does a Service Find Pods?

Through labels:

  1. Pods have labels: app: myapp
  2. Service finds Pods by these labels (selector)
  3. All found Pods are added to the Endpoints list
  4. Kubernetes automatically updates the list when Pods change

What a Junior Developer Should Remember

  • Service — stable address for unstable Pods
  • Service finds Pods via labels (selectors)
  • Service load balances traffic between Pods
  • Service DNS name: service-name.namespace.svc.cluster.local
  • Within the cluster you can simply use the name: http://myapp-service

When NOT to Use a Service

DON’T use a Service for: direct Pod-Pod communication (use Headless Service), L7 routing (use Ingress).

Middle Level

How Does a Service Work?

Load Balancing

A Service is an internal load balancer. When traffic arrives at the Service IP, it’s distributed among healthy Pods.

By default: random selection (via iptables) or Round-Robin (via IPVS). Service operates at L4 (TCP/UDP).

L4 (transport layer) — load balancing by IP:port. L7 (application layer) — load balancing by URL, headers, cookies.

kube-proxy

kube-proxy runs on each Node:

  • Monitors Service and Endpoints changes in the API
  • Configures routing rules (iptables/IPVS)
  • When a packet goes to ClusterIP, the Linux kernel redirects it to a Pod

Service Types

Type Access When to use
ClusterIP Only within the cluster Communication between microservices
NodePort External on Node port Testing, simple cases
LoadBalancer Public IP from cloud Production in cloud
ExternalName DNS alias Access to external resources

ClusterIP (default)

apiVersion: v1
kind: Service
metadata:
  name: backend
spec:
  type: ClusterIP
  selector:
    app: backend
  ports:
  - port: 80
    targetPort: 8080

Only accessible within the cluster. Used for communication between microservices.

Service Discovery

Kubernetes automatically creates DNS records for Services:

# Within the cluster
http://backend:80                  # within the same namespace
http://backend.default.svc.cluster.local  # full address

Headless Service

If clusterIP: None, the Service doesn’t get an IP. Pods are accessible directly by DNS:

spec:
  clusterIP: None
  selector:
    app: database

DNS returns the IPs of all Pods. Used with StatefulSet for direct access to specific Pods.

What a Middle Developer Should Remember

  • Service — L4 load balancer (TCP/UDP)
  • Service → Pod connection via Labels and Selectors
  • ClusterIP for internal communication, LoadBalancer for external
  • kube-proxy implements Service via iptables/IPVS
  • Headless Service (clusterIP: None) for direct Pod access

Senior Level

Service as a Network Facade Abstraction

A Service is not just a load balancer — it’s a stable network interface for a dynamic group of Pods that hides the ephemeral nature of containers from service consumers.

Deep Architecture: kube-proxy Modes

iptables mode (default)

  • kube-proxy creates iptables rules for each Service
  • Each Endpoint = a set of rules
  • Plus: no additional hop
  • Minus: O(n) rules, slow updates with a large number of Pods

IPVS mode

  • Uses IPVS (IP Virtual Server) — more scalable
  • Plus: O(1) lookup, supports more load balancing algorithms
  • Minus: requires kernel modules

Load balancing algorithms (IPVS)

  • roundrobin
  • leastconn
  • sourcehash
  • weighted

Service and Endpoints

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

Kubernetes automatically creates an Endpoint object:

apiVersion: v1
kind: Endpoints
metadata:
  name: api
subsets:
- addresses:
  - ip: 10.0.0.5
  - ip: 10.0.0.6
  ports:
  - port: 8080

EndpointSlice (v1.21+): more scalable version of Endpoints for thousands of Pods.

Service Without a Selector

apiVersion: v1
kind: Service
metadata:
  name: external-db
spec:
  ports:
  - port: 5432
---
apiVersion: v1
kind: Endpoints
metadata:
  name: external-db
subsets:
- addresses:
  - ip: 192.168.1.100  # External DB
  ports:
  - port: 5432

Allows including an external resource in K8s Service Discovery.

Session Affinity

spec:
  sessionAffinity: ClientIP
  sessionAffinityConfig:
    clientIP:
      timeoutSeconds: 3600

One client always lands on the same Pod. Warning: violates stateless architecture principles.

Service Mesh and the Future of Service

Service Mesh (Istio, Linkerd) replaces kube-proxy:

  • L7 load balancing (HTTP headers, cookies)
  • mTLS between services
  • Canary routing
  • Observability (tracing, metrics)

In Istio a sidecar container intercepts all traffic and implements advanced routing.

Performance and Scaling

Number of Pods iptables IPVS
100 Great Great
1000 Slowing Good
5000+ Problems Great

Troubleshooting

# Check Service
kubectl get svc myapp
kubectl describe svc myapp

# Check Endpoints
kubectl get endpoints myapp

# Check DNS
kubectl run -it --rm dns-test --image=busybox --restart=Never -- \
  nslookup myapp-service

# Check iptables rules (on Node)
iptables-save | grep myapp-service

Summary for Senior

  • Service — stable L4 facade for unstable Pods.
  • kube-proxy implements load balancing via iptables (default) or IPVS.
  • EndpointSlice — scalable replacement for Endpoints in large clusters.
  • Session Affinity violates stateless principles — use with caution.
  • For L7 load balancing (HTTP routing) use Ingress, not Service.
  • Service without selector — bridge to external resources.
  • Service Mesh — evolution of networking in K8s (L7, mTLS, observability).

Interview Cheat Sheet

Must know:

  • Service — stable L4 address (IP + DNS) for a group of ephemeral Pods
  • Service finds Pods via labels/selectors; updates Endpoints automatically
  • kube-proxy implements load balancing via iptables (default) or IPVS (more scalable)
  • ClusterIP — internal communication, NodePort — external access, LoadBalancer — cloud IP
  • Headless Service (clusterIP: None) — DNS returns IPs of all Pods (for StatefulSet)
  • Service without selector + manual Endpoints — bridge to external resources
  • For L7 load balancing (HTTP routing) use Ingress, not Service

Frequent follow-up questions:

  • “What happens if a Pod behind a Service crashes?” — kubelet updates Endpoints; traffic no longer goes to that Pod
  • “How does iptables differ from IPVS?” — iptables: O(n) rules, IPVS: O(1) lookup, better for thousands of Pods
  • “Why is Headless Service needed?” — Direct access to specific Pods (StatefulSet, databases)
  • “Does Service work at L4 or L7?” — L4 (TCP/UDP). For L7 (HTTP) — Ingress

Red flags (DO NOT say):

  • “Service = a container with an application” (it’s an abstract network route)
  • “Service replaces Pods” (Service routes traffic to Pods)
  • “IPVS is always better than iptables” (for small clusters iptables is simpler and sufficient)
  • “Session Affinity is good practice” (violates stateless principles)

Related topics:

  • [[What types of Service exist (ClusterIP, NodePort, LoadBalancer)]] — Service types
  • [[What is Pod in Kubernetes]] — what’s behind the Service
  • [[What is Ingress in Kubernetes]] — L7 routing