A partner system outside the OKE cluster must reach a Service via a port on worker nodes. Which Service type publishes that node port, and how should teams treat it as a public front door on OKE?
Select an answer to reveal the explanation.
Short Explanation
NodePort hangs the Service on a port on every worker—like side doors on each building. Handy as an escape hatch or for some ingress paths, but not the usual preferred public front door on OKE compared with a LoadBalancer Service.
Full Explanation
When a partner system outside the cluster must reach a Service via a port on worker nodes, NodePort is the Service type that publishes that port on each worker. On OKE it is best treated as an escape hatch or as a helper path for some ingress and flannel designs—not the usual preferred public front door, which is typically a LoadBalancer Service or an Ingress in front of ClusterIP Services. ClusterIP does not open the same high port on every worker’s public NIC by default; it stays internal to the cluster network model. Ingress alone without any Service does not magically bind host ports in the 30000–32767 range for every rule or every Pod name. ExternalName does not provision an OCI flexible load balancer; it returns a DNS alias to an external name outside normal Pod selection and readiness. Exam caveat: exposing NodePorts on publicly reachable worker IPs expands the attack surface and complicates security lists and network security groups—prefer managed load balancers for resident-facing or partner APIs whenever the platform path allows. Operational check: if NodePort is required for the partner path, confirm the allocated node port, restrict source CIDRs at the VCN edge, and document why LoadBalancer or Ingress was not used as the primary front door.