Bouyant Extends Reach and Scope of Linkerd Service Mesh
Bouyant has added IPv6 support along with an ability to more easily review audit zero-trust security policies before they are enforced by the open-source Linkerd service mesh.
In addition, Bouyant has reimplanted the retries, timeouts and per-route metrics for HTTPRoute and GPRCRoute resources in version 2.16 of the lightweight service mesh for Kubernetes environments.
Linkerd 2.16 also adds an ability to HTTP/2 keep-alive messages by default for all meshed communication and all HTTP headers are no longer logged in debug or trace output by default, unless explicitly enabled, to prevent leakage of sensitive data.
All Linkerd command line interface (CLI) output for Kubernetes resources also now support JSON output.
Finally, Bouyant is adding two automations to make it simpler to integrate external workloads running on, for example, a virtual machine and a command line interface (CLI) tool to improve remote debugging and support to the Buoyant Enterprise for Linkerd (BEL) edition of the service mesh.
Bouyant CEO William Morgan said that as Linkerd approaches its tenth anniversary the time was especially ripe to revamp retries and timeouts in a way that is more consistent with other composable elements, such as circuit breaking, that use the Gateway application programming interface (API) for configuration.
As a result, requests that time out can now be retried and retries and timeouts can now be combined with circuit breaking. That capability makes it easier for IT teams to capture granular per-route success rates, latencies, request volumes and other metrics without changing any application code.
The Gateway API, defined by the Technical Oversight Committee (TOC), is rapidly becoming the default mechanism for invoking a range of services, noted Morgan. That’s critical because it helps ensure that technology investments made today will have to stand the test of time at a time when responsibility for managing Kubernetes environments are being assumed by platform engineering teams using best DevOps practices to manage applications at scale, he added.
The overall goal is to reduce the level of technical debt these teams might otherwise have to manage by standardizing on the Gateway API, he added.
Next up, Bouyant in a forthcoming Linkerd 2.17 release will be in addition to using that API to observe egress in addition to ingress, he added. IT organizations that already rely on Linkerd to manage ingress also want to be able to observe traffic as it exits a cluster, said Morgan.
It’s not clear how many IT organizations have adopted service meshes to better manage network traffic flowing between APIs but as the number of Kubernetes clusters running in production environments continues to increase so too do the number of microservices-based applications that are constructed using APIs. It’s only a matter of time before the number of those APIs overwhelms the capabilities of proxy software or legacy API gateways, noted Morgan.
There are, of course, multiple options when it comes to service meshes that can run on top of Kubernetes. The challenge and the opportunity now is determining not just which one to adopt, but also how best to manage a service mesh for the long cloud-native haul ahead.
