Configure and Secure Service Meshes

This skill provides service mesh architecture and configuration guidance, with deep, config-level coverage of Istio and Linkerd (and background knowledge of Consul Connect and AWS App Mesh as other popular solutions). It's built around two core principle sets: traffic management fundamentals (progressive deployment via traffic splitting for canary and blue-green releases, circuit breaking to prevent cascade failures, load-balancing algorithm selection, and conservative timeout/retry defaults with service-specific overrides) and security by default (zero-trust networking that denies all traffic unless explicitly allowed, automatic mutual TLS everywhere, identity-based rather than network-based security, and policy-as-code with version control).

For Istio, it covers Gateway and VirtualService setup for HTTPS ingress with weighted traffic-split routing and per-route timeout/retry policies, DestinationRule configuration for connection pooling, circuit breaking, and load-balancer selection across versioned subsets, and security policies combining PeerAuthentication (strict mTLS) with AuthorizationPolicy (principal- and header-based access rules). For Linkerd, it covers TrafficSplit resources for weighted canary routing and ServerPolicy resources that restrict a service to specific path/method combinations. It also covers multi-cluster configuration via ServiceEntry and DestinationRule for external services, and observability configuration through a Telemetry resource wired to a Prometheus provider.

Performance guidance includes sidecar resource sizing (starting at 100m CPU / 128Mi memory), control-plane sizing (2-4 cores, 4-8GB RAM), and Pilot memory estimation (roughly 1MB per service plus 0.5MB per pod), plus configuration-scope optimizations like exportTo and namespace-scoped policies. Migration guidance recommends adopting the mesh namespace-by-namespace and service-by-service (via the sidecar.istio.io/inject annotation), validating policies in permissive mode before enforcing them, and establishing monitoring before adding security policies, with rollback supported by GitOps-versioned configuration, documented emergency bypass procedures, feature-flagged policy enforcement, and automated rollback triggers on error-rate thresholds.

istioctl proxy-config cluster <pod-name> -n <namespace>
istioctl analyze -n <namespace>

Use this skill when designing or troubleshooting an Istio or Linkerd service mesh - traffic splitting for canary releases, mTLS and authorization policy setup, circuit breaking and load-balancer tuning, multi-cluster service entries, or a phased namespace-by-namespace adoption rollout.

It is not a fit as a deep reference for Consul Connect or AWS App Mesh specifically - those are named as related solutions but the concrete YAML patterns and troubleshooting commands here are Istio- and Linkerd-specific.

Inputs are your service names, namespaces, and the traffic-management or security behavior you want (canary weights, timeout/retry values, mTLS mode, authorization rules). Outputs are working Kubernetes-native YAML manifests (Gateway, VirtualService, DestinationRule, PeerAuthentication, AuthorizationPolicy, TrafficSplit, ServerPolicy, ServiceEntry, Telemetry) plus istioctl commands for verifying proxy configuration, mTLS status, and routing behavior.

Platform and SRE teams operating microservices on Istio or Linkerd who need concrete, ready-to-adapt manifests for canary traffic splitting, zero-trust mTLS enforcement, circuit breaking, and multi-cluster service entries, plus a phased rollout and rollback plan for adopting the mesh safely across an existing cluster.