Istio

---




name: istio
compatibility: opencode
completeness: 95
content-types:
- guidance
- examples
- do-dont
- config
description: '"Istio in Cloud-Native Engineering - Connect, secure, control, and observe"
  services.'
license: MIT
maturity: stable
metadata:
  domain: cncf
  output-format: manifests
  role: reference
  scope: infrastructure
  triggers: cloud-native, connect, engineering, istio, service mesh, traffic management,
    kubernetes service, container orchestration
  archetypes:
  - educational
  - strategic
  anti_triggers:
  - brainstorming
  - vague ideation
  - non-containerized architecture
  response_profile:
    verbosity: medium
    directive_strength: low
    abstraction_level: strategic
version: "1.0.0"




---




  related-skills: cncf-argo, cncf-artifact-hub, cncf-aws-eks, cncf-azure-aks




# Istio in Cloud-Native Engineering

**Category:** api-management  
**Status:** Active  
**Stars:** 38,137  
**Last Updated:** 2026-04-22  
**Primary Language:** Go  
**Documentation:** [https://istio.io/latest/docs/](https://istio.io/latest/docs/)  

---

## Purpose and Use Cases

Istio is a core component of the cloud-native ecosystem, serving as a service mesh that adds observability, traffic control, and security policies to service-to-service communication without application code changes.

### What Problem Does It Solve?

Embedding cross-cutting concerns like traffic management, security, and observability directly into application code. It enables these features declaratively without code changes.

### When to Use This Project

Use Istio when you need a comprehensive service mesh with built-in traffic management, security (mTLS), and observability across your microservices. Consider lighter alternatives if you only need specific features.

### Key Use Cases


- Traffic management for microservices
- Service-to-service authentication with mTLS
- Observability with integrated tracing and metrics
- Policy enforcement and rate limiting
- Traffic splitting for canary deployments


---

## Architecture Design Patterns

### Core Components


- **Pilot**: Manages service discovery and traffic routing
- **Citadel**: Certificate authority for mTLS
- **Galley**: Configuration validation and distribution
- **Sidecar Proxy**: Envoy proxy injected into pods
- **Gateways**: Ingress and egress proxies for external traffic
- **Pilot Agent**: Sidecar agent that configures Envoy


### Component Interactions


1. **User → API Server**: Deploys application with sidecar
2. **Pilot → Istio Agent**: Pushes config to sidecars
3. **Istio Agent → Envoy**: Configures Envoy proxy
4. **Pilot → Kubernetes API**: Reads services and endpoints
5. **Citadel → Envoy**: Provides certificates for mTLS
6. **Collectors → Grafana/Jaeger**: Export telemetry data


### Data Flow Patterns


1. **Traffic Flow**: Ingress Gateway → Sidecar → Application → Sidecar → Destination
2. **Configuration Push**: Pilot reads Kubernetes API → Converts to Envoy config → Pushes to sidecars
3. **mTLS Handshake**: Client sidecar → Citadel (via Pilot Agent) → Server sidecar → Application
4. **Telemetry Collection**: Sidecar → Metrics → Prometheus, Traces → Jaeger


### Design Principles


- **Transparent**: No application code changes required
- **Pluggable**: Support for multiple policies and telemetry backends
- **Extensible**: Custom adapters and policies
- **Kubernetes-Native**: Leverages Kubernetes APIs
- **Sidecar Pattern**: Non-intrusive proxy injection


---

## Integration Approaches

### Integration with Other CNCF Projects


- **Kubernetes**: Native integration with Kubernetes APIs
- **Envoy**: Data plane proxy
- **Prometheus**: Metrics collection
- **Grafana**: Dashboard visualization
- **Jaeger/Zipkin**: Distributed tracing
- **CoreDNS**: DNS integration for service discovery
- **Cert-manager**: Certificate management


### API Patterns


- **Kubernetes API**: Custom resource definitions
- **Pilot API**: Configuration distribution
- **Citadel API**: Certificate management
- **Galley API**: Configuration validation


### Configuration Patterns


- **Kubernetes CRDs**: Istio resources
- **ConfigMap**: Gateway and sidecar configs
- **Annotation**: Pod and service annotations
- **Mesh Config**: Global mesh configuration


### Extension Mechanisms


- **Adapters**: Custom policy and telemetry
- **Handlers**: Policy enforcement
- **Rules**: Traffic routing rules
- **Mesh Extensions**: Custom sidecars


---

## Common Pitfalls and How to Avoid Them

### Misconfigurations


- **Sidecar Injection**: Incorrect pod selection
- **Traffic Routing**: Misconfigured virtual services
- **Security Policies**: Incorrect mTLS settings
- **Resource Limits**: Insufficient proxy resources
- **Gateway Configuration**: Incorrect gateway selection
- **Certificate Management**: Expired or missing certificates


### Performance Issues


- **Sidecar Overhead**: Proxy resource consumption
- **Control Plane Load**: Pilot configuration push
- **Data Plane Latency**: Proxy processing time
- **Certificate Rotation**: Frequent certificate updates
- **Config Propagation**: Slow configuration updates


### Operational Challenges


- **Control Plane Management**: Multi-cluster setups
- **Migration**: Gradual adoption
- **Resource Management**: Proxy resource requirements
- **Debugging**: Complex service mesh issues
- **Performance Tuning**: Traffic optimization
- **Security Operations**: Certificate lifecycle management


### Security Pitfalls


- **mTLS**: Misconfigured mutual TLS
- **Authorization Policies**: Overly permissive policies
- **Gateway Security**: Missing TLS termination
- **Certificate Expiry**: Stale Citadel certificates
- **Sidecar Injection**: Injecting into wrong namespaces


---

## Coding Practices

### Idiomatic Configuration


- **Kubernetes CRDs**: Native resource type
- **YAML Manifests**: Clear structure
- **Annotations**: Pod-level configuration
- **ConfigMap**: Mesh-wide configuration


### API Usage Patterns


- **Kubernetes API**: Custom resources
- **Pilot Admin API**: Configuration management
- ** Citadel Admin API**: Certificate management


### Observability Best Practices


- **Metrics**: Sidecar metrics collection
- **Tracing**: Jaeger/Zipkin integration
- **Access Logs**: Gateway and sidecar logs
- **Kiali**: Service mesh visualization
- **Grafana Dashboards**: Istio dashboards


### Testing Strategies


- **Unit Tests**: Component tests
- **Integration Tests**: Multi-component tests
- **E2E Tests**: Full mesh tests
- **Conformance Tests**: Istio compatibility


### Development Workflow


- **Development**: Istio development cluster
- **Testing**: Go tests, E2E tests
- **Debugging**: istioctl, debug sidecar
- **Deployment**: istioctl install
- **CI/CD**: Comprehensive test suite
- **Tools**: istioctl, kiali, pilot-discovery


---

## Fundamentals

### Essential Concepts


- **Service Mesh**: Network of services with Istio control plane
- **Sidecar**: Proxy container in pod
- **Gateway**: Ingress/egress proxy
- **Virtual Service**: Traffic routing rules
- **Destination Rule**: Policy for traffic to service
- **PeerAuthentication**: mTLS configuration
- **AuthorizationPolicy**: Access control
- **RequestAuthentication**: Authentication config
- **Sidecar**: Sidecar configuration
- **Gateway**: Gateway configuration


### Terminology Glossary


- **Sidecar**: Service proxy in pod
- **Gateway**: Ingress/egress proxy
- **Virtual Service**: Traffic routing rules
- **Destination Rule**: Traffic policy
- **PeerAuthentication**: mTLS config
- **AuthorizationPolicy**: Access control
- **RequestAuthentication**: Auth config
- **Telemetry**: Observability data
- **Security Policy**: Security configuration


### Data Models and Types


- **Virtual Service**: Traffic routing config
- **Destination Rule**: Traffic policy config
- **Gateway**: Gateway configuration
- **Peer Authentication**: mTLS config
- **Authorization Policy**: Access control config
- **Request Authentication**: Auth config
- **Sidecar**: Sidecar configuration
- **Workload Entry**: Workload definition
- **Service Entry**: Service definition


### Lifecycle Management


- **Sidecar Lifecycle**: Inject → Start → Config → Stop
- **Configuration Lifecycle**: Push → Apply → Validate
- **mTLS Lifecycle**: Handshake → Encrypt → Decrypt
- **Traffic Lifecycle**: Route → Balance → Forward
- **Telemetry Lifecycle**: Collect → Export → Store


### State Management


- **Configuration State**: Pilot configuration
- **Traffic State**: Active connections
- **mTLS State**: Certificate state
- **Telemetry State**: Collected metrics/traces
- **Discovery State**: Service discovery data


---

## Scaling and Deployment Patterns

### Horizontal Scaling


- **Sidecar Scaling**: Pod replica scaling
- **Control Plane Scaling**: Pilot replicas
- **Gateway Scaling**: Ingress gateway scaling
- **Mesh Expansion**: Multi-cluster scaling


### High Availability


- **Control Plane HA**: Multiple pilot instances
- **Sidecar Redundancy**: Multiple sidecars per service
- **Gateway HA**: Multiple ingress gateways
- **Certificate Rotation**: Automatic certificate renewal


### Production Deployments


- **Control Plane Deployment**: Pilot, Citadel, Galley
- **Sidecar Injection**: Selective injection
- **Traffic Management**: Production routing rules
- **Security**: mTLS in permissive or strict mode
- **Monitoring**: Integration with Prometheus and Grafana
- **Performance Tuning**: Proxy resource optimization
- **Rollout Strategy**: Gradual rollout with traffic splitting


### Upgrade Strategies


- **Control Plane Upgrade**: istioctl upgrade
- **Sidecar Injection**: Automatic and manual injection
- **Traffic Splitting**: Gradual rollout with canary
- **Backward Compatibility**: Version compatibility matrix


### Resource Management


- **Sidecar Resources**: Proxy CPU and memory limits
- **Control Plane Resources**: Pilot resource requirements
- **Gateway Resources**: Ingress gateway resources
- **Traffic Shaping**: Bandwidth management


---

## Additional Resources

- **Official Documentation:** [https://istio.io/latest/docs/](https://istio.io/latest/docs/)
- **GitHub Repository:** [github.com/istio/istio](https://github.com/istio/istio)
- **CNCF Project Page:** [cncf.io/projects/istio/](https://www.cncf.io/projects/istio/)
- **Community:** Check the GitHub repository for community channels
- **Versioning:** Refer to project's release notes for version-specific features

---

## Troubleshooting

### Common Issues

1. **Deployment Failures**
   - Check pod logs for errors
   - Verify configuration values
   - Ensure network connectivity

2. **Performance Issues**
   - Monitor resource usage
   - Adjust resource limits
   - Check for bottlenecks

3. **Configuration Errors**
   - Validate YAML syntax
   - Check required fields
   - Verify environment-specific settings

4. **Integration Problems**
   - Verify API compatibility
   - Check dependency versions
   - Review integration documentation

### Getting Help

- Check official documentation
- Search GitHub issues
- Join community channels
- Review logs and metrics
*Content generated automatically. Verify against official documentation before production use.*

## Tutorial

This tutorial will guide you through installing, configuring, and using Istio for service mesh management in Kubernetes.

### Prerequisites

Before beginning, ensure you have:
- A running Kubernetes cluster (minikube with 4GB+ RAM, kind, EKS, GKE, AKS)
- `kubectl` configured with cluster-admin permissions
- `istioctl` CLI (for Istio installation and debugging)
- Basic understanding of Kubernetes services and networking

Verify your setup:

```bash
# Check cluster connectivity
kubectl cluster-info

# Verify kubectl configuration
kubectl get nodes

# Check Kubernetes version (1.21+ recommended)
kubectl version --short

# Check if Envoy proxy sidecar injection is supported
kubectl get mutatingwebhookconfigurations
```

---

### 1. Installation

Istio can be installed using istioctl, Helm, or with managed offerings from cloud providers.

#### Method 1: Using istioctl (Recommended)

```bash
# Download istioctl
curl -L https://istio.io/downloadIstio | sh -

# Add istioctl to PATH
export PATH="$PATH:$(pwd)/istio-*/bin"
# Or for Linux:
# export PATH="$PATH:$(pwd)/istio-1.21.0/bin"

# Verify installation
istioctl version

# Or install istioctl via Homebrew (macOS/Linux)
brew install istioctl

# Or via Chocolatey (Windows)
choco install istioctl
```

#### Method 2: Using istioctl with Profile

```bash
# Install with default profile (recommended for production)
istioctl install --set profile=default -y

# Install with demo profile (for learning and testing)
istioctl install --set profile=demo -y

# Install with minimal profile (custom configuration)
istioctl install --set profile=minimal -y

# Install with custom settings
istioctl install --set profile=default \
  --set values.gateways.istio-ingressgateway.type=LoadBalancer \
  --set values.pilot.resources.requests.memory=1Gi \
  -y
```

#### Method 3: Using Helm

```bash
# Add the Istio Helm repository
helm repo add istio.io https://istio-release.storage.googleapis.com/charts
helm repo update

# Install Istio base charts
helm install istio-base istio.io/base -n istio-system --create-namespace

# Install Istio control plane
helm install istiod istio.io/istiod -n istio-system \
  --set global.sts.tokenAudience=istiod.istio-system.svc.service-account

# Install Istio ingress gateway
helm install istio-ingress istio.io/gateway -n istio-system \
  --set service.type=LoadBalancer

# Verify installation
kubectl get pods -n istio-system
```

#### Method 4: Using Managed Istio (Cloud Providers)

```bash
# Amazon EKS with AWS Distro for Istio
# See: https://aws.amazon.com/istio/

# Google GKE with Istio
gcloud container clusters update my-cluster \
  --update-istio=enabled \
  --istio-version=1.21.0

# Azure AKS with Istio
az aks update \
  --name myAKSCluster \
  --resource-group myResourceGroup \
  --enable-istio
```

---

### 2. Basic Configuration

#### Enable Sidecar Injection

```bash
# Enable injection on namespace
kubectl label namespace default istio-injection=enabled

# Or use label selector
kubectl label namespace production istio-injection=enabled

# Verify namespace is labeled
kubectl get namespace -L istio-injection

# Manually inject sidecar
kubectl get default -o yaml | istioctl kube-inject -f - | kubectl apply -f -
```

#### Configure Mesh Settings

```yaml
# Create IstioOperator configuration
cat <<EOF | kubectl apply -f -
apiVersion: istio.io/v1beta1
kind: IstioOperator
metadata:
  name: istio-control-plane
  namespace: istio-system
spec:
  profile: default
  components:
    pilot:
      k8s:
        resources:
          requests:
            memory: "1024Mi"
            cpu: "500m"
        env:
        - name: PILOT_ENABLE_PROTOCOL_SNIFFING_FOR_OUTBOUND
          value: "true"
    ingressGateways:
    - name: istio-ingressgateway
      enabled: true
      k8s:
        service:
          type: LoadBalancer
EOF
```

#### Configure mTLS

```yaml
# Enable mTLS in namespace
cat <<EOF | kubectl apply -f -
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: production
spec:
  mtls:
    mode: STRICT
---
  related-skills: cncf-argo, cncf-artifact-hub, cncf-aws-eks, cncf-azure-aks
# Disable mTLS for specific workloads
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: explicit-disabled
  namespace: production
spec:
  selector:
    matchLabels:
      app: monitoring
  mtls:
    mode: DISABLE
EOF
```

#### Configure Gateways

```yaml
# Create Gateway for external access
cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: myapp-gateway
  namespace: production
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - myapp.example.com
EOF
```

---
  related-skills: cncf-argo, cncf-artifact-hub, cncf-aws-eks, cncf-azure-aks

### 3. Usage Examples

#### Deploying an Application with Istio

```bash
# Deploy the sleep application (sample app)
kubectl apply -f istio-*/samples/sleep/sleep.yaml

# Verify sidecar injection
kubectl get pods -l app=sleep

# Check injected sidecar
istioctl proxy-status

# Describe pod to see sidecar
kubectl describe pod sleep-xxxxx
```

#### Traffic Management Examples

```bash
# Create a Virtual Service
cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: sleep
  namespace: default
spec:
  hosts:
  - sleep
  http:
  - route:
    - destination:
        host: sleep
        subset: v1
      weight: 100
---
  related-skills: cncf-argo, cncf-artifact-hub, cncf-aws-eks, cncf-azure-aks
# Create subsets
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: sleep
  namespace: default
spec:
  host: sleep
  subsets:
  - name: v1
    labels:
      version: v1
EOF

# Apply traffic policy
istioctl analyze
```

#### Testing Circuit Breaking

```yaml
# Configure circuit breaking
cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: myapp-circuit-breaker
  namespace: production
spec:
  host: myapp.production.svc.cluster.local
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        h2UpgradePolicy: UPGRADE
        http1MaxPendingRequests: 100
        http2MaxRequests: 1000
    outlierDetection:
      consecutive5xxErrors: 5
      interval: 30s
      baseEjectionTime: 30s
      maxEjectionPercent: 50
EOF
```

#### Observability with Kiali

```bash
# Enable Kiali addon
istioctl install --set profile=demo -y

# Access Kiali dashboard
istioctl dashboard kiali

# Or port-forward manually
kubectl -n istio-system port-forward svc/kiali 20001:20001

# Access via browser
open http://localhost:20001
```

---
  related-skills: cncf-argo, cncf-artifact-hub, cncf-aws-eks, cncf-azure-aks

### 4. Common Operations

#### Monitoring Mesh Health

```bash
# Check Istio components status
kubectl get pods -n istio-system

# Check proxy status
istioctl proxy-status

# Verify configuration
istioctl analyze

# Check sidecar injection status
istioctl proxy-status --injection

# View configuration dumps
istioctl proxy-config listeners <pod-name> -n <namespace>
istioctl proxy-config routes <pod-name> -n <namespace>
istioctl proxy-config clusters <pod-name> -n <namespace>
```

#### Debugging Service Mesh

```bash
# View Envoy logs
kubectl logs <pod-name> -c istio-proxy -n <namespace>

# View sidecar logs
kubectl logs <pod-name> -c sidecar-redirect -n <namespace>

# Test connectivity
istioctl proxy-status | grep SYMBOLIC-NAME
istioctl proxy-config <pod-name> -n <namespace>

# Check certificate status
istioctl proxy-config <pod-name> -n <namespace> --type certificate

# Verify mTLS status
istioctl proxy-check <pod-name> -n <namespace>
```

#### Managing Configuration

```bash
# List all Istio resources
kubectl get virtualservices -A
kubectl get destinationrules -A
kubectl get gateways -A
kubectl get servicesettings -A

# Dry-run configuration
istioctl analyze -I manifest.yaml

# Validate configuration
istioctl validate -f manifest.yaml

# Export configuration
istioctl proxy-config <pod-name> -n <namespace> -o json
```

#### Upgrading Istio

```bash
# Download new version
curl -L https://istio.io/downloadIstio | sh -
export PATH="$PATH:$(pwd)/istio-1.21.0/bin"

# Validate previous version
istioctl analyze

# Upgrade istioctl
istioctl upgrade --version 1.21.0

# Or use upgrade command
istioctl upgrade -y --version 1.21.0

# Verify upgrade
istioctl version
kubectl get pods -n istio-system
```

---

### 5. Best Practices

#### Configuration Best Practices

1. **Namespace Isolation**: Use dedicated namespaces for different mesh components
2. **Resource Limits**: Set appropriate CPU and memory limits for Istio components
3. **Auto-Injection**: Enable sidecar injection selectively by namespace
4. **Version Management**: Always use specific Istio versions in production
5. **Rolling Updates**: Use rolling updates for Istio control plane
6. **Backup Configuration**: Backup Istio configurations regularly
7. **Network Policies**: Configure network policies for mesh security
8. **Monitoring**: Enable metrics collection for all mesh components

#### Security Best Practices

1. **Enable mTLS**: Always enable strict mTLS in production
2. **Rotate Certificates**: Regularly rotate root and intermediate certificates
3. **Use Pod Security Policies**: Restrict pod capabilities
4. **Network Policies**: Implement network policies for micro-segmentation
5. **RBAC**: Configure RBAC for Istio resources
6. **Audit Logging**: Enable audit logging for security analysis
7. **Secret Management**: Use external secret management
8. **Image Verification**: Use verified Istio images

#### Observability Best Practices

1. **Collect All Metrics**: Enable comprehensive metrics collection
2. **Distributed Tracing**: Integrate with Jaeger or Zipkin
3. **Centralized Logging**: Configure centralized logging
4. **Dashboards**: Create Grafana dashboards for mesh metrics
5. **Alerting**: Set up alerts for mesh health
6. **Service Graph**: Monitor service dependency graph
7. **Latency Tracking**: Track request latency across services
8. **Error Rates**: Monitor error rates and trends

#### Performance Best Practices

1. **Optimize Sidecar**: Configure sidecar resource limits appropriately
2. **Disable Unused Features**: Disable features you don't use
3. **Use CRDs Efficiently**: Limit the number of Istio CRDs
4. **Network Optimization**: Configure network policies for optimal performance
5. **Caching**: Enable caching where appropriate
6. **Compression**: Enable HTTP compression
7. **Connection Pooling**: Configure connection pooling
8. **Load Balancing**: Choose appropriate load balancing strategies

*Content generated automatically. Verify against official documentation before production use.*

## Examples

### Virtual Service with Canary Deployment


```yaml
# Virtual Service with traffic splitting for canary deployment
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: myapp
  namespace: production
spec:
  hosts:
  - myapp.production.svc.cluster.local
  http:
  # Main traffic (90%)
  - route:
    - destination:
        host: myapp.production.svc.cluster.local
        subset: main
      weight: 90
    - destination:
        host: myapp.production.svc.cluster.local
        subset: canary
      weight: 10
    headers:
      request:
        add:
          x-deployment: canary
    match:
    - headers:
        x-canary:
          exact: "true"
    route:
    - destination:
        host: myapp.production.svc.cluster.local
        subset: canary
  subsets:
  - name: main
    labels:
      version: v1
  - name: canary
    labels:
      version: v2
```

### PeerAuthentication for Strict mTLS


```yaml
# Enforce strict mTLS across the mesh
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: production
spec:
  mtls:
    mode: STRICT
---
  related-skills: cncf-argo, cncf-artifact-hub, cncf-aws-eks, cncf-azure-aks
# Permissive mode for gradual migration
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: production-policy
  namespace: production
spec:
  mtls:
    mode: PERMISSIVE
```

### Gateway with TLS Termination


```yaml
# Ingress Gateway with TLS termination
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: myapp-gateway
  namespace: production
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    tls:
      mode: SIMPLE
      credentialName: myapp-tls-cert
    hosts:
    - myapp.example.com
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - myapp.example.com
    tls:
      httpsRedirect: true
```

---

## When to Use

Use this skill when:

- **Integrating a CNCF project into Kubernetes infrastructure** — You need to configure, deploy, or troubleshoot a cloud-native tool within a cluster
- **Designing cloud-native architecture** — You are selecting and integrating CNCF tools to solve specific infrastructure challenges
- **Resolving operational issues** — A CNCF component is misbehaving, underperforming, or needs configuration changes
---

## Core Workflow

1. **Assess Requirements** — Understand the use case, scale, integration needs, and existing infrastructure. **Checkpoint:** Document requirements, constraints, and success criteria.

2. **Design Architecture** — Plan component interactions, data flow, and deployment strategy using cloud-native best practices. **Checkpoint:** Verify the architecture addresses all requirements and follows CNCF conventions.

3. **Implement & Configure** — Create manifests, configurations, and deployment scripts. Include resource limits, health checks, and observability hooks. **Checkpoint:** Validate all YAML against schema and test in a staging environment.

4. **Deploy & Monitor** — Apply manifests to the cluster, verify component health, and confirm observability is working. **Checkpoint:** Confirm all pods/services are running, probes passing, and metrics/alerts configured.

---

## Constraints

### MUST DO
- Include at least one complete working YAML manifest example
- Note when content is auto-generated vs. manually verified
- Reference relevant CNCF project documentation

### MUST NOT DO
- Deploy manifests without testing in a staging environment first
- Use deprecated API versions (e.g., apps/v1beta1)
- Omit resource limits and requests in Kubernetes manifests

---

## Live References

> **These links are resolved at load time** — content is fetched and inlined to provide the latest documentation.

- [Istio Documentation](https://istio.io/latest/docs/)
- [Istio Traffic Management](https://istio.io/latest/docs/tasks/traffic-management/)
- [Istio Security](https://istio.io/latest/docs/tasks/security/)
- [Istio VirtualService Reference](https://istio.io/latest/docs/reference/config/networking/virtual-service/)
- [Istio DestinationRule Reference](https://istio.io/latest/docs/reference/config/networking/destination-rule/)
- [Istio PeerAuthentication Reference](https://istio.io/latest/docs/reference/config/security/peer_authentication/)