Understanding Kubernetes Services and Pods: Types, Proxies, and Configurations

Services and Pods

Kubernetes Pods have a lifecycle; they can be created and, once destroyed, they do not restart. When you run an application with a Deployment, Pods can be dynamically created and destroyed.

A Kubernetes Service is an abstraction that defines a logical set of Pods and a policy to access them, often called a microservice. The target Pod set is usually determined by a label selector.

For example, imagine a backend handling images running three interchangeable replicas. The frontend does not need to know which backend instance it talks to; the Service abstraction provides this decoupling.

Unlike a Pod's IP address, a Service IP (VIP) is virtual and is implemented via iptables (or IPVS) to transparently redirect traffic to appropriate Endpoints. Environment variables and DNS are populated based on the Service's VIP and port.

kube-proxy supports three proxy modes: userspace, iptables, and IPVS, each with slightly different operation.

Userspace

When a Service is created (e.g., a backend Service for an image‑processing app), the Kubernetes master assigns it a virtual IP such as 10.0.0.1 and a port (e.g., 1234). All kube-proxy instances observe the Service, open a port, and set up iptables rules that redirect traffic from the VIP to the Service port.

Clients connect to the VIP; iptables redirects the packet to a chosen backend, and the Service proxy forwards the traffic.

iptables

Similar to the userspace example, the Service receives a VIP. kube-proxy creates a chain of iptables rules that redirect traffic from the VIP to per‑Service and per‑Endpoint rules, which finally NAT the packet to the backend. Packets never leave kernel space, preserving the client IP.

IPVS

In large clusters (e.g., 10,000 services), iptables becomes a performance bottleneck. IPVS, built on kernel hash tables, provides consistent performance and advanced load‑balancing algorithms (least‑connection, locality‑aware, weighted, persistent).

ClusterIP

Example YAML for a ClusterIP Service:

apiVersion: v1
kind: Service
metadata:
  name: service-python
spec:
  ports:
  - port: 3000
    protocol: TCP
    targetPort: 443
  selector:
    run: pod-python
  type: ClusterIP

ClusterIP services are reachable only within the cluster.

NodePort

NodePort exposes the Service on a static port on each node (default range 30000‑32767), allowing external access:

apiVersion: v1
kind: Service
metadata:
  name: service-python
spec:
  ports:
  - port: 3000
    protocol: TCP
    targetPort: 443
    nodePort: 30080
  selector:
    run: pod-python
  type: NodePort

Clients can reach the Service via http://<node-ip>:30080.

LoadBalancer

LoadBalancer services provision an external load balancer (typically in public‑cloud environments) and expose the Service via an external IP.

apiVersion: v1
kind: Service
metadata:
  name: service-python
spec:
  ports:
  - port: 3000
    protocol: TCP
    targetPort: 443
    nodePort: 30080
  selector:
    run: pod-python
  type: LoadBalancer

Cloud‑specific annotations (e.g., AWS load‑balancer settings) can be added under metadata.annotations.

ExternalName

An ExternalName Service maps a Service name to an external DNS name instead of a selector.

kind: Service
apiVersion: v1
metadata:
  name: service-python
spec:
  ports:
  - port: 3000
    protocol: TCP
    targetPort: 443
  type: ExternalName
  externalName: remote.server.url.com

CoreDNS ≥ 1.7 is required; the Service resolves to a CNAME record pointing to the external DNS name.

ExternalName can also be used to access services across namespaces, enabling cross‑namespace ingress configurations.

Original source: https://segmentfault.com/a/1190000023125587