{"id":380,"date":"2025-02-04T12:52:42","date_gmt":"2025-02-04T12:52:42","guid":{"rendered":"https:\/\/blog.ngocha.biz\/?p=380"},"modified":"2025-02-04T12:52:42","modified_gmt":"2025-02-04T12:52:42","slug":"migrate-kubernetes-ingress-to-gateway-api","status":"publish","type":"post","link":"https:\/\/blog.ngocha.biz\/?p=380","title":{"rendered":"How To Migrate Kubernetes Ingress To Gateway API?"},"content":{"rendered":"

In this blog, we will learn to migrate Kubernetes Ingress to gateway API and follow the easy migrating steps.<\/p>\n

Most of the workflows still use the standard Ingress traffic routing mechanism for traffic routing, but it has limitations in the routing rules.<\/p>\n

The Gateway API offers a lot of traffic routing features to simplify the advanced routing rules.<\/p>\n

Kubernetes Ingress<\/h2>\n

Before we jump into the migration, let me give a brief introduction about the Ingress.<\/p>\n

Ingress in the Kubernetes cluster helps to route the traffic to the applications based on certain rules such as domain name and path.<\/p>\n

But, in Ingress, it is difficult to configure the header-based routing or method-based routing. Also, there is no separation for the TCP\/UDP or HTTP\/HTTPS-based routing.<\/p>\n

Here, we can use the Gateway API, which has all the features for the Ingress resource as well as more advanced functions.<\/p>\n

Kubernetes Gateway API<\/h2>\n

Kubernetes Gateway API is the replacement for the Ingress resource because of its advanced features for traffic routing when compared to Ingress.<\/p>\n

To learn the complete setup of the Kubernetes Gateway API in the Kubernetes cluster, please refer to this blog<\/a>.<\/p>\n

Let’s compare the core components of the Kubernetes Gateway API with the Ingress.<\/p>\n

Gateway Class <\/strong>– Defines the controller information like Ingress Class<\/strong><\/p>\n

Gateway<\/strong> – The entry point for the traffic, like Ingress<\/strong>.<\/p>\n

HTTPRoute<\/strong> – Defines the HTTP routing rules, like Ingress rules<\/strong>.<\/p>\n

Prerequisites<\/h4>\n
    \n
  1. Helm<\/a> v3.17.0 or a higher version should be available on the local machine.<\/li>\n
  2. Kubernetes Cluster<\/a> v1.30 or higher<\/li>\n
  3. Kubectl v1.30 or higher should be available on the local machine, and the config file should be configured to access the cluster.<\/li>\n<\/ol>\n

    Migrating from Kubernetes Ingress to Gateway API<\/h2>\n

    In this section, will migrate an existing Ingress routing configuration to the Gateway API.<\/p>\n

    Step 1: Setup the Nginx Ingress Controller in the Kubernetes Cluster<\/h3>\n

    I am setting up the Nginx Ingress Controller to show the demo from the beginning.<\/p>\n

    You might be thinking why we need a controller to route the traffic, but actually the Controller is an Nginx Pod which act as a reverse proxy, when we add rules in the Ingress object, the routing informations will be configured in the Nginx Pod.<\/p>\n

    When the traffic reaches the controller, it will route the traffic to the intended endpoints based on the rules and conditions.<\/p>\n

    To pull the Helm chart<\/a> of the Nginx Ingress Controller and to untar, use the following command.<\/p>\n

    helm pull oci:\/\/ghcr.io\/nginx\/charts\/nginx-ingress --untar<\/code><\/pre>\n
    This will give a local copy of the Helm chart, and open the following directory.<\/p>\n
    cd nginx-ingress<\/code><\/pre>\n
    We can see a values.yaml<\/code> file inside the directory, which has all the modifiable parameters.<\/p>\n
    We can change the values as per our requirements or store the entire chart on our repositories to reuse.<\/p>\n
    We are not modifying the default file, instead creating a new file demo-values.yaml<\/code> file.<\/p>\n
    cat <<EOF> demo-values.yaml\ncontroller:\n  service:\n    create: true\n    type: NodePort\n    httpPort:\n      enable: true\n      port: 80\n      nodePort: 30080  \n      targetPort: 80\nEOF<\/code><\/pre>\n
    By default, the Service Type of the Nginx Ingress Controller is Load Balancer, but if you are testing the setup on your local cluster, the setup might not work properly.<\/p>\n
    Note<\/strong>: If you are deploying the Nginx Ingress Controller on any production or in a cloud environment, keep the Service type as default (Load Balancer), which is an actual best practice.<\/p><\/blockquote>\n
    Now, we can deploy the Nginx Ingress Controller with the new values file.<\/p>\n
    helm install nginx-ingress -f demo-values.yaml --create-namespace --namespace=ingress-nginx .<\/code><\/pre>\n
    nginx-ingress<\/code> is the release name, and you can give any name.<\/p>\n
    demo-values.yaml<\/code> is the configuration file to override the default installation.<\/p>\n
    ingress-nginx<\/code> is the Namespace name where the Nginx Ingress Controller components need to be deployed.<\/p>\n
    Once the installation is properly done, you can see the following output.<\/p>\n
    \"the<\/figure>\n
    Let’s check the Nginx Ingress Controller components status.<\/p>\n
    If you want to know more about the Nginx Ingress Controller and configuration, please refer to this blog<\/a>.<\/p>\n
    kubectl -n ingress-nginx get all<\/code><\/pre>\n
    \"listing<\/figure>\n
    The Nginx Ingress Controller Pod is in a running state, which indicates all the Controller components are running without any issues.<\/p>\n
    Note down the Node Port number (30080<\/code>) for the access-related operations.<\/p>\n
    Currently, we haven’t installed any application, so once that is done, we can use the public IP of the cluster nodes with the Node Port number to access the application.<\/p>\n
    My cluster nodes are in the AWS cloud, so I can get the IP information over the GUI or CLI.<\/p>\n
    \"listing<\/figure>\n
    We can directly use the Public IP of any one of the Nodes with the Node Port number as a URL (34.209.152.25:30080<\/code>) to access the application, but that won’t be quite convenient.<\/p>\n
    To make the access more convenient, we use the Local DNS Resolution.<\/p>\n
    Step 2: Setup Local DNS Resolution<\/h3>\n
    For the local DNS resolution, we need to map the Nodes public IPs along with a host name in the \/etc\/hosts<\/code> directory of the local system.<\/p>\n
    We already know the public IPs of the cluster nodes so open the \/etc\/hosts<\/code> directory with sudo privileges.<\/p>\n
    sudo vim \/etc\/hosts<\/code><\/pre>\n
    \"Describing<\/figure>\n
    This is how we map the IP address with the hostname (dev.techiescamp.com<\/code>), you can provide any host name you want.<\/p>\n
    The DNS resolution only happens on the local machine where you configured it.<\/p>\n
    Note: To access the application over the internet using the domain name, you need to configure it with the DNS servers such as Route53, GoDaddy, etc.<\/p><\/blockquote>\n
    Step 3: Deploy an Application for the Demo<\/h3>\n
    We have an container image in the Docker hub, so we are using it for testing, you can also you it if you want.<\/p>\n
    Create a Namespace to deploy the applications and services.<\/p>\n
    kubectl create ns colors<\/code><\/pre>\n
    Now, we can deploy the applications.<\/p>\n
    cat <<EOF > colors-deployments.yaml\napiVersion: apps\/v1\nkind: Deployment\nmetadata:\n  name: orange-app\n  namespace: colors\n  labels:\n    app: orange-app\nspec:\n  replicas: 3\n  selector:\n    matchLabels:\n      app: orange-app\n  template:\n    metadata:\n      labels:\n        app: orange-app\n    spec:\n      containers:\n      - name: color-app\n        image: techiescamp\/go-color-app-demo:latest\n        ports:\n        - containerPort: 8080\n        env:\n        - name: POD_NAME\n          valueFrom:\n            fieldRef:\n              fieldPath: metadata.name\n        - name: POD_IP\n          valueFrom:\n            fieldRef:\n              fieldPath: status.podIP\n\n---\napiVersion: apps\/v1\nkind: Deployment\nmetadata:\n  name: green-app\n  namespace: colors\n  labels:\n    app: green-app\nspec:\n  replicas: 3\n  selector:\n    matchLabels:\n      app: green-app\n  template:\n    metadata:\n      labels:\n        app: green-app\n    spec:\n      containers:\n      - name: color-app\n        image: techiescamp\/go-color-app-demo:latest\n        ports:\n        - containerPort: 8080\n        env:\n        - name: POD_NAME\n          valueFrom:\n            fieldRef:\n              fieldPath: metadata.name\n        - name: POD_IP\n          valueFrom:\n            fieldRef:\n              fieldPath: status.podIP\nEOF<\/code><\/pre>\n
    kubectl apply -f colors-deployments.yaml<\/code><\/pre>\n
    Here, I have deployed two deployments, which help to demonstrate the path based routing.<\/p>\n
    We need services for these two Deployments to get the endpoints.<\/p>\n
    cat <<EOF > colors-svc.yaml\napiVersion: v1\nkind: Service\nmetadata:\n  name: orange-app-service\n  namespace: colors\n  labels:\n    app: orange-app\nspec:\n  selector:\n    app: orange-app\n  ports:\n  - protocol: TCP\n    port: 80\n    targetPort: 8080\n  type: ClusterIP\n---\napiVersion: v1\nkind: Service\nmetadata:\n  name: green-app-service\n  namespace: colors\n  labels:\n    app: green-app\nspec:\n  selector:\n    app: green-app\n  ports:\n  - protocol: TCP\n    port: 80\n    targetPort: 8080\n  type: ClusterIP\nEOF<\/code><\/pre>\n
    kubectl apply -f colors-svc.yaml<\/code><\/pre>\n
    Once all the deployments are completed, we can check the status.<\/p>\n
    kubectl -n colors get po,svc -o wide<\/code><\/pre>\n
    \"listing<\/figure>\n
    The resources are ready for the testing, let’s explore the Ingress resources.<\/p>\n
    Step 4: Describe Ingress Class<\/h3>\n
    The Ingress Class is an object which has the information about the Ingress Controller.<\/p>\n
    The default Ingress Class will automatically be created when we deploy an Ingress Controller.<\/p>\n
    The Ingress Class is a cluster scoped resource.<\/p>\n
    Let’s describe the Ingress Class.<\/p>\n
    kubectl get ingressclass<\/code><\/pre>\n
    \"listing<\/figure>\n
    Here, we can see that the controller is nginx.org\/ingress-controller<\/code>, which indicates that it is Nginx Ingress Controller.<\/p>\n
    Step 5: Create an Ingress to Define Routing Rules<\/h3>\n
    The Ingress is an object where we define the routing rules for traffic.<\/p>\n
    The controller keeps on watching the Ingress object creation and modifications.<\/p>\n
    The defined rules in the Ingress object will be configured in the controller so that once the traffic is reached in the controller, will route to the correct endpoint based on the rules.<\/p>\n
    We can create an Ingress object will the rules for path based as well as hostname based routing.<\/p>\n
    cat <<EOF > colors-ingress.yaml\napiVersion: networking.k8s.io\/v1\nkind: Ingress\nmetadata:\n  name: colors-ingress\n  namespace: colors\nspec:\n  ingressClassName: nginx\n  rules:\n  - host: dev.techiescamp.com\n    http:\n      paths:\n      - path: \/green\n        pathType: Prefix\n        backend:\n          service:\n            name: green-app-service\n            port:\n              number: 80\n      - path: \/orange\n        pathType: Prefix\n        backend:\n          service:\n            name: orange-app-service\n            port:\n              number: 80\nEOF<\/code><\/pre>\n
    Ingress objects are Namespace scoped so where the applications are lying, there you have to create the Ingress.<\/p>\n
    We have deployed the applications at colors<\/code> Namespace, so the Ingress object must be created in colors<\/code> Namespace.<\/p>\n
    Under the spec<\/code> section, need to mention the Ingress Class name, which is nginx<\/code>.<\/p>\n
    For the host name based traffic routing we have provided the hostname (dev.techiescamp.com<\/code>) that we have already configured with the local DNS resolution configuration.<\/p>\n
    Under the rules<\/code> sections, there are two rules, one for the first application (Green<\/code>) and the other for the second application (Orange<\/code>).<\/p>\n
    The Ingress to identify the service endpoints, we have provided the service names such as green-app-service<\/code> and orange-app-service<\/code>.<\/p>\n
    The demo application is created for the path based routing so that the paths are mentioned in the rules, such as \/green<\/code> for the first application and \/orange<\/code> for the second application.<\/p>\n
    So if want to access the applications, the URL should be <HOST_NAME>:<NODE_PORT_NUMBER>\/<PATH><\/code>.<\/p>\n
    kubectl apply -f colors-ingress.yaml<\/code><\/pre>\n
    After the Ingress object deployment, use the following command to list it.<\/p>\n
    kubectl -n colors get ingress<\/code><\/pre>\n
    \"listing<\/figure>\n
    Now, the configurations are ready, so need to access the applications.<\/p>\n
    For that, open any of the web browsers from the local machine and paste the URL dev.techiescamp.com:30080\/green<\/code>.<\/p>\n
    \"the<\/figure>\n
    We can see the output in the browser also if you notice the Pod name and IP, which is pointing to Pods of the first application deployment, so this ensures that the traffic is properly routed based on the rules that we provided in the Ingress object.<\/p>\n
    You can check the second application if you want with this URL dev.techiescamp.com:30080\/orange<\/code><\/p>\n
    We have understood how the traffic is routed through the Ingress controller, so now, it is time to migrate this configuration to the Kubernetes Gateway API.<\/p>\n
    Step 6: Install Kubernetes Gateway API in the Kubernetes Cluster<\/h3>\n
    First, we need to install the Gateway API Custom Resource Definitions in the Kubernetes cluster.<\/p>\n
    kubectl apply -f https:\/\/github.com\/kubernetes-sigs\/gateway-api\/releases\/download\/v1.2.1\/standard-install.yaml<\/code><\/pre>\n
    To check the CRDs, use the following command.<\/p>\n
    kubectl get crds | grep gateway<\/code><\/pre>\n
    \"listing<\/figure>\n
      \n
    1. Gateway Class<\/code> defines the Gateway API Controller<\/a> informations, same like the Ingress Class<\/code> in Ingress<\/li>\n
    2. Gateway<\/code> defines the entry point for the incoming traffic.<\/li>\n
    3. gRPC Route, HTTP Route<\/code> are the resources where we define the routing rules.<\/li>\n<\/ol>\n
      Step 7: Install Nginx Fabric Gateway API Controller.<\/h3>\n
      Similar to the Ingress, we need a controller for the Gateway API, and we can’t use the same controller of the Ingress because that doesn’t have the capabilities for the Gateway API routing configurations.<\/p>\n
      For the Ingress<\/strong>, we have used the Nginx Ingress Controller<\/strong>, and for the Gateway API<\/strong>, we use the Nginx Fabric Gateway API Controller<\/strong>.<\/p>\n
      To pull the Helm Chart<\/a> of the controller, use the following command.<\/p>\n
      helm pull oci:\/\/ghcr.io\/nginxinc\/charts\/nginx-gateway-fabric --untar<\/code><\/pre>\n
      For this also, we use the Node Port service for the controller.<\/p>\n
      Navigate to the Nginx-gateway-fabric<\/code> directory.<\/p>\n
      cd nginx-gateway-fabric <\/code><\/pre>\n
      Create a values file with the necessary parameters to deploy the controller with the Node Port service.<\/p>\n
      cat <<EOF> demo-values.yaml\nservice:\n  type: NodePort\n  ports:\n    - port: 80\n      targetPort: 80\n      protocol: TCP\n      name: http\n      nodePort: 31080\nEOF<\/code><\/pre>\n
      In this, we have changed the Node Port number (31080<\/code>).<\/p>\n
      To deploy the controller, use the following command.<\/p>\n
      helm install nginx-fabric --create-namespace -n fabric-gateway -f demo-values.yaml .<\/code><\/pre>\n
      Once the installation is done correctly, you will get the following output.<\/p>\n
      \"<\/figure>\n
      After the deployment, we can check the components of the Gateway API Controller.<\/p>\n
      If you want to know the setup of the Kubernetes Gateway API in the EKS cluster with the Load Balancer, you can refer to this blog<\/a>.<\/p>\n
      kubectl -n fabric-gateway get all<\/code><\/pre>\n
      \"listing<\/figure>\n
      We don’t have to make any modifications in the local DNS resolution because the hostname and IPs are the same.<\/p>\n
      Step 8: Describe Kubernetes Gateway API Gateway Class.<\/h3>\n
      As with the Ingress, when we deploy the Gateway API Controller, the Gateway Class will be created with the controller information.<\/p>\n
      kubectl get gatewayclass<\/code><\/pre>\n
      \"listing<\/figure>\n
      The gateway.nginx.org\/nginx-gateway-controller<\/code> is the Gateway API Controller name.<\/p>\n
      Step 9: Create the Kubernetes Gateway API Gateway Resource.<\/h3>\n
      This is slightly different from Ingress because in Ingress, we can directly create the rules with the Ingress object, but in Gateway API, we need to create an entry point for the traffic. Then only we can create rules.<\/p>\n
      To create an entry point for the traffic, we need to create a Gateway object.<\/p>\n
      cat <<EOF > colors-gateway.yaml\napiVersion: gateway.networking.k8s.io\/v1\nkind: Gateway\nmetadata:\n  name: colors-gateway\n  namespace: colors\nspec:\n  gatewayClassName: nginx\n  listeners:\n  - name: http\n    port: 80\n    protocol: HTTP\n    allowedRoutes:\n      namespaces:\n        from: All\nEOF<\/code><\/pre>\n
      Gateway is a Namespace scoped object, so we need to create the Gateway on where the endpoints are.<\/p>\n
      In Ingress<\/strong>, we define the Ingress Class<\/strong> in the Ingress object, but in Gateway API<\/strong>, the Gateway Class<\/strong> will be specified in the Gateway<\/strong> object.<\/p>\n
      Listeners are the type of network, we can define multiple listeners in a same Gateway (Example: 443, 8080).<\/p>\n
      The allowRoutes<\/code> section, we can instruct from what are the Namespaces to allow the traffic to the Gateway.<\/p>\n
      These are some of the basic configurations in the Gateway object.<\/p>\n
      kubectl apply -f colors-gateway.yaml<\/code><\/pre>\n
      To list the Gateway, use the following command.<\/p>\n
      kubectl -n colors get gateway<\/code><\/pre>\n
      \"listing<\/figure>\n
      If you describe it, you will get more information about the Gateway.<\/p>\n
      kubectl -n colors describe gateway colors-gateway<\/code><\/pre>\n
      Now, we can define rules for routing.<\/p>\n
      Step 10: Create Gateway API HTTP Route Resources to Define Routing Rules<\/h3>\n
      We have multiple resources to define our rules based on the protocol.<\/p>\n
      We know that our demo application is HTTP based, so we are using the HTTP Route resource.<\/p>\n
      cat <<EOF > colors-http-route.yaml\napiVersion: gateway.networking.k8s.io\/v1\nkind: HTTPRoute\nmetadata:\n  name: colors-httproute\n  namespace: colors\nspec:\n  parentRefs:\n  - name: colors-gateway\n    sectionName: http\n  hostnames:\n  - \"dev.techiescamp.com\"\n  rules:\n  - matches:\n    - path:\n        type: PathPrefix\n        value: \/green\n    backendRefs:\n    - name: green-app-service\n      port: 80\n  - matches:\n    - path:\n        type: PathPrefix\n        value: \/orange\n    backendRefs:\n    - name: orange-app-service\n      port: 80\nEOF<\/code><\/pre>\n
      The parentRefs<\/code> section where we define the Gateway resource.<\/p>\n
      hostname<\/code> section where we define the host name (dev.techiescamp.com<\/code>).<\/p>\n
      Under the rules<\/code> sections, we can define the service details to get the endpoints.<\/p>\n
      The HTTP Route Custom Resource is similar to the Ingress object in Ingress, where we define the routing rules.<\/p>\n
      The only difference is that in Ingress, the Ingress Class will be defined in the Ingress object, but in Gateway API, the Gateway Class will be defined in the Gateway object, and the Gateway object will be defined in the HTTP Route.<\/p>\n
      kubectl apply -f colors-http-route.yaml<\/code><\/pre>\n
      After the deployment, we list the HTTP Routes using the following command.<\/p>\n
      kubectl -n colors get httproutes<\/code><\/pre>\n
      You can describe to ensure the routes are properly configured and the status is active or not.<\/p>\n
      kubectl -n colors describe httproutes colors-httproute<\/code><\/pre>\n
      \"listing<\/figure>\n
      The migration configuration is properly done so we can check the application.<\/p>\n
      This time, for the testing, we need to use the URL with the Gateway API Controller Node Port, which is 31080.<\/p>\n
      \"the<\/figure>\n
      We have successfully migrated the traffic routing from the Ingress to the Gateway API.<\/p>\n
      Step 11: Remove the Nginx Ingress Controller from the Cluster<\/h3>\n
      Use the following command to uninstall the Nginx Ingress Controller.<\/p>\n
      helm -n ingress-nginx uninstall nginx-ingress<\/code><\/pre>\n
      Note: We have migrated the traffic routing from Ingress to Gateway API without any downtime, but in actual production, the Controller will be exposed with Load Balancer service and the domain name will be configured with DNS Servers.<\/p>\n
      During the migration, the Load Balancer DNS records were also remapped with the DNS server, so it might face some downtime.<\/p><\/blockquote>\n
      Conclusion<\/h2>\n
      This blog explains how we can migrate the existing Ingress setup to Gateway API for the futuristic traffic routing. This is the basic migration, but you can configure the entire traffic routing to Gateway API.<\/p>\n
      In future blogs, we will cover the Gateway API and its use cases more. Please refer to the official documentation<\/a> to learn more about the Gateway API.<\/p>\n
      \n
      Ngu\u1ed3n:<\/strong> How To Migrate Kubernetes Ingress To Gateway API? \u2014 DevOpsCube<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
      Source: https:\/\/devopscube.com\/migrate-kubernetes-ingress-to-gateway-api\/<\/p>\n","protected":false},"author":1,"featured_media":381,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-380","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\/380","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=380"}],"version-history":[{"count":0,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts\/380\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/media\/381"}],"wp:attachment":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=380"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=380"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=380"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}