Alek's Blog - networking

Istio vs. Linkerd: Service Mesh on Kubernetes

aleks — Tue, 12 May 2026 00:00:00 +0000

Both Istio</a> and Linkerd</a> are CNCF Graduated service meshes that provide automatic mTLS, traffic policy, and observability for Kubernetes workloads. Both run in sidecar mode for this comparison — a proxy container injected into every pod. The fundamental difference is the data plane: Istio uses Envoy</a>, Linkerd uses its own Rust-based proxy (linkerd2-proxy</code></a>). That choice drives the differences in overhead, extensibility, and egress control.</p>

This post compares them on the dimensions that matter for a production deployment. For the broader question of Istio vs. Envoy Gateway (ingress-only), ambient mode, and managed cloud specifics (AKS, GKE, OVH MKS), see the companion postIstio vs. Envoy Gateway: Gateway API on Kubernetes</a>.</p>



Istio vs. Envoy Gateway: Gateway API on Kubernetes
aleks — Thu, 30 Apr 2026 00:00:00 +0000
Both Istio</a> and Envoy Gateway</a> implement the
Kubernetes Gateway API</a> and use Envoy as their data plane.
That is roughly where the similarity ends. Istio is a full service mesh that happens to
implement Gateway API; Envoy Gateway is a dedicated Gateway API controller with no mesh
ambitions. Choosing between them is mostly a question of scope.</p>
This post starts with that comparison — architecture, mTLS, egress control, and resource
overhead — then broadens to cover Cilium</a> as a lighter alternative for
East-West security, how the choice plays out on managed Kubernetes offerings (AKS, GKE, and
OVH MKS including their cloud-native ingress and egress options), and finally how to get
the real client IP through a cloud load balancer to your application.</p>


Envoy Gateway v1.7: Global Rate Limiting with a Custom ratelimit Service
aleks — Sun, 19 Apr 2026 00:00:00 +0000
Global rate limiting in Envoy Gateway (EG)</a> can be set up in two ways:
the easy path (EG manages its own envoy-ratelimit</code> container) and the flexible path
(you bring your own envoyproxy/ratelimit</a> service).
This post covers the flexible path — Option B</strong> — and documents the three xDS patches
required to wire it up, the EG v1.7 breaking changes that affect the approach,
and a namespace-admin self-service deployment model.</p>


haproxy-spoe-rs: Deployment
aleks — Sun, 12 Apr 2026 00:00:00 +0000
This post covers deploying the haproxy-spoe-rs</a>
SPOA agent in production. It is a companion to the
architecture post</a> which explains the library design.</p>
The agent and HAProxy run as separate services</strong> — HAProxy connects to the agent over TCP.
This keeps their lifecycles independent and allows scaling each side separately.</p>


haproxy-spoe-rs: A Rust SPOA Agent Library for HAProxy
aleks — Sun, 12 Apr 2026 00:00:00 +0000
haproxy-spoe-rs</a> is a Rust library for writing
HAProxy SPOE</a> agents. This post
covers what SPOE is, the design decisions behind the library, and how its throughput compares
to the Go reference implementation.</p>


Running pdns_recursor as a root-independent validating resolver
aleks — Mon, 06 Apr 2026 00:00:00 +0000
PowerDNS Recursor</a> is a mature, production-grade recursive DNS resolver. This post documents how to configure it to bootstrap directly from a local root.zone</code> file — so it never needs to reach the root name servers at runtime — with full DNSSEC validation producing the ad</code> flag in responses.</p>


Running a validating DNS recursor from the root zone with Hickory DNS
aleks — Sat, 04 Apr 2026 00:00:00 +0000
Hickory DNS</a> is a Rust-based DNS implementation that covers the full stack: resolver, recursor, authoritative server, and DNSSEC. This post documents how to run it as a full recursive resolver</strong> — starting directly from the root zone, with DNSSEC validation and encrypted upstream transport — based on the changes developed in the recurser-from-root-zone</code></a> branch.</p>


tls-proxy-tunnel: Transparent TLS Tunnelling Through Corporate HTTP Proxies
aleks — Tue, 02 Jul 2024 00:00:00 +0000
Many enterprise networks sit behind a corporate HTTP CONNECT proxy. Applications
that speak TLS natively — think git</code>, curl</code>, SSH-over-HTTPS, or any custom
binary — often have no built-in proxy support. Configuring every single tool is
tedious, fragile, and sometimes impossible when you don’t control the binary.</p>
tls-proxy-tunnel</code> (tpt</code>) solves this at layer 4: it sits between your
application and the outside world, intercepts the TLS connection, extracts the
Server Name Indication (SNI) from the ClientHello, and tunnels the raw bytes
through your corporate HTTP CONNECT proxy — without ever terminating TLS.</p>


How does SNI Routing work in HAProxy
aleks — Fri, 17 May 2019 00:00:00 +0000
As I travel a lot I faced the problem that in some Wi-Fi networks certain ports are blocked for outgoing communication 😱. The solution is to use software that can handle TCP and HTTP via port 443</strong> so that I can use my Nextcloud and my XMPP client on the same port.</p>