
Kong gateway reaches 1.0 GA, now supports service mesh - hisham_hm
https://konghq.com/blog/kong-1-0-ga/
======
wavesquid
Hi all,

I was the lead developer on the service mesh implementation. I've just pushed
[https://github.com/Kong/kubernetes-sidecar-
injector](https://github.com/Kong/kubernetes-sidecar-injector) public, which
should make deploying kong a service mesh simple on kubernetes.

Let me know if you have any questions, I'll try and check over the next few
days.

~~~
vijaykodam
I see that your Kong service mesh using nginx as the underlying proxy. Are
there any plans to use Envoy proxy in future? Currently Istio and Linkerd2 are
based on Envoy. Unlike nginx, envoy doesnt have an enterprise version where
some enterprise features are held off. Also envoy has very good observability
and traffic management features.

~~~
rdli
Curious to see if Kong can do true hitless reloads without proxy restart.
Envoy can do this but I thought only NGINX Plus has this capability?

~~~
p0pr0ck5
Yes, Kong's entity configuration (including upstream services) are managed via
the runtime, not via reading a config file. This allows for updating proxy
configuration without restarting the process itself, allowing for zero-
downtime config changes.

------
jklepatch
I used Kong in a project recently. Very bare-bones, You need to build your own
client for it. Overall, it felt like a blackbox where things magically
happened. Totally hated it.

~~~
fosk
Hello, CTO of Kong here. You mean a client to consume the Admin API in order
to create entities on Kong? If that's the case the community has built lots of
open source clients in pretty much any language that would make the job of
integrating Kong within an existing system much easier. The community around
Kong has also built declarative configuration support that you can use instead
of the Admin API.

Our official declarative configuration will also be released very soon, and in
some environments (like Kubernetes) we already support it.

~~~
vaseem
I am surprised you did not try to upsell Enterprise version

~~~
fosk
It is a community product first and foremost with a plugin framework that
allows for extensibility with access to the full core API.

You can discuss with the community online [1], or meet a core contributor at
one of the community meetups or in the monthly community call that we usually
announce on Discuss.

[1] [https://github.com/Mashape/kong](https://github.com/Mashape/kong) or
[https://discuss.konghq.com/](https://discuss.konghq.com/)

------
aloisbarreras
Great work guys! I see that "Kong’s core router can now route raw TCP
traffic."

Can you elaborate? What kinds of routing parameters and rules can Kong use to
route raw TCP traffic?

~~~
hisham_hm
You can define a route to be either L7 ("http", "https") or L4 ("tcp", "tls").
For L7 routes you can use the usual routing parameters that were already
available in Kong, like routing by host, by paths (prefix or regex-based)
and/or by method. For stream routing, you can route by IP source port, IP
destination port and/or by SNI in the case of TLS connections.

------
philip1209
Congrats! I worked for Kong's VP of Engineering a couple of years ago at
OpenDNS. He's one of the best managers I've seen.

~~~
justicezyx
What would be the relevancy to this news?

And could you name a few traits of this person that make him/her stand out?

------
itmeyou
So I admittedly don't know much about this stuff, but what would be the
difference between using Kong and the Nginx ingress controller? What
advantages/improvements would I see/be able to use?

~~~
mikejulietbravo
Kong's K8s Ingress Controller lets you configure and run plugins (custom code)
on your proxy traffic. This gives you a lot of power on how you’d like to
route, authenticate, shape your traffic.

Nginx gives you the ability to tweak functionality, but it's not as dynamic or
as easy out of the box.

~~~
merlincorey
> Nginx gives you the ability to tweak functionality, but it's not as dynamic
> or as easy out of the box.

NginX supports Lua and Javascript embedded and out of the box on many
distributions.

~~~
vorpalhex
That is through a set of additional plugins. Kong uses that base and ships
with mature implementing plugins including a robust RESTful API for managing
config.

~~~
merlincorey
> That is through a set of additional plugins.

Which are compiled and enabled in several distribution packages.

------
nphase
How does Kong compare to Tyk?

~~~
jively
(Caveat: I’m the CEO of Tyk)

Tyk offers a more “batteries included” approach to Kong, and so doesn’t rely
on external plugin authors to extend the ecosystem. 100% of our dev team are
constantly working on our open source components and we like to keep it that
way.

Because of that, Tyk isn’t “open core” like Kong is, there’s no lock-in or
levers to get you to buy our value-adds like our Management Dashboard GUI or
our Multi-Data-Center clustering add-on - you should be able to do _all API
Management_ without having to pay us a penny.

A simple example is OpenID connect support, this is a Kong enterprise plugin,
with Tyk that comes as part of the normal gateway.

In terms of performance Tyk and Kong are pretty close now (Tyk pre 2.6 was
slower) but we believe we now have parity, especially when switching on things
like analytics, auth and rate limiting.

Tyk works very well in k8s though we don’t have a helm chart yet (coming
soon).

You can also deploy Tyk as pure SaaS (fully managed), hybrid cloud (we handle
back-end and control plane, you install gateways local to services) and full
on-prem (install anywhere: K8s, AWS, GCP, Azure - even on Arm servers). We’re
unique in that regard.

Tyk has always been separated into control-plane and operations-level
components (our gatewaybis very small), so we don’t see that as something new
to crow about. If you use our Dashboard, it moves the configuration and data
layer out of the gateways and moves it centrally. If you use our MDCB system
(enterprise) you can extend that capability across clusters in different
clouds to get really targeted, distributed API governance.

There’s a bunch of other things that are different too, but they are more
functional.

~~~
hartror
> you should be able to do all API Management without having to pay us a
> penny.

I contacted Kong sales once about OpenID connect support, they basically
dismissed us as too small. Needless to say we took Kong out of our stack and
won't consider it again.

~~~
graphememes
That's unfortunate, there is a good open source one that I have used and works
well. The enterprise one is definitely more verbose but the open source one
works well!

------
hrrsppd
How does 1.0 handle database migrations?

~~~
yolo42
Kong runs at a critical point in any infrastructure. Having any sort of
downtime is usually unacceptable.

To avoid downtime due to Kong upgrades, Kong now supports a blue-green
deployment method where for two Kong nodes of version A and version A+1 can
run together at the same time as the upgrade is being rolled out, and then
switching all traffic to A+1.

------
Supermighty
What would be the best way to deploy this with my application in Kubernetes?

~~~
yolo42
There are a few options to deploy Kong as your API Gateway:

Kong can work as an Ingress Controller for your Kubernetes cluster and run
plugins for your traffic at the Ingress layer. Refere to the repo for more
details: [https://github.com/kong/kubernetes-ingress-
controller](https://github.com/kong/kubernetes-ingress-controller)

You can simply deploy it as an application using the Helm chart:
[https://github.com/helm/charts/tree/master/stable/kong](https://github.com/helm/charts/tree/master/stable/kong)

------
pidginbil
I’ll need to give it a try.

------
scorn4sega
Great news! Thanks for sharing.

