|
|
|
|
|
by lycidas
2400 days ago
|
|
At my company, we were migrating all our apps to a kubernetes + istio platform over the past couple of months and my advice is this - don't use a service mesh unless you really, really need to. We initially choose istio because it seemed to satisfy all our requirements and more - mTLS, sidecar authz, etc - but configuring it turned out to be a huge pain. Things like crafting a non-superadmin pod security policy for it, trying to upgrade versions via helm, and trying to debug authz policies took up a non-trivial amount of time. In the end, we got everything working but I probably wouldn't recommend it again. It's funny that I was at kubecon last week and there was a start up whose value prop was hassle-free istio and the linkerd people stressed that they were less complex than istio. |
|
Istio may appear more complex but that's because it has a superior abstraction model and supports greater flexibility. We're beginning to migrate from Linkerd to Istio at this point. I had the same initial frustrations with podsecuritypolicy (and linkerd suffers from the same), but istio-cni solves the superuser problem, and I believe even the istio control plane is now much more locked down in the latest release.
However if I had my way I would be telling every team they don't need service mesh. We don't have any particular service large and complex enough to really take advantage of its sold features.