Once you have Pods running on a Google Kubernetes Engine cluster, you need a way to send traffic to them. Pods come and go. Their IP addresses change. Anything talking to a Pod by IP will break the moment that Pod gets rescheduled. Kubernetes Services solve this problem by giving you a stable network identity in front of a changing set of Pods, and the Professional Cloud Architect exam expects you to know which Service type fits which routing problem.
I'll walk through the five Service types you need to know, split by whether they handle internal traffic (Pod-to-Pod inside the cluster) or external traffic (from outside the cluster).
ClusterIP is the default Service type. When you create a ClusterIP Service, Kubernetes assigns it a single virtual IP that lives only inside the cluster, plus a DNS name. Other Pods send requests to that DNS name, the Service resolves it to the virtual IP, and traffic gets load-balanced across whichever Pods currently match the Service's selector. The application talking to the Service does not need to know how many Pods are behind it or what their IPs are. Pods can scale up, scale down, get rescheduled to a different node, and the caller keeps using the same DNS name without noticing.
This is the right answer for almost all internal communication. A frontend Pod calling a backend API, a worker calling a cache, a service mesh sidecar talking to its companion. ClusterIP gives you a stable name, automatic load balancing, and zero awareness of individual Pod identity.
Headless Service is the deliberate opposite. It has no virtual IP and does no load balancing. Instead, when you query its DNS name, you get back the IP addresses of the individual Pods directly. The application is then responsible for picking which Pod to talk to.
You use Headless Services when the application genuinely needs to address specific Pods. Stateful workloads are the classic case. A database cluster where each replica has a distinct role, a sharded cache where keys map to specific instances, or any system that does its own client-side load balancing. If you find yourself needing to know which Pod is which, that is the signal for Headless Service. If you do not, ClusterIP is what you want.
Once traffic needs to come from outside the cluster, the Service types change.
NodePort opens the same port on every node in the cluster. External traffic hitting any node IP at that port gets forwarded to the Service and load-balanced across its Pods. This is simple but limited. The port has to be in a high range (default 30000 to 32767), the client needs to know a node IP, and there is no built-in protection if a node goes down. NodePort on its own is rarely the production answer. It is more often used as a building block underneath a cloud load balancer.
LoadBalancer is what you actually use for production external traffic on Google Kubernetes Engine. When you create a LoadBalancer Service, GKE provisions a Google Cloud load balancer with an external IP address and wires it up to route traffic to the Service's Pods. From the outside, clients hit the external IP and never see any of the cluster mechanics. Internally, GKE handles the integration between the Service and the cloud load balancer for you. This is the default way to expose a single application on a single port to the internet.
ExternalName is the odd one out. It does not route traffic at all. It maps a Service name inside the cluster to an external DNS name, like example.com. When a Pod looks up the Service, DNS returns a CNAME pointing to the external name, and the Pod's traffic goes to whatever that resolves to. The use case is integration. You want your in-cluster application to talk to my-database, but the database actually lives at some managed external endpoint. ExternalName lets you abstract that without baking the external hostname into your application config.
Ingress is the last and most powerful option. Ingress is not a regular Service type. It sits in front of Services and provides HTTP and HTTPS routing. With Ingress you get URL-based routing (send /api/* to one Service, /static/* to another), SSL termination, and the ability to expose multiple Services through a single external IP. On GKE, an Ingress resource provisions a Google Cloud HTTP(S) Load Balancer behind the scenes. When you have more than one application, or you need path-based routing, or you want SSL handled at the edge, Ingress is the right answer instead of a separate LoadBalancer Service per app.
Professional Cloud Architect questions on Kubernetes networking almost always come down to picking the right Service type for a stated requirement. A few patterns to anchor on:
The trap on Professional Cloud Architect questions is reaching for LoadBalancer when the scenario describes multiple HTTP routes or multiple hostnames behind one IP. That is an Ingress question. The other common trap is choosing ClusterIP when the workload is stateful and the question mentions Pods needing to address each other directly. That is Headless Service.
My Professional Cloud Architect course covers Kubernetes Services for network routing on GKE alongside the rest of the containers and serverless material.
