Buoyant

Adding Linkerd's proxy metrics to an existing OTel Collector pipeline is one config change and a namespace annotation. The proxy emits golden metrics for every east-west request between meshed services: success rate, latency, and the mTLS identity of the caller on every series. No SDK calls, no image rebuilds. Annotate a namespace, roll the deployments, and every pod goes from 1/1 to 2/2. The second container starts emitting immediately. Mesut Oezdil, DevOps Engineer at Adfinis, wrote a 2026 reference post on the Buoyant blog walking through the integration pattern and how both layers complement each other. OTel instruments your code: business events, custom dimensions, and distributed traces. Linkerd instruments your network: service-to-service traffic with cryptographic caller identity and gRPC status codes that HTTP alone won't surface. If you're running OTel today, you have the application layer covered. The mesh layer adds the network's view of the same traffic, tagged with who called whom, at no instrumentation cost to your teams. Read the full blog post: https://hubs.ly/Q04k_DRS0  #Linkerd #OpenTelemetry #Kubernetes #Observability

Your CI pipeline is a bad place to run tests, but it's where everyone puts them by default. Testkube's Ole Lensmar made that case on our latest The AI Kubernetes Show episode. Pull test execution out of CI/CD and run it as Kubernetes Jobs instead. Everything gets containerized and runs as a Job on the cluster. Decoupling test execution means a run can be triggered by more than a commit. A GitOps event from Argo or Flux, a progressive delivery rollout, or a production signal can kick one off, too. That matters for shift-left and shift-right testing. Some tests need to run before merge, others need to run against real production traffic, and a pipeline-only model can't do both well. Tune into the full conversation: https://hubs.ly/Q04p6pDN0 #Kubernetes #CICD #PlatformEngineering #AIKubernetesShow #CloudNative

Live this week! 👇

Kubernetes does not have gRPC native load balancing. Applications that rely on gRPC streaming will result in long-lived TCP connections that are not load balanced and pinned to a specific pod. This leaves SRE teams implementing client-side retry logic and implementing their own load balancing. However, gRPC and Kubernetes underpin the majority of modern cloud applications as we know it. We ran 700 benchmark tests across 2.5 billion gRPC requests to see how vanilla Kubernetes and different service meshes actually handle a degraded pod.  Read the full benchmarking report: https://hubs.ly/Q04pvQp40 #Kubernetes #Linkerd #gRPC #Istio #Cilium #ServiceMesh #CloudNative

Making sure all your microservices are FIPS-compliant can be the kind of project that swallows an engineering team's bandwidth without shipping a single product feature. A FIPS-validated service mesh can handle the data-in-transit piece. Each pod gets a sidecar proxy, and the proxy handles mTLS between services using validated cryptographic modules, so your application code and its dependencies don't change. Buoyant Enterprise for Linkerd (BEL) is a FIPS-validated mesh with Rust-based sidecar microproxies. Rust cuts down on the memory safety bugs that show up in C++ based proxies, and BEL can generate an SBOM (Software Bill of Materials) to hand an auditor. Here's how it works: Install the CLI, spin up a cluster, apply the Gateway API CRDs, run ‘linkerd install’, and check the dashboard to confirm the FIPS-compliant modules are actually running. But note, this covers data in transit. Data at rest still needs its own FIPS-validated encryption and key management. Read the full blog post to learn about: ✦ The difference between FIPS 140-2 and 140-3 ✦ Which Kubernetes components touch sensitive data ✦ The add-ons people forget ✦ and much more ☞ https://hubs.ly/Q04p6tdd0  #Kubernetes #Linkerd #FIPS #ServiceMesh #FedRAMP

On-call gets paged for slowness, but frontend's success rate reads 100%. Nothing to see, right? Mesut Oezdil, DevOps engineer and OSS contributor, ran this scenario on a live cluster. A stress --cpu 8 pod pushed node CPU from 43% to 100%. Frontend's success rate never moved, but RPS dropped from 255 to 174, p95 went from 160ms to 197ms, and p99 climbed from 196ms to 288ms, a 47% jump. RED tells you the service is hurting, but not why. USE metrics, like node CPU and pod CPU throttle ratio, closed that gap. The mesh makes RED nearly free. Linkerd's kerd's proxy emits response_total and response_latency_ms_bucket per pod with zero app instrumentation. But bring your own Prometheus and you'll hit two real gotchas. Scrape traffic on port 4191 inflated our Rate panel by 25% until we excluded it, and queries grouped by deployment returned nothing until we mapped the linkerd_io_proxy_deployment annotation to a label. Check out the full writeup:https://hubs.ly/Q04nv0Ll0 #OpenSource #Kubernetes #Linkerd #Prometheus #SRE

Your team can get service mesh-certified for free. Service Mesh 101 is 6 hands-on labs: Linkerd deployment, mTLS, golden metrics, reliability features. Self-paced, no time commitment, certificate on completion. Good option before a service mesh evaluation or migration. → https://hubs.ly/Q04kJR8f0  #Linkerd #Kubernetes #PlatformEngineering