GKE: The Ingress Controllers

The story begins with the project I was working on. Now a days deployment on cloud is beneficial as it saves lots of time and money to setup new infrastructure on your On-Premises, as cloud is also evolving from Bare HVM machines to containers as light weight VM’s.

This blog is not for the comparison of two Ingress Controller class but the challenges we faced while integrating client’s new requirement to the existing setup, which was hosted on GKE workloads with GCE (default) Ingress class as load balancer.

With time we realised the limitations of GCE Ingress class as it was still evolving and our project was already live on production. We brain stormed on how we can change the GCE Ingress class to Nginx Ingress class. Another hurdle was that the static ip which was registered for Load Balancer was Global not Regional. So we cannot change the Controller class to Nginx Ingress.

Moving forward to give briefing about the two Ingress class controllers: Nginx Ingress & GCE Ingress.

Below are the features which we want to achieve in the project deployed on GKE (Google Kubernetes Engine) workloads.

1. White listing of ip’s as we don’t want to expose it to the world.
2. Session Affinity (Stickiness).
3. Redirection of http request to https.

As we know all the above three features are not straight forward to achieve in GCE Ingress Controller class.

To apply above features either we need to initiate Nginx Ingress Controller class or implement Nginx Ingress from scratch, which will act as Load Balancer instead of GCE Ingress.

Sample YAML file to show the nginx ingress config

apiVersion: extensions/v1beta1
 kind: Ingress
 metadata:
   name: nginx-ingress
   namespace: default
   annotations:
     kubernetes.io/ingress.class: nginx
     nginx.ingress.kubernetes.io/rewrite-target: /
     # White Listing of IP's
     nginx.ingress.kubernetes.io/whitelist-source-range: "xxx.xxx.xxx.xxx"
     # Redirect HTTP request to HTTPS
     nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
     # Applying SSL certificate for HTTPS 
     nginx.ingress.kubernetes.io/auth-tls-secret: secretName
     # Session Affinity or Stickiness
     nginx.ingress.kubernetes.io/affinity: "cookie"
     nginx.ingress.kubernetes.io/session-cookie-max-age: max-age-in-sec
     nginx.ingress.kubernetes.io/session-cookie-expires: cookie-expire-in-sec
 spec:
   rules:
   - host: example.com
     http:   
       paths: 
       - path: /*
         backend:
           serviceName: frontend-service
           servicePort: 80

Now, let’s assume, you had applied GCE Ingress but still you want to achieve these features for Google Kubernetes Engine workloads.

For white listing of IP’s

In GCE we can use Cloud Armor. It is a web application firewall service provided by Google cloud.

For Session Affinity

You can use a BackendConfig to configure generated cookie affinity.

To do this exercise, you need a VPC-native cluster. Generated cookie affinity is useful only for Services that are backed by network endpoint groups, and network endpoint groups require a VPC-native cluster.

To set generated cookie affinity, use affinityType to “GENERATED_COOKIE” in your BackendConfig manifest. You can also use affinityCookieTtlSec to set the time period for the cookie.

sessionAffinity:
  affinityType: "GENERATED_COOKIE"
  affinityCookieTtlSec: 50

In your Service manifest, include the cloud.google.com/neg: '{"ingress": true}' annotation:

kind: Service
metadata:
  name: my-bsc-service
  labels:
    purpose: bsc-config-demo
  annotations:
    cloud.google.com/neg: '{"ingress": true}'
    beta.cloud.google.com/backend-config: '{"ports": {"80":"my-bsc-backendconfig"}}'

RedirectioN http to https

Redirection from http to https feature is an upcoming feature in ingress.

As we know GCE Ingress is still in evolving phase and Nginx Ingress provides above features and more. I would like to recommend you should go ahead with Nginx Ingress till GCE Ingress evolves.

Thank you.