Today, we are excited to announce the general availability of Kong Ingress Controller (KIC) 2.4! Earlier this year, we launched KIC 2.2 with initial support for Kubernetes Gateway API. In this release, we’re adding weighted load balancing and support for TCP and UDP routes, as well as some much needed quality-of-life features for our customers. 

A Refresher on Kubernetes Gateway API

Kubernetes Gateway API is a collection of resources that model service networking in Kubernetes. These resources (GatewayClass, Gateway, HTTPRoute, TCPRoute, Service, etc.) can replace the existing Ingress controller available in Kubernetes today.

Gateway API contains three primary resources:

• GatewayClass: Represents a class of gateways that can be created with a common configuration and behavior
• Gateway: The gateway, which routes traffic (in our case, Kong Gateway)
• Routes: Describes how traffic coming via the gateway maps to the Services

Designed by the Kubernetes community, Gateway API represents the next step in managing ingress traffic for Kubernetes clusters. The well-known Ingress API in Kubernetes is limited, as it only delivers a subset of the functionality now being made available with the Gateway API. The gateway and route resources provide additional features and capacities such as:

• True Layer 4 support (TCPRoute, UDPRoute, etc.)
• Advanced traffic control (e.g., port-based route matching)
• Resilience features (e.g., multiple services for rules with weights)

Gateway API marks a significant paradigm shift in how ingress traffic configuration is expressed in Kubernetes. When you create a Gateway Resource (instead of a Deployment) to deploy and manage your Gateway Servers in the cluster, you now can manage their configuration (for things like the listening addresses and ports) using standard Kubernetes APIs and tools like kubectl instead of managing command-line flags, environment variables, etc.

What’s New in KIC 2.4

Support for TCP, UDP and HTTP RoutesTech Preview

One of the main strengths of Gateway API is the underlying design of it being route-agnostic. This means it allows for TCP, UDP and HTTP routes out of the box. With KIC 2.4, we are pleased to announce that we have built out support for TCP, UDP and HTTP routes. To get started, feel free to view our example Gateway routes. 

Weighted Load Balancing in Gateway
APITech Preview

KIC 2.4 release adds support for multiple backendRefs in the HTTP, TCP and UDP route objects, enabling weighted load-balancing between multiple services for any specific routing rule. This feature allows you to specify weights/ratios to split traffic between your different backends. This can be particularly useful for situations in which you need to split traffic during initial rollouts, canary deployments or for split testing. The `backendRefs` type accepts a list of backends that a route rule will be sending traffic to. The user-defined weights of these backends will then split the traffic. The following example uses the weight field to forward 75% of HTTP requests to httpbin and 25% to nginx. 

Weighted Load Balancing in Gateway API

Combined RoutesTech Preview

Ingresses map individual matches to a specific Service, whereas Kong routes map any match to a single Kong service. To account for this difference, KIC creates a Kong route for each path in an Ingress, which ensures that traffic routes correctly but potentially creates a large number of routes. The new `CombinedRoutes` feature flag changes how Ingress resources are translated so that a single route can handle all Ingress paths that use the same hostname, service and port. As a result, this significantly reduces the overall size of the data plane configuration that is pushed to the Kong Admin API. This feature is expected to be disruptive for some (it changes both the route naming scheme and route set); you must opt into setting it with the controller argument –feature-gates=CombinedRoutes. To learn more about feature gates and how to enable combined routes, view our documentation. 

CRD Categories for KICGA

Categories are a list of grouped resources the custom resource belongs to. To simplify day-to-day operations and management, Kong Ingress Controller CRDs now use the `kong-ingress-controller` category. Rather than having to query multiple Kubernetes objects, you are now able to view all KIC custom resources by running `kubectl get kong-ingress-controller` to get all related types.

Managing CA certificates across multiple KIC WorkspacesGA

Some customers use multiple instances of KIC to manage multiple workspaces. Kong CA certificates are uniquely visible from any workspace, but their corresponding Kubernetes resources are only available to a single controller.

With the new `–skip-ca-certificates` flag, customers can now make configuration changes across multiple controllers without deleting CA certificates. The new `–skip-ca-certificates` flag should be set on all controllers except for the controller managing CA certificates.

What’s Coming Next?

We plan in future versions of the Kong Ingress Controller to build out full feature parity with Gateway API and have it transition into beta. Accompanying this functionality will also be the launch of our Gateway Operator. At a glance, the Gateway Operator is a tool to automatically provision, configure and upgrade Kong Gateway and KIC, manage multiple deployments of the gateway in a single cluster, and support multiple Gateway instances. 

Get started with KIC 2.4 today! As always, feedback is welcome and you may keep track of the progress on our Github repository.