Data Flow: Istio Service Mesh
Purpose: For platform engineers and app developers, shows how Istio service mesh augments the base openCenter cluster architecture with mTLS, traffic control, and enhanced observability.
Simplified Overview
Namespace Layout
| Namespace | Services | Purpose |
|---|---|---|
istio-system | istiod, Istio Gateway | Service mesh control plane and ingress |
flux-system | Source, Kustomize, Helm, Notification controllers | GitOps reconciliation engine |
olm | Operator Lifecycle Manager, OLM Catalog | Installs and manages operators (Kafka, Keycloak, etc.) |
cert-manager | cert-manager, ClusterIssuers | Automated TLS certificate lifecycle |
kyverno | Kyverno engine, admission webhook | Policy enforcement (17 baseline policies) |
keycloak | Keycloak, PostgreSQL | Identity and access management via OIDC |
rbac-manager | RBAC Manager | Declarative RBAC from Keycloak group claims |
metallb-system | MetalLB speakers, controller | Bare-metal load balancer (L2/BGP) |
kube-system | kube-vip | Virtual IP for control-plane HA (stable API server endpoint) |
observability | Prometheus, Grafana, Alertmanager, Loki, Promtail, Tempo, OTel Collector, Kafka, Kiali | Metrics, logs, traces, event streaming, alerting, and mesh visualization |
longhorn-system | Longhorn Manager, CSI driver | Distributed block storage |
harbor | Harbor Core, Registry, Trivy | Private container registry with vulnerability scanning |
headlamp | Headlamp UI, branding plugin | Kubernetes web dashboard with OIDC authentication |
velero | Velero server | Cluster backup and disaster recovery |
customer-apps | Customer deployments + istio-proxy sidecars | Application workloads with mesh traffic |
Data Flow Summary
- Ingress path: External traffic → MetalLB → Istio Gateway → VirtualService → Application Pod (via sidecar)
- Service-to-service: Pod A sidecar →|mTLS| Pod B sidecar (certificates issued by istiod)
- Control-plane HA path: kube-vip elects leader on control-plane nodes → advertises virtual IP → all clients/nodes reach Kubernetes API via stable VIP
- GitOps path: Git push → FluxCD Source Controller → Kustomize/Helm Controller → Kubernetes API → Resources deployed (including Istio CRDs)
- Secrets path: SOPS-encrypted YAML in Git → FluxCD decrypts with Age key → Kubernetes Secret created
- Observability path: Sidecars emit metrics/logs/traces automatically → OpenTelemetry Collector → Kafka → Prometheus + Loki + Tempo → Grafana + Kiali
- Policy path: Resource admission → Kyverno webhook → validate against ClusterPolicies → admit or reject
- Auth path: User login → Keycloak OIDC → JWT with group claims → RBAC Manager → RoleBindings → API Server authorization
- Headlamp path: Operator browser → MetalLB → Istio Gateway → Headlamp UI → Keycloak OIDC login → Kubernetes API (scoped by RBAC)
- OLM path: FluxCD deploys OLM → OLM installs operators from catalog → operators provision Kafka, Keycloak, and other stateful services
- Traffic management: VirtualService weight-based routing → canary deployments, traffic shifting, fault injection
Istio-Specific Components
| Resource | Purpose |
|---|---|
VirtualService | L7 routing rules (host, path, headers, traffic weights) |
DestinationRule | Load balancing, circuit breaking, connection pool settings |
PeerAuthentication | mTLS mode per namespace or workload (STRICT / PERMISSIVE) |
AuthorizationPolicy | L7 access control (allow/deny by source, path, method) |
Gateway (Istio) | Ingress listener configuration (ports, TLS, hosts) |
ServiceEntry | Register external services into the mesh |
Differences from Base Architecture
| Concern | Base Cluster | With Istio |
|---|---|---|
| Ingress controller | Gateway API (Kubernetes-native) | Istio Gateway + VirtualService |
| Service-to-service auth | NetworkPolicy (L3/L4 only) | mTLS with SPIFFE identity (L7) |
| Traffic shifting | Not supported | VirtualService weights |
| Circuit breaking | Not supported | DestinationRule outlier detection |
| Observability | Manual instrumentation for traces | Automatic trace injection by sidecar |
| Resource overhead | None | ~50MB memory + ~2ms latency per sidecar |
| Mesh visualization | N/A | Kiali service graph |
Alternative Deployment: Istio Gateway Alongside openCenter Gateway API
In this model, the openCenter-managed Gateway API handles platform and non-mesh traffic, while Istio deploys its own gateway for mesh-managed workloads. Both gateways sit behind MetalLB.
Key Differences from Primary Deployment
| Concern | Primary (Istio replaces Gateway API) | Alternative (side-by-side) |
|---|---|---|
| Platform traffic routing | Istio Gateway | openCenter Gateway API (unchanged) |
| Mesh app traffic routing | Istio Gateway | Istio Gateway |
| Headlamp, Grafana, Harbor | Routed through Istio Gateway | Routed through openCenter Gateway API |
| Sidecars on platform services | Yes | No (only on customer workloads) |
| Blast radius | Full cluster in mesh | Only labeled namespaces in mesh |
| Migration path | Big-bang (all traffic via Istio) | Incremental (opt-in per namespace) |
This model is preferred when migrating incrementally — platform services remain on the proven Gateway API path while customer workloads opt into the mesh namespace by namespace.
Related
- Logical Diagram — base cluster architecture
- Service Mesh & APIs — Istio configuration guide
- Gateway & TLS — non-mesh ingress setup