Learning GitOps - FluxCD - Service Mesh Integration (Istio, Linkerd, AWS App Mesh)

#Introduction

In episode 17 you learned blue/green and A/B testing with Flagger — traffic split to two application versions, tested, then promoted. At that point Flagger handled the routing, but a question remained: where is the traffic routed and how are service-to-service connection observation, retry, timeout, up to mTLS managed? The answer is a service mesh.

This episode covers service mesh integration with FluxCD. The key point: a mesh is an ordinary Kubernetes application — operators, CRDs, and a control plane — so it can be installed and configured entirely through Git. That means all routing and telemetry policies are versioned like any other manifest.

#Why a Service Mesh

A service mesh is an infrastructure layer for inter-service communication. Every pod is given a sidecar proxy that intercepts incoming and outgoing traffic, so applications don't need to know how to retry, load balance, handle TLS, or do observability. Its two main components:

• Data plane: the collection of proxies (Envoy in Istio, linkerd-proxy in Linkerd) that move traffic.
• Control plane: the component that reads policies and distributes them to the proxies (istiod, Linkerd control plane).

#Istio Integration

The most GitOps-friendly Istio installation uses the official istio-base, istiod, and gateway charts, declared as a HelmRepository and HelmRelease. With enablePrometheusMerge: true, mesh metrics automatically flow into the Prometheus pipeline.

Once the charts are in, enable sidecar injection with the istio-injection: enabled label on the namespace, and declare routing through VirtualService (where traffic per host is routed) and DestinationRule (policies like mTLS and load balancing per subset):

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: api
  namespace: apps
spec:
  hosts:
    - api.apps.svc.cluster.local
  http:
    - route:
        - destination:
            host: api
            subset: stable
          weight: 90
        - destination:
            host: api
            subset: canary
          weight: 10
---
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: api
  namespace: apps
spec:
  host: api
  subsets:
    - name: stable
      labels:
        version: stable
    - name: canary
      labels:
        version: canary
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL

Quick installation verification with the CLI:

istioctl version
istioctl proxy-status
istioctl analyze --namespace apps

#Linkerd Integration

Linkerd is much lighter. Its installation manifests can be generated and committed directly to Git:

linkerd install --crds > install/linkerd/crds.yaml
linkerd install > install/linkerd/control-plane.yaml

FluxCD only needs to point one Kustomization at the install/linkerd folder. This is the most direct example of "mesh as code" — pure YAML from the repo, without an interactive installer.

Linkerd uses ServiceProfile to describe a service's API and TrafficSplit to split traffic between versions at the service level:

apiVersion: split.smi-spec.io/v1alpha2
kind: TrafficSplit
metadata:
  name: api
  namespace: apps
spec:
  service: api
  backends:
    - service: api-stable
      weight: 900m
    - service: api-canary
      weight: 100m

For observability, add the linkerd-viz addon as a HelmRelease. The dashboard can be accessed with linkerd viz dashboard, and linkerd viz top deploy/api shows real-time latency per deployment.

#AWS App Mesh Integration

On AWS, App Mesh offers a managed mesh: the control plane is held by AWS, while the proxy remains Envoy inside the cluster. Setup starts from the mesh and virtual node deployed by FluxCD:

apiVersion: appmesh.k8s.aws/v1beta2
kind: Mesh
metadata:
  name: dev-null-mesh
spec:
  namespaceSelector:
    matchLabels:
      mesh: dev-null
---
apiVersion: appmesh.k8s.aws/v1beta2
kind: VirtualNode
metadata:
  name: api
  namespace: apps
spec:
  meshName: dev-null-mesh
  listeners:
    - portMapping:
        port: 8080
        protocol: http
  backends:
    - virtualService:
        virtualServiceName: orders.apps.svc.cluster.local

The router and route configuration determine where traffic goes:

apiVersion: appmesh.k8s.aws/v1beta2
kind: VirtualRouter
metadata:
  name: api-router
  namespace: apps
spec:
  meshName: dev-null-mesh
  listeners:
    - portMapping:
        port: 8080
        protocol: http
  routes:
    - name: api-route
      httpRoute:
        match:
          prefix: /
        action:
          weightedTargets:
            - virtualNodeName: api
              weight: 100

#Multi-Mesh Observability

A mesh without observability only adds complexity. Four layers to think about:

• Distributed tracing: Istio integrates with Jaeger, Linkerd with OpenTelemetry, App Mesh with X-Ray. Traces connect requests across services so the root cause is found without guessing.
• Service graphs: Kiali for Istio, "tap" and the viz dashboard for Linkerd. Both show who talks to whom.
• Metrics dashboards: all meshes expose Prometheus metrics. Grafana dashboards are also versioned in Git and synced by FluxCD.
• Canary analysis visualization: while a canary runs, compare the latency and error rate of both subsets right on the dashboard — the promotion decision becomes data-driven.

#Closing

This episode showed that a service mesh isn't something separate from GitOps — a mesh is just another Kubernetes application installed and configured through Git. We covered Istio installation with HelmRelease, VirtualService and DestinationRule automation, lightweight Linkerd with TrafficSplit, AWS App Mesh with virtual nodes and routers, and observability in the form of tracing, service graphs, and dashboards.

The key takeaways:

• Mesh as code: mesh installation and policies are declared in Git, FluxCD syncs them.
• Choose according to need: Istio for rich features, Linkerd for simplicity, App Mesh for those living on AWS.
• Versioned traffic management: VirtualService, TrafficSplit, and route configs are reviewed through pull requests.
• Observability is mandatory: without tracing and metrics, canary decisions have no basis.
• Flagger runs on top of the mesh: the canary analysis from episodes 15-17 uses VirtualService or TrafficSplit as the routing mechanism.

With a mesh, traffic can now be finely managed — but this opens a new attack surface. In the next episode, episode 19, we'll discuss securing Flux: authentication, RBAC, network security, and supply chain security with Cosign and admission controllers. See you in episode 19!