Exam Professional Cloud Architect topic 1 question 93 discussion

Why not using Ingress? (A)

Name is service resource, it's B: https://cloud.google.com/kubernetes-engine/docs/concepts/service?hl=es-419

Answer A

A and B both create under the hood a Service of type LoadBalancer with external IP address. However, when it comes to http(s) traffic an ingress is the way to go because of ssl termination and for the routing options.

C & D is clearly incorrect. B is incorrect because of this: "service of type LoadBalancer to load-balance the HTTPS traffic." GKE Service Load Balancer is L4 Network or Internal Load Balancer, does not support HTTPS traffic. Thus only A is correct.

The clue is HTTPS traffic. You need L7 stack. It can be achieved only through ingress controller.

B A. Ingress resource: While Ingress can be used for external load balancing, it often requires additional configuration for HTTPS termination (offloading SSL from your application containers). Additionally, LoadBalancer services typically offer a simpler setup for basic external load balancing without HTTPS termination concerns. C & D. Compute Engine Instance Group Autoscaling: GKE manages its own nodes separate from Compute Engine instances. Autoscaling on a Compute Engine instance group wouldn't manage the Kubernetes pods or nodes effectively in this scenario.

service loadBalancer: https://cloud.google.com/kubernetes-engine/docs/concepts/service-load-balancer This page provides a general overview of how Google Kubernetes Engine (GKE) creates and manages Google Cloud load balancers when you apply a Kubernetes LoadBalancer Services manifest. It describes the different types of load balancers and how settings like the externalTrafficPolicy and GKE subsetting for L4 internal load balancers determine how the load balancers are configured. -> l4 tcp/udp not https Ingress: https://cloud.google.com/kubernetes-engine/docs/concepts/ingress This page provides a general overview of what Ingress for external Application Load Balancers is and how it works. Google Kubernetes Engine (GKE) provides a built-in and managed Ingress controller called GKE Ingress. This controller implements Ingress resources as Google Cloud load balancers for HTTP(S) workloads in GKE. -S http(s)

B is correct

I'm assuming B is the suggested answer because a the question doesn't state that the application should be available externally. Services allow exposing resources internally and to load balancers. However, it should be A, as the assumption would be a an external web application. https://cloud.google.com/kubernetes-engine/docs/concepts/service

Most if the labs in Google boost skills discuss how to expose the deployment using a load balancer.

https://cloud.google.com/kubernetes-engine/docs/concepts/ingress "This page provides a general overview of what Ingress for external Application Load Balancers is and how it works. Google Kubernetes Engine (GKE) provides a built-in and managed Ingress controller called GKE Ingress. This controller implements Ingress resources as Google Cloud load balancers for HTTP(S) workloads in GKE."

https://cloud.google.com/kubernetes-engine/docs/concepts/ingress As there is no mention about the type of the traffic, Internal or external - Going with A - Ingress.

Option-C and D are straightforwardly wrong Between A and B : B is the correct answer, because it makes use of loadbalancing the ingress in K8S native style. That is the reason why cluster scaling is also done. This is how it should External Load Balancing Ingress --> K8S Service of type LoadBalancer --> pods that can autoscale Directly allowing external loadbalcing ingress to autoscaled Pod, doesn't makes sense to use GKE

Ingress is Https while Service is TCP/UDP. https://cloud.google.com/load-balancing/docs/choosing-load-balancer https://cloud.google.com/kubernetes-engine/docs/concepts/service-networking

B is correct

A Is the best choice