Kubernetes Services

A Kubernetes Service is a logical abstraction that enables stable network access to a group of ephemeral Pods, ensuring consistent communication within a dynamic containerized environment. It provides a single entry point to access one or more Pods running the same application, even as those Pods are rescheduled or replaced.

What does Kubernetes Services do?

In Kubernetes, Pods are frequently created and destroyed. Their IP addresses change, making direct communication unreliable. Kubernetes Services solve this by:

• Offering a consistent DNS name and virtual IP (ClusterIP) to represent a dynamic set of Pods
• Enabling built-in load balancing to distribute traffic across Pods
• Facilitating internal and external communication via well-defined service types
• Supporting service discovery with DNS resolution

For developers, this means you can deploy your app without worrying about the lifecycle of individual Pods. Your frontend app can talk to your backend using a simple internal DNS name, e.g., backend.default.svc.cluster.local, and Kubernetes takes care of routing the traffic to the right place.

Key Features

• Label selectors: Services automatically find matching Pods using labels.
• Port mapping: You can expose your app on different ports internally and externally.
• Traffic routing: Kubernetes uses kube-proxy to forward requests to one of the matching Pods using round-robin or IPVS.
• DNS resolution: CoreDNS resolves service names to the virtual ClusterIP.
• Endpoint management: Kubernetes tracks the live IPs of Pods and updates the Service’s endpoints in real-time.

Use Case Examples

1. Internal Communication with ClusterIP (default)

Use this for internal service-to-service communication inside the cluster.

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

This creates a stable DNS name backend.default.svc.cluster.local. Any Pod in the same namespace can reach the backend using this name, even if the actual Pod IPs change.

2. External Access with LoadBalancer

Use this when you want to expose your app to the internet through a cloud provider.

apiVersion: v1
kind: Service
metadata:
  name: webapp
spec:
  type: LoadBalancer
  selector:
    app: webapp
  ports:
    - port: 80
      targetPort: 3000

Kubernetes will provision a cloud load balancer (e.g., AWS ELB, GCP Load Balancer) and route external traffic to port 3000 on your Pods.

3. Static Port Access with NodePort

Use this for quick access to your service on each node’s IP and a fixed port.

apiVersion: v1
kind: Service
metadata:
  name: debug-api
spec:
  type: NodePort
  selector:
    app: debug-api
  ports:
    - port: 80
      targetPort: 8080
      nodePort: 30080

You can now reach your service at http://<node-ip>:30080. Not recommended for production due to lack of load balancing and security features.

4. Connecting to External Services with ExternalName

Use this to map a Kubernetes Service to an external DNS name without managing any Pods.

apiVersion: v1
kind: Service
metadata:
  name: external-db
spec:
  type: ExternalName
  externalName: db.example.com

Accessing external-db.default.svc.cluster.local will resolve to db.example.com.

Types of Kubernetes Services

Developer Notes

• Health checks: Services don’t perform health checks themselves. Use readiness probes on Pods to avoid routing traffic to unready backends.
• Session affinity: You can configure Services to use client IP for sticky sessions.

Example: sessionAffinity: ClientIP

• Headless Services: Set clusterIP: None to skip kube-proxy routing. Useful for StatefulSets or DNS-based service discovery.
• Service without selector: Manually define endpoints. Handy for legacy apps or external services.

Common Pitfalls

• Incorrect label selectors: If labels don’t match, the Service won’t find any Pods.
• Exposing too much: Using NodePort or LoadBalancer without a firewall or Ingress controller can expose sensitive apps.
• DNS delays: In some environments, changes to Services may take time to propagate through CoreDNS.

Security Considerations

• Always pair externally exposed Services with proper Ingress controllers, TLS, and authentication mechanisms.
• Apply NetworkPolicies to control which Pods can reach the Service.
• Monitor Endpoints and service access logs for unusual activity or misrouted traffic.

Similar Concepts

• Ingress: Layer 7 routing for HTTP/S traffic, often used with LoadBalancer Services.
• EndpointSlice: More scalable representation of Service endpoints.
• Service Mesh: Adds observability, traffic shaping, and mTLS to Service communication.