Why ambient mesh and not sidecar?

Ambient mesh uses a shared agent on each Kubernetes node, called a ztunnel. This zero-trust tunnel securely connects and authenticates elements within the mesh, redirecting all traffic through the local ztunnel agent.

This separation allows operators to manage the data plane independently from applications, enabling easier scaling and upgrades.

Ztunnels provide core service mesh functions: zero trust, mTLS, telemetry, authentication, and L4 authorization, without parsing HTTP.

In comparison, ztunnel doesn’t perform L7 processing, making it leaner than sidecars and suitable as shared infrastructure. The traditional sidecar, which has been a staple of Istio for years, now faces a significant competitor. This new contender challenges the long-standing dominance of the sidecar model, introducing innovative approaches and technologies that promise to enhance performance, security, and overall efficiency in service mesh architectures.

Pre-requisites

This post assumes you already have istio set up in ambient mode. In case you don’t, this will get you up and running in two minutes:

1
helm repo add istio https://istio-release.storage.googleapis.com/charts --force-update
2

3
helm install -n istio-system istio-base istio/base --create-namespace
4
helm install -n istio-system istio-cni istio/cni --set profile=ambient
5
helm install -n istio-system istiod istio/istiod --set profile=ambient
6
helm install -n istio-system ztunnel istio/ztunnel
7
helm install -n istio-ingress istio-ingress istio/gateway --create-namespace
8

9
kubectl get crd gateways.gateway.networking.k8s.io &> /dev/null || { kubectl kustomize "github.com/kubernetes-sigs/gateway-api/config/crd?ref=v1.1.0" | kubectl apply -f -; }

The Gateway

The Gateway API simplifies the configuration of ingress and egress traffic, providing a unified approach to managing traffic routing within the mesh. This helps in maintaining a clear and manageable structure for directing traffic to the appropriate services.

1
apiVersion: gateway.networking.k8s.io/v1
2
kind: Gateway
3
metadata:
4
  name: gateway
5
  namespace: ingress-internal
6
spec:
7
  gatewayClassName: istio
8
  addresses:          #
9
  - value: 10.0.16.3  # This block is optional.
10
    type: IPAddress   #
11
  listeners:
12
  - name: http
13
    hostname: "*.matthewdavis.io"
14
    port: 80
15
    protocol: HTTP
16
    allowedRoutes:
17
      namespaces:
18
        from: Selector
19
        selector:
20
          matchLabels:
21
            gateway-internal-access: "true" # Change to reflect your label.
22
  - name: https
23
    hostname: "*.matthewdavis.io"
24
    port: 443
25
    protocol: HTTPS
26
    tls:
27
      mode: Terminate
28
      certificateRefs:
29
      - name: ingress-internal # Ensure secret is in the same namespace!
30
    allowedRoutes:
31
      namespaces:
32
        from: Selector
33
        selector:
34
          matchLabels:
35
            gateway-internal-access: "true" # Change to reflect your label.

1
kubectl label ns internal-services gateway-internal-access=true

Create HTTPRoute Objects

Create HTTPRoute resources to define how traffic should be routed to your services. Here’s an example for two different services:

1
apiVersion: gateway.networking.k8s.io/v1
2
kind: HTTPRoute
3
metadata:
4
  name: tool-a
5
  namespace: internal-services
6
spec:
7
  hostnames:
8
    - "tool-a.matthewdavis.io"
9
  parentRefs:
10
    - name: gateway
11
      namespace: ingress-internal
12
  rules:
13
    - backendRefs:
14
        - name: tool-a
15
          port: 8080

1
apiVersion: gateway.networking.k8s.io/v1
2
kind: HTTPRoute
3
metadata:
4
  name: tool-b
5
  namespace: internal-services
6
spec:
7
  hostnames:
8
    - "tool-b.matthewdavis.io"
9
  parentRefs:
10
    - name: gateway
11
      namespace: ingress-internal
12
  rules:
13
    - backendRefs:
14
        - name: tool-b
15
          port: 9090

Learn more

• https://istio.io/latest/docs/tasks/traffic-management/ingress/gateway-api
• https://gateway-api.sigs.k8s.io