Why should a normal ClusterIP Service-backed civic app avoid hostNetwork and hostPID?
Select an answer to reveal the explanation.
Short Explanation
hostNetwork/hostPID mean sharing the node's hallway and process list—great for rare system agents, awful for a normal Service app. ClusterIP, probes, and in-cluster DNS work fine without those host shares.
Full Explanation
hostNetwork and hostPID place a Pod into the node’s network or PID namespaces. That weakens isolation, exposes more of the node’s surface, and is inappropriate for a normal ClusterIP-backed civic app without a strong, exceptional need (for example certain node agents). Ordinary municipal services should use the Pod network and rely on Services for discovery and exposure rather than sharing host namespaces.
hostNetwork is not required for ClusterIP Services to receive traffic; ClusterIP works on the Pod network. hostPID is not mandatory for readiness probes—probes execute in the container’s context without sharing the host PID namespace. In-cluster DNS resolution for Services works without hostNetwork; claiming DNS cannot resolve without hostNetwork confuses networking modes.
Exam caveat: questions may tempt you with “just set hostNetwork for connectivity”—reject that for normal apps. Operational check: ensure the civic Deployment has hostNetwork and hostPID unset/false; confirm Service ClusterIP connectivity with a debug Pod curl to the Service DNS; city security reviews should flag host namespace sharing on ordinary apps as a policy violation unless a documented exception exists.