{"id":25,"date":"2026-04-12T13:51:27","date_gmt":"2026-04-12T13:51:27","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/alibaba-cloud-service-mesh-asm-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-container\/"},"modified":"2026-04-12T13:51:27","modified_gmt":"2026-04-12T13:51:27","slug":"alibaba-cloud-service-mesh-asm-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-container","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/alibaba-cloud-service-mesh-asm-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-container\/","title":{"rendered":"Alibaba Cloud Service Mesh (ASM) Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Container"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Category<\/h2>\n\n\n\n<p>Container<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Introduction<\/h2>\n\n\n\n<p>Alibaba Cloud <strong>Service Mesh (ASM)<\/strong> is a managed service mesh offering for Kubernetes-based microservices, designed to standardize <strong>traffic management, security (mTLS), and observability<\/strong> across services\u2014without requiring application code changes in most cases.<\/p>\n\n\n\n<p>In simple terms: you deploy your applications on Kubernetes (typically <strong>Alibaba Cloud Container Service for Kubernetes (ACK)<\/strong>), then ASM injects a <strong>sidecar proxy<\/strong> next to each workload. Those proxies handle service-to-service communication features like retries, timeouts, canary releases, and encryption\u2014centrally and consistently.<\/p>\n\n\n\n<p>Technically, ASM provides a <strong>managed Istio-compatible control plane<\/strong> and integrates it with your Kubernetes clusters. Your applications keep using normal Kubernetes Services, while the mesh uses Envoy sidecars (data plane) and Istio APIs\/CRDs (control plane configuration) to enforce policies and routing.<\/p>\n\n\n\n<p>ASM solves common microservices problems:\n&#8211; \u201cHow do we do safe canary releases across dozens of services?\u201d\n&#8211; \u201cHow do we get consistent mTLS and authorization between services?\u201d\n&#8211; \u201cHow do we observe service-to-service traffic with standard metrics, logs, and traces?\u201d\n&#8211; \u201cHow do we apply governance without rewriting every application?\u201d<\/p>\n\n\n\n<blockquote>\n<p>Naming\/Status note: The official product name is <strong>Alibaba Cloud Service Mesh (ASM)<\/strong>. If your account shows different labels or editions, <strong>verify in official docs<\/strong> because naming and editions can vary by region and console updates.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is Service Mesh (ASM)?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Official purpose<\/h3>\n\n\n\n<p>Service Mesh (ASM) is Alibaba Cloud\u2019s managed service mesh service, intended to help teams run microservices on Kubernetes with consistent:\n&#8211; <strong>Traffic management<\/strong> (routing, load balancing rules, circuit breaking patterns)\n&#8211; <strong>Security<\/strong> (mTLS, identity-based access control)\n&#8211; <strong>Observability<\/strong> (metrics, logs, traces)<\/p>\n\n\n\n<p>ASM is generally positioned as \u201cmanaged Istio\u201d (Istio-compatible APIs and architecture). Exact supported Istio versions and feature availability can vary\u2014<strong>verify in official docs<\/strong>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Core capabilities<\/h3>\n\n\n\n<p>Common, practical capabilities you should expect from ASM (and validate in your region\/edition):\n&#8211; Sidecar-based <strong>data plane<\/strong> for L7\/L4 traffic control (Envoy proxies)\n&#8211; <strong>Istio APIs\/CRDs<\/strong> for routing and policy configuration\n&#8211; <strong>mTLS<\/strong> for service-to-service encryption and identity\n&#8211; <strong>Ingress\/Egress gateways<\/strong> for north-south traffic patterns (where enabled)\n&#8211; <strong>Observability integration<\/strong> (metrics\/logging\/tracing) via Alibaba Cloud services and\/or common OSS tooling (availability depends on edition and integration choices)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Major components (conceptual)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Control plane (managed by ASM)<\/strong>: configuration distribution, certificate management, policy\/routing evaluation.<\/li>\n<li><strong>Data plane (in your clusters)<\/strong>: sidecar proxies (Envoy) deployed alongside your pods; optionally gateways.<\/li>\n<li><strong>Mesh configuration<\/strong>: Istio resources such as <code>VirtualService<\/code>, <code>DestinationRule<\/code>, <code>Gateway<\/code>, <code>PeerAuthentication<\/code>, and <code>AuthorizationPolicy<\/code> (actual CRDs available depend on the ASM-managed Istio profile\/version).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Service type<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Managed control plane<\/strong> (SaaS-like) + <strong>in-cluster agents\/components<\/strong> (Kubernetes add-ons and sidecars).<\/li>\n<li>You keep ownership of your Kubernetes clusters and workloads; ASM manages the mesh control plane lifecycle depending on your chosen model.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scope: regional \/ account \/ cluster<\/h3>\n\n\n\n<p>In practice, ASM is typically:\n&#8211; <strong>Region-scoped<\/strong> (you create an ASM instance in a region and attach one or more Kubernetes clusters in that region and network context).\n&#8211; <strong>Account-scoped<\/strong> within your Alibaba Cloud account and governed by RAM policies.\n&#8211; <strong>Cluster-attached<\/strong>: you explicitly add ACK clusters to the mesh.<\/p>\n\n\n\n<p>Exact scoping (cross-region, cross-VPC, multi-cluster topology) depends on ASM features and your network design\u2014<strong>verify in official docs<\/strong>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How it fits into the Alibaba Cloud ecosystem<\/h3>\n\n\n\n<p>ASM usually sits in the \u201cContainer + Microservices governance\u201d layer and integrates most often with:\n&#8211; <strong>ACK (Container Service for Kubernetes)<\/strong>: primary runtime for mesh workloads\n&#8211; <strong>VPC<\/strong>: network foundation for clusters and service-to-service traffic\n&#8211; <strong>RAM<\/strong>: permissions and access control for operators\n&#8211; <strong>SLB\/NLB\/ALB<\/strong> (product availability varies): ingress exposure and load balancing options\n&#8211; <strong>Log Service (SLS)<\/strong>: centralized logging (including proxy access logs if enabled)\n&#8211; <strong>Application Real-Time Monitoring Service (ARMS)<\/strong>: metrics and APM-style visibility (integration depends on setup)<\/p>\n\n\n\n<p>Use ASM when you want standardized governance without running and upgrading Istio yourself.<\/p>\n\n\n\n<p>Official docs starting point (verify current URLs if your region differs):\n&#8211; https:\/\/www.alibabacloud.com\/help\/en\/asm\/<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use Service Mesh (ASM)?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Business reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Faster, safer releases<\/strong>: canary, blue\/green, traffic splitting, and progressive delivery patterns reduce outage risk.<\/li>\n<li><strong>Standardized governance<\/strong> across teams: central policies apply to many services without per-app changes.<\/li>\n<li><strong>Reduced platform toil<\/strong>: managed control plane reduces the operational burden compared to self-managed Istio.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Technical reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Consistent L7 traffic behavior<\/strong>: retries, timeouts, header-based routing, fault injection (if supported).<\/li>\n<li><strong>Service-to-service security<\/strong>: mTLS identity and encryption across microservices.<\/li>\n<li><strong>Better multi-service debugging<\/strong>: consistent telemetry from proxies improves root-cause analysis.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Central configuration<\/strong>: governance via Istio CRDs rather than app config sprawl.<\/li>\n<li><strong>Unified observability<\/strong>: mesh-level metrics, logs, and traces help SREs correlate incidents.<\/li>\n<li><strong>Change control<\/strong>: routing policies can be rolled out and reviewed like code (GitOps).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/compliance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Encryption in transit<\/strong> for east-west traffic (mTLS).<\/li>\n<li><strong>Identity-based policies<\/strong>: allow\/deny communication based on workload identities and namespaces.<\/li>\n<li><strong>Auditability<\/strong>: change history via Kubernetes manifests; plus cloud audit logs where integrated.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scalability\/performance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Traffic shaping<\/strong> and outlier detection patterns can protect services under load.<\/li>\n<li><strong>Resilience patterns<\/strong> at the network layer reduce cascading failures (within limits).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should choose it<\/h3>\n\n\n\n<p>Choose ASM when:\n&#8211; You run (or are moving to) <strong>Kubernetes microservices on ACK<\/strong>\n&#8211; You need <strong>consistent traffic control and security<\/strong> across many services\n&#8211; You want <strong>managed mesh operations<\/strong> instead of owning Istio upgrades, compatibility, and CVE patching yourself<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should not choose it<\/h3>\n\n\n\n<p>Avoid (or delay) ASM when:\n&#8211; You have a small number of services and don\u2019t need mesh features (sidecars add complexity and overhead)\n&#8211; You rely heavily on non-HTTP protocols or edge cases where Envoy\/Istio behavior may be surprising (validate first)\n&#8211; Your organization is not ready for the operational model (CRDs, debugging proxies, certificate lifecycle)\n&#8211; You cannot tolerate additional latency\/CPU\/memory overhead from sidecars<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is Service Mesh (ASM) used?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Industries<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>E-commerce and retail (high-change, high-traffic services)<\/li>\n<li>FinTech and banking (mTLS, policy enforcement, audit requirements)<\/li>\n<li>SaaS platforms (multi-tenant traffic controls and observability)<\/li>\n<li>Gaming and media (high throughput, resilience patterns)<\/li>\n<li>Telecom and IoT platforms (large service graphs and operational governance)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Team types<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Platform engineering teams building internal developer platforms on ACK<\/li>\n<li>SRE\/operations teams standardizing telemetry and policies<\/li>\n<li>DevOps teams implementing progressive delivery<\/li>\n<li>Security engineering teams enforcing east-west encryption and segmentation<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Workloads<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Kubernetes microservices (HTTP\/gRPC commonly)<\/li>\n<li>API backends and service graphs with many dependencies<\/li>\n<li>Hybrid environments (where supported): multi-cluster designs, shared services, staged migrations<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Architectures<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Microservices (service-per-team)<\/li>\n<li>Event-driven microservices (mesh for synchronous dependencies; event bus separately)<\/li>\n<li>Multi-cluster active\/active or active\/passive (validate ASM multi-cluster features)<\/li>\n<li>Zero-trust internal networks (mesh + network policies)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Real-world deployment contexts<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Production meshes for core business services<\/li>\n<li>Dev\/test meshes for validating routing rules and mTLS<\/li>\n<li>Migration phases: gradually onboarding namespaces\/services to the mesh<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">5. Top Use Cases and Scenarios<\/h2>\n\n\n\n<p>Below are practical scenarios where Alibaba Cloud Service Mesh (ASM) is commonly used.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Canary releases with traffic splitting<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> You need to ship a new version without risking full blast radius.<\/li>\n<li><strong>Why ASM fits:<\/strong> Route a percentage of traffic to v2 while keeping v1 stable, controlled by mesh config.<\/li>\n<li><strong>Example:<\/strong> 90% to <code>reviews-v1<\/code>, 10% to <code>reviews-v2<\/code>, then ramp up.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Blue\/green cutover for critical services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> You want near-instant rollback for risky changes.<\/li>\n<li><strong>Why ASM fits:<\/strong> Route by header\/cookie or switch all traffic between two versions quickly.<\/li>\n<li><strong>Example:<\/strong> Switch <code>payments<\/code> traffic from green to blue with one config change.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Enforcing mTLS for east-west encryption<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Internal service calls traverse shared networks and must be encrypted.<\/li>\n<li><strong>Why ASM fits:<\/strong> Mesh-issued identities and mTLS encrypt service-to-service calls.<\/li>\n<li><strong>Example:<\/strong> Set namespace policy to require mTLS and block plaintext.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Service-to-service authorization (zero trust within cluster)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Any service can call any other service by default.<\/li>\n<li><strong>Why ASM fits:<\/strong> Authorization policies can restrict calls by namespace\/service identity.<\/li>\n<li><strong>Example:<\/strong> Only <code>frontend<\/code> can call <code>catalog<\/code>; others denied.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Standardized retries\/timeouts (resilience)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Teams implement retries inconsistently, causing thundering herds or timeouts.<\/li>\n<li><strong>Why ASM fits:<\/strong> Central traffic policies reduce inconsistency and can be applied per service.<\/li>\n<li><strong>Example:<\/strong> Add a 2s timeout and limited retries to <code>inventory<\/code> calls.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Circuit breaking \/ outlier handling patterns<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A failing instance causes repeated errors and cascading failures.<\/li>\n<li><strong>Why ASM fits:<\/strong> Mesh-level outlier detection can reduce impact (capabilities vary; validate).<\/li>\n<li><strong>Example:<\/strong> Eject unhealthy pods from load balancing pool after consecutive 5xx errors.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Unified observability for microservices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Hard to trace cross-service latency and error hotspots.<\/li>\n<li><strong>Why ASM fits:<\/strong> Sidecars emit consistent metrics and can propagate trace headers (setup required).<\/li>\n<li><strong>Example:<\/strong> Identify that 80% of checkout latency comes from <code>recommendations<\/code>.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Safer migrations between services or clusters<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> You\u2019re splitting a monolith into microservices or moving traffic between clusters.<\/li>\n<li><strong>Why ASM fits:<\/strong> Routing control helps shift traffic gradually while observing behavior.<\/li>\n<li><strong>Example:<\/strong> Route only a subset of users to the new <code>user-profile<\/code> service.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Multi-tenant platform isolation (logical)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Different tenants\/teams share a cluster but require isolation.<\/li>\n<li><strong>Why ASM fits:<\/strong> Mesh policies can restrict cross-namespace traffic; combined with Kubernetes RBAC.<\/li>\n<li><strong>Example:<\/strong> Tenant A namespace cannot call Tenant B namespace services.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Controlled egress to external dependencies<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Services call external APIs; you need visibility and control.<\/li>\n<li><strong>Why ASM fits:<\/strong> Egress policies\/gateways can centralize external access patterns (validate in ASM).<\/li>\n<li><strong>Example:<\/strong> Force all outbound traffic to go via an egress gateway with logs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">11) Header-based routing for experiments (A\/B tests)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> You want to test features for a subset of users.<\/li>\n<li><strong>Why ASM fits:<\/strong> Route requests with specific headers to experimental service versions.<\/li>\n<li><strong>Example:<\/strong> Requests with <code>x-exp: on<\/code> go to <code>search-v2<\/code>.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">12) Gradual enabling of security policies<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Turning on mTLS everywhere breaks legacy clients.<\/li>\n<li><strong>Why ASM fits:<\/strong> Use permissive mode first, then strict, service-by-service.<\/li>\n<li><strong>Example:<\/strong> Enable permissive mTLS in a namespace, fix non-mesh clients, then enforce strict.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">6. Core Features<\/h2>\n\n\n\n<blockquote>\n<p>Feature availability can vary by ASM edition, region, and supported Istio version. Treat specifics as \u201ccheck your console + official docs\u201d.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Managed service mesh control plane<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Runs and manages the service mesh control plane for you.<\/li>\n<li><strong>Why it matters:<\/strong> Reduces operational overhead (upgrades, HA setup, control plane scaling).<\/li>\n<li><strong>Practical benefit:<\/strong> Platform teams focus on policies and architecture rather than Istio maintenance.<\/li>\n<li><strong>Caveats:<\/strong> You still own <strong>data plane<\/strong> resource usage and troubleshooting in your clusters.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Sidecar injection and data plane governance<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Injects Envoy sidecars into pods to intercept and manage traffic.<\/li>\n<li><strong>Why it matters:<\/strong> Sidecars are how L7 policies get enforced consistently.<\/li>\n<li><strong>Practical benefit:<\/strong> Uniform traffic telemetry and policy enforcement without code changes.<\/li>\n<li><strong>Caveats:<\/strong> Adds CPU\/memory overhead and potential latency; requires careful resource sizing.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Traffic management via Istio APIs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Supports routing rules using Istio CRDs such as:<\/li>\n<li><code>VirtualService<\/code> (routing)<\/li>\n<li><code>DestinationRule<\/code> (subsets\/traffic policies)<\/li>\n<li><code>Gateway<\/code> (ingress configuration)<\/li>\n<li><strong>Why it matters:<\/strong> Enables safe releases and complex routing without modifying apps.<\/li>\n<li><strong>Practical benefit:<\/strong> Canary, blue\/green, header-based routing, fault injection (if supported).<\/li>\n<li><strong>Caveats:<\/strong> Misconfiguration can cause outages; treat policies as production code.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Service-to-service security (mTLS)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Encrypts service-to-service traffic and authenticates workloads.<\/li>\n<li><strong>Why it matters:<\/strong> Protects data in transit and establishes workload identity.<\/li>\n<li><strong>Practical benefit:<\/strong> Helps meet internal security and compliance requirements.<\/li>\n<li><strong>Caveats:<\/strong> Legacy clients, non-mesh workloads, and some protocols may need special handling.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Authorization policies (service-to-service access control)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Allows\/denies requests based on identity, namespace, workload labels, and request attributes.<\/li>\n<li><strong>Why it matters:<\/strong> Implements zero-trust patterns inside Kubernetes.<\/li>\n<li><strong>Practical benefit:<\/strong> Prevent lateral movement and accidental overreach between teams.<\/li>\n<li><strong>Caveats:<\/strong> Policies must be tested carefully; overly strict rules can break dependencies.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Observability: metrics, logs, traces (mesh telemetry)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Sidecars can emit traffic metrics (latency, RPS, error rates), logs, and tracing context.<\/li>\n<li><strong>Why it matters:<\/strong> Microservices are hard to observe without consistent telemetry.<\/li>\n<li><strong>Practical benefit:<\/strong> Faster incident triage and dependency mapping.<\/li>\n<li><strong>Caveats:<\/strong> Telemetry collection can add cost; ensure retention and sampling strategies.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Ingress and egress control (mesh gateways)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Central gateways can manage north-south and outbound traffic (depending on setup).<\/li>\n<li><strong>Why it matters:<\/strong> Standardizes edge behavior and auditing.<\/li>\n<li><strong>Practical benefit:<\/strong> Unified TLS termination patterns, routing rules, and access logging.<\/li>\n<li><strong>Caveats:<\/strong> Gateway capacity planning becomes critical; also introduces another hop.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Multi-cluster \/ mesh expansion (where supported)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Attach multiple clusters to one mesh for consistent governance.<\/li>\n<li><strong>Why it matters:<\/strong> Enables staged migrations and regional resilience designs.<\/li>\n<li><strong>Practical benefit:<\/strong> Central policy management across clusters.<\/li>\n<li><strong>Caveats:<\/strong> Multi-cluster networking and DNS\/service discovery are complex; verify supported topologies.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">7. Architecture and How It Works<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">High-level architecture<\/h3>\n\n\n\n<p>ASM follows the common service mesh model:\n&#8211; A <strong>managed control plane<\/strong> distributes configuration and certificates.\n&#8211; Each pod in the mesh runs an <strong>Envoy sidecar<\/strong> proxy.\n&#8211; Traffic between services flows through sidecars, which enforce routing and security policies.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Request\/data\/control flow<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Control flow:<\/strong> You apply configuration (Istio CRDs) to the Kubernetes API server. ASM control plane watches those resources and pushes configuration to sidecars.<\/li>\n<li><strong>Data flow:<\/strong> Requests go from client pod \u2192 client sidecar \u2192 network \u2192 server sidecar \u2192 server pod.<\/li>\n<li><strong>Security flow:<\/strong> Mesh-issued certs enable mutual authentication; policies determine whether requests are allowed.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Integrations with related services (common patterns)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>ACK:<\/strong> primary Kubernetes runtime and API server for mesh resources.<\/li>\n<li><strong>VPC:<\/strong> pod-to-pod and service-to-service networking.<\/li>\n<li><strong>SLB\/NLB\/ALB:<\/strong> exposes ingress gateway or Kubernetes Ingress (depending on design).<\/li>\n<li><strong>ARMS \/ Prometheus-compatible monitoring:<\/strong> metrics and dashboards (implementation options vary).<\/li>\n<li><strong>SLS:<\/strong> proxy access logs and application logs collection.<\/li>\n<\/ul>\n\n\n\n<p>Exact integration steps depend on your environment; always validate with the ASM docs for your region.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Dependency services<\/h3>\n\n\n\n<p>Typical dependencies you should account for:\n&#8211; ACK cluster(s)\n&#8211; VPC\/subnets, security groups\n&#8211; Load balancer resources for ingress gateways (if exposed)\n&#8211; Log\/metrics backends for observability<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/authentication model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Operator access:<\/strong> Alibaba Cloud RAM users\/roles control who can manage ASM and ACK.<\/li>\n<li><strong>Workload identity:<\/strong> Mesh identities are derived from Kubernetes service accounts and mesh CA certificates (Istio model).<\/li>\n<li><strong>Encryption in transit:<\/strong> mTLS for east-west traffic (configurable per namespace\/workload).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Networking model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Sidecars intercept traffic via iptables rules in pods (typical sidecar model).<\/li>\n<li>Service discovery typically relies on Kubernetes Services and DNS.<\/li>\n<li>For multi-cluster, you must plan:<\/li>\n<li>network reachability between clusters<\/li>\n<li>service discovery across clusters<\/li>\n<li>gateway placement and TLS\n  (Verify ASM\u2019s supported multi-cluster modes.)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Monitoring\/logging\/governance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Decide early on:<\/li>\n<li>Where metrics live (Prometheus, ARMS, managed Prometheus, etc.)<\/li>\n<li>Where traces go (Jaeger\/Zipkin\/ARMS APM depending on availability)<\/li>\n<li>Where access logs go (SLS often)<\/li>\n<li>Treat mesh configs as code:<\/li>\n<li>GitOps with review gates<\/li>\n<li>policy testing in staging meshes<\/li>\n<li>controlled rollouts<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Simple architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart LR\n  U[User \/ Client] --&gt; LB[Load Balancer \/ Ingress]\n  LB --&gt; IGW[Ingress Gateway (Envoy)]\n  IGW --&gt; SVC1[Service A Pod]\n  SVC1 --&gt;|mTLS| SVC2[Service B Pod]\n\n  subgraph PodA[Pod: Service A]\n    AAPP[App Container]\n    APX[Envoy Sidecar]\n    AAPP &lt;--&gt; APX\n  end\n\n  subgraph PodB[Pod: Service B]\n    BAPP[App Container]\n    BPX[Envoy Sidecar]\n    BAPP &lt;--&gt; BPX\n  end\n\n  SVC1 --- PodA\n  SVC2 --- PodB\n\n  CP[ASM Managed Control Plane] --&gt; APX\n  CP --&gt; BPX\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Production-style architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart TB\n  subgraph AlibabaCloud[Alibaba Cloud Account]\n    subgraph VPC[VPC]\n      subgraph ACK1[ACK Cluster A]\n        NS1[Namespace: prod]\n        GW1[Ingress Gateway Service (LB)]\n        MS1[Microservices + Sidecars]\n        OBS1[Telemetry Collectors (optional)]\n      end\n\n      subgraph ACK2[ACK Cluster B]\n        NS2[Namespace: prod]\n        GW2[East-West \/ Ingress Gateway (optional)]\n        MS2[Microservices + Sidecars]\n      end\n\n      SLS[(Log Service - SLS)]\n      ARMS[(ARMS \/ Monitoring Backend)]\n      LBEXT[Public\/Private Load Balancer]\n    end\n\n    ASMCP[Service Mesh (ASM)\\nManaged Control Plane]\n    RAM[RAM (IAM)]\n    ActionTrail[ActionTrail (Audit)]\n  end\n\n  Internet((Internet)) --&gt; LBEXT --&gt; GW1\n  GW1 --&gt; MS1\n  MS1 &lt;--&gt; MS2\n\n  ASMCP --&gt; MS1\n  ASMCP --&gt; MS2\n  MS1 --&gt; SLS\n  MS1 --&gt; ARMS\n  MS2 --&gt; SLS\n  MS2 --&gt; ARMS\n\n  RAM --&gt; ASMCP\n  RAM --&gt; ACK1\n  RAM --&gt; ACK2\n  ActionTrail --&gt; AlibabaCloud\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">8. Prerequisites<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Account and billing<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>An active <strong>Alibaba Cloud account<\/strong> with billing enabled (Pay-as-you-go or subscription depending on your purchasing model).<\/li>\n<li>Ensure your account can create:<\/li>\n<li>ACK clusters<\/li>\n<li>ASM instances<\/li>\n<li>VPC resources<\/li>\n<li>Load balancers (if you expose ingress)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Permissions \/ IAM (RAM)<\/h3>\n\n\n\n<p>You\u2019ll typically need RAM permissions for:\n&#8211; Creating and managing <strong>ACK<\/strong> clusters and Kubernetes resources\n&#8211; Creating and managing <strong>ASM<\/strong>\n&#8211; Managing dependent networking and observability services<\/p>\n\n\n\n<p>Alibaba Cloud provides managed policies for many services (names can change). Common examples include \u201cfull access\u201d policies for ACK and ASM, but <strong>verify exact policy names in official docs<\/strong>:\n&#8211; ASM admin permissions (verify)\n&#8211; ACK\/Container Service admin permissions (verify)\n&#8211; VPC and SLB admin permissions (verify)\n&#8211; SLS\/ARMS permissions if you integrate observability<\/p>\n\n\n\n<p>Best practice: use least privilege and separate operator roles (platform, security, app teams).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Tools<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><code>kubectl<\/code> (required)<\/li>\n<li>Access to your ACK cluster kubeconfig (via ACK console)<\/li>\n<li>Optional (depending on ASM workflow):<\/li>\n<li><code>istioctl<\/code> for diagnostics (verify if ASM supports\/endorses a specific version)<\/li>\n<li>Helm (if you deploy add-ons)<\/li>\n<li>A terminal with network reachability to the ACK API endpoint (public or via VPN\/bastion depending on cluster exposure)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Region availability<\/h3>\n\n\n\n<p>ASM is not necessarily available in every Alibaba Cloud region, and features can vary. Pick a region where both <strong>ACK<\/strong> and <strong>ASM<\/strong> are supported. <strong>Verify in official docs\/console<\/strong>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas \/ limits<\/h3>\n\n\n\n<p>Potential limits you should check before production:\n&#8211; Number of clusters attachable to one ASM instance\n&#8211; Number of namespaces or workloads in the mesh\n&#8211; Control plane capacity limits by edition\n&#8211; Load balancer quotas (often a real constraint)\n&#8211; VPC and EIP quotas<\/p>\n\n\n\n<p>Check:\n&#8211; Alibaba Cloud Quotas Center (if applicable)\n&#8211; ASM product documentation for mesh limits<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>ACK cluster (managed Kubernetes)<\/li>\n<li>VPC, vSwitches (subnets), security groups<\/li>\n<li>Container registry (optional, if you build your own images)<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">9. Pricing \/ Cost<\/h2>\n\n\n\n<p>ASM pricing can vary by <strong>region<\/strong>, <strong>edition<\/strong>, and <strong>commercial model<\/strong>. Do not rely on fixed numbers from third parties; use official pricing pages and your console quote.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Current pricing model (how to think about it)<\/h3>\n\n\n\n<p>Typically, expect cost in these buckets:<\/p>\n\n\n\n<p>1) <strong>ASM service fee<\/strong>\n&#8211; Often billed per <strong>ASM instance<\/strong> and\/or by <strong>spec\/edition<\/strong> (control plane capacity, HA, features).\n&#8211; Some features (multi-cluster, advanced governance, etc.) may affect price depending on edition.\n&#8211; <strong>Verify pricing dimensions<\/strong> on the official ASM pricing page.<\/p>\n\n\n\n<p>2) <strong>ACK cluster costs<\/strong>\n&#8211; ACK clusters have their own pricing model (cluster management fee depending on type\/edition) plus worker node compute.<\/p>\n\n\n\n<p>3) <strong>Compute overhead for sidecars<\/strong>\n&#8211; Every meshed pod includes an Envoy sidecar, increasing:\n  &#8211; CPU usage\n  &#8211; memory usage\n  &#8211; network overhead\n&#8211; This increases ECS node sizing requirements or serverless billing.<\/p>\n\n\n\n<p>4) <strong>Load balancer costs<\/strong>\n&#8211; Ingress gateways typically require an SLB\/NLB\/ALB. These can be significant in production.<\/p>\n\n\n\n<p>5) <strong>Observability costs<\/strong>\n&#8211; Metrics ingestion\/retention (ARMS or managed Prometheus)\n&#8211; Log storage and indexing (SLS)\n&#8211; Tracing (if stored and queried)<\/p>\n\n\n\n<p>6) <strong>Network and data transfer<\/strong>\n&#8211; Cross-zone or cross-region traffic (if used) may add cost.\n&#8211; Egress to the Internet is often billed.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Free tier<\/h3>\n\n\n\n<p>ASM may or may not have a free tier, trial, or promotional credits depending on region\/time. <strong>Verify in official pricing<\/strong>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Hidden\/indirect costs to plan for<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Higher Kubernetes node count due to sidecar overhead<\/li>\n<li>Additional load balancers for gateways<\/li>\n<li>Increased log volume from proxy access logs<\/li>\n<li>Operational time for policy design, testing, and incident response training<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost optimization tips<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Mesh only what you need: start with a few namespaces\/services.<\/li>\n<li>Right-size sidecar resources (requests\/limits) to avoid node waste.<\/li>\n<li>Turn on access logging selectively (or sample).<\/li>\n<li>Use staging meshes for policy testing to reduce production mistakes.<\/li>\n<li>Minimize cross-zone traffic where possible; keep chatty services co-located.<\/li>\n<li>Prefer fewer gateways with adequate autoscaling rather than many underutilized gateways.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example low-cost starter estimate (conceptual)<\/h3>\n\n\n\n<p>A lab environment commonly includes:\n&#8211; 1 small ACK cluster (minimal worker nodes)\n&#8211; 1 ASM instance (smallest supported spec)\n&#8211; 1 load balancer (only if you need inbound access)\n&#8211; Minimal telemetry retention<\/p>\n\n\n\n<p>Because pricing is region\/edition-specific, <strong>estimate using official tools<\/strong>:\n&#8211; ASM pricing page: https:\/\/www.alibabacloud.com\/product\/asm (then follow pricing links in-console if needed)\n&#8211; Alibaba Cloud Pricing Calculator: https:\/\/www.alibabacloud.com\/pricing\/calculator (verify availability for ASM in your region)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Example production cost considerations<\/h3>\n\n\n\n<p>For production you should model:\n&#8211; Peak pod count \u00d7 sidecar overhead\n&#8211; HA gateways (multiple replicas) and load balancers\n&#8211; Telemetry ingestion at peak RPS\n&#8211; Multi-cluster interconnect costs (if applicable)\n&#8211; Long retention for audit\/compliance logs<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">10. Step-by-Step Hands-On Tutorial<\/h2>\n\n\n\n<p>This lab focuses on a safe, real workflow: create an ACK cluster, create an ASM instance, onboard a namespace, deploy two service versions, and do a canary traffic split using Istio resources.<\/p>\n\n\n\n<blockquote>\n<p>Important: Console steps can change. Use this tutorial as a practical guide, and <strong>follow the ASM \u201cGetting Started\u201d doc for your region<\/strong> when a console field differs.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Objective<\/h3>\n\n\n\n<p>Deploy a simple microservices demo on ACK, onboard it into <strong>Alibaba Cloud Service Mesh (ASM)<\/strong>, and perform a <strong>canary release<\/strong> using mesh traffic routing\u2014then validate and clean up.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Lab Overview<\/h3>\n\n\n\n<p>You will:\n1. Create or use an ACK cluster\n2. Create an ASM instance and attach the ACK cluster\n3. Enable sidecar injection for a namespace\n4. Deploy two versions of a service (<code>v1<\/code> and <code>v2<\/code>)\n5. Route traffic by weight (90\/10, then 50\/50)\n6. Optionally enforce mTLS (permissive \u2192 strict)\n7. Validate, troubleshoot, and clean up<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Create (or reuse) an ACK cluster<\/h3>\n\n\n\n<p><strong>Goal:<\/strong> Have a running Kubernetes cluster where you can deploy workloads.<\/p>\n\n\n\n<p>1) In the Alibaba Cloud console, go to:\n&#8211; <strong>Container Service for Kubernetes (ACK)<\/strong><\/p>\n\n\n\n<p>2) Create a cluster:\n&#8211; Choose a region where <strong>ASM is available<\/strong>\n&#8211; Choose a small, cost-effective node type for a lab\n&#8211; Ensure kubectl access is possible (public API endpoint or private access via VPN\/bastion)<\/p>\n\n\n\n<p>3) Download kubeconfig:\n&#8211; In ACK cluster details \u2192 <strong>Connection Information<\/strong> \u2192 download kubeconfig\n&#8211; Configure local access:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export KUBECONFIG=~\/Downloads\/kubeconfig\nkubectl version --short\nkubectl get nodes\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> <code>kubectl get nodes<\/code> shows Ready nodes.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Create an ASM instance and attach the ACK cluster<\/h3>\n\n\n\n<p><strong>Goal:<\/strong> Create a managed mesh and connect your cluster to it.<\/p>\n\n\n\n<p>1) In the Alibaba Cloud console, go to:\n&#8211; <strong>Service Mesh (ASM)<\/strong><\/p>\n\n\n\n<p>2) Create an ASM instance:\n&#8211; Choose the same region as the ACK cluster (for simplest setup)\n&#8211; Select an edition\/spec appropriate for a lab\n&#8211; Confirm networking requirements (VPC) and any prerequisites shown by the console<\/p>\n\n\n\n<p>3) Attach \/ add the ACK cluster to the mesh:\n&#8211; In the ASM instance \u2192 <strong>Cluster Management<\/strong> (or similar)\n&#8211; Add the ACK cluster<\/p>\n\n\n\n<p>4) Wait until the cluster status becomes \u201cattached\/managed\/ready\u201d (wording varies).<\/p>\n\n\n\n<p><strong>Expected outcome:<\/strong> ASM shows your ACK cluster as connected and healthy.<\/p>\n\n\n\n<p><strong>Verification:<\/strong>\n&#8211; In your cluster, list Istio-related namespaces and CRDs (names can vary):<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl get ns\nkubectl get crd | grep -E 'istio|networking.istio|security.istio' || true\n<\/code><\/pre>\n\n\n\n<p>If CRDs aren\u2019t visible yet, wait a few minutes\u2014ASM may install components asynchronously.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: Enable sidecar injection for a namespace<\/h3>\n\n\n\n<p><strong>Goal:<\/strong> Configure a namespace so workloads get Envoy sidecars automatically.<\/p>\n\n\n\n<p>1) Create a namespace:<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl create namespace asm-demo\n<\/code><\/pre>\n\n\n\n<p>2) Enable automatic injection.\nIn Istio, this is often done by labeling the namespace. Common label:<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl label namespace asm-demo istio-injection=enabled --overwrite\n<\/code><\/pre>\n\n\n\n<blockquote>\n<p>Note: Some managed meshes use a different label (for example <code>asm-injection=enabled<\/code>) or a revision-based label. <strong>Verify the correct label in ASM docs\/console<\/strong>.<\/p>\n<\/blockquote>\n\n\n\n<p>3) Confirm the label:<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl get namespace asm-demo --show-labels\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Namespace shows an injection label set to enabled.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: Deploy a simple \u201ctwo versions\u201d service<\/h3>\n\n\n\n<p>We\u2019ll deploy:\n&#8211; <code>hello-v1<\/code> that returns \u201cv1\u201d\n&#8211; <code>hello-v2<\/code> that returns \u201cv2\u201d\n&#8211; A <code>curl<\/code> client pod to generate traffic<\/p>\n\n\n\n<p>We\u2019ll use <code>hashicorp\/http-echo<\/code> for simplicity.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">4.1 Deploy services and deployments<\/h4>\n\n\n\n<p>Apply the following manifest:<\/p>\n\n\n\n<pre><code class=\"language-bash\">cat &lt;&lt;'EOF' | kubectl apply -n asm-demo -f -\napiVersion: v1\nkind: Service\nmetadata:\n  name: hello\n  labels:\n    app: hello\nspec:\n  ports:\n  - name: http\n    port: 80\n    targetPort: 5678\n  selector:\n    app: hello\n---\napiVersion: apps\/v1\nkind: Deployment\nmetadata:\n  name: hello-v1\nspec:\n  replicas: 1\n  selector:\n    matchLabels:\n      app: hello\n      version: v1\n  template:\n    metadata:\n      labels:\n        app: hello\n        version: v1\n    spec:\n      containers:\n      - name: app\n        image: hashicorp\/http-echo:1.0\n        args: [\"-text=hello from v1\"]\n        ports:\n        - containerPort: 5678\n---\napiVersion: apps\/v1\nkind: Deployment\nmetadata:\n  name: hello-v2\nspec:\n  replicas: 1\n  selector:\n    matchLabels:\n      app: hello\n      version: v2\n  template:\n    metadata:\n      labels:\n        app: hello\n        version: v2\n    spec:\n      containers:\n      - name: app\n        image: hashicorp\/http-echo:1.0\n        args: [\"-text=hello from v2\"]\n        ports:\n        - containerPort: 5678\nEOF\n<\/code><\/pre>\n\n\n\n<h4 class=\"wp-block-heading\">4.2 Deploy a client pod<\/h4>\n\n\n\n<pre><code class=\"language-bash\">cat &lt;&lt;'EOF' | kubectl apply -n asm-demo -f -\napiVersion: v1\nkind: Pod\nmetadata:\n  name: curl\n  labels:\n    app: curl\nspec:\n  containers:\n  - name: curl\n    image: curlimages\/curl:8.5.0\n    command: [\"sleep\", \"3650d\"]\nEOF\n<\/code><\/pre>\n\n\n\n<h4 class=\"wp-block-heading\">4.3 Verify sidecar injection worked<\/h4>\n\n\n\n<p>Check pods:<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl get pods -n asm-demo -o wide\n<\/code><\/pre>\n\n\n\n<p>Then inspect one pod to see if it has <strong>2 containers<\/strong> (app + sidecar):<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl get pod -n asm-demo -l app=hello,version=v1 -o jsonpath='{.items[0].spec.containers[*].name}'; echo\nkubectl get pod -n asm-demo -l app=hello,version=v2 -o jsonpath='{.items[0].spec.containers[*].name}'; echo\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> You should see something like <code>app istio-proxy<\/code> (name may differ but usually <code>istio-proxy<\/code>).<\/p>\n\n\n\n<p>If you only see <code>app<\/code>, injection is not enabled\u2014see Troubleshooting.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: Generate traffic and observe baseline behavior<\/h3>\n\n\n\n<p>Exec into the curl pod and call the service multiple times.<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl exec -n asm-demo -it curl -- sh\n<\/code><\/pre>\n\n\n\n<p>Inside the pod:<\/p>\n\n\n\n<pre><code class=\"language-sh\">for i in $(seq 1 10); do\n  curl -s http:\/\/hello\/ ; echo\ndone\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> You\u2019ll likely see a mix of \u201chello from v1\u201d and \u201chello from v2\u201d because Kubernetes Service load balancing is round-robin across endpoints.<\/p>\n\n\n\n<p>Exit the pod:<\/p>\n\n\n\n<pre><code class=\"language-sh\">exit\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 6: Apply ASM\/Istio routing rules (canary 90\/10)<\/h3>\n\n\n\n<p>Now we\u2019ll control traffic using Istio resources. This assumes ASM supports standard Istio CRDs.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">6.1 Create subsets via DestinationRule<\/h4>\n\n\n\n<pre><code class=\"language-bash\">cat &lt;&lt;'EOF' | kubectl apply -n asm-demo -f -\napiVersion: networking.istio.io\/v1beta1\nkind: DestinationRule\nmetadata:\n  name: hello\nspec:\n  host: hello\n  subsets:\n  - name: v1\n    labels:\n      version: v1\n  - name: v2\n    labels:\n      version: v2\nEOF\n<\/code><\/pre>\n\n\n\n<h4 class=\"wp-block-heading\">6.2 Create VirtualService for weighted routing<\/h4>\n\n\n\n<pre><code class=\"language-bash\">cat &lt;&lt;'EOF' | kubectl apply -n asm-demo -f -\napiVersion: networking.istio.io\/v1beta1\nkind: VirtualService\nmetadata:\n  name: hello\nspec:\n  hosts:\n  - hello\n  http:\n  - route:\n    - destination:\n        host: hello\n        subset: v1\n      weight: 90\n    - destination:\n        host: hello\n        subset: v2\n      weight: 10\nEOF\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> 90% of calls go to v1, 10% to v2.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">6.3 Verify traffic split<\/h4>\n\n\n\n<p>Run 50 requests:<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl exec -n asm-demo curl -- sh -c 'for i in $(seq 1 50); do curl -s http:\/\/hello\/ ; echo; done' | sort | uniq -c\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Counts should roughly reflect 90\/10 split (not exact due to randomness and small sample size).<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 7: Shift traffic to 50\/50, then 0\/100<\/h3>\n\n\n\n<p>Update the VirtualService to 50\/50:<\/p>\n\n\n\n<pre><code class=\"language-bash\">cat &lt;&lt;'EOF' | kubectl apply -n asm-demo -f -\napiVersion: networking.istio.io\/v1beta1\nkind: VirtualService\nmetadata:\n  name: hello\nspec:\n  hosts:\n  - hello\n  http:\n  - route:\n    - destination:\n        host: hello\n        subset: v1\n      weight: 50\n    - destination:\n        host: hello\n        subset: v2\n      weight: 50\nEOF\n<\/code><\/pre>\n\n\n\n<p>Re-check:<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl exec -n asm-demo curl -- sh -c 'for i in $(seq 1 50); do curl -s http:\/\/hello\/ ; echo; done' | sort | uniq -c\n<\/code><\/pre>\n\n\n\n<p>Then go all-in on v2 (0\/100):<\/p>\n\n\n\n<pre><code class=\"language-bash\">cat &lt;&lt;'EOF' | kubectl apply -n asm-demo -f -\napiVersion: networking.istio.io\/v1beta1\nkind: VirtualService\nmetadata:\n  name: hello\nspec:\n  hosts:\n  - hello\n  http:\n  - route:\n    - destination:\n        host: hello\n        subset: v1\n      weight: 0\n    - destination:\n        host: hello\n        subset: v2\n      weight: 100\nEOF\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> All responses should be \u201chello from v2\u201d.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 8 (Optional): Enable mTLS (permissive \u2192 strict)<\/h3>\n\n\n\n<p>mTLS resources and API versions depend on the Istio version ASM is running. The following is a common approach in Istio:<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">8.1 Start with PERMISSIVE<\/h4>\n\n\n\n<p>This allows both plaintext and mTLS while you validate compatibility.<\/p>\n\n\n\n<pre><code class=\"language-bash\">cat &lt;&lt;'EOF' | kubectl apply -n asm-demo -f -\napiVersion: security.istio.io\/v1beta1\nkind: PeerAuthentication\nmetadata:\n  name: default\nspec:\n  mtls:\n    mode: PERMISSIVE\nEOF\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Traffic should continue working.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">8.2 Switch to STRICT<\/h4>\n\n\n\n<p>This requires mTLS for in-mesh traffic.<\/p>\n\n\n\n<pre><code class=\"language-bash\">cat &lt;&lt;'EOF' | kubectl apply -n asm-demo -f -\napiVersion: security.istio.io\/v1beta1\nkind: PeerAuthentication\nmetadata:\n  name: default\nspec:\n  mtls:\n    mode: STRICT\nEOF\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Calls from meshed workloads to meshed workloads continue to work. Calls from non-meshed clients may fail.<\/p>\n\n\n\n<p>Validate again:<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl exec -n asm-demo curl -- curl -sS http:\/\/hello\/\n<\/code><\/pre>\n\n\n\n<p>If it fails, revert to permissive while you troubleshoot.<\/p>\n\n\n\n<blockquote>\n<p>If <code>PeerAuthentication<\/code> CRD is not found, your ASM version\/profile may differ. <strong>Verify supported security APIs in ASM docs<\/strong>.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Validation<\/h3>\n\n\n\n<p>Run these checks:<\/p>\n\n\n\n<p>1) <strong>Sidecars present:<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl get pod -n asm-demo -l app=hello,version=v1 -o jsonpath='{.items[0].spec.containers[*].name}'; echo\nkubectl get pod -n asm-demo -l app=hello,version=v2 -o jsonpath='{.items[0].spec.containers[*].name}'; echo\n<\/code><\/pre>\n\n\n\n<p>2) <strong>Istio resources applied:<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl get virtualservice -n asm-demo\nkubectl get destinationrule -n asm-demo\nkubectl get peerauthentication -n asm-demo 2&gt;\/dev\/null || true\n<\/code><\/pre>\n\n\n\n<p>3) <strong>Traffic behavior matches weights:<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl exec -n asm-demo curl -- sh -c 'for i in $(seq 1 30); do curl -s http:\/\/hello\/ ; echo; done' | sort | uniq -c\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Troubleshooting<\/h3>\n\n\n\n<h4 class=\"wp-block-heading\">Problem: Sidecar not injected<\/h4>\n\n\n\n<p><strong>Symptoms<\/strong>\n&#8211; Pods only have one container (<code>app<\/code>)\n&#8211; Mesh routing rules don\u2019t affect traffic<\/p>\n\n\n\n<p><strong>Fixes<\/strong>\n&#8211; Confirm namespace label:<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl get ns asm-demo --show-labels\n<\/code><\/pre>\n\n\n\n<ul class=\"wp-block-list\">\n<li>If you added the label after pods were created, restart deployments:<\/li>\n<\/ul>\n\n\n\n<pre><code class=\"language-bash\">kubectl rollout restart deployment -n asm-demo hello-v1 hello-v2\n<\/code><\/pre>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Verify your ASM uses a different injection label or revision model. <strong>Check ASM docs\/console<\/strong>.<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Problem: Istio CRDs not found<\/h4>\n\n\n\n<p><strong>Symptoms<\/strong>\n&#8211; Applying VirtualService\/DestinationRule fails with \u201cno matches for kind \u2026\u201d<\/p>\n\n\n\n<p><strong>Fixes<\/strong>\n&#8211; Confirm cluster is successfully attached to ASM and components are installed.\n&#8211; Wait and retry (initial installation can take time).\n&#8211; In managed environments, CRD versions may differ. Check which API versions exist:<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl get crd | grep istio\n<\/code><\/pre>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use the CRD\u2019s supported API version (for example <code>v1alpha3<\/code> vs <code>v1beta1<\/code>) if required\u2014<strong>verify in your cluster<\/strong>.<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Problem: Traffic split doesn\u2019t seem to work<\/h4>\n\n\n\n<p><strong>Symptoms<\/strong>\n&#8211; Always gets v1 or always v2<\/p>\n\n\n\n<p><strong>Fixes<\/strong>\n&#8211; Confirm both deployments have Ready pods and endpoints:<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl get deploy -n asm-demo\nkubectl get endpoints -n asm-demo hello -o yaml | sed -n '1,120p'\n<\/code><\/pre>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Confirm labels match subsets exactly (<code>version: v1<\/code>, <code>version: v2<\/code>)<\/li>\n<li>Ensure you are calling the correct host (<code>hello<\/code> inside the namespace)<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Problem: mTLS strict breaks traffic<\/h4>\n\n\n\n<p><strong>Symptoms<\/strong>\n&#8211; Curl fails after enabling STRICT<\/p>\n\n\n\n<p><strong>Fixes<\/strong>\n&#8211; Ensure client and server are both in-mesh (both have sidecars)\n&#8211; Revert to permissive while investigating:<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl apply -n asm-demo -f - &lt;&lt;'EOF'\napiVersion: security.istio.io\/v1beta1\nkind: PeerAuthentication\nmetadata:\n  name: default\nspec:\n  mtls:\n    mode: PERMISSIVE\nEOF\n<\/code><\/pre>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Check for non-mesh workloads calling into the namespace; they will fail in STRICT unless you provide exceptions\/gateways.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Cleanup<\/h3>\n\n\n\n<p>To avoid ongoing charges, clean up in this order.<\/p>\n\n\n\n<p>1) Delete demo namespace resources:<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl delete namespace asm-demo\n<\/code><\/pre>\n\n\n\n<p>2) In ASM console:\n&#8211; Detach\/remove the ACK cluster from the ASM instance (workflow name varies)<\/p>\n\n\n\n<p>3) Delete the ASM instance:\n&#8211; Ensure it is not attached to any clusters\n&#8211; Delete the instance from the ASM console<\/p>\n\n\n\n<p>4) Delete ACK cluster if you created it for the lab:\n&#8211; In ACK console \u2192 delete cluster\n&#8211; Ensure worker nodes, load balancers, and EIPs are released<\/p>\n\n\n\n<p>5) Verify you have no leftover billable resources:\n&#8211; Load balancers\n&#8211; EIPs\/NAT gateways\n&#8211; SLS projects with high retention\n&#8211; Monitoring instances<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">11. Best Practices<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Architecture best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Start with a <strong>single cluster + single mesh<\/strong> before multi-cluster.<\/li>\n<li>Onboard services <strong>incrementally by namespace<\/strong>.<\/li>\n<li>Standardize labels (<code>app<\/code>, <code>version<\/code>, <code>team<\/code>, <code>env<\/code>) to make routing\/policy manageable.<\/li>\n<li>Prefer <strong>service boundaries<\/strong> aligned with team ownership to reduce policy complexity.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM\/security best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use <strong>RAM roles<\/strong> for automation (CI\/CD) and separate them from human admin roles.<\/li>\n<li>Limit who can apply mesh-wide policies (ClusterRole for Istio CRDs).<\/li>\n<li>Use GitOps + review for mesh policy changes.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Measure sidecar overhead early (CPU\/memory) and adjust node sizing.<\/li>\n<li>Avoid enabling verbose access logs cluster-wide by default.<\/li>\n<li>Consolidate gateways where possible and autoscale based on metrics.<\/li>\n<li>Keep observability retention aligned to needs (7\u201314 days for high-volume logs unless compliance requires more).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Performance best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Define sane timeouts and retry budgets to avoid retry storms.<\/li>\n<li>Use connection pooling and keepalives carefully (validate with your protocol behavior).<\/li>\n<li>Benchmark latency impact of sidecars on critical paths.<\/li>\n<li>Isolate gateway workloads on dedicated nodes if needed.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Reliability best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Test policies in staging with realistic traffic before production.<\/li>\n<li>Implement progressive delivery with automated rollback criteria.<\/li>\n<li>Avoid \u201cbig bang\u201d mTLS strict across all namespaces; migrate gradually.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operations best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Define runbooks for:<\/li>\n<li>sidecar injection issues<\/li>\n<li>mesh policy rollback<\/li>\n<li>gateway overload<\/li>\n<li>certificate and mTLS debugging<\/li>\n<li>Track mesh version compatibility with ACK upgrades.<\/li>\n<li>Keep a \u201cbreak glass\u201d process: ability to disable injection or remove routing rules in an incident.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Governance\/tagging\/naming best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Name Istio resources predictably:<\/li>\n<li><code>vs-&lt;service&gt;-&lt;purpose&gt;<\/code><\/li>\n<li><code>dr-&lt;service&gt;<\/code><\/li>\n<li>Use Kubernetes annotations\/labels for ownership:<\/li>\n<li><code>owner<\/code>, <code>cost-center<\/code>, <code>data-classification<\/code><\/li>\n<li>Document approved routing patterns (canary templates) to reduce errors.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">12. Security Considerations<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Identity and access model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Operator identity:<\/strong> RAM users\/roles; use MFA and least privilege.<\/li>\n<li><strong>Kubernetes RBAC:<\/strong> controls who can deploy and configure mesh resources.<\/li>\n<li><strong>Workload identity:<\/strong> typically based on Kubernetes service accounts; used for mTLS and policy decisions.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Encryption<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>In transit (east-west):<\/strong> mTLS between sidecars when enabled.<\/li>\n<li><strong>North-south TLS:<\/strong> typically terminated at ingress gateway or load balancer; decide where TLS should terminate based on compliance and observability needs.<\/li>\n<li><strong>At rest:<\/strong> depends on your storage backends (SLS, disk encryption for nodes, etc.). ASM itself focuses on traffic governance, not data-at-rest encryption.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network exposure<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Minimize public exposure:<\/li>\n<li>Use private load balancers for internal meshes when possible<\/li>\n<li>Restrict security group rules to known sources<\/li>\n<li>Use network segmentation:<\/li>\n<li>separate VPCs\/environments (dev\/stage\/prod)<\/li>\n<li>Kubernetes NetworkPolicies (mesh is not a replacement)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secrets handling<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Avoid embedding credentials in mesh configs.<\/li>\n<li>Use Kubernetes Secrets with encryption at rest where available, or integrate a secrets manager.<\/li>\n<li>Restrict who can read Secrets and who can exec into pods.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Audit\/logging<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use <strong>ActionTrail<\/strong> (Alibaba Cloud audit logging) for control-plane API actions (verify coverage for ASM actions).<\/li>\n<li>Log changes to mesh resources via Git and Kubernetes audit logs (if enabled).<\/li>\n<li>Store gateway\/proxy access logs in SLS with appropriate retention.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compliance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>mTLS helps with encryption in transit requirements.<\/li>\n<li>Policy enforcement supports segmentation and least privilege.<\/li>\n<li>Ensure logs do not capture sensitive headers\/body content; sanitize as needed.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Common security mistakes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enabling STRICT mTLS without inventorying non-mesh callers<\/li>\n<li>Overly permissive authorization policies (\u201callow all\u201d)<\/li>\n<li>Exposing gateways publicly without WAF\/rate-limiting controls<\/li>\n<li>Forgetting to restrict admin access to Istio CRDs (anyone can reroute production traffic)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secure deployment recommendations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Start with <strong>PERMISSIVE<\/strong>, then move to <strong>STRICT<\/strong> namespace by namespace.<\/li>\n<li>Use <strong>AuthorizationPolicy<\/strong> to implement least privilege between services.<\/li>\n<li>Protect gateways with:<\/li>\n<li>WAF\/API gateway (if needed)<\/li>\n<li>rate limiting (where supported)<\/li>\n<li>strict TLS policies<\/li>\n<li>Ensure you have a rollback path for mesh configs.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">13. Limitations and Gotchas<\/h2>\n\n\n\n<p>Because ASM is a managed service mesh, expect both mesh-level and managed-service constraints.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Known limitations (common in managed meshes)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Sidecar overhead<\/strong>: increases pod resource usage and node cost.<\/li>\n<li><strong>Complex debugging<\/strong>: failures may involve app + proxy + policy layers.<\/li>\n<li><strong>Protocol edge cases<\/strong>: some protocols require specific configuration; validate for gRPC, WebSockets, and non-HTTP traffic.<\/li>\n<li><strong>CRD\/API version mismatch<\/strong>: your manifests must match the Istio API versions installed by ASM.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas and scaling constraints<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Limits on number of clusters per mesh instance (verify)<\/li>\n<li>Limits on number of proxies\/workloads or config size (verify)<\/li>\n<li>Load balancer quotas and bandwidth caps can become bottlenecks<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Regional constraints<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>ASM availability and features vary by region.<\/li>\n<li>Some observability integrations may be region-dependent.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing surprises<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Log volume from access logs and high-cardinality metrics<\/li>\n<li>Multiple load balancers for gateways across environments<\/li>\n<li>Additional compute from sidecars and gateways<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compatibility issues<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>ACK cluster versions vs ASM-supported Istio versions<\/li>\n<li>CNI plugins and network policies interaction (validate your CNI setup)<\/li>\n<li>Ingress controller interplay: using Kubernetes Ingress vs Istio Gateway patterns can cause confusion<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational gotchas<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Injection labels applied after deployment require restarts.<\/li>\n<li>Traffic routing changes can have immediate blast radius\u2014use change control.<\/li>\n<li>mTLS strict can break:<\/li>\n<li>non-mesh pods calling services<\/li>\n<li>external clients without gateways<\/li>\n<li>Misconfigured retries can amplify outages.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Migration challenges<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Migrating from self-managed Istio to ASM requires careful planning:<\/li>\n<li>CRD compatibility<\/li>\n<li>certificate\/identity changes<\/li>\n<li>gateway replacement<\/li>\n<li>Plan a staged cutover: mirror traffic, then gradually shift.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Vendor-specific nuances<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Console workflows and managed components may differ from upstream Istio guides.<\/li>\n<li>Some features may be offered via Alibaba Cloud integrations rather than upstream components\u2014<strong>verify in official docs<\/strong>.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">14. Comparison with Alternatives<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Options to consider<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Self-managed Istio on ACK<\/strong><\/li>\n<li><strong>Alibaba Cloud MSE (Microservices Engine) governance features<\/strong> (not a service mesh; more app\/runtime governance\u2014validate fit)<\/li>\n<li><strong>Kubernetes Ingress + service-level libraries<\/strong> (no mesh)<\/li>\n<li><strong>Other clouds\u2019 meshes<\/strong>: AWS App Mesh, Google Anthos Service Mesh, etc.<\/li>\n<li><strong>Open-source alternatives<\/strong>: Linkerd (self-managed), Consul service mesh (self-managed)<\/li>\n<\/ul>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Option<\/th>\n<th>Best For<\/th>\n<th>Strengths<\/th>\n<th>Weaknesses<\/th>\n<th>When to Choose<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Alibaba Cloud Service Mesh (ASM)<\/td>\n<td>Teams on ACK wanting managed mesh<\/td>\n<td>Managed control plane; Istio-compatible governance; integrates with Alibaba Cloud<\/td>\n<td>Sidecar overhead; managed constraints; feature variance by region\/edition<\/td>\n<td>You want Istio-style mesh without running it yourself<\/td>\n<\/tr>\n<tr>\n<td>Self-managed Istio on ACK<\/td>\n<td>Deep customization and full control<\/td>\n<td>Full control over versions and addons; can customize heavily<\/td>\n<td>High ops burden (upgrades, CVEs, HA); requires expertise<\/td>\n<td>You need features not exposed in ASM or strict control over versions<\/td>\n<\/tr>\n<tr>\n<td>ACK + Ingress (no mesh)<\/td>\n<td>Smaller systems, fewer services<\/td>\n<td>Simpler; less overhead; familiar Kubernetes model<\/td>\n<td>No consistent east-west governance; limited L7 control between services<\/td>\n<td>Early-stage microservices or low complexity environments<\/td>\n<\/tr>\n<tr>\n<td>Alibaba Cloud MSE (governance, registry, gateway)<\/td>\n<td>App-level microservice governance (depending on modules)<\/td>\n<td>Strong governance patterns for microservices ecosystems (validate)<\/td>\n<td>Not a service mesh; may not provide uniform proxy-based control<\/td>\n<td>When you need registry\/config\/governance rather than mesh sidecars<\/td>\n<\/tr>\n<tr>\n<td>AWS App Mesh \/ GCP Anthos Service Mesh<\/td>\n<td>Workloads in those clouds<\/td>\n<td>Native integration with their ecosystems<\/td>\n<td>Not applicable if you\u2019re standardizing on Alibaba Cloud<\/td>\n<td>Multi-cloud teams standardizing per-cloud services<\/td>\n<\/tr>\n<tr>\n<td>Linkerd \/ Consul (self-managed)<\/td>\n<td>Lightweight mesh or alternative feature sets<\/td>\n<td>Potentially simpler (Linkerd) or integrated service registry (Consul)<\/td>\n<td>Still self-managed; migration complexity; different APIs<\/td>\n<td>If you prefer non-Istio mesh design and accept self-ops<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">15. Real-World Example<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Enterprise example: Regional e-commerce platform<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Hundreds of microservices on ACK, frequent releases, inconsistent retries\/timeouts, security team mandates encryption-in-transit and service segmentation.<\/li>\n<li><strong>Proposed architecture:<\/strong><\/li>\n<li>One ASM instance per environment (prod\/stage), attached to multiple ACK clusters per region<\/li>\n<li>Ingress gateways behind private\/public load balancers<\/li>\n<li>mTLS enabled gradually; AuthorizationPolicies restrict service access<\/li>\n<li>Centralized telemetry to SLS + ARMS; dashboards for golden signals per service<\/li>\n<li><strong>Why ASM was chosen:<\/strong><\/li>\n<li>Managed control plane reduces operational burden vs self-managed Istio<\/li>\n<li>Istio CRDs enable progressive delivery across service graph<\/li>\n<li>Security policies enforce internal zero-trust without rewriting apps<\/li>\n<li><strong>Expected outcomes:<\/strong><\/li>\n<li>Reduced incident frequency during releases via canary rollouts<\/li>\n<li>Improved MTTR due to consistent service telemetry<\/li>\n<li>Better compliance posture via mTLS and auditable policies<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Startup\/small-team example: SaaS API platform<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A small team runs 15 microservices on ACK; they need canary releases and better tracing without building custom libraries.<\/li>\n<li><strong>Proposed architecture:<\/strong><\/li>\n<li>Single ASM instance attached to one ACK cluster<\/li>\n<li>Mesh only critical namespaces initially<\/li>\n<li>Use VirtualService\/DestinationRule for canary<\/li>\n<li>Keep observability lightweight: minimal logs, sampled tracing<\/li>\n<li><strong>Why ASM was chosen:<\/strong><\/li>\n<li>Quick governance capabilities with minimal platform engineering headcount<\/li>\n<li>Standard patterns for traffic splitting and timeouts<\/li>\n<li><strong>Expected outcomes:<\/strong><\/li>\n<li>Faster deployments with controlled risk<\/li>\n<li>Actionable visibility into service latency bottlenecks<\/li>\n<li>Clear growth path to stricter security later<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">16. FAQ<\/h2>\n\n\n\n<p>1) <strong>Is Alibaba Cloud Service Mesh (ASM) the same as Istio?<\/strong><br\/>\nASM is a managed service mesh offering that is typically <strong>Istio-compatible<\/strong>. You use Istio-style CRDs for policies, but the control plane lifecycle is managed by Alibaba Cloud. Exact versions\/features can differ\u2014verify in ASM docs.<\/p>\n\n\n\n<p>2) <strong>Do I need to change application code to use ASM?<\/strong><br\/>\nOften no. Many features (routing, mTLS, telemetry) work via sidecars. Some advanced tracing or auth flows may require app configuration.<\/p>\n\n\n\n<p>3) <strong>What is the main tradeoff of using ASM?<\/strong><br\/>\nOperational simplicity and consistent governance vs added runtime overhead (sidecars) and policy complexity.<\/p>\n\n\n\n<p>4) <strong>Does ASM work only with ACK?<\/strong><br\/>\nASM is primarily used with ACK in Alibaba Cloud. If additional cluster types are supported, verify in official docs.<\/p>\n\n\n\n<p>5) <strong>How do I onboard services gradually?<\/strong><br\/>\nCommon approach: enable injection per namespace, then roll out workloads in that namespace. Start with non-critical services.<\/p>\n\n\n\n<p>6) <strong>What happens if I misconfigure a VirtualService?<\/strong><br\/>\nYou can reroute or break production traffic. Use staging validation, code review, and small incremental changes.<\/p>\n\n\n\n<p>7) <strong>How much latency does a sidecar add?<\/strong><br\/>\nIt depends on workload, traffic rate, and configuration. Measure in your environment; expect some overhead.<\/p>\n\n\n\n<p>8) <strong>Can I do canary releases without ASM?<\/strong><br\/>\nYes (e.g., with Ingress controllers or application-level routing), but ASM provides consistent service-to-service routing and observability.<\/p>\n\n\n\n<p>9) <strong>Does ASM provide a built-in dashboard like Kiali?<\/strong><br\/>\nSome meshes provide dashboards or integrations; availability varies. Verify ASM\u2019s current observability tooling and integrations.<\/p>\n\n\n\n<p>10) <strong>How do I control which pods get sidecars?<\/strong><br\/>\nTypically by labeling namespaces for injection, or using pod annotations. ASM may support revision-based injection\u2014verify.<\/p>\n\n\n\n<p>11) <strong>Can I enforce mTLS for only one namespace?<\/strong><br\/>\nYes in typical Istio models via <code>PeerAuthentication<\/code> in that namespace, but confirm with your ASM-supported API versions.<\/p>\n\n\n\n<p>12) <strong>How do I prevent one team\u2019s services from calling another team\u2019s services?<\/strong><br\/>\nUse AuthorizationPolicies (mesh) plus Kubernetes RBAC\/NetworkPolicies for defense in depth.<\/p>\n\n\n\n<p>13) <strong>Is ASM suitable for stateful workloads?<\/strong><br\/>\nIt can be, but sidecar overhead and traffic patterns matter. Validate performance for databases and stateful services carefully.<\/p>\n\n\n\n<p>14) <strong>What\u2019s the difference between ingress gateway and Kubernetes Ingress?<\/strong><br\/>\nKubernetes Ingress is a generic Kubernetes resource typically implemented by an ingress controller. Istio Gateway is mesh-specific and integrates with mesh routing policies. You can use either depending on design.<\/p>\n\n\n\n<p>15) <strong>How do I estimate cost impact before adopting ASM?<\/strong><br\/>\nModel: ASM service fee + ACK costs + sidecar overhead + load balancers + observability ingestion\/storage + network egress. Use the official pricing calculator and run a small pilot.<\/p>\n\n\n\n<p>16) <strong>Can I run multiple meshes in one cluster?<\/strong><br\/>\nSome Istio deployments support revision-based or multi-control-plane setups; managed ASM support varies. Verify in official docs.<\/p>\n\n\n\n<p>17) <strong>What is the recommended way to roll back a failed canary?<\/strong><br\/>\nUpdate the VirtualService weights back to 100% old version, or remove the VirtualService to revert to Kubernetes default load balancing.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">17. Top Online Resources to Learn Service Mesh (ASM)<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Resource Type<\/th>\n<th>Name<\/th>\n<th>Why It Is Useful<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Official documentation<\/td>\n<td>Alibaba Cloud ASM Documentation \u2014 https:\/\/www.alibabacloud.com\/help\/en\/asm\/<\/td>\n<td>Canonical feature set, setup steps, API compatibility notes<\/td>\n<\/tr>\n<tr>\n<td>Official product page<\/td>\n<td>Alibaba Cloud Service Mesh (ASM) \u2014 https:\/\/www.alibabacloud.com\/product\/asm<\/td>\n<td>High-level overview and entry points to pricing\/docs<\/td>\n<\/tr>\n<tr>\n<td>Official pricing<\/td>\n<td>ASM pricing (via product\/pricing page; region-dependent) \u2014 start at https:\/\/www.alibabacloud.com\/product\/asm<\/td>\n<td>Explains billing dimensions; avoids outdated third-party numbers<\/td>\n<\/tr>\n<tr>\n<td>Pricing calculator<\/td>\n<td>Alibaba Cloud Pricing Calculator \u2014 https:\/\/www.alibabacloud.com\/pricing\/calculator<\/td>\n<td>Build region-specific estimates including dependent services<\/td>\n<\/tr>\n<tr>\n<td>Kubernetes service<\/td>\n<td>ACK Documentation \u2014 https:\/\/www.alibabacloud.com\/help\/en\/ack\/<\/td>\n<td>Cluster creation, kubeconfig, networking fundamentals<\/td>\n<\/tr>\n<tr>\n<td>Networking<\/td>\n<td>VPC Documentation \u2014 https:\/\/www.alibabacloud.com\/help\/en\/vpc\/<\/td>\n<td>Required for multi-cluster design and secure connectivity<\/td>\n<\/tr>\n<tr>\n<td>Observability<\/td>\n<td>Log Service (SLS) Docs \u2014 https:\/\/www.alibabacloud.com\/help\/en\/sls\/<\/td>\n<td>Centralized log collection and retention planning<\/td>\n<\/tr>\n<tr>\n<td>Observability<\/td>\n<td>ARMS Docs \u2014 https:\/\/www.alibabacloud.com\/help\/en\/arms\/<\/td>\n<td>Monitoring\/APM options for mesh telemetry (verify integrations)<\/td>\n<\/tr>\n<tr>\n<td>Upstream reference<\/td>\n<td>Istio Documentation \u2014 https:\/\/istio.io\/latest\/docs\/<\/td>\n<td>Understanding CRDs and mesh concepts (adapt to ASM-supported versions)<\/td>\n<\/tr>\n<tr>\n<td>Hands-on examples<\/td>\n<td>Istio Samples \u2014 https:\/\/github.com\/istio\/istio\/tree\/master\/samples<\/td>\n<td>Sample apps and routing examples; use as conceptual guidance<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">18. Training and Certification Providers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Institute<\/th>\n<th>Suitable Audience<\/th>\n<th>Likely Learning Focus<\/th>\n<th>Mode<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps engineers, SREs, platform teams<\/td>\n<td>Kubernetes, service mesh concepts, cloud DevOps practices<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>ScmGalaxy.com<\/td>\n<td>Beginners to intermediate engineers<\/td>\n<td>DevOps fundamentals, tooling, CI\/CD, cloud basics<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.scmgalaxy.com\/<\/td>\n<\/tr>\n<tr>\n<td>CLoudOpsNow.in<\/td>\n<td>Cloud operations engineers<\/td>\n<td>Cloud operations, monitoring, incident response, platform ops<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.cloudopsnow.in\/<\/td>\n<\/tr>\n<tr>\n<td>SreSchool.com<\/td>\n<td>SREs and operations teams<\/td>\n<td>SRE principles, reliability engineering, observability<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.sreschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>AiOpsSchool.com<\/td>\n<td>Ops and monitoring engineers<\/td>\n<td>AIOps concepts, monitoring automation, analytics<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.aiopsschool.com\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">19. Top Trainers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Platform\/Site<\/th>\n<th>Likely Specialization<\/th>\n<th>Suitable Audience<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>RajeshKumar.xyz<\/td>\n<td>DevOps\/Kubernetes training content (verify offerings)<\/td>\n<td>Engineers seeking guided learning<\/td>\n<td>https:\/\/rajeshkumar.xyz\/<\/td>\n<\/tr>\n<tr>\n<td>devopstrainer.in<\/td>\n<td>DevOps and container training (verify offerings)<\/td>\n<td>Beginners to advanced DevOps learners<\/td>\n<td>https:\/\/www.devopstrainer.in\/<\/td>\n<\/tr>\n<tr>\n<td>devopsfreelancer.com<\/td>\n<td>DevOps freelance\/training services (verify offerings)<\/td>\n<td>Teams needing short-term expertise<\/td>\n<td>https:\/\/www.devopsfreelancer.com\/<\/td>\n<\/tr>\n<tr>\n<td>devopssupport.in<\/td>\n<td>DevOps support and enablement (verify offerings)<\/td>\n<td>Ops teams needing troubleshooting help<\/td>\n<td>https:\/\/www.devopssupport.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">20. Top Consulting Companies<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Company Name<\/th>\n<th>Likely Service Area<\/th>\n<th>Where They May Help<\/th>\n<th>Consulting Use Case Examples<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>cotocus.com<\/td>\n<td>DevOps, cloud, platform engineering (verify portfolio)<\/td>\n<td>Platform design, Kubernetes operations, delivery pipelines<\/td>\n<td>Mesh adoption planning, GitOps for Istio CRDs, production readiness reviews<\/td>\n<td>https:\/\/cotocus.com\/<\/td>\n<\/tr>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps consulting and enablement (verify offerings)<\/td>\n<td>Training + consulting for DevOps and containers<\/td>\n<td>ASM pilot, mesh governance patterns, SRE runbooks and rollout strategy<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>DEVOPSCONSULTING.IN<\/td>\n<td>DevOps consulting (verify portfolio)<\/td>\n<td>DevOps transformation and operations<\/td>\n<td>Observability integration, cost optimization, incident response processes for meshed apps<\/td>\n<td>https:\/\/www.devopsconsulting.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">21. Career and Learning Roadmap<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn before ASM<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Kubernetes fundamentals:<\/li>\n<li>Pods, Deployments, Services, Ingress<\/li>\n<li>namespaces, labels\/selectors<\/li>\n<li>RBAC, ConfigMaps\/Secrets<\/li>\n<li>Networking basics:<\/li>\n<li>L4 vs L7, DNS, TLS\/mTLS<\/li>\n<li>load balancing concepts<\/li>\n<li>Observability basics:<\/li>\n<li>metrics (RED\/USE), logs, tracing<\/li>\n<li>Alibaba Cloud essentials:<\/li>\n<li>VPC concepts, security groups<\/li>\n<li>ACK cluster lifecycle<\/li>\n<li>RAM permissions<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after ASM<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Advanced mesh security:<\/li>\n<li>Authorization policies, JWT validation patterns (if supported)<\/li>\n<li>defense in depth with NetworkPolicies<\/li>\n<li>Progressive delivery at scale:<\/li>\n<li>automated canary analysis<\/li>\n<li>service-level objectives (SLOs)<\/li>\n<li>Multi-cluster architecture:<\/li>\n<li>service discovery patterns<\/li>\n<li>traffic failover strategies<\/li>\n<li>Platform engineering practices:<\/li>\n<li>golden path templates for teams<\/li>\n<li>policy-as-code and GitOps workflows<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Job roles that use it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud\/Platform Engineer<\/li>\n<li>DevOps Engineer<\/li>\n<li>Site Reliability Engineer (SRE)<\/li>\n<li>Kubernetes Administrator<\/li>\n<li>Security Engineer (cloud-native)<\/li>\n<li>Solutions Architect (microservices modernization)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path<\/h3>\n\n\n\n<p>Alibaba Cloud certifications and tracks can change. If you want a certification-oriented path:\n&#8211; Start with Alibaba Cloud foundational certs (if available)\n&#8211; Add Kubernetes certifications (e.g., CKA\/CKAD) for transferable skills\n&#8211; Build a portfolio of mesh projects and incident learnings<br\/>\nFor official Alibaba Cloud certification availability, <strong>verify on Alibaba Cloud certification pages<\/strong>:\n&#8211; https:\/\/edu.alibabacloud.com\/ (verify certification listings)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Project ideas for practice<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Create a \u201cpolicy library\u201d repo: standard VirtualService\/DestinationRule templates<\/li>\n<li>Implement namespace-by-namespace mTLS rollout plan with rollback steps<\/li>\n<li>Build a mesh observability dashboard: latency p95, error rate, top dependencies<\/li>\n<li>Run a chaos test: introduce fault injection (if supported) and observe blast radius<\/li>\n<li>Cost study: measure sidecar overhead across 10 services and propose right-sizing<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">22. Glossary<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>ACK<\/strong>: Alibaba Cloud Container Service for Kubernetes.<\/li>\n<li><strong>ASM (Service Mesh)<\/strong>: Alibaba Cloud managed service mesh offering (Istio-compatible model).<\/li>\n<li><strong>Service Mesh<\/strong>: Infrastructure layer that manages service-to-service communication.<\/li>\n<li><strong>Control plane<\/strong>: The component that distributes configuration and manages certificates\/policies.<\/li>\n<li><strong>Data plane<\/strong>: The proxies (sidecars\/gateways) that handle traffic and enforce policies.<\/li>\n<li><strong>Sidecar<\/strong>: A proxy container running alongside an app container in the same pod.<\/li>\n<li><strong>Envoy<\/strong>: A popular proxy used as the data plane in many Istio-based meshes.<\/li>\n<li><strong>mTLS<\/strong>: Mutual TLS; both client and server authenticate each other and encrypt traffic.<\/li>\n<li><strong>VirtualService<\/strong>: Istio resource that defines routing rules (weights, matches, rewrites).<\/li>\n<li><strong>DestinationRule<\/strong>: Istio resource that defines subsets and traffic policies for a service.<\/li>\n<li><strong>Gateway<\/strong>: Istio resource that configures edge proxy listeners for inbound traffic.<\/li>\n<li><strong>Namespace<\/strong>: Kubernetes partitioning construct often used for teams\/environments.<\/li>\n<li><strong>Canary release<\/strong>: Gradually shifting traffic to a new version to reduce risk.<\/li>\n<li><strong>Zero trust<\/strong>: Security model that requires explicit authorization and strong identity even inside the network.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">23. Summary<\/h2>\n\n\n\n<p>Alibaba Cloud <strong>Service Mesh (ASM)<\/strong> is a <strong>Container<\/strong>-category service that brings a managed service mesh (commonly Istio-style) to <strong>ACK<\/strong> workloads, enabling consistent <strong>traffic management<\/strong>, <strong>mTLS security<\/strong>, and <strong>observability<\/strong> across microservices.<\/p>\n\n\n\n<p>It matters because microservices sprawl makes releases, security, and troubleshooting difficult. ASM centralizes these concerns at the network\/proxy layer so teams can ship safer and operate more reliably.<\/p>\n\n\n\n<p>Cost-wise, plan beyond the ASM service fee: the biggest drivers are often <strong>sidecar compute overhead<\/strong>, <strong>gateway load balancers<\/strong>, and <strong>telemetry storage\/ingestion<\/strong>. Security-wise, treat mesh policies as production code, roll out mTLS gradually, and lock down who can change routing.<\/p>\n\n\n\n<p>Use ASM when you need standardized governance across many Kubernetes services and want a managed control plane. Skip it for very small systems or when sidecar complexity outweighs benefits.<\/p>\n\n\n\n<p>Next step: follow the official ASM \u201cGetting Started\u201d documentation for your region, then extend this lab by adding <strong>AuthorizationPolicy<\/strong> and integrating mesh telemetry with <strong>SLS\/ARMS<\/strong> based on your organization\u2019s observability standards.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Container<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2,6],"tags":[],"class_list":["post-25","post","type-post","status-publish","format-standard","hentry","category-alibaba-cloud","category-container"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/25","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=25"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/25\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=25"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=25"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=25"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}