Ingress
1. Ingress
One of the most powerful tools to direct traffic into your clusters is the Ingress resource. The Ingress resource operates one layer higher than Services. You can think of it as a Service for Services. That being said, Ingress is not a Service, or even a type of Service. It’s a collection of rules that direct external inbound connections to a set of Services within the cluster. With GKE, Kubernetes Ingress resources are implemented using Cloud Load Balancing. When an Ingress resource is created in the cluster, GKE creates an Application Load Balancer and configures it to route traffic to the application. While Ingress can deliver traffic to NodePort or LoadBalancer services, it’s most efficiently used with ClusterIP services via container-native load balancing. By utilizing network endpoint groups (NEGs), the load balancer routes traffic directly to the Pod IPs, bypassing the extra network hops associated with traditional Service types. Within a simple Ingress resource, the Ingress controller creates an Application Load Balancer using the Ingress object specification. In the object, a backend Service can be selected by specifying the Service name “demo” and the Service port “80.” This configuration tells the Application Load Balancer to route all client traffic to the Service named “demo” on port 80. Let’s shift to a different example where there is an Ingress manifest and inside the specifications are rules. Currently, GKE only supports HTTP rules, and each rule takes the same name as the host. The host can be further filtered based on the path, and a path will have a Service backend that defines the Service’s name and port. Ingress supports multiple host names for the same IP address, for example demo.example.com and lab.user.com. The traffic will be redirected from the Application Load Balancer, based on the host names, to their respective backend Services. For example, the load balancer will route traffic for demo.example.com to the Service named demo1 on port 80. This example considers rules based on the URL path. Under Spec, a path defined as /demopath will be directed to the backend Service named demo1. Similarly, /labpath will be directed to its backend Service demo2. So what happens to the traffic that doesn’t match any of these host-based or path-based rules? The traffic with no matching rules is simply sent to the default backend, which is a service that acts as the destination for traffic that doesn't match any of the specified paths in an Ingress manifest. A default backend can be specified by providing a backend field in your Ingress manifest. If a default backend isn’t specified, GKE will supply one that replies with error code 404. Ingress can be updated with a kubectl edit command. When the Ingress resource has been updated, the API server will tell the Ingress controller to reconfigure the Application Load Balancer according to the changes that have been made. Ingress can also be updated by using the kubectl replace command, which replaces the Ingress object manifest file entirely. Ingress for an external Application Load Balancer natively supports many Google Cloud services. Using Identity-Aware Proxy provides granular access control at the application level. With this, authenticated users can have HTTPS access to the applications within a cluster without any VPN setup. Google Cloud Armor provides built-in protection against distributed denial of service (DDOS) and web attacks for clusters using an Application Load Balancer. Security rules can be set up to allow list or deny list IP addresses or ranges. Predefined rules can also be used to defend against cross-site scripting and SQL injection application-aware attacks. Security rules can be customized to mitigate multivector attacks and restrict access using geolocation. Cloud CDN allows an application’s content to be brought closer to its users. It does this by using more than 100 Edge points of presence. These settings can be configured using BackendConfig. BackendConfig is a custom resource used by the Ingress controller to define configuration for all of these Services. Ingress gains many security features from the underlying Google Cloud resources it relies on. For example, Ingress provides TLS termination support at the loadbalancer at the edge of the network. This allows the load balancer to create another connection to the destination. Although this second connection is unsecured by default, it can be secured. This allows SSL certificates to be managed in one place. Ingress can serve multiple SSL certificates. Ingress also supports the HTTP/2 standard in addition to HTTP/1.0 and HTTP/1.1. So, if a microservices-based application is being developed, it’s necessary to ensure that each microservice’s communication with all the others uses a high-performance, low-overhead remote procedure call system. gRPC is a common way to solve this, and it needs HTTP/2. So gRPC can be used along with HTTP/2 to create performant, low-latency, scalable microservices within the cluster. Finally, with multi-cluster and multi-region support, a single standard Ingress resource can be used to load balance traffic globally to multiple clusters across multiple regions. This also supports location-based load balancing, called geo-balancing across multiple regions, which improves the availability of the cluster.2. Let's practice!
Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.