Maesh, a Lightweight and Simpler Service Mesh(blog.containo.us)
blog.containo.us
Maesh, a Lightweight and Simpler Service Mesh
https://blog.containo.us/announcing-maesh-a-lightweight-and-simpler-service-mesh-made-by-the-traefik-team-cb866edc6f29
22 comments
This looks interesting, but it's not clear to me if this supports TLS traffic to the daemon-set nodes running on each individual node. A key thing that I am looking at meshes for are last mile TLS encryption, with a appropriate sidecar.
We think that it is interesting to have an alternative with a simpler design bringing almost all features. So yes, mTLS between pods is not supported. But it's a decent tradeoff for many users. Finally, mTLS could be supported in the future between nodes :)
This is one of the several reasons Linkerd moved from per-host to sidecars.
For mTLS, the moment you want to have identity per service (as opposed to one cert across everything in the mesh), you need the security boundary to be at the pod level.
For mTLS, the moment you want to have identity per service (as opposed to one cert across everything in the mesh), you need the security boundary to be at the pod level.
Is it like running Istio-ingressgateway only, without mesh expansion and sidecar injection? It looks simpler than Istio, but I'm on mobile and will try Maesh on a test cluster later.
So glad to see this supports SMI. That makes introduction of these new implementations much more digestible
Thanks! We deeply believe that the best infrastructure products are open and free from vendor lock-in.
Being compliant to SMI will make both Maesh and the specifications stronger.
I'd love to see a comparison between Maesh and Linkerd v1 -- sidecar-based meshes like Istio (AKA coordinated envoy) and API gateways like Kong are not direct competitors with Maesh, Linkerd v1 is.
Is Maesh a newer imagining of what Linkerd v1 sought to do? Is it a better k8s-integrated solution?
Is Maesh a newer imagining of what Linkerd v1 sought to do? Is it a better k8s-integrated solution?
At first glance the difference is proxy on the node and not per pod. It is also K8s centric where L5d is easier compatible and has way more more powerful configuration options and runs on vms as well.
I would say that L5d 2.0 would be the direct competitor. They are both: small, simple, opt-in, K8s centric, and support SMI.
I would say that L5d 2.0 would be the direct competitor. They are both: small, simple, opt-in, K8s centric, and support SMI.
I think you compared it to linkerd v2 (formerly known as Conduit) -- Linkerd v1 was used primarily per-node though it was also capable of per-pod...
l5d v1 is the direct competitor, but is just theoretically lacking k8s integration, though it actually is usable with k8s, I've written about it on my tiny tiny k8s cluster.
Basically what I'm wondering is how much better the integration is for Maesh
[0]: https://vadosware.io/post/up-and-running-with-linkerd-v1/
l5d v1 is the direct competitor, but is just theoretically lacking k8s integration, though it actually is usable with k8s, I've written about it on my tiny tiny k8s cluster.
Basically what I'm wondering is how much better the integration is for Maesh
[0]: https://vadosware.io/post/up-and-running-with-linkerd-v1/
I wonder if this will work along iwth Consul Connect (another service mesh), or if this is an alternative to it.
https://www.consul.io/docs/connect/index.html
I wish more open-source products would write semi-neutral explanations of what their project is, isn't and how it compares to some similar services.
For example, I think Kubernetes does a pretty good job of explaining what it isn't.
https://kubernetes.io/docs/concepts/overview/what-is-kuberne...
https://www.consul.io/docs/connect/index.html
I wish more open-source products would write semi-neutral explanations of what their project is, isn't and how it compares to some similar services.
For example, I think Kubernetes does a pretty good job of explaining what it isn't.
https://kubernetes.io/docs/concepts/overview/what-is-kuberne...
This looks like an interesting off the shelf alternative to Envoy, which currently requires you to implement your own control plane. Moving forward, is this going to be open-core with a paid EE edition type of thing like Traefik?
There are multiple control planes for Envoy (e.g. Istio) already; I wouldn't punish them for modularity.
So API gateways are becoming Services Meshes and Service Meshes are becoming API gateways. Have we reached critical mass on number of solutions? Will they start to consolidate?
"Service Mesh" seems to designate a Kubernetes-specific terminology, for those, like me, who wondered what the title was about.
Kubernetes is a container orchestration platform, AKA a way to deploy software on servers. If all of this sounds complex, it is, as it's Google-scale.
Kubernetes is a container orchestration platform, AKA a way to deploy software on servers. If all of this sounds complex, it is, as it's Google-scale.
From the description, and given who developed it, is this basically a way to run a Traefik instance per node and have the instance dynamically configure itself using the Kubernetes API? Or is there more to it?
Kudos for the traefik team. I've just started to use it an is amazing.
Ooh. I look forward to deploying this on Iron Arachne's stack.
What is up with these names? For a moment I felt either dyslexic or like I’m experiencing a stroke.
Whæt's wröng?
Is there anything similar that works with Docker Swarm?
Should work on OpenShift too right?
Using Traefik for more than a year now, working like a charm.
I wonder if SO_KEEPALIVE is implemented ? I ask this because we have funny devs that don't know how to implement SO_KEEPALIVE on springboot projects correctly. That can be annoying for an Operation Team....