PagCat

In the world of Kubernetes, network policies are essential for controlling traffic within your cluster. But what are they really? And why, when and how should you implement them?

In Part I of this post, The trouble with Topology Aware Routing: Sacrificing reliability in the name of cost savings, I describe a Topology Aware Routing (TAR), a Kubernetes feature that restricts traffic within an availability zone from crossing to other zones. This feature is relevant to Kubernetes users deploying multi-zone clusters to the cloud, because it can cut cloud spend, sometimes dramatically. Cloud providers like AWS and Google charge for traffic across zones, and since Kubernetes balances traffic as evenly as possible, high-traffic clusters can rack up cross-zone traffic charges very quickly. By restricting traffic from crossing zone boundaries, TAR can cut this aspect of cloud spend.

But TAR is not without drawbacks: it can lead to worse overall system reliability. Because it restricts traffic from crossing zones, when it is enabled, the pods in one zone cannot be used to compensate for failures in other zones. In Part I, we saw an extreme example. I deployed a basic app running on a multi-zone cluster, induced a failure in one zone, and showed that with TAR enabled, application pods in the zone were unable to recover. Unable to reach functioning pods in other zones, the failure persisted and success rate in the zone dropped to 0, even though there were healthy pods elsewhere in the cluster.

If using TAR can reduce reliability, what does this mean for Kubernetes adopters who want the best of both worlds—minimal cloud costs and maximal reliability? In this post, I'll describe a way to accomplish exactly that. But first, we need to discuss the different ways things can fail.

Topology Aware Routing is a feature of Kubernetes that prevents cluster traffic within one availability zone from crossing to another availability zone. For high-traffic applications deployed in multi-zone clusters, this can provide significant cost savings: cloud providers can charge for traffic that crosses zone boundaries, and these costs can be expensive at scale...

I'm super excited to co-organize KubeCrash again. This conference will focus on Platform Engineering: Building the Ultimate Internal Developer Platform. We'll have keynotes by Spotify and NatWest, an end user panel with speakers from Boeing, Shutterstock, Adobe, and lots of amazing deep technical sessions.

I'm particularly excited that Rob Koch and Sandeep Kanabar will be presenting — two members of the CNCF Deaf & Hard of Hearing Working Group. And, as last time, we'll donate $1 for each registration to Deaf Kids Code.

Register today. It's virtual, free, and focused on open source!

Today we’re happy to announce the release of Linkerd 2.15, which adds support for workloads outside of Kubernetes. This new “mesh expansion” feature allows Linkerd users for the first time to bring applications running on VMs, physical machines, and other non-Kubernetes locations into the mesh, delivering Linkerd’s uniform layer of secure, reliable, and observable connectivity across both Kubernetes and non-Kubernetes workload alike.

I had so much fun writing this and learned so much from Flynn and Jason Morgan (thank you, for walking me through all the details!). I never thought about the sustainability angle. Linkerd has always focused on having the smallest possible footprint, so of course, that also means the smallest possible environmental impact.

I'm thrilled to see the CNCF TAG Environmental Sustainability is shining a light on this important issue, and so glad that Linkerd's design philosophy is fully aligned with its mission.

Check out my blog post to learn how Linkerd can help you reduce your environmental impact!

Every month at Buoyant's Service Mesh Academy, we dig into a Linkerd-related technical topic. In August, we covered the new multicluster functionality in Linkerd 2.14 and summarized in a blog post: curious what folks think!

Good news everyone, sidecars are cool again! The long-awaited merge of "sidecar KEP" in Kubernetes 1.28 officially introduces sidecars to the Kubernetes API and makes some major improvements to how they work.

In this post William Morgan walks you through everything you need to know: what sidecars are, what's good and what's bad about them, and what changes in Kubernetes 1.28—all from the perspective of a sidecar enthusiast and highly opinionated service mesh person.