This topic introduces terms related to Service Mesh (ASM).
Overview
Category | Term | |
Common terms | Istio, managed service mesh, control plane, data plane, and namespace | |
Billing-related terms | ||
Mesh-related terms | Cluster and workload | |
Management of data plane components | ||
ASM gateways | ||
Traffic | virtual service, destination rule, throttling, circuit breaking, canary release, and blue-green deployment | |
Observability | mesh topology and SLO | |
Security | ||
Istio
Istio is an open source service mesh that provides a uniform and more efficient way to connect, secure, control, and monitor services. Istio provides a comprehensive microservices governance solution for you to handle issues related to microservices management, network connection, and security management.
managed service mesh
Service Mesh integrates and manages all components on the Istio control plane. ASM instances allow you to focus on application development and deployment without the need to maintain the Istio control plane. ASM instances are easy to use and provide high availability at low cost. For more information, see What is ASM?
control plane
Service Mesh is logically split into a data plane and a control plane. The control plane is used to manage and configure proxies to route traffic. For more information, see What is ASM?
data plane
The data plane consists of a set of intelligent Envoy proxies deployed as sidecars. These proxies mediate and control all network communication between microservices and that between sidecar proxies and the control plane. For more information, see What is ASM?
namespace
Namespaces are used in Kubernetes to divide cluster resources between users. By default, a Kubernetes cluster starts with three initial namespaces: default, kube-system, and kube-public. Administrators can create custom namespaces as required.
The namespaces that you create in a Service Mesh instance, whether in the ASM console or by using the kubectl client, belong only to the ASM instance. They are independent of the Kubernetes clusters on the data plane managed by the ASM instance. Therefore, the namespaces for the control plane in the ASM instance may be different from those of the Kubernetes clusters on the data plane managed by the ASM instance. When you create or delete namespaces for the Service Mesh instance, the namespaces of the Kubernetes clusters on the data plane managed by the ASM instance are not affected. For more information, see Manage global namespaces.
pay-as-you-go
Pay-as-you-go is a billing method that allows you to use resources before you pay for them. If you use the pay-as-you-go billing method, you are charged only for the resources that are used. You do not need to purchase resources in advance. For more information, see Billing rules.
service entry
A service entry is a custom resource of ASM that is used to add a service to the abstract model or service registry of ASM. Registered services are maintained in ASM. After you add an entry for an external service, the Envoy proxies can send traffic to the service as if the service was in the mesh. For more information, see Manage service entries.
sidecar proxy
A sidecar proxy is a container that is automatically injected into the microservice at run time. By default, each Envoy proxy in ASM can access requests from all ports of the workloads associated with it, and then forward the requests to the corresponding workloads. You can modify the ports and protocols supported by the Envoy proxy and specify the services that the Envoy proxy can access.
By default, ASM provides a webhook controller that functions as a sidecar injector to automatically inject sidecar proxies into the pods of applications when you create pods in a cluster. You can configure the sidecar proxy injection policies used by the sidecar injector and the resources and pods serving the sidecar injector. For more information, see topics related to sidecar management.
ingress gateway
Ingress gateways are Kubernetes services rather than custom resources in ASM. Ingress gateways are supported by pods. When you create an ingress gateway for a cluster in ASM, a Kubernetes service and a Deployment resource are deployed in the cluster. For more information, see Ingress gateway.
egress gateway
An egress gateway routes all outbound traffic in the mesh. For more information, see Egress gateway.
gateway
A custom resource of ASM that describes a load balancer running at the edge of the mesh for receiving inbound or outbound HTTP/TCP traffic. The specification describes a set of ports that need to be exposed, the type of protocol to use, and the server name indication (SNI) configuration for the load balancer. For more information, see Manage Istio gateways.
virtual service
A virtual service is a custom resource of ASM that defines a set of routing rules for specific services in a service mesh. Each routing rule defines matching criteria for traffic of a specific protocol. The traffic that matches a routing rule is sent to a destination service, or a subset or version of the destination service defined in the service registry. For more information, see Manage virtual services.
destination rule
A destination rule is a custom resource of ASM that defines policies that apply to traffic intended for a service after routing has occurred. These rules specify configurations for load balancing, connection pool size from the sidecar, and outlier detection settings to detect and evict unhealthy hosts from the load balancing pool. For more information, see Manage destination rules.
throttling
Throttling is a method used to protect the target service from being accessed excessively. ASM provides the local throttling feature that you can use to throttle traffic for gateways and services. For more information, see Use the local throttling feature of ASM.
circuit breaking
Circuit breaking is a capability provided by ASM that enables applications to handle issues related to failures, the potential peak of access requests, or unknown network factors. This way, the circuit breaking feature helps avoid network failures and service call failures and therefore prevents the system from being crashed or downgraded in performance. ASM allows you to configure the circuit breaking feature in the TrafficPolicy field. If the number of access requests on a network reaches the circuit breaking threshold, new access requests will be denied. For more information, see Use the API-based circuit breaking feature of ASM.
canary release
Canary release is a software development strategy in which a new version of an application is deployed for testing purposes while the base version still serves as a production release for normal operations at the same stage. This helps you identify and address issues at the earliest opportunity while ensuring overall system stability. 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 deployment
Blue-green deployment is an application release model that allows you to run two identical production environments: blue and green, ensuring business continuity. The current application version is running in one environment (blue) while the new application version is running in another one (green) for testing purposes. Once testing has been completed in the green environment, all live application traffic is directed to the green environment, and the current application version is upgraded to the new version. The two versions are always available during the release of an application. If an error occurs in one version, another one can be used. Therefore, zero downtime is realized. For more information, see Use ASM to deploy an application in blue-green release mode and phased release mode.
mesh topology
Mesh Topology provides observability for applications in ASM instances. This tool provides a GUI that allows you to monitor service behavior. For more information, see Mesh topology.
SLO
A service level objective (SLO) is an objective or a range of objectives that a service needs to achieve. An SLO consists of one or more service level indicators (SLI). An SLI is a metric that measures service health. SLOs provide a formal way to describe, measure, and monitor the performance, quality, and reliability of microservice-oriented applications. SLOs are a shared quality benchmark for application developers, platform operators, and O&M personnel. They can use SLOs as a reference to measure and continuously improve the service quality. An SLO helps describe the service health in a more accurate way. For more information, see SLO management.
OIDC
OpenID Connect (OIDC) is an identity authentication and authorization protocol, which is commonly used to implement single sign-on (SSO). For more information, see Configure OIDC-based SSO by using an ingress gateway and Configure an ASM security policy to implement OIDC SSO.
JWT
JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. JWT is an open standard (RFC 7519). A JWT can serve as an independent authentication token, which contains information such as the user ID, user role, and permissions, to help clients obtain resources from the resource server. A JWT can also provide additional claim information required for other business scenarios. This is suitable for logons in distributed sites. For more information, see RFC 7519, Configure JWT authentication for an ASM instance, and Configure JWT authentication for an ingress gateway in ASM.