-
Notifications
You must be signed in to change notification settings - Fork 3
Networking trade off
This trade-off aims at defining the most suited networking components for the Reference System platform's infrastructure.
The comparisons below address the Ingress Controller and Service Mesh choice.
- Management of incoming web traffic, including certificates and TLS management, with high availability
- Protection/security of http/https endpoints
- Routing traffic to services, with Single Sign On
- Strong and native connection with IAM services, including management of authorizations
- Sending metrics to be monitored
- Open source solution
| HTTP | HTTPS | High Availability | Native OpenID Connect integration | Metrics | Open Source | |
|---|---|---|---|---|---|---|
| Apache APISIX | ☑ | ☑ | ☑ | ☑ | ☑ | ☑ |
| Istio Ingress | ☑ | ☑ | ☑ | ☐1 | ☑ | ☑ |
| Kong | ☑ | ☑ | ☑ | ☐2 | ☑ | ☑ |
| NGINX Ingress | ☑ | ☑ | ☑ | ☐1 | ☑ | ☑ |
| Traefik proxy | ☑ | ☑ | ☑ | ☐3 | ☑ | ☑ |
1 Not natively but can be extended with oauth2-proxy.
2 Only supported with enterprise/commercial version.
3 Only supported with enterprise/commercial version but can integrate oauth2-proxy through ForwardAuth.
All the solutions are sufficient for Reference System.
We prefer APISIX for the OpenID Connect plugin natively supported.
- Kubernetes Ingress Controllers, learnk8s.io.
- Apache APISIX documentation.
- Istio Ingress documentation.
- Kong documentation.
- NGINX Ingress Controller documentation.
- Traefik documentation.
- Capacity to display communication exchanges between services
- Block/unblock traffic between services
- Sending metrics to be monitored
- Open source solution
| Control traffic | Display exchanges | High Availability | Metrics | Ideal Ingress Controller | Sidecar | Resources overhead | Egress | Open Source | Support | |
|---|---|---|---|---|---|---|---|---|---|---|
| Istio | ☑ | ☑1 | ☑ | ☑ | Istio Ingress | Envoy | Performance & scalability | ☑ | ☑ | Google, IBM |
| Kuma | ☑ | ☑ | ☑ | ☑ | Kong Ingress | Envoy | ☐ | ☑2 | CNCF sandbox, developed by Kong | |
| Linkerd | ☑ | ☑ | ☑ | ☑ | Any | Linkerd2 proxy | Benchmarks | ☑ | ☑ | CNCF graduated, developed by Buoyant |
| NGINX Service Mesh | ☑ | ☐ | ☑ | ☑ | NGINX Ingress Controller | NGINX+ | ☑ | ☐ | F5 | |
| Traefik Mesh | ☑ | ☐ | ☐3 | ☑ | Traefik proxy | None Node pod proxy |
☐ | ☑ | Traefik Labs |
1 Rely on Kiali dashboard.
2 Enterprise grade with Kong Mesh.
3 Only supported with enterprise/commercial version.
NGINX Service Mesh require a enterprise grade subscription. Hence, it does not meet the conditions of Reference System.
Istio and Linkerd are the two most mature solutions as they both already proved themselves in production workflows. Istio became the most popular one thanks to the large feature set it provides plus its strong support. However, complexity is the cost for its flexibility. Moreover, the service mesh's need for this project are fairly basics.
On the other hand, Linkerd strength lies in its performances and its ease of use. It also come along interesting features like a service communication map or egress management.
We consider the ingress controller APISIX combined with Linkerd for Service Mesh as the best fit regarding Reference System infrastructure.