Kong for Kubernetes 0.10 Released With Ingress v1 Resource, Improved Ingress Class Handling, and More!
Kong for Kubernetes is a Kubernetes Ingress Controller and a full-fledged edge-router which can route traffic to any destination of your choice. In addition to Ingress management, it provides enhanced security and management capabilities. With Kong, you can use Kubernetes not just for running your workloads but also for securing and monitoring connectivity between your workloads – all managed via Kubernetes manifests .
This release’s highlights include support for Ingress v1 resource and Admission v1 resources, enhancements to handling of kubernetes.io/ingress.class annotations, and structured logs.
Support For Ingress V1
0.10 adds support for the Ingress v1, the latest version of the Ingress resource, introduced in Kubernetes 1.19. Key highlights include:
- Defined path-matching behavior, indicating whether a path must be an exact match, is a prefix, or is matched using some other, vendor-specific behavior.
- Support for a wider range of regular expression grammars; you can now use all powerful features of Kong.
- Clarified field names and promotion of the commonly-used ingress class annotation to an official Ingress field.
Improved Ingress Class Handling
The usage of the
kubernetes.io/ingress.class annotation has been rewritten from ground up. Resources now fall into one of two categories:
- Resources that the controller translates directly into Kong configuration, such as an Ingress (which translates to a route) or KongConsumer (which translates to a consumer). These resources require a class annotation.
- Resources that the controller only loads when they are attached to a directly-translated resource, such as a KongPlugin attached to an Ingress or a credential Secret attached to a KongConsumer. These resources do not require a class annotation.
Prior to this release, resources in the first category did not require a class annotation if the controller was set to use the default (“kong”) ingress class, and always processed these resources. This behavior is now only optionally available on some (Ingress and KongConsumer) resources, is disabled by default, and is usable when using the default ingress class or a custom ingress class.
This release also fixes a bug that prevented resources in the second class from updating if they did not have a class annotation and the controller was set to use a custom class. Kong configuration the controller creates from resources referenced by another resource will now track changes to both the referenced and referencing Kubernetes resources properly.
Structured logs separate log data from the log format, allowing the controller to present the same log information in a variety of formats. Rather than formatting context-specific information into a static, human-readable string, the controller now dynamically inserts log data into a template and renders the format requested by the
CONTROLLER_LOG_FORMAT environment variable.
The log format flag accepts “text” or “json”, which produce human-readable logs similar to older versions’ logs and JSON logs, respectively. Support for JSON logs allows you to ship controller logs to a structured log management system (ElasticSearch, Splunk, Loki, etc.) for easy filtering and help our users quickly identify issues within the controller.
Support For ValidationWebhookConfiguration v1
0.10 introduces support for v1 ValidationWebhookConfiguration admission webhook, introduced in Kubernetes 1.16. Highlights include:
- Finer-grained control over which resources require validation.
- Configurable timeouts and validation service ports.
- Improved validation on object deletion.
- Improved defaults based on community feedback.
Required class annotations
While 0.10.0 does simplify ingress class handling, this requires some changes that break previous behavior. Resources that the controller renders directly into Kong configuration (versus resources that only result in configuration when attached to another resource) now generally require ingress class annotations, whereas controller versions prior to 0.10.0 would load resources without class annotations when the controller was set to filter on the default ingress class (“kong”).
For compatibility with existing configuration, we do allow users to disable this change on Ingress and KongConsumer resources using configuration variables, though we recommend adding class annotations at your earliest convenience: using class annotations ensures there is no ambiguity regarding which controller should process the resource, which avoids potential conflicts in multi-controller environments.
End of support for global KongPlugins in favor of KongClusterPlugins
The controller uses a “global” label to indicate when a KongPlugin or KongClusterPlugin resource should create a global plugin in Kong configuration. 0.10.0 removes support for this label on KongPlugins, and you should convert existing global KongPlugins to KongClusterPlugins. You can list these using kubectl:
kubectl get kongplugin -l global=true --all-namespaces
This change is necessary to properly enforce the security guarantees established by Kubernetes’ RBAC system.
0.10 deprecates support for the extensions/v1beta1 Ingress resources in favor of networking.k8s.io/v1beta1 and networking.k8s.io/v1 Ingress resources, following their deprecation in Kubernetes 1.19. Although 0.10 continues to support extensions/v1beta1 Ingresses, they will be removed in a future version. We recommend users migrate their resources (which requires running Kubernetes 1.14 or newer) at their earliest convenience.
Kong for K8s supports a variety of deployments and run-times. For a complete view of Kong for K8s compatibility, please see the compatibility document.
You can try out Kong for K8s using our lab environment, available for free to all at https://konghq.com/workshops/kong-for-kubernetes/.
You can install Kong for K8s on your Kubernetes cluster with one command:
$ kubectl apply -f bit.ly/k4k8s
or using Helm:
$ helm repo add kong https://charts.konghq.com
$ helm repo update
$ helm install kong/kong
Alternatively, if you want to use your own Kubernetes cluster, follow our getting started guide to get your hands dirty.