Hello,
Can we use Kong as a service mesh and an API gateway at the same time ?
Cheers.
I’m waiting the same answers but anyone has responded. 
yeah, i am still waiting too !
Community member here. I have always thought of mesh vs api gateway as two different patterns realistically if implemented well.
-> = network hops
Gateway Model:
Client -> Kong(API Gateway) -> service1,service2,service3
And Kong could be fronting services 4-1000+ in the network too.
Mesh Model:
Client -> Kong(mesh side car to service 1)
Client -> Kong(mesh side car to service 2)
Client -> Kong(meshed side car to service3)
And the list goes on where Kong could be sitting meshed to other services those service1-3 are “in front” of.
Is there just some goal you both have of having Kong sidecar to some API services but also to still have the usability to reverse proxy to other api services not hosted on the same server Kong sits? From a technical perspective idk why it could not(I don’t think proxypass or DNS functionality just stops working when using Kong in a mesh), but you would have to wait for an official Kong dev to answer this as I am not sure if they engineered it in a way to do both @ same time. I think the best way would be give a quick test though. Run Kong as mesh and see if you can still also setup service+route pair and it act as a gateway.
1 Like
Can we use Kong as a service mesh and an API gateway at the same time?
Yes, absolutely. Kong nodes in a same cluster form a service mesh when they communicate over tls streams or https (in service mesh you usually have 4 parties communicating: Service A → Sidecar Kong A → tls/https → Sidecar Kong B → Service B). Kong nodes will automatically do mutual tls in such scenario. TLS is a requirement for Kong service mesh. Whether it is a mesh or not is determined runtime when connections are made. We support gradual deployment of a service mesh. Each Kong node can be ingress, egress, sidecar, and api gateway at the same time.
Service mesh is usually deployed using an orchestration platform/tooling, e.g. Kubernetes, that may apply some constraints or additional patterns on how things should work (and how/where should they be managed), we try hard to integrate on those and make the experience as painless as it can be, though there are some rough edges still.
2 Likes
so to sum up, Kong is used as an API Gateway and a Service Mesh at the same time, meaning that no matter how you use it, it’s up and running , and the only condition to that is to have those sidecars injected in the targeted pods . right ?
Yes, and we provide a plugin for injecting sidecars automatically on Kubernetes:
Edit: the plugin will be bundled with Kong 1.1 (if running 1.0.3, you can install it manually). We are releasing 1.1rc2 today/tomorrow.
1 Like
Very impatient to test the kong sidecar auto injection mecanism ! with this kong become a full fledged API Platform, from the edge to the core !!
thank you.