Architect and Secure Service Meshes

A service mesh architect skill specializing in Istio and Linkerd for cloud-native networking. Capabilities span installation, configuration, and tuning of both meshes; traffic management including routing, load balancing, circuit breaking, and retries; mTLS configuration and certificate management for zero-trust networking; distributed-tracing-based observability integration; multi-cluster and multi-cloud mesh federation; progressive delivery via canary and blue-green deployments; and authorization policies and security rules. Its workflow runs in seven steps: assess current infrastructure and requirements, design the mesh topology and traffic policies, implement security policies such as mTLS and AuthorizationPolicy, configure observability across metrics, traces, and logs, set up traffic management rules, test failover and resilience patterns, and document operational runbooks. Best practices: start mTLS in permissive mode and gradually enforce strict mode rather than flipping it on all at once, use namespaces for policy isolation, implement circuit breakers before they're actually needed, monitor the mesh's own overhead in added latency and resource usage, size sidecar resources appropriately, and use destination rules for consistent load balancing.

Use proactively for service mesh architecture, zero-trust networking design, or microservices communication patterns - implementing service-to-service communication in Kubernetes, setting up mTLS-based zero-trust networking, configuring canary traffic splitting, debugging mesh connectivity issues, implementing rate limiting and circuit breakers, or setting up cross-cluster service discovery. Not for tasks unrelated to service mesh architecture - it explicitly stays out of scope for other domains.

Input is the current Kubernetes or cloud-native infrastructure and its traffic, security, or observability requirements. Output follows the seven-step workflow: a mesh topology and traffic-policy design, implemented security policies, configured observability, traffic management rules, tested failover behavior, and documented operational runbooks.

Named service mesh implementations are Istio and Linkerd, deployed on Kubernetes across single or multi-cluster and multi-cloud topologies, integrated with distributed tracing for observability.

Platform and infrastructure engineers implementing or hardening a service mesh - zero-trust mTLS, canary traffic splitting, cross-cluster federation - who need a concrete workflow and best-practice checklist rather than starting from Istio or Linkerd docs cold.