{"id":822,"date":"2021-06-24T03:59:38","date_gmt":"2021-06-24T03:59:38","guid":{"rendered":"https:\/\/blog.ngocha.biz\/?p=822"},"modified":"2021-06-24T03:59:38","modified_gmt":"2021-06-24T03:59:38","slug":"setup-ingress-gke-ingress-controller","status":"publish","type":"post","link":"https:\/\/blog.ngocha.biz\/?p=822","title":{"rendered":"How to Setup Ingress on GKE using GKE Ingress Controller"},"content":{"rendered":"

This tutorial will guide you to setup Ingress on GKE using a GKE ingress controller that covers:<\/p>\n

    \n
  1. The need for ingress<\/li>\n
  2. The logic behind the GKE ingress controller<\/li>\n
  3. Creating your first ingress with a demo application.<\/li>\n
  4. Different ways of ingress domain\/host and path mappings<\/li>\n<\/ol>\n

    Let\u2019s dive right in.<\/p>\n

    Why GKE Ingress?<\/h2>\n

    Exposing each service as a Loadbalancer is not an ideal solution to deal with Kubernetes ingress traffic.<\/p>\n

    You need a Kubernetes ingress controller to manage all the ingress traffic for the cluster. With direct DNS or a wildcard DNS mapping, you can route traffic to backend kubernetes services.<\/p>\n

    Also you can have multiple DNS attached to a single ingress Loadbalancer and route to different service backends using the Ingress controller.<\/p>\n

    Also, you can have path-based routing rules in the ingress resources to different kubernetes services.<\/p>\n

    The good thing is, GKE comes with an inbuilt GKE ingress controller<\/strong>. So you don’t have to do any extra configurations to set up an ingress controller.<\/p>\n

    You can also set up other ingress controllers like the Nginx ingress controller<\/a>. It depends upon the project requirements and the features supported by each controller implementation.<\/p>\n

    For this tutorial, we will just look at how to create an ingress object with the GKE ingress controllers.<\/p>\n

    How Does GKE Ingress Work?<\/h2>\n

    As you probably know, for Kubernetes ingress to work, you need an Ingress controller.<\/p>\n

    If you are not aware of ingress concepts, please read the ingress tutorial <\/a>to understand how it works.<\/p>\n

    GKE has its own ingress controller called GKE ingress controller.<\/p>\n

    When you create an ingress object, GKE launches a Load Balancer (Public or Private) with all the routing rules mentioned in the ingress resource.<\/p>\n

    Since the Loadbalancer is outside the cluster, the backend service defined in the ingress resources should be of type LoadBalancer.<\/p>\n

    Whereas in normal ingress controller implementation like Nginx ingress controller, the proxy layer resides inside the cluster and it can talk to services without Nodeport.<\/p>\n

    \"GKE
    Click to view in HD<\/span><\/figcaption><\/figure>\n

    In GKE, there is a concept of Network Endpoint Groups<\/a>. Even though the backend service is of type NoePort, GKE doesn’t randomly send traffic to any node in the cluster to reach the pods. With NEGs, all the traffic will be sent directly to the nodes where the pod resides.<\/p>\n

    Without NEGs, the traffic from the Loadbalancer can read any node in the cluster and can result in extra network hops to reach the node where the pod resides.<\/p>\n

    Setup Ingress on GKE using a GKE Ingress Controller<\/h2>\n

    Now, let’s look at a practical example of setting up ingress using the GKE ingress controller.<\/p>\n

    To understand the GKE ingress workflow and configurations better, we will do the following.<\/p>\n

      \n
    1. Deploy an Nginx deployment with a NodePort<\/code> service (Nodeport is a requirement)<\/li>\n
    2. Create an ingress object with static IP that has a rule to route traffic to the Nginx service endpoint.<\/li>\n
    3. Validate the ingress deployment by accessing Nginx over the Loadbalancer IP.<\/li>\n<\/ol>\n

      Let’s get started with the setup.<\/p>\n

      Step 1: Deploy an Nginx deployment With Service Type NodePort<\/h3>\n

      Save the following manifest as nginx.yaml<\/code>. We are adding a custom index.html using a configmap<\/code> which replaced the default Nginx index.html<\/code> file.<\/p>\n

      \n
      Note:<\/strong><\/b> For GKE ingress to work, the service type has to be NodePort. It is a requirement.<\/div>\n<\/div>\n
      ---\napiVersion: apps\/v1\nkind: Deployment\nmetadata:\n  name: nginx-deployment\n  namespace: default\nspec:\n  selector:\n    matchLabels:\n      app: nginx\n  replicas: 2 \n  template:\n    metadata:\n      labels:\n        app: nginx\n    spec:\n      containers:\n      - name: nginx\n        image: nginx:latest\n        ports:\n        - containerPort: 80\n        readinessProbe:\n          httpGet:\n            scheme: HTTP\n            path: \/index.html\n            port: 80\n          initialDelaySeconds: 10\n          periodSeconds: 5\n        volumeMounts:\n            - name: nginx-public\n              mountPath: \/usr\/share\/nginx\/html\/\n      volumes:\n      - name: nginx-public\n        configMap:\n          name: nginx-index-html-configmap\n---\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: nginx-index-html-configmap\n  namespace: default\ndata:\n  index.html: |\n    <html>\n    <h1>Welcome To Webapp 01<\/h1>\n    <\/br>\n    <h1>Hi! You are Trying to Access Webapp Through GKE Ingress <\/h1>\n    <\/html\n---\napiVersion: v1\nkind: Service\nmetadata:\n  name: nginx-service\n  namespace: default\nspec:\n  selector:\n    app: nginx\n  type: NodePort\n  ports:\n    - port: 80\n      targetPort: 80\n<\/code><\/pre>\n
      Create the deployment.<\/p>\n
      kubectl apply -f nginx.yaml<\/code><\/pre>\n
      It gets deployed in the default namespace.<\/p>\n
      Validate the deployment. You should see two Replicas of Nginx.<\/p>\n
      kubectl get deployments<\/code><\/pre>\n
      Validate the Nginx service endpoint. You should be abe able to see the randomly assigned NodePort.<\/p>\n
      kubectl get svc nginx-service<\/code><\/pre>\n
      Step 2: Create Ingress for the Nginx Deployment<\/h3>\n
      Now that we have a working deployment, we will create an ingress resource.<\/p>\n
      Let’s start with a basic setup and then I will address other options in the ingress.<\/p>\n
      What we are going to do is create an ingress that routes traffic to our Nginx service endpoint.<\/p>\n
      First, we need to create a Static Public IP address with the name ingress-webapps<\/code> that we can use with the ingress. With static IP you can point the required domain name<\/strong> to the Ingress IP.<\/p>\n
      gcloud compute addresses create ingress-webapps --global<\/code><\/pre>\n
      Save the following manifest as ingress.yaml<\/code><\/p>\n
      apiVersion: networking.k8s.io\/v1\nkind: Ingress\nmetadata:\n  name: nginx-ingress\n  annotations:\n    kubernetes.io\/ingress.class: \"gce\"\n    kubernetes.io\/ingress.global-static-ip-name: \"ingress-webapps\"\nspec:\n  rules:\n  - http:\n      paths:\n      - path: \"\/*\"\n        pathType: ImplementationSpecific\n        backend:\n          service:\n            name: nginx-service\n            port:\n              number: 80<\/code><\/pre>\n
      As you can see we have two annotations in the manifest file.<\/p>\n
        \n
      1. kubernetes.io\/ingress.class<\/code> annotation with value gce<\/code> tells GKE to create a public Load Balancer. If you don’t specify it, it defaults to public only.<\/li>\n
      2. kubernetes.io\/ingress.global-static-ip-name<\/code> annotation with value ingress-webapps<\/code> tells GKE to attach the static IP we created to the ingress Load Balancer.<\/li>\n
      3. We are creating a http<\/code> rule to route all the traffic, ie \/*<\/code> to the nginx-service<\/code> endpoint.<\/li>\n<\/ol>\n
        Let’s create the ingress<\/p>\n
        kubectl apply -f ingress.yaml<\/code><\/pre>\n
        When you create ingress, it creates a Loadbalancer with the routing rules mentioned in the ingress YAML.<\/p>\n
        Step 3: Validate Ingress<\/h3>\n
        Let’s list the ingress and get the Load balancer IP.<\/p>\n
         kubectl get ingress<\/code><\/pre>\n
        \"GKE<\/figure>\n
        After few minutes you should be able to access the Nginx service running inside the cluster using the<\/p>\n
        Alternatively, you can check the Google Cloud load balancer dashboard to get more details about the Ingress Loadbalancer.<\/p>\n
        \"GKE
        Click to view in HD<\/span><\/figcaption><\/figure>\n
        Hosting Multiple Domains on Same GKE Ingress Loadbalancer<\/h2>\n
        If you have a use case to host multiple applications with DNS on the same Load balancer, you can do it by mapping the same Loadbalancer IP in both the DNS A records.<\/p>\n
        Now, in the ingress specification, you need to add both the domain names with the respective backend service endpoints as shown below.<\/p>\n
        apiVersion: networking.k8s.io\/v1\nkind: Ingress\nmetadata:\n  name: nginx-ingress\n  annotations:\n    kubernetes.io\/ingress.class: \"gce\"\n    kubernetes.io\/ingress.global-static-ip-name: \"ingress-webapps\"\nspec:\n  rules:\n  - host: \"www.web01.com\"\n    http:\n      paths:\n      - pathType: ImplementationSpecific\n        path: \"\/\"\n        backend:\n          service:\n            name: web01-service\n            port:\n              number: 8080\n  - host: \"www.web02.com\"\n    http:\n      paths:\n      - pathType: ImplementationSpecific\n        path: \"\/\"\n        backend:\n          service:\n            name: web02-service\n            port:\n              number: 8080\n<\/code><\/pre>\n
        Path-Based Routing Using GKE Ingress<\/h2>\n
        Now, let’s say you have many backend services that need to be routed based on a specific path. In that case, your ingress would like the following.<\/p>\n
        apiVersion: networking.k8s.io\/v1\nkind: Ingress\nmetadata:\n  name: nginx-ingress\n  annotations:\n    kubernetes.io\/ingress.class: \"gce\"\n    kubernetes.io\/ingress.global-static-ip-name: \"ingress-webapps\"\nspec:\n  rules:\n  - http:\n      paths:\n      - path: \"\/*\"\n        pathType: ImplementationSpecific\n        backend:\n          service:\n            name: nginx-service\n            port:\n              number: 80\n      - path: \"\/api\"\n        pathType: ImplementationSpecific\n        backend:\n          service:\n            name: api-service\n            port:\n              number: 80\n       - path: \"\/users\"\n        pathType: ImplementationSpecific\n        backend:\n          service:\n            name: user-service\n            port:\n              number: 80<\/code><\/pre>\n
        Multiple Ingress Resources with Single GKE Ingress Controller<\/h2>\n
        When we setup ingress controllers like Nginx, you can have multiple ingress resources mapped to a single Ingress controller.<\/p>\n
        However, when it comes to GKE Loadbalancer based ingress controllers, you cannot map multiple ingress objects to a single GKE ingress controller.<\/p>\n
        For each ingress object or a resource, a separate Google Loadbalancer will be provisioned.<\/p>\n
        Here is what the google cloud document <\/a>says about the multiple ingress resource mapping limitation.<\/p>\n
        \n
        Combining multiple Ingress resources into a single Google Cloud load balancer is not supported.<\/div>\n<\/div>\n
        The one way to circumvent this problem is to have all the ingress rules in a single ingress resource.<\/p>\n
        There is a limitation of a maximum of 50 paths per backend mapping. See out all the Quota limitations<\/a>.<\/p>\n
        Customizing GKE Ingress Configurations<\/h2>\n
        The example we have seen uses all the default settings of the GKE ingress controller.<\/p>\n
        But when it comes to production project requirements, you may have to tweak the configurations based on your application.<\/p>\n
        Few use cases are,<\/p>\n
          \n
        1. Custom Headers:<\/strong> You might have to add custom HTTP headers to the GKE ingress controller.<\/li>\n
        2. Session Affinity: <\/strong>If you want requests from a given user to be served by the same backend.<\/li>\n<\/ol>\n
          Refer to the GKE ingress controller features<\/a> document to understand all the supported configurations.<\/p>\n
          To use the extra GKE ingress features, you need to deploy a Backend config with the required features. Backendconfig<\/code> is a custom resource type available as part of GKE ingress controllers.<\/p>\n
          For, example, to enable session affinity based on a cookie, you have to deploy the following backend config.<\/p>\n
          apiVersion: cloud.google.com\/v1\nkind: BackendConfig\nmetadata:\n  name: session-cookie-config\nspec:\n  sessionAffinity:\n    affinityType: \"GENERATED_COOKIE\"\n    affinityCookieTtlSec: 50<\/code><\/pre>\n
          And for setting custom headers in GKE ingress, you have to use the following backend config.<\/p>\n
          apiVersion: cloud.google.com\/v1\nkind: BackendConfig\nmetadata:\n  name: my-backendconfig\nspec:\n  customRequestHeaders:\n    headers:\n    - \"X-Client-Region:{client_region}\"\n    - \"X-Client-City:{client_city}\"\n    - \"X-Client-CityLatLong:{client_city_lat_long}\"<\/code><\/pre>\n
          Conclusion<\/h2>\n
          In this tutorial, we have learned to set up Ingress on GKE using a GKE ingress controller and Google cloud load balancer.<\/p>\n
          Choosing a GKE ingress controller vs. another ingress controller depends on the project requirements and features required in the ingress layer.<\/p>\n
          You might need more information or you may some issues while setting it up.<\/p>\n
          Either way, drop a comment below.<\/p>\n
          \n
          Ngu\u1ed3n:<\/strong> How to Setup Ingress on GKE using GKE Ingress Controller \u2014 DevOpsCube<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
          Source: https:\/\/devopscube.com\/setup-ingress-gke-ingress-controller\/<\/p>\n","protected":false},"author":1,"featured_media":823,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-822","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-devops"],"_links":{"self":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts\/822","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=822"}],"version-history":[{"count":0,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts\/822\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/media\/823"}],"wp:attachment":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=822"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=822"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=822"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}