Kubernetes Pod Network Configuration

Kubernetes Pod Network Configuration is the collection of Pod spec fields governing how a Pod's networking is set up beyond the default CNI-provisioned, cluster-internal networking every Pod receives automatically — covering DNS resolution behavior, host networking opt-in, and additional network interfaces — giving authors control over networking specifics for the narrower set of workloads whose requirements go beyond the standard Pod networking model.

DNS Configuration

dnsPolicy Options

spec.dnsPolicy determines how a Pod's DNS resolution is configured: ClusterFirst, the default, routes DNS queries through the cluster's internal DNS service first, falling back to the node's upstream DNS for names outside the cluster domain; Default instead inherits the node's own DNS configuration directly; None leaves DNS entirely unconfigured, requiring the Pod's own dnsConfig to specify everything explicitly; and ClusterFirstWithHostNet applies ClusterFirst behavior specifically for Pods also using host networking, where the ordinary ClusterFirst policy would not otherwise apply correctly.

Custom dnsConfig

spec.dnsConfig allows fine-grained customization of the Pod's resolv.conf-equivalent settings — additional nameservers, search domains, and resolver options — layered on top of whatever the chosen dnsPolicy establishes as a baseline, useful for workloads needing to resolve names against a non-standard or additional DNS source alongside the cluster's own.

hostAliases for Static Name Resolution

spec.hostAliases injects static hostname-to-IP mappings directly into the Pod's /etc/hosts, providing a way to resolve specific names without depending on any DNS server at all, useful for pinning a dependency's resolution during migration or testing without altering cluster-wide DNS configuration.

Host Networking

hostNetwork Opt-In

Setting spec.hostNetwork: true causes the Pod to skip creating its own network namespace entirely, instead directly using the node's own network namespace, meaning the Pod's containers see and bind to the node's actual network interfaces rather than a Pod-specific virtual interface, and the Pod's IP becomes the node's own IP.

Consequences of Host Networking

Host networking eliminates the usual Pod-to-Pod IP isolation and removes the overhead of virtual interface setup, but also means port conflicts behave exactly as they would for any two ordinary processes competing for the same port on a single host, and it bypasses Service-based abstraction for anything the Pod itself initiates, making it appropriate mainly for specific infrastructure components (such as certain networking or monitoring DaemonSets) rather than general application workloads.

Host Port and Host IPC/PID Sharing

hostPort as Covered Under the Container Port Model

As detailed under the container port model, hostPort reserves a specific port directly on the node, functioning as a narrower, per-container alternative to full host networking when only specific ports, rather than the entire network namespace, need direct node-level exposure.

hostIPC and hostPID

spec.hostIPC and spec.hostPID, while not strictly networking fields, are frequently configured alongside host networking for the same category of privileged infrastructure workloads, extending the Pod's namespace sharing beyond networking to IPC and process visibility at the host level, each carrying its own security implications distinct from pure network configuration.

Additional Network Interfaces

Multi-Interface Pods Through CNI Plugin Extensions

Beyond the single primary network interface every Pod receives by default, certain CNI configurations support attaching additional network interfaces to a Pod through annotations or dedicated custom resources recognized by a multi-network-capable CNI plugin, used in specialized networking scenarios — such as a Pod needing direct access to a separate physical network for specific data-plane traffic — that a single shared cluster network cannot accommodate.

Configuration Outside the Core Pod Spec

Because standard Kubernetes core types have no native multi-interface field, this capability is realized entirely through CNI-plugin-specific extension mechanisms layered on top of the Pod spec rather than through any field defined by the core API itself, meaning its exact configuration syntax varies depending on which multi-network CNI implementation a cluster has deployed.