Kubernetes Service YAML Generator

Kubernetes Services explained: types, selectors, endpoints, and DNS

A Kubernetes Service is the stable networking abstraction that sits in front of a fleet of ephemeral Pods. Pods are born and die constantly — their IPs change, they get rescheduled, they autoscale — and no client can be expected to track that. A Service gives you one fixed virtual IP and DNS name, and kube-proxy / the CNI quietly load-balances each connection across whichever Pods currently match the selector. The API group is v1 (not apps/v1), because Services predate the apps controllers.

In other words: Deployment creates the Pods, Service exposes them. Without a Service, two Pods in the same cluster can technically talk Pod-to-Pod, but the moment one of them restarts the IP changes and everything breaks.

The five Service types

• ClusterIP (default) — a virtual IP reachable only from inside the cluster. Perfect for internal APIs, databases, caches.
• NodePort — opens the same TCP port (30000–32767) on every node and forwards to the Pods. Cheap way to expose something externally, but fragile (clients need to know node IPs).
• LoadBalancer — asks the cloud provider to provision an external load balancer (ELB on AWS, GLB on GCP, Azure LB). You pay per LB (~US$ 18-25/month each), so prefer one Ingress over many LoadBalancer Services.
• ExternalName — pure DNS CNAME alias to an external hostname. No proxying, no selector — useful for migrating from an external dependency without changing app code.
• Headless (clusterIP: None) — no virtual IP at all; DNS returns the A records of every Pod. The required pattern for StatefulSets, where each replica needs an addressable identity (pod-0.svc..., pod-1.svc...).

Minimum manifest

apiVersion: v1
kind: Service
metadata:
  name: my-app-svc
spec:
  type: ClusterIP
  selector:
    app: my-app
  ports:
  - name: http
    port: 80
    targetPort: 8080
    protocol: TCP
    appProtocol: http

The selector matches labels on Pods — that is how Kubernetes knows which Pods to route to. port is what clients call (the Service port); targetPort is what the container actually listens on (can be a number or a named port from the Pod spec). nodePort only applies when type is NodePort or LoadBalancer.

How traffic actually reaches a Pod

When you create a Service with a selector, Kubernetes also creates an Endpoints object (or, since 1.21, an EndpointSlice — faster at scale) that lists the IP:port of every matching Pod. kube-proxy watches that list and programs iptables/IPVS rules on each node so connections to the ClusterIP are DNAT'd to a real Pod. From inside the cluster you reach the Service at my-app-svc.default.svc.cluster.local (or just my-app-svc if you are in the same namespace).

Session affinity and load-balancing

By default Services do round-robin (well, hashed iptables rules approximating it). Set spec.sessionAffinity: ClientIP to make every connection from the same source IP hit the same Pod — useful for legacy stateful apps. With a true service mesh (Istio, Linkerd) the sidecar Envoy proxy takes over load-balancing entirely and you gain L7 features (retries, circuit breakers, locality-aware routing).

Service vs Ingress

• Service is L4 (TCP/UDP/SCTP). It does not understand HTTP, paths, hosts, or TLS termination.
• Ingress is L7 HTTP routing — virtual hosts, path prefixes, TLS certificates, often backed by an Ingress controller (nginx, Traefik, AWS ALB Ingress Controller).
• Production pattern: one LoadBalancer Service in front of an Ingress controller, and ClusterIP Services for everything else.

FAQ

Does the ClusterIP stay stable across restarts? Yes — once allocated, the ClusterIP is fixed until you delete the Service. You can also pin it explicitly with spec.clusterIP: 10.96.0.42 if you really need to.

When should I use a headless Service? Whenever clients need to talk to a specific replica (StatefulSet, distributed databases like Cassandra/Kafka, peer-discovery protocols). DNS returns one A record per Pod instead of a single virtual IP.

Are LoadBalancer Services expensive? Yes — each one provisions a real cloud LB (~US$ 18-25/month on AWS NLB, plus data transfer). Use one Ingress to fan out to many backend Services instead.

Can a Service select Pods in a different namespace? No — selectors are namespace-scoped. To bridge namespaces, use an ExternalName Service or manually create an Endpoints object with the same name as the Service.

Why is my Service returning "connection refused" even though the Pod is running? Usually the targetPort does not match what the container actually listens on, or the readiness probe is failing and kube-proxy has removed the Pod from the endpoints list. Check kubectl get endpoints my-app-svc — if the list is empty, you know it is the selector or readiness.