Hands-on Lab·Certified Kubernetes Administrator
hostPort and hostNetwork
The two ways a Pod can take a port on the node it runs on, what each does to scheduling, and why a Deployment that uses either one quietly stops scaling.
Services and Networking Guide 56 of 103 Intermediate
- Kubernetes1.36.4
- Cluster4 nodes
- Runtimecontainerd 2.2.6
- CNICalico v3.32.1
- TimeAbout 15 min
Node addresses are this lab's. The scheduler message and the behaviour are the same anywhere.
| Server Name | IP Address | OS | Roles | CPU | RAM | HDD |
|---|---|---|---|---|---|---|
| CKA1001 | 192.168.0.175 | Ubuntu 26.04 LTS | Control Plane Node | 2 Core | 4 GB | 50 GB |
| CKA1001-NODE01 | 192.168.0.176 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
| CKA1001-NODE02 | 192.168.0.177 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
| CKA1001-NODE03 | 192.168.0.178 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
This guide includes
Use this when something has to answer on a node's own port with no Service in front of it - an ingress controller, a node agent. This matters because claiming a host port makes that port part of what a node has to offer, so it becomes a scheduling constraint you never meant to write.
- claiming a port on the node directly with
hostPort, no Service and no kube-proxy involved - creating a second Pod that wants the same port, and seeing what the scheduler does about it
- asking a Deployment for four replicas across three schedulable nodes with one port each
- taking the idea to its conclusion with
hostNetwork: true- every port at once
Before you start
- guide 47 - the supported way to expose a workload, which these two are not.
-
A Pod that claims a port on its node
-
A second Pod that wants the same port
-
What that means for a Deployment
-
The same idea, taken to its conclusion