Question-31: In today's world, Kubernetes is the system of choice when it comes to deploying and managing microservices. It is only logical for us to want these microservices to communicate with one another, and Kubernetes offers a variety of methods to accomplish this goal. You are constructing an application with a variety of microservices that should stay inside the cluster even after the application is finished. You would want to be able to setup each microservice with a predetermined number of replicas, however this is not currently possible. You also want to be able to address a given microservice from any other microservice in a consistent manner, and this should be possible independent of the number of replicas that the microservice grows to. You will need to use the Google Kubernetes Engine to put this solution into action. What action should you take?
A. Deploy every every microservice as its own separate deployment. Make the Deployment accessible to other microservices in the cluster by utilising a Service, and then use the Service's DNS name to refer to the Deployment from those other microservices.
B. Deploy every every microservice as its own separate deployment. Expose the Deployment that is running in the cluster by using an Ingress, and then use the IP address that the Ingress provides to address the Deployment from other microservices that are running in the cluster.
C. Deploy a Pod for each individual microservice. Expose the Pod in the cluster by utilising a Service, and make use of the Service DNS name when addressing the microservice from other microservices that are included inside the cluster.
D. Deploy a Pod for each individual microservice. Expose the Pod that is part of the cluster by using an Ingress, and then use the IP address name that is associated with the Ingress to address the Pod from other microservices that are part of the cluster.
Correct Answer
Get All 340 Questions and Answer for Google Professional Cloud Architect
: 1 Explanation: Because Ingress already includes an HTTP(S) LB that has an external IP address, it is not necessary to use it for communications within the cluster itself. Deploy each microservice individually as its own separate deployment. Make the Deployment accessible to other microservices in the cluster by utilising a Service, and then use the Service's DNS name to refer to the Deployment from those other microservices. Because ngress already includes an HTTP(S) LB that has an external IP, a separate one for internal communications within the cluster is not required. DNS name is used as an alias service name for External name, which is user for internal requests. Microservice is used to create replicas according to this request and is deployed as part of the process. 1. The statement You want to be able to configure each microservice with a specific number of replicas. suggests that you should use either Deployment or StatefulSet, depending on whether the service type is stateless or stateful. However, the option only has Deployment, so options C and D are not viable choices. 2. According to the description, You also want to be able to address a specific microservice from any other microservice in a uniform way, and this should be possible regardless of the number of replicas the microservice scales to. The latter portion is the most important aspect, which indicates that the traffic that is sent directly to each service is governed by a set of specific rules; in K8S, this refers to URL, which is Ingress with an external HTTP LB.