Exposing Kubernetes services to the internet

WHAT THIS TESTS This checks whether you understand Kubernetes networking as layers and can place each object correctly between Pods and external clients.

A GOOD ANSWER COVERS Pods are ephemeral with changing IPs, so a Service provides a stable virtual IP and DNS name and load-balances across the healthy Pods matching its selector. Service types differ by reach: ClusterIP is the default and is reachable only inside the cluster; NodePort opens a static high port on every node so traffic to any node IP on that port reaches the Service, which is crude for production; LoadBalancer asks the cloud provider to provision an external load balancer with a public IP that forwards to the Service, giving one external entry point per Service. An Ingress operates at layer 7. The Ingress resource declares routing rules, host example.com to service A, path /api to service B, and the Ingress controller, such as NGINX or a cloud controller, is the actual proxy that implements them behind a single external load balancer. This lets many services share one IP, with host and path based routing, TLS termination, and centralized config, instead of one expensive cloud load balancer per service.

COMMON WRONG ANSWERS Treating Ingress as a Service type; it is a separate layer-7 object needing a controller. Giving every service its own LoadBalancer, which is costly and unmanageable. Thinking NodePort is production-grade. Forgetting that an Ingress does nothing without a running controller.

LIKELY FOLLOW-UPS Why is a LoadBalancer per service expensive at scale? How does the Ingress controller terminate TLS? What is the difference between Ingress and the newer Gateway API? How does kube-proxy implement Service load balancing?

ONE CONCRETE EXAMPLE A cluster runs a frontend and an api Service, both ClusterIP. You deploy an NGINX Ingress controller fronted by one cloud LoadBalancer, then an Ingress routing app.example.com/ to frontend and app.example.com/api to api, with a TLS cert terminated at the controller. One public IP and certificate now serve both services with path-based routing, instead of two separate cloud load balancers.