This article is a part of the series “Hands-On With Apache APISIX Ingress ”.

Previously, I wrote an article comparing the Kubernetes Gateway API and the Ingress API .

The Gateway API was designed to overcome the limitations of the Ingress API (like proprietary annotations and custom CRDs), thus providing a unified way to expose services outside the cluster.

You can read more about the Gateway API , but we will keep the focus of this tutorial on using the Gateway API in practice with Apache APISIX Ingress.

Before you move on, make sure you:

  1. Go through the previous tutorial to learn about canary releases.
  2. Have access to a Kubernetes cluster. This tutorial uses minikube for creating a cluster.
  3. Install and configure kubectl to communicate with your cluster.
  4. Install Helm to deploy the APISIX Ingress controller.

Installing the Gateway API CRDs

Kubernetes does not support the Gateway API out of the box. So, you can manually install the CRDs by running:

kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v0.5.0/standard-install.yaml

Deploying APISIX Ingress and the Sample Application

You can install APISIX and APISIX Ingress controller with Helm. To enable APISIX Ingress controller to work with the Gateway API, you can set the flag --set ingress-controller.config.kubernetes.enableGatewayAPI=true as shown below:

helm repo add apisix https://charts.apiseven.com
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update
kubectl create ns ingress-apisix
helm install apisix apisix/apisix --namespace ingress-apisix \
--set gateway.type=NodePort \
--set ingress-controller.enabled=true \
--set ingress-controller.config.apisix.serviceNamespace=ingress-apisix \
--set ingress-controller.config.kubernetes.enableGatewayAPI=true

As in our previous tutorials , we will deploy bare-minimum-api as our sample application:

kubectl run bare-minimum-api-v1 --image navendup/bare-minimum-api --port 8080 -- 8080 v1.0
kubectl expose pod bare-minimum-api-v1 --port 8080
kubectl run bare-minimum-api-v2 --image navendup/bare-minimum-api --port 8080 -- 8080 v2.0
kubectl expose pod bare-minimum-api-v2 --port 8080

Configuring Canary Release With the Gateway API

A canary release allows you to rollout new changes in your application gradually. You can configure this in APISIX through the Kubernetes Gateway API as shown below:

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: HTTPRoute
metadata:
  name: canary-release
spec:
  hostnames:
  - local.navendu.me
  rules:
  - backendRefs:
    - name: bare-minimum-api-v1
      port: 8080
      weight: 50
    - name: bare-minimum-api-v2
      port: 8080
      weight: 50

We use the HTTPRoute API to configure our Route in APISIX. The APISIX Ingress controller will convert the HTTPRoute resource to APISIX configuration.

As in the previous tutorial , you can adjust the weights of the traffic split to configure a canary release. With the configuration shown above, traffic will be split equally between the two versions of the bare-minimum-api:

➜ curl http://127.0.0.1:56194/
Hello from API v1.0!
➜ curl http://127.0.0.1:56194/
Hello from API v2.0!
➜ curl http://127.0.0.1:56194/
Hello from API v1.0!
➜ curl http://127.0.0.1:56194/
Hello from API v2.0!
➜ curl http://127.0.0.1:56194/
Hello from API v1.0!
➜ curl http://127.0.0.1:56194/
Hello from API v2.0!
➜ curl http://127.0.0.1:56194/
Hello from API v1.0!
➜ curl http://127.0.0.1:56194/
Hello from API v2.0!

What’s Next?

This tutorial gave you a quick walkthrough on how you can use the Kubernetes Gateway API with Apache APISIX.

You can learn more about using APISIX as your Kubernetes Ingress/Gateway from apisix.apache.org .

See the complete list of articles in the series “Hands-On With Apache APISIX Ingress ”.