By on September 18, 2019

Kong Ingress Controller 0.6 Released with Support for Admission Controller, Istio, and Kuma

We are thrilled to announce the release of Kong Ingress Controller 0.6! This release builds on the previous releases and unlocks integrations and features, including the Admission Controller, integration with Kuma and Istio, and support for Kustomize native configuration management.

Admission Controller

The Kong Ingress Controller now contains a Kubernetes Admission Controller.

The admission controller validates Custom Resource Definitions (CRD) as they are created or updated and rejects any invalid configurations. This implements a declarative configuration model and enables operators to automatically detect invalid configurations.

Two CRD, KongConsumer and KongPlugin, are supported with this release and support for KongCredential and KongIngress resources will be coming in the future.

Please follow the admission controller guide for more details.

Service Mesh Integration with Kuma and Istio

The  Kong Ingress Controller can now be integrated with Service Meshes such as Istio and Kuma by acting as an Ingress point in a service mesh deployment. This setup makes the Kong Ingress Controller the single port of entry for all external traffic coming into the service mesh.

Kong Ingress handles all external client-facing routing, policies, documentation, metrics, while load-balancing and service-to-service policy enforcement is performed through the underlying  service mesh solution.

This flexible architecture allows Kubernetes cluster owners to use their preferred service mesh to manage East/West traffic while benefiting from the capabilities of the Kong Ingress Controller for all North/South traffic.

The following graphic shows a high-level deployment of Kong Ingress Controller using either the Kuma or Istio service mesh. Envoy is injected as a sidecar to Kong Ingress pod and handles the routing for all traffic upstream.

Simplified deployment

With this release, we are moving toward a unified deployment design to simplify deployments, debugging and the amount of configuration that goes into setting up Kong Ingress Controller. There is now only a single Kubernetes Deployment that contains all the necessary components to run Kong Ingress.

In-memory deployment

While running in in-memory mode, each pod’s controller actively configures the Kong container in its pod. This limits the blast radius of failure of a single container of Kong or controller container to that pod only, as pods continue to function normally.

Database-driven deployment

Prior to this release, Kong Ingress Controller was deployed as an additional Kubernetes Deployment alongside a Kong Deployment. The new Deployment packs Kong and the Controller in the same Pod, simplifying configuration and operations. Same as before, a leader is elected amongst all the instances of a Controller, which configures Kong’s Database. 

Kustomize-driven deployment

Kong Ingress Controller already supported installation using Kong Operator, Helm Chart and YAML manifests. With this release, we are announcing support for Kustomize as well.

Kustomize makes it easy to define and override specific sections of YAML definitions, all in a declarative fashion without templating YAMLs. You can use remote builds in Kustomize to declarative generate deployments of Ingress Controller:

Kong Enterprise

This new release brings in support for using Kong Enterprise 0.36 as the Ingress point and provides a single dashboard for the summary of all traffic flowing into a Kubernetes Cluster.

With Kong Enterprise as an Ingress point, you get a number of enhancements to your experience. 

  • Kong Teams allows you to customize Kong Enterprise to fit your security needs, including RBAC for your organization, Admin API access management, and the option to group teams and/or services by Workspaces, so team members only see what they should without extra noise or risk.
  • Kong Vitals provides visibility into your traffic, API health, and overall cluster health. 
  • Use Kong Developer Portal to easily document the services you have running in Kong and extend access throughout your organization.
  • Add Kong Brain to enable features like Auto-Documentation via Dev Portal. 
  • Add Kong Immunity to enhance security by receiving customized alerts for any anomalous traffic that runs through Kong.
  • Leverage Kong Enterprise plugins that help you further extend Kong use cases and customization specific to your organizational needs.

Furthermore, the Kong Ingress Controller can also map Kubernetes namespaces to Kong Enterprise Workspaces, leading to a fluid experience as you switch between Kubernetes Dashboard and Kong Manager. 

The new release adds Kustomize-driven deployment for Kong Enterprise, as well as provides official YAML manifests:

Check out this guide for more details.

Revamped documentation

The documentation for the Kong Ingress Controller has been reworked and expanded to aid users in choosing the right deployment and walk through configuring different types of services. Check out the new documentation:

https://github.com/Kong/kubernetes-ingress-controller/tree/master/docs

Also, check out the guides section to get help in using any feature of the Ingress Controller:

https://github.com/Kong/kubernetes-ingress-controller/tree/master/docs/guides

Bleeding edge builds

A Docker Image is built for each commit to Kong Ingress Controller’s master branch.

Power users can pull-in bleeding edge updates from the following Docker repository:

https://bintray.com/kong/kubernetes-ingress-controller/master

Misc improvements

This release brings in support for two new features introduced in Kong 1.3 using KongIngress resource:

  • Header based routing
  • Least connection load-balancing

Kubernetes 1.15 introduced the Ingress resource under the networking.k8s.io API-group, which will be its home in the future for good. extensions/Ingress resource is now considered deprecated. To facilitate easy transition, Kong Ingress Controller dynamically switches between extensions/Ingress and networking/Ingress resource types based on whatever type is exposed by the Kubernetes server.

Finally, the KongCredential CRD support has been reworked with support for multiple credentials per consumer.

Getting help

Please feel free to ask questions on our Community forum — Kong Nation — and open a Github issue if you happen to run into a bug. 

Happy Konging!