4 ms·
I am seeing more and more users wanting to implement end-to-end connectivity from GW to service mesh. Particularly when it comes to Kong, we have done all the h
by fosk 6y ago
I am seeing more and more users wanting to implement end-to-end connectivity from GW to service mesh. Particularly when it comes to Kong, we have done all the heavy lifting in Kong[1] + Kuma[2] (the latter a CNCF project) to do that.
Typically we want to create a service mesh overlay across our applications and their services - to secure and observe the underlying service traffic - and still expose a subset of those via an API GW (and via an Ingress Controller) at the edge, to either mobile applications or an ecosystem of partners (where a sidecar pattern model is not feasible).
With Kuma and its "gateway" data plane proxy mode, this can be easily achieved via the Kong Ingress Controller, which is mentioned in this spreadsheet.
Disclaimer: I am a maintainer of both Kong and Kuma.
[1] - https://github.com/Kong/kong https://github.com/Kong/kong
[2] - https://github.com/kumahq/kuma https://github.com/kumahq/kuma
- tn890 6y agoWould you recommend taking this to production as an Istio replacement? What are the downsides? I couldn't find a good comparison like the one in OP about ingress controllers.
- fosk 6y agoThis setup has been running in production in mission critical use-cases already, and unlike Istio, it provides fully automated multi-zone support across both Kubernetes and VM environments on both the CP and DP. If you have questions, you can always reach out at https://kuma.io/community https://kuma.io/community