Service Mesh (ASM) can simplify microservice management in a microservices model. This topic provides a quick-start tutorial to describe how to use ASM to manage applications.
Procedure
Step | Operation | Description |
1 | To use ASM, you must first create an ASM instance. ASM allows you to perform operations such as traffic management, security management, fault recovery, observation, and monitoring on applications. | |
2 | Add a Container Service for Kubernetes (ACK) cluster to the ASM instance | An application deployed in an ASM instance runs in a cluster. Therefore, you must first add an ACK cluster to the ASM instance. |
3 | Create an ingress gateway in the ACK cluster that is added to the ASM instance | An ingress gateway provides a unified entrance for routing the inbound traffic at Layer 7. It routes HTTP requests from the same TCP-based port to different Kubernetes services based on the request content. |
4 | Deploy an application in the ACK cluster that is added to the ASM instance | After you deploy an ingress gateway in the ACK cluster that is added to an ASM instance, you can deploy applications in the ACK cluster. |
5 | Use Istio resources to route traffic to different versions of a service | ASM allows you to route traffic to different versions of a service based on the specified ratio. This feature applies to scenarios such as canary release and A/B testing. You can use Istio resources to route traffic to different versions of a service. |
6 | Mesh Topology provides observability for applications in ASM instances. This tool provides a graphical user interface (GUI) that allows you to monitor service behavior. You can use Mesh Topology to view the traffic flows and the communication between workloads. |
FAQ
Why am I unable to use the kubeconfig file of an ASM instance to deploy an application?
The ASM console provides the kubeconfig file to connect to ASM instances. This way, you can use the kubectl client to manage the Custom Resource Definitions (CRDs) of Istio, such as virtual services. The control plane of an ASM instance is used to manage Istio resources. You cannot deploy applications in the control plane.
Why am I unable to deploy the CRDs of Istio, such as virtual services, in the clusters that are managed by ASM?
Istio resources are managed in the control plane. The control plane also provides the kubeconfig file that is used to connect to the ASM instance.
Why am I unable to manage Istio resources by using the kubeconfig files of clusters?
The CRDs of Istio are saved in the control plane. The control plane converts the rules that are defined by Istio CRDs into the rules in sidecar configurations and applies the converted rules.
What are the differences between the namespaces in the control plane of an ASM instance and the namespaces of the clusters on the data plane?
The namespaces that you create in an ASM instance, whether in the ASM console or by using the kubectl client, belong only to the ASM instance. The namespaces are independent of the Kubernetes clusters on the data plane that are managed by the ASM instance.When you create or delete namespaces for the ASM instance, the namespaces of the Kubernetes clusters on the data plane managed by the ASM instance are not affected.