What this prompt does
This prompt drives the AI to produce a full Istio service mesh configuration for a [service_count]-service architecture on [cluster_type]. It covers installation with the [install_profile] profile and sidecar injection for [namespace], traffic management for [primary_service] using [routing_strategy], STRICT mutual TLS, circuit breaking for [fragile_service], local rate limiting on [rate_limited_service], observability via [observability_stack], a gateway with [auth_method], and a canary split sending [canary_percent]% to a new version of [canary_service].
The structure works because it maps to the concrete Istio resources you actually apply — VirtualService, DestinationRule, PeerAuthentication, and Gateway — rather than describing the mesh abstractly. Circuit breaking is keyed to real numbers ([max_conn] connections, [error_threshold] consecutive errors before ejection), so outlier detection on a fragile external dependency is configured precisely. Naming [fragile_service] and [rate_limited_service] separately keeps the resilience controls targeted where they matter instead of applied uniformly. Scoping the install to [service_count] services with the [install_profile] profile also keeps the mesh footprint proportional to the estate, rather than enabling features you will never use.
When to use it
- A microservices estate has outgrown ad-hoc networking and needs mTLS, traffic control, and tracing in one place.
- You want STRICT mutual TLS between services with a PERMISSIVE ingress for external traffic.
- A fragile external dependency like a payment gateway needs circuit breaking so one slow service cannot cascade.
- You need local rate limiting on a public-facing service to protect it from bursts.
- You are rolling out a new version and want a controlled canary split via traffic weighting.
- You want service dependency visualization and distributed tracing wired up from the start.
Example output
Expect a set of Istio manifests grouped by concern: install configuration, VirtualService and DestinationRule pairs for [primary_service], a PeerAuthentication policy for mTLS, a DestinationRule with connection-pool and outlier-detection settings for [fragile_service], an EnvoyFilter or rate-limit config for [rate_limited_service], gateway and RequestAuthentication resources, and a canary traffic-split definition. Each block is annotated with what it does.
Pro tips
- Get outlier detection on
[fragile_service]right first — tuning[max_conn]and[error_threshold]is usually what stops one slow dependency from taking down the rest. - Start mTLS in PERMISSIVE mode mesh-wide before flipping
[namespace]to STRICT, so you can confirm every workload has a sidecar without breaking traffic. - Match
[routing_strategy]to a real need; header-based routing is great for A/B tests but adds rules you must maintain, so do not add it speculatively. - Keep
[canary_percent]small to begin with and increase it only after the[observability_stack]shows the new version is healthy. - Confirm sidecar injection is actually enabled on
[namespace]before debugging policy; missing sidecars cause symptoms that look like misconfiguration. - Use the
[auth_method]gateway config as the single external entry point rather than exposing services directly, so authentication stays in one place. - Apply traffic-management rules to
[primary_service]incrementally and watch the[observability_stack]between changes, since a mistaken VirtualService can silently blackhole traffic.
