Inside an OKE cluster, the clerk portal must call the checkout service. Which Service type provides a stable in-cluster virtual IP that forwards to ready Pods and is not itself a public internet front door?
Select an answer to reveal the explanation.
Short Explanation
ClusterIP is the inside voice of the cluster: a stable virtual IP for Pod-to-Pod calls. It tracks ready backends and is not exposed to the public internet by itself. Call checkout by service name, not by chasing Pod IPs.
Full Explanation
Inside the cluster, when the clerk portal must call checkout, ClusterIP is the Service type that provides a stable in-cluster virtual IP and DNS name forwarding to currently ready Pods. It is deliberately not a public internet front door; other Pods use it for east-west calls while the control plane updates membership as replicas change. Requiring LoadBalancer for purely Pod-to-Pod calls provisions an OCI load balancer you do not need for internal traffic and conflates north-south public exposure with in-cluster discovery. ExternalName aliases an external DNS name; pointing it at a random worker hostname is brittle, bypasses readiness-aware Pod backends, and is not how you front Ready checkout Pods. Putting every Pod on hostNetwork and publishing node public IPs in application config couples clients to nodes, bypasses the Service abstraction, and is a poor default for in-cluster calls. Exam caveat: ClusterIP traffic still only reaches Pods that pass readiness and match the selector—having a stable VIP with empty endpoints still fails callers. Operational check: curl the checkout ClusterIP or DNS name from a portal Pod, confirm endpoints list Ready checkout Pods, and verify no public OCI load balancer was created solely for that internal Service.