Skip to content

Chapter 3 of 8

Services, Networking, and Discovery

A Service is an abstraction that defines a logical set of Pods and a policy to access them, typically through a stable virtual IP and DNS name. Services discover their backend Pods via a label selector, and the endpoints controller automatically updates the Service's backend list whenever matching Pods appear or disappear. In large clusters, the legacy Endpoints API has been superseded by EndpointSlices, which split backend Pods into multiple smaller objects, reducing update size and enabling scalable routing. kube-proxy on each node reads EndpointSlices (or Endpoints) and programs iptables, IPVS, or eBPF rules to implement the Service virtual IP and load-balance traffic to the right Pod IPs.

Kubernetes exposes several Service types for different access patterns. ClusterIP, the default, exposes the Service on a cluster-internal IP reachable only from within the cluster. NodePort exposes the Service on each node's IP at a static port (default range 30000-32767), making it reachable from outside the cluster as <NodeIP>:<NodePort>. LoadBalancer provisions a cloud-provider-specific external load balancer that routes traffic to backend nodes on a public IP. A Headless Service (clusterIP: None) does not allocate a virtual IP or perform load balancing; instead, DNS queries return the Pods' IPs directly, which is especially useful for StatefulSets and custom discovery. An ExternalName Service maps a Service to a CNAME DNS record, allowing Pods to reach an external service via a cluster-internal name.

Network security is controlled through NetworkPolicy resources, which specify how groups of Pods are allowed to communicate with each other and other network endpoints. NetworkPolicy enforcement requires a CNI plugin that supports it, such as Calico, Cilium, or Weave Net. A NetworkPolicy without a podSelector applies to all Pods in the namespace; if neither an ingress nor an egress rule list is provided, all matching traffic is allowed. The default cluster behavior is permissive: if no NetworkPolicy selects a Pod, all ingress and egress traffic is allowed. Cluster-internal name resolution is provided by kube-dns or coredns, and Service names resolve via the pattern <svc>.<ns>.svc.cluster.local.

All chapters
  1. 1Pods and Container Fundamentals
  2. 2Workload Controllers and Scaling
  3. 3Services, Networking, and Discovery
  4. 4Namespaces, Configuration, and Storage
  5. 5Cluster Architecture and Scheduling
  6. 6Resource Management and Probes
  7. 7Security, Identity, and Admission Control
  8. 8Tooling, Extensibility, and Operations

Drill it

Reading is not remembering. These come from the Kubernetes Core Objects Cheatsheet deck:

Q

What is a Kubernetes Pod?

A Pod is the smallest deployable unit in Kubernetes; it encapsulates one or more tightly coupled containers that share a network namespace, IPC, and optionally...

Q

What does a Pod represent in the Kubernetes object model?

A Pod represents a single instance of a running process in a cluster and is described by a Pod manifest containing metadata (labels, annotations) and a pod spec...

Q

What Kubernetes object directly manages a set of identical Pods?

A ReplicaSet manages a stable set of identical Pods and ensures a specified number of pod replicas are running at any given time.

Q

What controller is most commonly used to deploy stateless workloads in production?

A Deployment, which manages a ReplicaSet and provides declarative updates, rolling updates, and rollback capability.

Study all 120 cards → Export to Anki