You are developing an application using different microservices that should remain internal to the cluster. You want to be able to configure each microservice with a specific number of replicas. You also want to be able to address a specific microservice from any other microservice in a uniform way, regardless of the number of replicas the microservice scales to. You need to implement this solution on Google Kubernetes Engine. What should you do?

The correct approach is to deploy each microservice as a Deployment and expose it with a Service. A Deployment manages a set of identical Pods, ensuring the desired number of replicas are running and handling updates gracefully. A Service provides a stable DNS name and IP address for a set of Pods, load-balancing requests across them. This allows other microservices to communicate with a target microservice using its stable Service DNS name, regardless of how many Pods are backing it or if those Pods change. Incorrect options: Using an Ingress is for exposing services externally to the cluster, not for internal cluster communication. Deploying microservices as individual Pods is not scalable or resilient, as Pods are ephemeral and do not inherently manage replicas or provide stable network identities.