Linkerd Goes on a Diet with Opt-In Extensions
Buoyant has released version 2.10 of Linkerd open source service mesh, a release that comes in at 300MB less than its previous version. The newly-trimmed release doesn’t come at the expense of features, but rather the addition of extensions, with several, previously default tools now being offered as opt-in extensions instead.
“Linkerd is already the fastest, smallest service mesh that’s out there, but we’re taking that a step further and making the default installation the bare minimum you need to have a service mesh function. Everything else that’s not strictly necessary is packaged up as these opt-in extensions,” said William Morgan, CEO of Buoyant, the company behind Linkerd, in an interview. “An extension is basically a Kubernetes controller or operator. We’re relying as much as possible on Kubernetes primitives, but what we are doing is, there’s a little bit of wrapper magic that happens that makes those extensions feel like the rest of Linkerd.”
Among those formerly-default features now being offered as extensions are the multicluster extension, which contains cross-cluster communications tools, the Jaeger distributed tracing collector and user interface extension, and a visualization extension containing the on-cluster metrics stack, which consists of Grafana, the dashboard, Prometheus, and more. While saving 300MB of memory is good for precisely that, Morgan also said that the overhead of running Prometheus was unnecessary for some users, and also a point of difficulty when it comes to scaling.
“That Prometheus component is the thing that scales the most aggressively as your cluster takes traffic. So if you have a very large cluster with a lot of traffic, that’s kind of the most operationally difficult part of the cluster to manage,” said Morgan. “A lot of Linkerd adopters are running their own Prometheus-based metric stack anyways, so there’s not always a reason to have these on-cluster Prometheus.”
Whenever we talk about operational size in this context, the idea of running on the edge often surfaces, and Morgan said that, again, the removal of Prometheus “will only ease adoption of the edge.” Extensions are not solely about removing defaults and slimming down operational size, however, and Morgan said that he hopes that the Kubernetes ecosystem will join in.
“It’s great to remove things from the default installation and have this really minimalist feature set, but we also want to allow third parties to be able to build extensions without having to get their hands dirty with the core Linkerd CLI. So, if you build a Linkerd extension, you’re really just building on top of existing Kubernetes primitives, and Linkerd will just make it feel like the rest of the Linkerd experience,” said Morgan.
“Linkerd exists in this very rich ecosystem of Kubernetes things, and many of those things kind of make sense to use in conjunction with Linkerd. So what I’m hoping is, we’ll see things like Ingress Controllers, like Gatekeeper, things that people often use with Linkerd, that will also become Linkerd extensions. And then you have this very nice ability to deploy these things in a way that’s pre-configured to work with Linkerd.”
One extension Linkerd users can look forward to is the in-house offering from Buoyant, what Morgan referred to as the “beta Buoyant extension”, that will make it easy to integrate Linkerd with Buoyant Cloud, the company’s hosted Linkerd dashboard.
In addition to extensions, Linkerd 2.10 also extends a feature introduced in 2.9, which enabled default mTLS for all TCP connections. Linkerd 2.10 now extends this to all TCP connections across clusters, meaning Linkerd can securely connect Kubernetes services across cluster boundaries. Along the same lines, Linkerd 2.10 adds an opaque ports feature, which enables Linkerd to provide mTLS for all TCP traffic. For example, if you are running an unencrypted MySQL, you might bypass the Linkerd proxy. With opaque ports, you don’t need to bypass Linkerd, and now Linkerd can provide mTLS, as well as other functionality, such as TCP-level metrics.
Kong Mesh 1.2 Adds OPA, FIPS Support
In other service mesh news, Kong Mesh 1.2 is out with a similar focus on adding new security features. Built on the open source Kuma universal control plane for service mesh based on Envoy, Kong Mesh 1.2 adds support for the Federal Information Processing Standards (FIPS), multi-zone security, and native integration of Open Policy Agent (OPA), which Kong CTO Marco Palladino says OPA use on Kong Mesh dramatically compared to other service meshes.
“Kong Mesh is the first and only service mesh that provides a native support of OPA built-in within the service mesh itself. In order to use OPA in other service meshes, the user needs to deploy an additional sidecar proxy with the OPA agent alongside every service and in addition to the service mesh sidecar proxy. Then, the user needs to write the OPA policies and store them somewhere so they can be parsed. Finally, if used in a service mesh spanning across multiple clusters, the user needed to distribute the OPA policies across every cluster, cloud or zone that the service mesh supported,” wrote Palladino in an email. “With Kong Mesh, none of this is required anymore (well, except writing the Rego policy that needs to be enforced).”
As for FIPS support, this appears to be a trend among service mesh feature additions lately, with both Tetrate’s GetIstio project and Solo.io’s Gloo Mesh Enterprise both adding support for the standards last month. Palladino puts FIPS support in much the same category as OPA, noting that it can be difficult to deploy.
“Today FIPS is not enabled by default in Envoy, and as such, it is painful to deploy, especially across an enterprise organization where multiple platforms (Kubernetes, VMs, etc.), clouds and operating systems are running. With this new release, Kong Mesh accelerates security compliance by bundling FIPS support in every data plane proxy across all the distributions we support, with no action required by the user,” wrote Palladino. “By default, implementing Kong Mesh 1.2 means that we are deploying a FIPS-enabled service mesh to accelerate security and compliance across every environment Kong Mesh supports. Like with OPA, this makes Kong Mesh 1.2 the easiest way to accelerate FIPS compliance across the organization.”
