See what makes Kong the fastest, most-adopted API gateway
Check out the latest Kong feature releases and updates
Single platform for SaaS end-to-end connectivity
Enterprise service mesh based on Kuma and Envoy
Collaborative API design platform
How to Scale High-Performance APIs and Microservices
Call for speakers & sponsors, Kong API Summit 2023!
6 MIN READ
Today, we’re thrilled to announce the general availability of Kong 1.0 – a scalable, fast, open source Microservice API Gateway built to manage, secure and connect hybrid and cloud-native architectures. Kong runs in front of any service and is extended through plugins including authentication, traffic control, observability and more.
By releasing 1.0 we are making a promise of backward compatibility moving forward. With years of development and thousands of production users, we added significant features and tons of fixes that makes Kong faster, more flexible and resilient, including:
In 1.0, users can now deploy Kong not only as an API gateway but also as a standalone service-mesh proxy. Kong plugins provide key functionality for service mesh out of the box and integrations with other cloud-native technologies including Prometheus, Zipkin, health checks, canary, blue-green and much more.
In 1.0, the Kong cluster creates a Certificate Authority which Kong nodes can use to establish mutual TLS authentication with each other. Additionally, Kong can now route raw TCP traffic which means Kong can now balance traffic from mail servers and other TCP-based applications, all the way from L7 to L4.
Kong 1.0 now supports primitive, passive, proxy-pass of gRPC traffic in addition to REST. For this initial iteration, no Kong plugins can be applied to manipulate gRPC traffic. gRPC is built on top of HTTP/2, and this initial support provides another option for Kong users looking to connect east-west traffic with low overhead and latency. This is particularly helpful in enabling Kong users to open more mesh deployments in hybrid environments.
Kong 1.0 introduces a new Database Abstraction Object (DAO), which eases migrations from one database schema to another with near-zero downtime. The new DAO allows users to upgrade their Kong cluster all at once, without requiring manual intervention to upgrade each node.
The PDK is a set of Lua functions and variables that can be used by custom-plugins to implement their own logic on Kong. Though it was released in 0.14.0, changes in 1.0 fulfill the promise that plugins built with the PDK will be compatible with Kong versions 1.0 and higher.
You can find the full list of changes in all Kong releases in the Changelog. There are a number of breaking changes in this release, so please be sure to read the suggested upgrade path for 1.0.
Although today we make the promise that Kong is stable and backward compatible, Kong is far from done. We’re excited to continue building the project and the community with you! We’re extremely grateful to our community for all of the support in getting us to this milestone, and we look forward to continuing to build and grow together.
Try Kong 1.0, and let us know what you think.
Since we open sourced Kong four years ago, hundreds of Kong contributors across the world have made countless improvements to the Kong codebase that have brought us to our 1.0 release. Before we get into the new features and fixes in 1.0, we need to first thank the incredible community of Kong users and contributors that got us here. When we first open sourced Kong we could not have imagined the amazing community that has grown around it, and that continues to grow today!
“Kong was built with the vision of a hybrid world in mind, and Kong 1.0 represents a critical step towards that vision. Together with our Community, we’ve made key changes to the architecture of the platform, including the ability to support service mesh, that will give our users the ability to handle any deployment across vendors, environments, and ecosystems. Moving forward, be assured that we’re deepening our commitment to support even more emerging ecosystems”, – Kong CTO, Marco Palladino.
Now, we’ll take a deeper look at some of our new features in 1.0 and how they can help our Community.
In 1.0, users can now deploy Kong as a standalone service mesh. With sidecar proxies offering greater visibility, security and resiliency, a service mesh can help address some of the challenges incumbent with microservices. In addition to these benefits, Kong’s service mesh provides a few key advantages compared to other vendors, all of which stem from our injecting the same runtime we use at the edge as a sidecar proxy.
With Kong you can instantly extend the same functionality you use at the edge into a mesh. Easily move services into a mesh at your own pace, by deploying Kong onto the same host as the container running your service.
Connect services in your mesh to services across all environments, platforms, and vendors. Use Kong to bridge the gap between cloud-native design and traditional architecture patterns without changing your services’ code.
Our plugin architecture offers users unparalleled flexibility. Kong plugins provide key functionality out of the box and supporting seamless integrations with other cloud-native technologies including Prometheus, Zipkin, and many others. Plugins run locally with each service rather than requiring an extra network hop to another component for complex requests.
Kong and its plugins are optimized for performance. Other platforms may introduce latency between services in a container or mesh, we introduce less than a millisecond of delay.
Kong 1.0 now supports gRPC protocols in addition to REST, for Kong users looking to build high-performance APIs while minimizing overhead.
Kong’s support for service mesh is enabled by the addition of mutual Transport Layer Security (TLS) between Kong instances, and modifications to the plugin run loop. These changes allow Kong to be deployed alongside each instance of a service, brokering information between services and automatically scaling as those services scale. The Kong cluster creates a Certificate Authority which Kong nodes can use to establish mutual TLS authentication with each other.
As a result of the new mTLS support, Kong’s core router can now route raw TCP traffic. This means that you can now use Kong to balance traffic from mail servers and other TCP based applications.
Kong 1.0 allows users to specify separate control and data planes in their Kong configurations. Previously, you needed to configure each cluster’s data and control planes separately, now you can make a change in a centralized location that will be reflected across multiple Kong clusters. Separate data and control plane configurations allow Kong users to better control large deployments. The separation also makes deployments more secure by allowing you to protect Kong’s configuration behind a firewall and only expose the data plane.
Kong 1.0 introduces a new Database Abstraction Object (DAO), which eases migrations from one database schema to another with minimal to zero downtime. The new DAO allows users to upgrade their Kong cluster all at once, without requiring manual intervention to upgrade each node sequentially.
One of our reasons for labeling Kong 1.0 now is the Plugin Development Kit (PDK). Extensibility via plugins has been on Kong’s list of design criteria from the very beginning, and the PDK makes building those plugins safe and easy. Though it was released in 0.14.0, changes in 1.0 fulfill the promise that plugins built with the PDK will be compatible with Kong versions 1.0 and higher.
The PDK is a set of Lua functions and variables that can be used by custom-plugins to implement their own logic on Kong. It provides a number of advantages over writing plugins from scratch, these include:
All Kong plugins require a standard set of functionality, which the PDK provides out of the box. This both saves plugin developers time and guarantees that plugins written on the PDK will behave similarly to each other (same parsing rules, same errors, etc.) making them easier to use.
The PDK’s interfaces are easier to use than the bare-bones ngx_lua API. The PDK allows its users to isolate plugin operations such as logging or caching from those of other plugins.
The PDK is semantically versioned to maintain backward compatibility. In the future, plugins will be able to lock the PDK version they depend upon.
Check out the Plugin Development Kit Reference, or check out our deep-dive into the PDK for more!
To ensure that the performance in our data plane exceeds the requirements for services meshes and other decentralized architectures, we made several improvements to our plugin run loop. Below we’ll detail some of these improvements and their impact on performance.
Plugins can now execute code in the new preread phase. This allows Kong users to improve performance by initializing plugins when the initial TCP connection is made.
All plugins have a new field, run_on, which will control their activation in service mesh and “regular API gateway” mode. This enables more granular control over plugin activity to avoid redundancies and further enhance performance.
Kong 1.0 also includes substantial improvements to interactions with AWS Lambda and Azure FaaS, including Lambda Proxy Integration and improvements to the Azure Functions plugin to filter out headers disallowed by HTTP/2 when proxying HTTP/1.1 responses to HTTP/2 clients.
Share Post