A development team at your company has created a dockerized HTTPS web application. You need to deploy the application on Google Kubernetes Engine (GKE) and make sure that the application scales automatically.
How should you deploy to GKE?
A development team at your company has created a dockerized HTTPS web application. You need to deploy the application on Google Kubernetes Engine (GKE) and make sure that the application scales automatically.
How should you deploy to GKE?
To deploy a dockerized HTTPS web application on Google Kubernetes Engine (GKE) and ensure it scales automatically, you should use the Horizontal Pod Autoscaler and enable cluster autoscaling. Additionally, you should use an Ingress resource to load-balance the HTTPS traffic. The Horizontal Pod Autoscaler will manage the scaling of your pods based on resource usage, and cluster autoscaling will manage the scaling of your nodes. Using an Ingress resource is ideal for HTTPS traffic as it provides advanced routing capabilities and can handle SSL termination, making it a suitable choice for managing HTTPS traffic in a Kubernetes environment.
Why not using Ingress? (A)
"Ingress is a Kubernetes resource that encapsulates a collection of rules and configuration for routing external HTTP(S) traffic to internal services. On GKE, Ingress is implemented using Cloud Load Balancing. When you create an Ingress in your cluster, GKE creates an HTTP(S) load balancer and configures it to route traffic to your application." Are you exposing multiple services through single IP address? Hence, do you need routing your traffic? Correct answer is B.
My bad, as stated by other, Service doesn't support L7 load balancing. Hence, need to setup ingress resource. Correct answer is A.
B is ok. https://cloud.google.com/kubernetes-engine/docs/tutorials/hello-app
service resource does a NLB using IP address, however, Ingress does HTTP(S) Load balancer. A should be an answer.
I think A is OK:
It is A, K8s best way to LB is Ingress.
Name is service resource, it's B: https://cloud.google.com/kubernetes-engine/docs/concepts/service?hl=es-419
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
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
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."
Most if the labs in Google boost skills discuss how to expose the deployment using a load balancer.
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
The clue is HTTPS traffic. You need L7 stack. It can be achieved only through ingress controller.
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.
Bowth options A and B can satisfy the requirements, they are both based on a load balancer. Option A is more adapted and more flexible as later on, you can set up routing rules to expose more then just one service using the same loadbalancer which can help reduce cost, you don't really need that flexibity for this case, but since it's gonna cost the same thing for now (const of a loadbalancer). Its better to go with the ingress option.
A Is the best choice
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
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.
B is correct
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.
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.