Kong 1.0 is now Generally Available! (1.0.0 released)


#1

Hello everyone,

We are pleased to announce that Kong 1.0 is here!

:package: Download Kong 1.0.0 today!

1.0.0 contains the following changes over RC4:

  • The router rebuilding is resilient to semaphore timeouts
  • kong.tools.responses / helpers.responses has been removed from kong (in favor of kong.response.exit)
  • Kong expects the APIs table to be empty before updating to 1.0.0. Otherwise, it stops the upgrade showing an informative message.

It also includes some fixes:

  • PostgreSQL creates index expressions more correctly
  • Cassandra migrations don’t fail when executed in a cluster environment
  • The connection with the database is now shared correctly between request and non-request contexts
  • The semaphore protecting the router is always released, even when an error is raised from the router
  • Default messages from Lapis are no longer included in some Kong responses
  • Certain CRUD events are no longer duplicated
  • Multipart form arguments are correctly parsed

You can browse the complete list of changes for this release on GitHub. Additionally, Kong 1.0rc4 contains all changes introduced by 1.0rc1, 1.0rc2, 1.0rc3 and 1.0rc4 and you can also get the full list of changes in our changelog

Upgrade Path from 0.14 :arrow_up:

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):

  1. If you still have API entities in your system, you must move them to Routes or Services before upgrading to Kong 1.0
  2. Download 1.0, and configure it to point to the same datastore as your 0.14 cluster. Run kong migrations up.
  3. Both 0.14 and 1.0 nodes can now run simultaneously on the same datastore. Start provisioning 1.0 nodes, but do not use their Admin API yet. Prefer making Admin API requests to your 0.14 nodes instead.
  4. Gradually divert traffic away from your 0.14 nodes, and into your 1.0 cluster. Monitor your traffic to make sure everything is going smoothly.
  5. When your traffic is fully migrated to the 1.0 cluster, decommission your 0.14 nodes.
  6. From your 1.0 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.0 nodes.

Upgrade Path from 1.0rc1, 1.0rc2, 1.0rc3 & 1.0rc4 :arrow_up:

The process is the same as for upgrading for 0.14.x, but on step 2 you should run kong migrations up --force instead.

Install 1.0rc4 on a Fresh Datastore :arrow_down:

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]

Kong 0.15

If you are installing Kong from scratch, or you don’t have any API objects in your system anymore, you should upgrade to Kong 1.0. If you can’t translate your API objects to Routes and Services yet, but want to use the new features or need the fixes in 1.0.0, today we also released Kong 0.15.0. It includes all the functionality embedded in Kong 1.0, without removing the API objects.

Two important disclaimers:

  1. This is the last planned release with support for APIs. We strongly recommend all our users to translate their APIs to Routes and Services as soon as possible.
  2. Some of the new functionalities included in Kong 1.0, like Service Mesh or Stream Routes, will not work with APIs.

The Upgrade Path for 0.15 is the same as for 1.0, except that you don’t need to translate APIs to make it work.

Once you have done the translation, the upgrade from 0.15.0 to 1.0 requires no migrations:

  1. Download 1.0, and configure it to point to the same datastore as your 0.15 cluster.
  2. Both 0.15 and 1.0 nodes can now run simultaneously on the same datastore. Start provisioning 1.0 nodes, but do not use their Admin API yet. Prefer making Admin API requests to your 0.15 nodes instead.
  3. Gradually divert traffic away from your 0.15 nodes, and into your 1.0 cluster. Monitor your traffic to make sure everything is going smoothly.
  4. When your traffic is fully migrated to the 1.0 cluster, decommission your 0.15 nodes.

You can read more about the new features in 1.0 in our realease blog.

We are incredibly excited about this new release. Please try it out! As always, you can reach us via this forum or via GitHub issues if you need any help or experience problems.

We’d like to thank everyone who gave us feedback for our release candidates — this release is in part thanks to you!


#2

Congrats to the team :raised_hands: So excited about the progress into mesh architecture :spider_web:


#3

You guys are doing a great job !


#4

Where is the documentation about grpc?


#5

Hi,

Since there is still work in progress on the official Docker image (https://github.com/docker-library/official-images/pull/5209).
I built an unofficial image for early testing only (https://hub.docker.com/r/dmaumenee/kong).

I was too impatient to play with this new Christmas present :wink:


#6

Great milestone for the product. Best part is this feels like only the beginning. Don’t ever slow down and keep pushing the boundaries to make this application flawless in every regard.


#7

My understanding is that Kong works with gRPC because of TCP stream support and mutual TLS, which were both added to support service mesh. gRPC can be proxied on L4 but we don’t really support L7 routing for gRPC yet. I’d suggest checking out the Streams and Service Mesh documentation, and the stream listen and origins sections of the Configuration Reference doc.


Question about HTTP/2 / gRPC
#8

The 1.0 Docker image has just been released on DockerHub :tada:

https://hub.docker.com/_/kong/