Enabling the use of Gateway API

Gateway API is a flexible system for controlling incoming traffic to Kubernetes applications. You can configure Gateway API for License Service. This feature is available from License Service version 4.2.21.

Before you begin

Gateway API is supported from Kubernetes 1.26.

About this task

  • This procedure provides a validated example of configuring Gateway API by using the Envoy implementation. You might choose an alternative approach. However, if it does not work, it is your responsibility to troubleshoot the solution or use the one that is described in this procedure.
  • If you manually enabled the use of Gateway API by using this technote, you do not need to perform this procedure.

Procedure

  1. Deploy Gateway API with Envoy Gateway.
    1. Install Gateway API CRDs. For more information, see Getting started with Gateway API.
    2. Install Envoy Gateway from OCI registry, for example by using Helm. See the gateway repository on the Envoy Proxy GitHub project.
      For information about other installation options, see: Installation.
      Note: If you use the Helm installation, you can skip the CRDs installation during the Envoy deployment because you already deployed CRDs in step 1.a. You can use the --skip-crds parameter, for example in the Helm execution command.
  2. Create the default GatewayClass on the cluster. Use ibm-licensing as the Envoy name.
    cat <<EOF | kubectl apply -f -
    apiVersion: gateway.networking.k8s.io/v1
    kind: GatewayClass
    metadata:
      name: ibm-licensing
    spec:
      controllerName: gateway.envoyproxy.io/gatewayclass-controller
    EOF
    The License Service operator automatically creates a ConfigMap for BackendTLSPolicy, and deploys the Gateway, HTTPRoute, and BackendTLSPolicy.
  3. Validate the installation. Check whether:
    • A new namespace for Envoy (for example, envoy-gateway-system) with GatewayClass is created. For other validation points, see: Testing the configuration.
    • Gateway, HTTPRoute, and BackendTLSPolicy exist.
  4. Retrieve the new host name. To retrieve the new host name from the Gateway created in the ibm-licensing namespace, run the following command.
    LIC_NS="ibm-licensing"
    kubectl get gateway ibm-licensing-service-gateway -n "$LIC_NS" 
    -o jsonpath='{.status.addresses[?(@.type=="Hostname")].value}{"\n"}'
    If the host name is not assigned, check whether the GatewayClass ibm-licensing was created and the cluster provides load balancer capabilities. Run the following command.
    kubectl get gatewayclass ibm-licensing

What to do next

If you are configuring Gateway API as a substitute for Kubernetes Ingress, you can optionally perform the following actions.
  • Delete the old ingress-nginx controller. License Service does not delete the existing Ingress definition out of the License Service namespace and does not watch it.
    Note: Perform this step only if the ingress-nginx controller is not used by other applications.
    1. If Helm was used to install the ingress-nginx controller, use the following command.
      helm uninstall ingress-nginx --namespace ingress-nginx
      kubectl delete namespace ingress-nginx
      Alternatively, delete the existing resources from the ingress-nginx namespace. Then, delete the namespace.
    2. Test again whether the route from step 4 is working.
  • Delete Ingress from the License Service namespace.
    LIC_NS="ibm-licensing"
    kubectl delete ingress ibm-licensing-service-instance -n "$LIC_NS"
If you want to disable support for Gateway API, run the following command.
LIC_NS="ibm-licensing"
kubectl patch ibmlicensing instance -n "$LIC_NS" --type=merge -p '
spec:
  gatewayEnabled: false
'