Networking & Services Knowledge

A Service provides stable networking for a changing set of Pods. It uses selectors to find ready backends, creates a stable virtual IP and DNS name, and keeps access consistent even when Pods restart or move.

ClusterIP exposes an internal virtual IP reachable inside the cluster. NodePort exposes the Service on a port on each node as <NodeIP>:<NodePort>. LoadBalancer asks the infrastructure provider to create an external load balancer for the Service.

It provides a stable virtual IP and DNS name for a changing set of Pods selected by labels. kube-proxy or an eBPF dataplane sends traffic from the Service IP to ready endpoints listed in EndpointSlices.

kube-proxy programs Service routing on nodes, commonly with iptables or IPVS rules. In some clusters, an eBPF CNI replaces part or all of kube-proxy behavior, but the goal is still to route Service traffic to healthy endpoints.

IPVS mode uses Linux IP Virtual Server for Service load balancing. It can perform better than large iptables rule sets in big clusters, but it still depends on correct Service, EndpointSlice, and node networking state.

Use kubectl expose deployment web --port=80 --type=NodePort for a quick NodePort Service. In production, review the generated Service YAML, set names and selectors deliberately, and choose ClusterIP, NodePort, LoadBalancer, or Ingress/Gateway based on access needs.

An EndpointSlice is the scalable representation of Service backends. It records endpoint IPs, ports, readiness, and topology hints. EndpointSlices replaced the older Endpoints API for better scaling and richer endpoint metadata.

The selector may not match Pod labels, Pods may not be Ready, Pods may be in another namespace, or target Pods may not exist. Check kubectl get endpointslice -l kubernetes.io/service-name=<svc> and compare labels.

port is the port exposed by the Service. targetPort is the port on the selected Pods. If targetPort is wrong, traffic reaches the Service but fails at the backend connection.

Use kubectl get svc -A. Add -o wide to see more details such as ClusterIP, external IPs, and ports.

CoreDNS provides service discovery through names such as <service>.<namespace>.svc.cluster.local. Pods usually query the cluster DNS Service to resolve Services, and short names work within the same namespace.

The common default is svc.cluster.local for Services under the cluster domain cluster.local. The full Service name is usually <service>.<namespace>.svc.cluster.local, but the cluster domain can be customized.

Use kubectl exec -it <pod> -- nslookup kubernetes.default or run a temporary debug Pod with DNS tools. If the image lacks nslookup, use a toolbox image such as busybox, netshoot, or dnsutils depending on the environment.

The Pod may have wrong /etc/resolv.conf, NodeLocal DNS issues, a broken kube-dns Service, NetworkPolicy blocking DNS, CoreDNS plugin errors, upstream DNS failures, or CNI connectivity problems.

Ingress defines HTTP and HTTPS routing into the cluster. It needs an Ingress controller, such as NGINX, Traefik, or a cloud controller, to watch Ingress objects and program actual proxy or load balancer behavior.

A Service provides stable networking to Pods. Ingress provides HTTP or HTTPS routing into the cluster, usually routing hostnames and paths to Services. Ingress depends on Services for backend selection.

Create a networking.k8s.io/v1 Ingress with rules for host, path, pathType, backend service name, and service port. For example, route host example.com path / with pathType: Prefix to Service web on port 80. The cluster also needs a matching Ingress controller.

Gateway API is a newer Kubernetes networking API that separates infrastructure ownership from route ownership. GatewayClass chooses the implementation, Gateway defines listeners, and routes such as HTTPRoute define application routing with richer delegation and traffic-splitting support.

A NetworkPolicy is a firewall-like Kubernetes object that controls allowed ingress and egress for selected Pods. It is enforced by the CNI. Once a policy selects a Pod for a direction, allowed peers and ports must be explicit for that direction.

By default, all Pod ingress and egress traffic is allowed. Pods become isolated only after a NetworkPolicy selects them for ingress, egress, or both, depending on the policyTypes and rules.

An ExternalName Service maps a Kubernetes Service name to an external DNS name using a CNAME record. It does not create a ClusterIP or proxy traffic; clients resolve the external name through DNS.

Readiness gates let custom Pod conditions influence whether a Pod is considered Ready. External controllers, such as load balancer or platform controllers, can set those conditions so Kubernetes traffic readiness reflects external system state.

Hairpin mode allows a Pod to access a Service IP that routes back to the same Pod or same node. Without correct hairpin behavior, direct Pod IP access can work while Service access from the backend Pod or node behaves strangely.

ServiceAccount tokens authenticate Pods to the Kubernetes API server. Apps and controllers may use them to discover Services, watch EndpointSlices, or read other allowed API resources. They do not route traffic by themselves; RBAC controls what the token can access.