While preparing for the GCP Professional Cloud Architect (PCA) exam, many candidates get confused by in-cluster microservices communication patterns. In the real world, this is fundamentally a decision about how to expose and address scaled microservices reliably without violating cluster network boundaries or operational best practices. Let’s drill into a simulated scenario.
The Scenario #
CloudByte Gaming is a global game development startup specializing in real-time multiplayer experiences. Their backend architecture heavily relies on Google Kubernetes Engine (GKE) to deploy microservices that handle matchmaking, game state synchronization, user profiles, and chat features.
Each microservice needs to remain internal to the cluster for security and performance reasons. It is crucial for CloudByte that each microservice can scale horizontally by adjusting replica counts independently to optimize resource utilization and handle traffic spikes.
Furthermore, for observability and maintainability, they want other microservices within the cluster to call any microservice consistently — using a stable, uniform addressing method — regardless of how many replicas that microservice currently runs.
Key Requirements #
Design the microservices deployment strategy on GKE so that:
- Microservices remain accessible only inside the cluster.
- Each microservice can be scaled independently via replica count.
- Microservices communicate with each other through a uniform internal DNS name that abstracts the underlying pods and replicas.
The Options #
- A) Deploy each microservice as a Deployment. Expose the Deployment within the cluster using a ClusterIP Service, and use the Service’s DNS name to address it from other microservices inside the cluster.
- B) Deploy each microservice as a Deployment. Expose the Deployment via an Ingress with an IP address, and use the Ingress IP to address the Deployment from other microservices.
- C) Deploy each microservice as a standalone Pod (no Deployment). Expose each Pod internally using a ClusterIP Service, and address the Pod using the Service DNS from other microservices.
- D) Deploy each microservice as a standalone Pod. Expose the Pod via an Ingress with an IP address, and use the Ingress IP address to address the Pod internally.
Correct Answer #
Option A.
Step-by-Step Winning Logic #
Deploying microservices as Deployments provides native support for scaling via replica count and lifecycle management (rolling updates, self-healing). Exposing these Deployments internally via a ClusterIP Service creates a stable, internal DNS name for all pods behind it, abstracting away pod IPs and allowing other microservices to discover and call the service uniformly.
This aligns with Kubernetes best practices that promote the “cattle not pets” principle — treating pods as ephemeral instances behind a durable service abstraction. Using an Ingress (Options B and D) is intended for external HTTP(S) traffic routing and is unnecessary, adds complexity, and exposes IPs externally, violating the requirement to keep microservices internal.
Deploying standalone pods (Options C and D) removes Kubernetes’ powerful deployment lifecycle benefits and complicates scaling and management.
The Architect’s Analysis #
The Traps (Distractor Analysis) #
-
Why not B?
An Ingress typically exposes services externally (outside the cluster) and uses HTTP(S) routing. Internal microservices communication should use cluster-local mechanisms for efficiency and security. Relying on an Ingress IP within the cluster increases latency and operational complexity. -
Why not C?
Deploying single pods is not scalable or resilient. Pods may die and be recreated with new IPs, breaking direct addressing without a stable Service abstraction. -
Why not D?
Combining standalone pods with external ingress is conceptually and operationally unsound for internal cluster communication, exposing the pods unnecessarily and complicating network policies and security.
The Architect Blueprint #
- Mermaid Diagram illustrating the flow of internal traffic between microservices via Services.
graph LR
MS1[Microservice 1 Deployment]
MS2[Microservice 2 Deployment]
SVC1[ClusterIP Service: ms1.svc.cluster.local]
SVC2[ClusterIP Service: ms2.svc.cluster.local]
MS1 --> SVC1
MS2 --> SVC2
MS1 -->|Internal DNS: ms2| SVC2
MS2 -->|Internal DNS: ms1| SVC1
- Diagram Note:
Microservices are deployed as scalable Deployments, each fronted by a ClusterIP Service exposing a stable DNS name for internal communication.
The Decision Matrix #
| Option | Est. Complexity | Est. Monthly Cost | Pros | Cons |
|---|---|---|---|---|
| A | Low | Low | Scalable, kubernetes-native, stable DNS | None significant for internal traffic |
| B | Medium | Medium-High | Supports HTTP routing & SSL termination | Unnecessary ingress complexity, external exposure risk |
| C | Medium | Medium | Simple but not scalable | No rolling updates, ephemeral pods |
| D | High | High | External routing possible | Operationally complex and insecure for internal usage |
Real-World Practitioner Insight #
Exam Rule #
When the scenario requires internal microservices communication with scalable replicas on GKE, always pick Deployments with ClusterIP Services. This aligns with Kubernetes’ designed service abstraction.
Real World #
A live production GKE cluster almost never exposes microservices internally via Ingress; instead, Services provide stable naming and load balancing, keeping latency low and operational complexity manageable. This approach minimizes toil and maximizes reliability—key pillars of Site Reliability Engineering (SRE).