Continuing our release candidate cycle for Kong 1.0, we’re happy to announce the availability of RC3!
Download Kong 1.0.0rc3 today and give us your feedback!
This third release candidate contains the first version of Service Mesh, and some fixes for problems detected while testing RC2. We’d like to thank everyone who reported issues - keep them coming!
RC3 Contains the Following Improvements over RC2:
Service Mesh and Stream Routing:
- The Kong cluster creates a Certificate Authority shared by all Kong nodes,
which they can use to establish mutual TLS authentication with other nodes in a service mesh
kong.conf, accepting IPs and hostnames, with the optional
transparent(for using iptables) suffixes
- Kong’s core router can now route raw TCP and TLS traffic
- Stream traffic routing is done in a new phase called
- Mutual TLS authentication happens in the new
protocolproperty of Route and Service entities can now be
tlsin addition to
- Three new properties of Route entities are available for routing
Other Changes in Core:
- The new
transparentsuffix also applies for
- Support for upgrading
- Multiple improvements and fixes on the schema library
- The PDK has been extended to include Consumer, Service and Route handling variables
- Upgraded the
lua-cassandradependency and fixed issues
- Fixed an issue with the
kong quitcommand timeouting with PostgreSQL
- Bumped the
- Typos, style and grammar fixes (thanks @saideepd, @gy741, @arpitpandey0209, @joelvisroman, @vkmrishad, @mr-yamraj, @geekysrm, @Mehvix, @vyaspranjal33, @iTechTR, @shyamjalan , and @steffinstanly)
Changes in Plugins:
Plugins can now execute code in the new
All plugins have a new field,
run_on, which will control their activation
in service mesh and “regular API gateway” mode
first, is what most plugins will use - on the first Kong node the request hits. Other possible values are
all(execute plugin in every Kong node) and
second(on Service Mesh mode, execute on the Kong node which is not the
ACL: Fixed an error in the migrations which prevented upgrading
Correlation-Id: Fixed an error when access phase did not execute
Upgrade Path from 0.14
We have made sure that the following upgrade path from 0.14.x is supported, including “cold” nodes (Note: upgrading from a pre-0.14 cluster is not supported):
- Download 1.0rc3, and configure it to point to the same datastore as your 0.14 cluster. Run
kong migrations up.
- Both 0.14 and 1.0rc3 nodes can now run simultaneously on the same datastore. Start provisioning 1.0rc3 nodes, but do not use their Admin API yet. Prefer making Admin API requests to your 0.14 nodes instead.
- Gradually divert traffic away from your 0.14 nodes, and into your 1.0rc3 cluster. Monitor your traffic to make sure everything is going smoothly.
- When your traffic is fully migrated to the 1.0rc3 cluster, decommission your 0.14 nodes.
- From your 1.0rc3 cluster, run:
kong migrations finish. From this point on, it will not be possible to start 0.14 nodes pointing to the same datastore anymore. Only run this command when you are confident that your migration was successful. From now on, you can safely make Admin API requests to your 1.0rc3 nodes.
Install 1.0rc3 on a Fresh Datastore
1.0 introduces a new, improved migrations framework. The following commands can be run to prepare a new 1.0 cluster from a fresh datastore:
$ kong migrations bootstrap [-c config] $ kong start [-c config]
Our next release candidate, 1.0RC4, will add more features to Service Mesh. Stay tuned for more updates!
As always, feel free to reach out to us here or via GitHub issues if you have any questions or feedback about this upgrade path, or the contents of this release in general! We appreciate the feedback we receive from our release candidates testers and thank them in advance!