Istio Installation¶

Why Tetrate Istio?¶

Tetrate Istio Distro delivers enterprise-grade reliability, security, and operational safety while maintaining 100% OSS Istio compatibility at no additional cost - essentially "OSS Istio, but better" with zero migration risk.

OSS Istio vs Tetrate Istio Distro (TID) Comparison¶

Feature	OSS Istio	Tetrate Istio Distro (TID)	Tetrate Istio Distro Value Proposition
Migration Compatibility	Standard upstream Istio	100% upstream Istio with no proprietary modifications	Zero Migration Risk: Drop-in replacement with identical APIs and behavior
Build Quality	Community builds, untested combinations	Vetted builds tested against all major cloud platforms	Production Hardening: Enterprise-tested stability vs untested community combinations
Security & Compliance	Standard crypto modules	FIPS-verified builds (Certificate #4407) + distroless images available	Enhanced Security: Government-grade cryptography + reduced attack surface
Configuration Safety	Basic validation only	Platform-based configuration validations + enforced version compatibility	Operational Safety: Prevents misconfigurations and incompatible version deployments
Support Lifecycle	8 months community support	Extended CVE patching and version support	Extended Lifecycle: Longer security support window reduces forced upgrade pressure
Cost Model	Free	Free	Free Upgrade Path: All production benefits with zero cost increase from OSS

Learning Objectives¶

By the end of this hands-on exercise, you will be able to:

a. Installation & Setup¶

Objective 1

Deploy Tetrate Istio Distro (TID) using best practices for production-ready service mesh installation

b. Hybrid Mesh Architecture¶

Objective 2

Implement hybrid mesh deployment patterns within a single cluster, including:

Traditional sidecar-based workloads for Layer 7 processing
Ambient mode (sidecarless) workloads for lightweight Layer 4 connectivity
Seamless interoperability between both deployment models

c. Security & Policy Enforcement¶

Objective 3

Configure and validate authorization policies across hybrid deployments:

Apply fine-grained AuthZ security policies
Test cross-deployment communication (sidecar ↔ ambient)
Verify policy enforcement and traffic flow behavior

d. Enterprise Observability¶

Objective 4

Explore advanced observability capabilities and understand the migration path to Tetrate Service Bridge (TSB) for:

Multi-cluster visibility and management
Enterprise-grade monitoring and troubleshooting
Day 2 operations at scale

Setup Overview¶

Prerequisites - Required Tools¶

Kubernetes cluster access
kubectl configured
helm installed
istioctl installed

1. Istio Installation & Setup¶

Quick Setup (default istio - latest version)¶

curl -sL https://bootstrap.tetr8.io/scripts/install-tid.sh | bash -s --  --cluster-name cluster1 --profile ambient

# Validate :-
kubectl get pod -n istio-system
NAME                            READY   STATUS    RESTARTS   AGE
istio-cni-node-8xwzx            1/1     Running   0          9m34s
istiod-76557548f-8n7hz          1/1     Running   0          10m
ztunnel-6g8tz                   1/1     Running   0          8m53s

Customize Installation with specific Istio version (OPTIONAL)¶

# List available istio versions/tags
curl -sL https://bootstrap.tetr8.io/scripts/install-tid.sh | bash -s -- --list-versions

# Install specific istio version
curl -sL https://bootstrap.tetr8.io/scripts/install-tid.sh | bash -s -- --version 1.27.1-tetrate0 --chart-version 1.27.1+tetrate0 --revision stable-1-27-1 --profile ambient -c cluster1

Info

For existing Istio Users- Migrate to ambient mode Migrate to Ambient mode

2. Hybrid Mesh Architecture¶

Deploy the application - Transaction Portal Service ¶

3. Test Interop - Sidecar App to Ambient App and vice versa¶

a. Deploy Sleep service

kubectl create namespace sleep
kubectl label namespace sleep istio-injection=enabled --overwrite=true  #istio.io/rev=REVISION
kubectl -n sleep apply -f https://raw.githubusercontent.com/istio/istio/master/samples/sleep/sleep.yaml

b. Various test scenarios for validating account-service functionality in ambient mode using the sleep service as a test client

Scenario 1. sleep pod with sidecar injected

kubectl -n sleep exec -it deploy/sleep -- curl -s http://account-service.account-service.svc.cluster.local:9080/checkBalance
#Expected output in terminal
{"account_id":"12345","account_type":"checking","balance":1500,"last_activity":"2024-01-01T10:00:00Z","service":"account-service","status":"active"}

Scenario 2. sleep pod in ambient mode

kubectl label namespace sleep istio-injection-
kubectl rollout restart deploy sleep -n sleep
kubectl label namespace sleep istio.io/dataplane-mode=ambient
k -n sleep exec -it deploy/sleep -- curl -s http://account-service.account-service.svc.cluster.local:9080/checkBalance

#expected output one for inbound and other for outbound to ztunnel.
2025-09-16T09:30:21.427031Z     info    access  connection complete     src.addr=172.20.6.31:46572 src.workload="sleep-67f677f4ff-tn4wv" src.namespace="sleep" src.identity="spiffe://cluster.local/ns/sleep/sa/sleep" dst.addr=172.20.26.115:15008 dst.hbone_addr=172.20.26.115:9080 dst.service="account-service.account-service.svc.cluster.local" dst.workload="account-service-v1-78cd9c6b88-nwr7d" dst.namespace="account-service" dst.identity="spiffe://cluster.local/ns/account-service/sa/transaction-account-service" direction="inbound" bytes_sent=258 bytes_recv=130 duration="2ms"
2025-09-16T09:30:21.427472Z     info    access  connection complete     src.addr=172.20.6.31:39676 src.workload="sleep-67f677f4ff-tn4wv" src.namespace="sleep" src.identity="spiffe://cluster.local/ns/sleep/sa/sleep" dst.addr=172.20.26.115:15008 dst.hbone_addr=172.20.26.115:9080 dst.service="account-service.account-service.svc.cluster.local" dst.workload="account-service-v1-78cd9c6b88-nwr7d" dst.namespace="account-service" dst.identity="spiffe://cluster.local/ns/account-service/sa/transaction-account-service" direction="outbound" bytes_sent=130 bytes_recv=258 duration="3ms"

Scenario 3. sleep pod without sidecar(plain k8s, no ambient)

kubectl label namespace sleep istio.io/dataplane-mode-
k -n sleep exec -it deploy/sleep -- curl -s http://account-service.account-service.svc.cluster.local:9080/checkBalance

#expected ztunnel output
2025-09-16T09:25:40.170511Z     info    access  connection complete     src.addr=172.20.6.31:40348 src.workload="sleep-67f677f4ff-tn4wv" src.namespace="sleep" dst.addr=172.20.26.115:9080 dst.service="account-service.account-service.svc.cluster.local" dst.workload="account-service-v1-78cd9c6b88-nwr7d" dst.namespace="account-service" direction="inbound" bytes_sent=258 bytes_recv=130 duration="1ms"

c. Authz Test- Apply authz policy to restrict account-service access from transaction-portal only and test from sleep running in ambient mode

# change for Transaction portal
kubectl apply -f - <<EOF
---
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: account-service-ztunnel
  namespace: account-service
spec:
  selector:
    matchLabels:
      app: account-service
  action: ALLOW
  rules:
  - from:
    - source:
        principals:
        - cluster.local/ns/transaction-portal/sa/transaction-portal
EOF

kubectl -n sleep exec -it deploy/sleep -- curl -s http://account-service.account-service.svc.cluster.local:9080/balanceCheck

Expected Outcome

Terminal Output:- upstream connect error or disconnect/reset before headers. reset reason: connection termination

zTunnel logs-

2025-09-16T09:58:11.689957Z     error   access  connection complete     src.addr=172.20.5.106:43370 src.workload="sleep-5cb9b8887d-4vdf5" src.namespace="sleep" src.identity="spiffe://cluster.local/ns/sleep/sa/sleep" dst.addr=172.20.26.115:15008 dst.hbone_addr=172.20.26.115:9080 dst.service="account-service.account-service.svc.cluster.local" dst.workload="account-service-v1-78cd9c6b88-nwr7d" dst.namespace="account-service" dst.identity="spiffe://cluster.local/ns/account-service/sa/transaction-account-service" direction="inbound" bytes_sent=0 bytes_recv=0 duration="0ms" error="connection closed due to policy rejection: allow policies exist, but none allowed"

Workshop Progress Summary¶

Congratulations!

You have successfully completed all the Objectives. Let's review what you've accomplished so far.

What You've Achieved¶

Objective 1 Complete: TID Installation¶

Production-Ready Foundation

Tetrate Istio Distro deployed with enterprise-grade hardening

Objective 2 Complete: Hybrid Mesh Architecture¶

Advanced Deployment Patterns

Sidecar-based workloads operational with full Layer 7 capabilities
Ambient mode workloads running in sidecarless configuration
Cross-deployment communication established between both modes
Service discovery working seamlessly across deployment types

Objective 3 Complete: Security & Policy Enforcement¶

Zero Trust Implementation

Authorization policies configured and enforced
Cross-mode communication secured (sidecar ↔ ambient)
Policy validation confirmed through testing
mTLS encryption protecting service-to-service communication

Current Architecture Status¶

graph TB
    subgraph "Kubernetes Cluster"
        subgraph "Sidecar Mode"
            S1[Service A + Envoy]
            S2[Service B + Envoy]
            S3[Service C + Envoy]
        end
        subgraph "Ambient Mode"
            A1[Service C]
            A2[Service D]
            Z[ztunnel DaemonSet]
        end
        subgraph "Istio Control Plane"
            CP[TID Control Plane]
        end
    end

    S1 -..->|mTLS + AuthZ| A1
    S2 -.->|mTLS + AuthZ| A2
    CP -->|XDS| S1
    CP -->|XDS| S2
    CP -->|XDS| Z
    Z -->|L4 Proxy| A1
    Z -->|L4 Proxy| A2
    A2 -->|mTLS + AuthZ| S3

    style S1 fill:#e1f5fe
    style S2 fill:#e1f5fe
    style S3 fill:#e1f5fe
    style A1 fill:#f3e5f5
    style A2 fill:#f3e5f5
    style CP fill:#e8f5e8

Observaility with OSS Stack and Challenges¶

Istio Observability Challenges with OSS Observability Stack