Pods come and go with their changing IP addresses, so Kubernetes abstracts them behind Services, which define a logical set of Pods and a stable access policy. A Service uses label selectors to match Pods and provides a stable IP, DNS name, and load balancing. The default ClusterIP type exposes the Service only inside the cluster for microservice-to-microservice traffic, while NodePort adds a static port in the 30000–32767 range on every node's IP, enabling external access via NodeIP:NodePort. LoadBalancer builds on top by provisioning a cloud-provider load balancer such as AWS ELB, with traffic flowing External LB → NodePort → ClusterIP → Pod. ExternalName maps a Service to a CNAME record pointing to an external DNS name, providing a cluster-internal alias for outside services, and headless Services (clusterIP: None) return Pod IPs directly through DNS, often paired with StatefulSets to give each Pod a stable address for peer-to-peer communication.
For HTTP and HTTPS traffic at higher layers, an Ingress resource defines host-based and path-based routing rules with optional TLS termination. An Ingress resource is inert on its own; it requires an Ingress Controller such as NGINX, Traefik, HAProxy, or AWS ALB to watch the resources and configure the underlying load balancer. TLS certificates are referenced through a Secret containing tls.crt and tls.key, and tools like cert-manager automate issuance from Let's Encrypt via ACME HTTP-01 or DNS-01 challenges, with the DNS-01 challenge supporting wildcard certificates. At the network level, NetworkPolicies are namespace-scoped rules enforced by CNI plugins such as Calico and Cilium that control Pod-to-Pod and Pod-to-external traffic by IP and port. Without any policy in a namespace, all Pods can talk to all Pods, so the recommended baseline is a default-deny policy that selects all Pods and blocks all traffic, layered with explicit allow rules including an egress allowance for UDP/53 to the kube-system namespace so CoreDNS continues to resolve names. Service meshes like Istio, Linkerd, and Consul Connect add a further layer for service-to-service communication, with sidecar proxies (typically Envoy) injected automatically by a mutating admission webhook that provide mutual TLS, retries, traffic splitting, and observability. Istio extends this with VirtualService for routing rules such as canary weights and DestinationRule for post-routing traffic policies including connection pools and outlier detection.