Service Mesh
Objectives
- retry
- timeout
- security, mutual TLS
- observability
- and more...
Actual landscape
How it works
admission controller with policy → side-car injection! a container is inserted int every single pod.
- Istio (Google) : Istio trademarks were donated to the Open Usage Commons. Injects an Envoy proxy in every pod.
- Linkerd (CNCF project) lightweigh, minimized, service mesh
- Consul (HashiCorp) : GA for managed-Consul on AKS -- fully configured for "production".
- Open Service Mesh (Microsoft) : based on the popular and powerful Envoy proxy
https://www.solo.io/products/webassembly-hub/
Customize Envoy Proxy with WebAssembly
Simply and securely extend Envoy Proxy, Gloo API gateway and Istio service mesh with a Wasm module in the language of your choice.
Cilium and eBPF as a game changer ?
https://cilium.io
"Cilium is an open source software for providing, securing and observing network connectivity between container workloads - cloud native, and fueled by the revolutionary Kernel technology eBPF."
Today, popular service mesh such as Linkerd and Istio are using sidecar. For instance Istio is using the popular Envoy proxy. The drawback of this approach is that it adds a lot of ressources (one sidecar per pod !) which is... bad.
eBPF is a new approach in order to do the same without sidecars. And cilium is a service mesh that implements this approch. It provides as well Hubble, a nice interface for observability.
Take aways
- eBPF may be a game changer
- keep an eye on Cilium... and its policy engine
- Cilim is not only a service mesh... but this is what it is known to be