Alek's Blog - istio

Istio AuthorizationPolicy & HTTP/2 Coalescing

aleks — Mon, 13 Jul 2026 00:00:00 +0000

Isolating an admin surface behind its own hostname and an IP-restricted Istio</a> AuthorizationPolicy</code> sounds like a Tuesday-afternoon change: add a second HTTPRoute</code>, add a DENY</code> policy with an allowlist, done. Two non-obvious Envoy behaviors turned it into a two-day debugging exercise instead — one in how AuthorizationPolicy</code> resolves “the client’s IP,” and one in how browsers reuse HTTP/2 connections across hostnames that share a certificate. Neither is specific to Keycloak or to this particular setup; both apply to any Istio or Envoy Gateway API ingress sitting behind a cloud load balancer with a shared wildcard certificate.</p>

This post walks through both bugs, how they were root-caused, and the fix for each — so the next person hitting either symptom can skip straight to the cause.</p>


LLM Inference on OVH MKS: Terraform, Ansible, and Deployment
aleks — Tue, 02 Jun 2026 00:00:00 +0000
Part 1</a> covered the architecture and use cases. This post walks through the complete Terraform and Ansible setup and a first deployment.</p>


LLM Inference on OVH MKS: The Complete Guide
aleks — Tue, 02 Jun 2026 00:00:00 +0000
This is the index and reading guide for a six-part series on self-hosting LLM inference on a
GPU-enabled Kubernetes node pool, using OVH Managed Kubernetes Service (MKS) as the concrete
platform throughout. The series runs end to end: the decision of whether to self-host at all,
provisioning the GPU infrastructure, serving a model behind an OpenAI-compatible API, wiring up
observability and autoscaling, connecting real client tools, and finally putting a multi-user
gateway in front of the whole thing.</p>


LLM Inference on OVH MKS: Introduction
aleks — Tue, 02 Jun 2026 00:00:00 +0000
This post covers the decision context for self-hosting LLM inference on OVH MKS: when it makes sense, what the stack looks like, and what the costs are. Part 2</a> walks through the Terraform and Ansible setup.</p>


SigNoz on OVH MKS: Access Log Reports with Vector and ClickHouse
aleks — Mon, 18 May 2026 00:00:00 +0000
Posts 1</a> and 2</a> of this series set up the SigNoz observability stack on OVH MKS and demonstrated metrics, traces, and Kubernetes pod log collection. This post adds a practical use case: structured Envoy access log collection via Vector, archiving to OVH Object Storage in Combined Log Format, and monthly HTML reports via awffull — accessible at https://reports.<your-domain></code> through the existing Istio gateway.</p>


SigNoz on OVH MKS: The Complete Guide
aleks — Sat, 16 May 2026 00:00:00 +0000
This is the index and reading guide for a three-part series that turns storage-engine theory into a
fully reproducible, sovereign observability stack: SigNoz</a> Community Edition on
OVH Managed Kubernetes Service (MKS), with metrics, distributed traces, and logs all stored in a
single ClickHouse cluster and cold-tiered to OVH Object Storage Infrequent Access. It is an
alternative to hyperscaler-locked observability SaaS, built as a working example repository rather
than a slide deck — clone it, fill in credentials, run Terraform and Ansible. Unlike a stack that
bolts together Prometheus, Jaeger or Tempo, and Loki or Elasticsearch as three separately-operated
databases, SigNoz stores metrics, traces, and logs together in ClickHouse from the start — one
retention policy, one S3 tiering config, one SQL interface, instead of three.</p>


SigNoz on OVH MKS: Infrastructure with Terraform + Ansible
aleks — Sat, 16 May 2026 00:00:00 +0000
The previous two series covered the theory: which storage engine fits 7-year log archiving</a> and what managed cloud services cost</a>. This post turns that analysis into a fully reproducible sovereign observability stack. The goal is not just lower cost, but operational control and EU-hosted observability without hyperscaler lock-in — SigNoz</a> Community Edition on OVH, with metrics, distributed traces, and logs all stored in ClickHouse with S3 cold-tier tiering to OVH Object Storage Infrequent Access.</p>


SigNoz on OVH MKS: Metrics, Traces & Logs with Istio Ambient
aleks — Sat, 16 May 2026 00:00:00 +0000
Part 1</a> set up the infrastructure: OVH MKS, vRack, Istio Ambient Mode, and SigNoz itself via Terraform + Ansible. This post covers what to do after the cluster is running — sending telemetry data, verifying the S3 cold tier is active, and building the first dashboards.</p>


ClickHouse Use Case: Vector, Istio, nginx, Java on OVH MKS
aleks — Thu, 14 May 2026 00:00:00 +0000
The first four parts of this series compared Elasticsearch, OpenSearch, Loki, Quickwit, and
ClickHouse across storage models, operations, security, and UX. This part shows what a
concrete production setup looks like when the decision has been made: ClickHouse</strong> as the
log store, Vector</strong> as the ingestion agent, running on OVH Managed Kubernetes Service
(MKS)</strong> with OVH Object Storage</strong> as the cold tier.</p>
This is Part 5 of a five-part series:</p>

Full guide:</strong> Elasticsearch vs. OpenSearch vs. Loki vs. Quickwit vs. ClickHouse: The Complete Guide</a></li>
Part 1</a> — storage models, compression, resource consumption, and SaaS options</li>
Part 2</a> — cluster setup, Kubernetes operations, backup and disaster recovery</li>
Part 3</a> — encryption, RBAC, and WORM compliance</li>
Part 4</a> — UI layers, dashboards, alerting, and cold-tier query behaviour</li>
Part 5 — this post</li>
</ul>


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 post
Istio 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>