Kong 1.1.0rc2 available for testing

1

Hello again, Kong people!

We are excited to announce the second release candidate for our next release, Kong 1.1.0rc2!

This comes with a bunch of stability fixes based on the feedback we got from 1.1.0rc1, plus one extra goodie we sneaked in as it almost made it to rc1: transparent proxying mode!

:package: Download Kong 1.1.0rc2 today — we are eager for feedback!

What’s new since Kong 1.1.0rc1: :fireworks:

Improvements

  • Transparent proxying - the service attribute on Routes is now optional; a Route without an assigned Service will proxy transparently (#4286)

Fixes

  • Core
    • Resolve hostnames in Cassandra contact points (#4378)
    • Fix health checks for Targets that need two-level DNS resolution (e.g. SRV → A → IP) (#4386)
    • Fix serialization of map types in the Cassandra backend (#4368)
  • Admin API
    • Fix Admin API inferencing of map types using form-encoded (#4368)
  • PDK
    • PDK version identifier was bumped to 1.1.0
    • kong.client.get_subsystem was moved to kong.nginx.get_subsystem (#4358)
  • DB-less / Declarative config
    • fix the behavior of the /tags endpoint and ?tags= query string from the Admin API when using database=off (#4380)
    • fix initial load of the declarative config file (#4342)
    • reloading the declarative config via /config refreshes the Upstream balancers (#4372)

Dependencies

  • Bump OpenSSL to 1.1.0b
  • Bump lua-resty-dns-client to 3.0.2

And a recap of all the new stuff in the 1.1.0 series :fireworks:

  • Kong can now run without a database, using in-memory storage only:
    • New option in kong.conf: database=off to start Kong without a database
    • New option in kong.conf: declarative_config=kong.yml to load a YAML file using
      Kong’s new declarative config format
    • New command: kong config init to generate a template kong.yml file to get you started
    • New command: kong config parse kong.yml to verify the syntax of the kong.yml file before using it
    • New Admin API endpoint: /config to replace the configuration of Kong entities entirely,
      replacing it with the contents of a new declarative config file
  • Bulk database import, using the same declarative configuration format as the in-memory mode
    • New command: kong config db_import kong.yml to upsert all entities specified in the kong.yml file in bulk
  • Support for tags in entities:
    • Every core entity now adds a tags field
    • Admin API endpoints now support searching by tag (for example, /consumers?tags=example_tag)
    • You can search by multiple tags:
      • /services?tags=serv1,mobile to search for services matching tags serv1 and mobile
      • /services?tags=serv1/serv2 to search for services matching tags serv1 or serv2
    • New Admin API endpoint /tags/ for listing entities by tag: /tags/example_tag
  • Improvements for orchestration scenarios:
    • The Kubernetes Sidecar Injection plugin is now bundled into Kong for a smoother K8s experience
    • New option --wait in kong quit to ease graceful termination when using orchestration tools
  • Improvements for stream handling:
    • The stream_realip_module is now bundled
    • The stream subsystem now supports Nginx directive injections
    • New PDK functions: kong.client.get_protocol (returning “http”, “https”, “tcp” or “tls”)
      and kong.client.get_subsystem (returning “http” or “stream”)
  • Support for ACL authenticated groups
  • Various bugfixes

Quick start for using Kong without a database

  1. To do a test run of Kong using database-less mode, start Kong as usual, adding the KONG_DATABASE=off environment variable (you can also set database=off in kong.conf instead if you want to make the changes permanent):
$ export KONG_DATABASE=off
$ kong start -c kong.conf
  1. You can generate an example kong.yml file in the current directory:
$ kong config init -c kong.conf

  1. Edit the kong.yml and add entities there — the generated file has instructions.

  2. Now you can load your declarative config using the /config endpoint and all entities in that file will be populated in Kong’s memory:

$ http :8001/config config=@kong.yml

Upgrade Path :arrow_up:

You can upgrade from 0.14.1 or any release in the 1.0 series (Note: upgrading from a pre-0.14 cluster is not supported). You can use a Blue/Green deployment method to update: “Blue” means your current version (0.14.1 or 1.0), “Green” means the new version 1.1.0rc2:

  1. Download 1.1.0rc2, and configure it to point to the same datastore as your Blue cluster. Run kong migrations up.
  2. Both Blue and Green nodes can now run simultaneously on the same datastore. Start provisioning 1.1.0rc2 nodes, but do not use their Admin API yet. Prefer making Admin API requests to your Blue cluster instead.
  3. Gradually divert traffic away from your Blue nodes, and into your 1.1.0rc2 cluster. Monitor your traffic to make sure everything is going smoothly.
  4. When your traffic is fully migrated to the Green 1.1.0rc2 cluster, decommission your Blue nodes.
  5. From your 1.1.0rc2 cluster, run: kong migrations finish. From this point on, it will not be possible to start Blue 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.1.0rc2 nodes.

Install 1.1.0rc2 on a fresh datastore :arrow_down:

Since version 1.0, Kong uses a new, improved migrations framework. The following commands can be run to prepare a new 1.1 cluster from a fresh datastore:

$ kong migrations bootstrap [-c kong.conf]
$ kong start [-c kong.conf]

What’s next :rocket:

Again, depending on the community feedback, we are going to either tag and release 1.1.0 final or make a new release candidate 1.1.0rc3.

As always, consider yourself encouraged to reach out to us here or via GitHub issues if you have any questions or feedback about this release! Your feedback is essential to make Kong better!

2 Likes
2

Hello there!
We’re excited to try the new RC specially after fixes for DNS Balancer (for Healthchecks).
Is there an ETA for official 1.1.0 to be released? Does it look like we’ll have 1.1.0 rc2 promoted or should we have a candidate 3?

Thanks!

1 Like
3

@Daniel_Liberman Hi, and welcome!

So far, we are looking at promoting rc2 to being the formal 1.1.0 release by the end of this week or early next week, if nothing comes up. If you have some spare cycles, please go ahead and test it, and report issues (or lack of it!). Hearing feedback about our release candidates always increase our confidence in publishing formal releases :slight_smile:

Cheers!

4

I won’t be using the dbless config stuff personally but let me give 1.1.0 rc2 a go tomorrow in our dev just so I can help yah verify nothing was broken for existing db users in the process. I will need to diff the main handler and init files from some some custom bungle pr’s I leverage and bring them up to 1.1.0 rc2 speed(hopefully those files are not massive different at this point xD ). Still glad to see the dbless feature come out as I am sure it will help with adoption to teams that prefer a simpler architecture if anything else (less dependencies less problems I always say :slight_smile: ).

5

@jeremyjpj0916 great to hear that, your feedback is always welcome! Looking forward to tag 1.1 final, lift the feature freeze in next and start working on merging @bungle’s PRs :slight_smile:

1 Like
6

1.1.0rc2 is looking good on Heroku :white_check_mark:

4 Likes
7

4am here so getting late, can’t dig any further today but maybe something gets discovered/fixed in the migrations process around what I am seeing: https://github.com/Kong/kong/issues/4420 , am a man of my word though did try to test 1.1.0rc2 today :laughing: , at first glance it seems like somehow a migration never occurred and fell through the cracks in kong’s major version 2 version upgrade and the commands today on 1.0.3 are not detecting that one chilling there non-null.

As for @bungle patches on the kong/init.lua and the kong/runloop/handler.lua files there were big enough changes I did not try to patch his polling techniques for the plugins / router builds (that have provided me fantastic Kong stability on 1.0.3) into my 1.1.0rc2 testing, hopefully he gets a moment to bring those up to speed so yall can evaluate and consider if they belong in core Kong still :slight_smile: .

8

@jeremyjpj0916 Thanks for the feedback!

We are currently in the process of testing our migration upgrade paths between Kong 0.14 -> 1.1 and 1.0 -> 1.1, sorry for the delay, we may have let something slip through. Hopefully, we’ll be able to replicate this behavior in our upgrade test suite and fix it.

As always, thanks for giving our release candidates a try, it really helps!

1 Like
9

@thibaultcha awesome stuff, yeah seems like an edge case where maybe if you set KONG_PLUGINS and don’t include bundled and hand pick your plugins(and leave some bundled plugins out that migrations might pop up for at some point) that potentially one of the “bundled” plugins migrations gets left unran in that table I referenced in the issue perhaps was my first thoughts. Let me know if I can offer any other outside help, every bug captured and squashed ='s a better application for all.

-Jeremy