Terms

Istio

An open-source service mesh platform that connects, secures, controls, and observes microservices. Istio adds a non-intrusive governance layer to cloud-native applications -- handling network connection, security management, and service management -- without requiring changes to application code. For more information, see What is Alibaba Cloud Service Mesh (ASM)?.

Managed service mesh

A fully managed Istio-based service mesh. ASM hosts and operates all control plane components, freeing you to focus on application development and deployment rather than Istio infrastructure maintenance. For more information, see What is Alibaba Cloud Service Mesh (ASM)?.

Control plane

The management layer of a service mesh that manages and configures proxies to route traffic. It translates high-level routing rules into proxy-specific configurations. In ASM, the control plane is logically split from the data plane: you define policies, and ASM distributes them to every proxy in the mesh. For more information, see What is Alibaba Cloud Service Mesh (ASM)?.

Data plane

The network layer of a service mesh, consisting of intelligent Envoy proxies deployed as sidecars that mediate and control all network communication between microservices and between sidecar proxies and the control plane.

• Sidecar mode: An Envoy proxy runs as a sidecar container in each application pod.

For more information, see What is Alibaba Cloud Service Mesh (ASM)?.

Namespace

A Kubernetes mechanism that partitions cluster resources into isolated virtual groups. Every cluster starts with three default namespaces: default, kube-system, and kube-public. Cluster administrators create additional namespaces to organize workloads by team, environment, or project.

ASM namespaces vs. Kubernetes namespaces: Namespaces created in an ASM instance (through the ASM console or kubectl) belong exclusively to that ASM instance. They are independent of the namespaces in the Kubernetes clusters on the data plane. Creating or deleting an ASM namespace does not affect the namespaces in the managed data plane clusters. For more information, see Manage global namespaces.

Pay-as-you-go

A postpaid billing model where you pay only for the resources you consume. No upfront purchase or commitment is required. For more information, see Billing rules.

Sidecar proxy

In sidecar mode, an Envoy proxy container is automatically injected into each application pod at creation time. The sidecar proxy intercepts all inbound and outbound network traffic for that pod, applying mesh policies -- routing, security, and observability -- without changes to the application itself.

By default, ASM includes a webhook controller (sidecar injector) that automatically injects sidecar proxies when pods are created. You can configure injection policies, the ports and protocols supported by the proxy, and the scope of services each proxy can access. For more information, see Data plane component management.

Ztunnel

A high-performance Layer 4 (L4) proxy used in ambient mode. Developed in Rust and deployed as a DaemonSet on every node, ztunnel transparently intercepts traffic entering and leaving pods on that node. It handles mTLS encryption and decryption, Layer 4 authorization policies, and redirects traffic to a waypoint proxy and other components when necessary.

Waypoint

A Layer 7 (L7) proxy based on Envoy, used in ambient mode. Unlike sidecar proxies, waypoints run independently of application pods and can be scaled and upgraded separately. After enabling ambient mode, you can enable a waypoint for specific applications that require L7 capabilities. Once enabled, ztunnel automatically forwards traffic destined for those services to the corresponding waypoint proxy.

Ingress gateway

A Kubernetes Service (rather than a custom resource in ASM) backed by Envoy proxy pods, deployed at the edge of the mesh to manage inbound traffic from external clients. When you create an ingress gateway in ASM, a Kubernetes Service and a Deployment are provisioned in the target cluster. For more information, see Ingress gateway.

Egress gateway

A gateway that manages all outbound traffic leaving the mesh. Use an egress gateway to centralize, monitor, and apply policies to traffic flowing from mesh services to external endpoints. For more information, see Egress gateway.

Gateway

An ASM custom resource that configures a load balancer at the edge of the mesh. A Gateway resource specifies which ports to expose, the protocols to accept (HTTP/TCP), and Server Name Indication (SNI) settings for TLS traffic. Gateway resources work together with virtual services to define complete routing paths from external clients to mesh services. For more information, see Manage gateway rules.

Service entry

An ASM custom resource that adds a service to the abstract model or service registry of ASM. After you add a service entry, Envoy proxies can route traffic to the external service as if it were part of the mesh, applying the same traffic management, security, and observability policies. For more information, see Manage service entries.

Virtual service

An ASM custom resource that defines routing rules for traffic within the mesh. Each routing rule specifies match conditions for traffic of a specific protocol and a destination service or service subset to forward matching traffic to. Virtual services decouple where clients send requests from how those requests are routed, enabling traffic splitting, A/B testing, and staged rollouts. For more information, see Manage virtual services.

Destination rule

An ASM custom resource that defines traffic policies applied after routing decisions are made. Destination rules configure:

• Load balancing algorithm

• Connection pool size from the sidecar

• Outlier detection to identify and evict unhealthy endpoints from the load balancing pool

For more information, see Manage destination rules.

Throttling

A rate-limiting mechanism that protects services from excessive traffic. ASM supports local throttling for both gateways and services, letting you set maximum request rates. When traffic exceeds the configured threshold, excess requests are rejected. For more information, see Configure local throttling on an ingress gateway.

Circuit breaking

A resilience pattern that prevents cascading failures across services. When the number of errors or pending requests to a service exceeds a configured threshold, the circuit "opens" and new requests are immediately rejected rather than queued. This protects both the failing service and its callers from overload.

Configure circuit breaking thresholds in the TrafficPolicy section of a destination rule. For more information, see Use the route-level circuit breaking feature of ASM.

Canary release

A deployment strategy that rolls out a new version to a small subset of users while the stable version continues serving production traffic. Gradually increase the percentage of traffic directed to the new version to detect issues early and roll back quickly if needed.

For more information, see Use ASM to deploy an application in blue-green release mode and phased release mode, Use traffic labels to implement an end-to-end canary release, and Perform a canary release based on traffic splitting for a Knative Service by using Knative on ASM.

Blue-green release

A deployment strategy that maintains two identical production environments -- blue and green. The current version runs in one environment (blue) while the new version is deployed and tested in the other (green). After validation, all traffic switches from blue to green in a single cutover. Because both environments remain available throughout, you can switch back instantly if issues arise, achieving zero-downtime deployments.

For more information, see Use ASM to deploy an application in blue-green release mode and phased release mode and Integrate with Apsara DevOps to implement blue-green deployments.

Mesh topology

A built-in visualization tool that provides observability for applications in your ASM instances. The graphical interface allows you to monitor service behavior. For more information, see Mesh topology.

SLO

A Service Level Objective (SLO) defines a target value or acceptable range for a measurable aspect of service reliability. SLOs are built on Service Level Indicators (SLIs) -- specific metrics such as latency, availability, or error rate. They provide a shared, quantifiable benchmark that developers, platform operators, and O&M personnel use to track and improve service health. For more information, see SLO management.

OIDC

OpenID Connect (OIDC) is an identity authentication and authorization protocol built on OAuth 2.0, commonly used to implement Single Sign-On (SSO). In ASM, configure OIDC on an ingress gateway or through an ASM security policy to authenticate users before they reach backend services.

For more information, see Configure OIDC-based SSO on an ingress gateway and Configure an ASM security policy to implement OIDC SSO.

JWT

JSON Web Token (JWT) is a compact, self-contained token format defined in RFC 7519 for securely transmitting claims between parties. A JWT carries information such as user identity, roles, and permissions, enabling stateless authentication across distributed systems. In ASM, configure JWT authentication on ingress gateways to validate tokens in incoming HTTP requests before routing them to backend services.

For more information, see Authenticate a JWT in an HTTP request for authorization and Configure JWT authentication for an ingress gateway in ASM.