Istio on marktaguiad.dev

Istio: A/B Testing and Canary Deployment

marktaguiad@marktaguiad.dev (Mark Taguiad) — Fri, 03 Apr 2026 00:00:00 +0000

A/B testing and Canary Deployment allows you to route traffic between different versions of your application to compare performance, behavior, or user experience.

With Istio, you can control traffic without changing application code—just by configuring the service mesh.

Replicate this using this repo.

1kubectl apply -k kube/ab-testing/demo

A/B Testing vs Canary Deployment

Aspect	Canary Deployment	A/B Testing
Purpose	Safe rollout	Experimentation
Traffic split	Gradual (10% → 100%)	Fixed (often 50/50)
Decision basis	Errors, latency	User behavior, metrics
End goal	Replace old version	Pick best variant
Versions	Usually same feature	Different UX/features

A/B Testing

Labels

Label your deployments properly.

Istio: Fault Injection, Retries and Circuit Breaker

marktaguiad@marktaguiad.dev (Mark Taguiad) — Sat, 28 Mar 2026 00:00:00 +0000

Continuation of Kubernetes Istio.

I’ve mentioned in this post that will sticking with HTTPRoute, but feature discussed here only support (for now) Istio API.

Ingress Gateway

Istio deploys a default resource for this, and for this example we are using the default ingress gateway ingressgateway.

If you want to create a custom ingress gateway.

istio-gateway.yaml

 1apiVersion: install.istio.io/v1alpha1
 2kind: IstioOperator
 3metadata:
 4  name: istio-control-plane
 5  namespace: istio-system
 6spec:
 7  components:
 8    ingressGateways:
 9      - name: istio-ingressgateway-prod
10        namespace: istio-system
11        enabled: true
12        label:
13          istio: ingressgateway-prod
14
15      - name: istio-ingressgateway-dev
16        namespace: istio-system
17        enabled: true
18        label:
19          istio: ingressgateway-dev

This will create two ingress gateway.

Istio: mTLS and RBAC

marktaguiad@marktaguiad.dev (Mark Taguiad) — Tue, 24 Mar 2026 00:00:00 +0000

Continuation of Kubernetes Istio, this time we’ll focus on Security.

Security

mTLS (Mutual TLS)

This will ensure that service-to-service traffic is encrypted and authenticated.

Istio allows you to configure three main modes per namespace, workload, or globally:

Mode	Behavior	When to Use
STRICT	Only allows mTLS-encrypted traffic. Plain HTTP connections are rejected.	Best for production when you want full security between services.
PERMISSIVE	Accepts both mTLS-encrypted and plain HTTP traffic.	Useful during gradual migration to mTLS. Old workloads can still communicate without encryption.
DISABLE	Does not use mTLS at all.	For testing, legacy workloads, or non-critical traffic.

You might get confused with the HTTPS traffic, it just mean that all traffic are converted by istio envoy to mTLS. So as long as the request is going through first the sidecar then it is valid.

Istio: Routing

marktaguiad@marktaguiad.dev (Mark Taguiad) — Mon, 23 Mar 2026 00:00:00 +0000

Modern applications are no longer built as single, monolithic systems—they’re composed of many small, interconnected services. Managing how these services communicate can quickly become complex, especially as systems scale. This is where Istio comes in.

Istio acts as a powerful service mesh that sits between your services and handles three critical concerns: traffic management, security, and observability.

With Istio, you gain fine-grained control over how traffic flows between services—enabling advanced deployment strategies like A/B testing and canary releases with ease. At the same time, it strengthens service-to-service security and provides deep visibility into your system through metrics, logs, and tracing.

Istio on marktaguiad.dev

Istio: A/B Testing and Canary Deployment

Table of Contents

A/B Testing vs Canary Deployment

A/B Testing

Labels

Istio: Fault Injection, Retries and Circuit Breaker

Table of Contents

Ingress Gateway

Istio: mTLS and RBAC

Table of Contents

Security

mTLS (Mutual TLS)

Istio: Routing