A sanitation routing image sits in OCIR and must run on OKE. What is the atomic scheduled unit that actually runs that image (alone or with tightly coupled sidecars)?
Select an answer to reveal the explanation.
Short Explanation
On Kubernetes/OKE, the Pod is the thing the scheduler places—the suitcase that holds your container (and optional sidecars). Long-running services usually wrap Pods in Deployments, but the Pod is still what runs the OCIR image.
Full Explanation
On Kubernetes/OKE, the atomic scheduled unit that runs a sanitation routing image—alone or with tightly coupled sidecars—is the Pod: one or more containers that share network namespace and volumes and are placed together by the scheduler as a single unit. Sidecars for logging, proxies, or agents ride in the same Pod because they must share localhost and lifecycle with the application container. An OCI compartment is an IAM and tenancy scope for organizing cloud resources; it is not scheduled onto worker CPUs as a runtime unit. A LoadBalancer Service fronts existing Pods and allocates a load balancer; without a Pod template there is nothing for the scheduler to place or for the node to run. A ConfigMap stores configuration data as keys and values; worker nodes do not execute ConfigMap entries as binaries. Exam caveat: long-running services rarely leave a naked Pod as the only object—Deployments or similar controllers own Pod templates and replica counts—but the scheduler still places Pods, not Deployments as processes. Operational check: kubectl get pods -o wide after deploy, confirm the image runs inside a Pod on a worker, and note that sidecars appear as additional containers in that same Pod specification.