One OKE cluster hosts both the clerk portal and the inspector mobile API for a city. What orchestration constructs slice the cluster so a Service or controller affects only the intended replica set?
Select an answer to reveal the explanation.
Short Explanation
Namespaces are neighborhoods; labels are name tags on each house. Controllers and Services use those tags to touch this set of replicas, not every container on the node. That is cluster slicing, not a tenancy redesign.
Full Explanation
When one OKE cluster hosts both a clerk portal and an inspector mobile API, isolation and targeting come from namespaces as scopes and labels as selection keys. Controllers and Services use label selectors to affect only the intended replica set; namespaces bound names and many policies so two apps can coexist without colliding. That is how orchestration slices a shared cluster without a tenancy rebuild per microservice. Recreating the entire OCI compartment tree for every microservice pushes identity and cost boundaries down to infrastructure that is far coarser than Pod selection and is not how you target replicas inside Kubernetes. One public LoadBalancer IP with no selectors and no scopes dumps unrelated backends together and cannot distinguish portal from inspector Pods. Hard-coded Pod names in every manifest break as soon as controllers recreate Pods with new names; selectors on stable labels are the durable binding. Exam caveat: labels must be consistent between workload templates and Service selectors, and namespace boundaries do not replace network policy if you need traffic isolation. Operational check: label portal and inspector Pods distinctly, confirm each Service’s selector returns only its Pods, and verify a mistaken cross-namespace or wrong-label selector yields empty endpoints.