Microservices Governance

Microservices Application

General

A microservices application is a collection of resource objects such as workloads, services and service mesh resources. Microservices applications can be connected to the platform for visual governance. You can create a microservices application by creating new workloads and services or by selecting existing ones, so that traffic management, canary release, trace tracking and topology viewing are supported for the application.

Note: To use the microservices governance feature in a cluster, the microservices governance component must be deployed in the cluster first. You can enable the microservices governance component when creating the cluster, or deploy it from the component list on the cluster details page.

Creating a Microservices Application

In the ZStack Zaku main menu, select Container Orchestration > Microservices Governance > Microservices Application. On the Microservices Application page, click Create Microservices Application and the Create Microservices Application page is displayed.

You can refer to the following example to enter the required information:

Name: set the name of the microservices application. Naming rules: the length is limited to 1-50 characters, the input can contain only lowercase letters, digits and hyphens (-), and it must start with a lowercase letter and end with a digit or a lowercase letter.
Description: optional. Add remarks about the microservices application.
Workload: specify the workloads of the microservices application. You can select existing workloads or create new ones.
- Select existing: directly select an existing workload.
  Note: One workload can be associated with only one microservices application.
- Create: create a new workload and associate it with the microservices application. For details, see Creating Workloads.
Workload Version: set the workload version. Version rules: the length is limited to 1-50 characters, the input can contain only lowercase letters, digits and hyphens (-), and a hyphen cannot be used at the beginning or the end.
Note: If the workload already has the zsedge.io/version label, the value of this label is used as the workload version by default. It can be modified manually, and the modified value overwrites the zsedge.io/version label of the workload.
Service: specify the services of the workloads. You can select existing services or create new ones.
- Select existing: directly select an existing service.
  Note: An existing service must be associated with the workloads of the microservices application.
- Create: create a new service. For details, see Creating Services

Managing Microservices Applications

In the ZStack Zaku main menu, click Container Orchestration > Microservices Governance > Microservices Application to enter the Microservices Application page.

Microservices applications support the following operations:

Operation	Description
Create microservices application	Create a new microservices application.
Canary release	Create a canary release to update the workloads under the microservices application by means of a canary release. Note: Canary release is not supported in the following cases: There is no workload under the microservices application. There is no service under the microservices application. The service mesh resources of the microservices application have been modified in a way other than a form. A canary release task already exists for the microservices application. When the services under the microservices application are associated with workloads through the zsedge.io/version label, the traffic policy of the canary release cannot take effect accurately. You need to update the service Yaml first to remove the zsedge.io/version label from spec.selector, and then perform the canary release. Visual viewing and management of a canary release are not supported in the following cases: The service mesh resources of the microservices application have been modified in a way other than a form, or there is no service mesh resource under the microservices application. There is no workload under the microservices application.
Delete microservices application	Delete the microservices application. Note: Deleting a microservices application also deletes the service mesh resources under it.

Canary Release

A canary release is a software deployment strategy that aims to apply a new version to the production environment safely and gradually. ZStack Zaku supports visual operations for the complete canary release process, including creating a canary release task, configuring traffic policies, monitoring the canary release process in real time and taking a version offline, so as to achieve a smooth transition and risk control for version updates. This section describes the whole canary release process.

The whole canary release process includes the following four steps:

Creating a canary release task
Monitoring the canary release
Adjusting the traffic policy
Taking over all traffic and taking a version offline

Create a canary release task.
In the ZStack Zaku main menu, click Container Orchestration > Microservices Governance > Microservices Application. On the Microservices Application page, select the microservices application for which the canary release is to be performed and click Canary Release. The Canary Release page is displayed.
Creating a canary release task includes the following two steps:
1. New workload version
  Create a workload of the new version. Three methods are supported: quick creation, standard creation and selecting an existing workload.
  1. Quick creation
    Only the name, the number of replicas and the image configuration of the workload are set, and the other configurations remain the same as those of the old workload version.
    You can refer to the following example to enter the required information:
    - Workload Name: specify the name of the new workload version. Naming rules: the length is limited to 2-50 characters, the input can contain only lowercase letters, digits and hyphens (-), and it must start with a lowercase letter and end with a lowercase letter or a digit.
    - Workload Version: specify the version of the new workload version. Version rules: the length is limited to 1-50 characters, the input can contain only lowercase letters, digits and hyphens (-), and a hyphen cannot be used at the beginning or the end.
    - Replicas: set the number of pods that the workload contains. Up to 100 replicas are supported. Workloads of the DeamonSet type do not need the number of replicas to be set.
    - Image Configuration: configure the image of the container. By default, the setting is the same as that of the old workload version.
      
      Container: the container name. It is the same as that of the old workload version and cannot be modified.
      
      Image Source: select the source of the container image. Both a repository and an external repository are supported.
      If you select Repository, the container is created using an image that has been uploaded to the ZStack Zaku repository. Set the following parameters:
      
      Image: select the container image.
      
      Tag: select the image tag.
      
      If you select External repository, the image is pulled from a repository outside ZStack Zaku to create the container. Set the following parameters:
      
      Image: enter the detailed image address, for example: docker.io/library/nginx:latest.
      
      Image pulling Secret: optional. If the external repository to which the image belongs is a private repository, select a secret for repository authentication.
    Note: With the quick creation method, all configurations except the name, the number of replicas and the image configuration of the workload remain the same as those of the old workload version. If the PVC mounted to the old workload version does not support read or write by multiple nodes, use standard creation to select a new PVC.
  2. Standard creation
    You can refer to the following example to enter the required information:
    - Create Workload: create a new workload. For details, see Creating Workloads
    - Workload Version: specify the version of the new workload version. Version rules: the length is limited to 1-50 characters, the input can contain only lowercase letters, digits and hyphens (-), and a hyphen cannot be used at the beginning or the end.
      Note: If the workload already has the zsedge.io/version label, the value of this label is used as the workload version by default. It can be modified manually, and the modified value overwrites the zsedge.io/version label of the workload.
  3. Select existing
    You can refer to the following example to enter the required information:
    - Select Workload: if the new workload version has already been created in another way, you can select this workload directly.
      Note: Make sure that the selected workload can be associated with the services under the application.
    - Workload Version: specify the version of the new workload version. Version rules: the length is limited to 1-50 characters, the input can contain only lowercase letters, digits and hyphens (-), and a hyphen cannot be used at the beginning or the end.
      Note: If the workload already has the zsedge.io/version label, the value of this label is used as the workload version by default. It can be modified manually, and the modified value overwrites the zsedge.io/version label of the workload.
2. Canary policy
  You can refer to the following example to enter the required information:
  - Policy type: select the type of the traffic policy. Two ways of distributing traffic between the new and old versions are supported: by traffic ratio and by request content.
    If you select by traffic ratio, the access traffic is sent to the new workload version according to the configured ratio, and the remaining traffic is sent to the old workload version. Set the following parameters:
    
    Traffic ratio of the new version: set the ratio of the traffic to be sent to the new version. The default value is 50%, and the maximum value is 100%.
    If you select by request content, the traffic that matches the following request content configuration is sent to the new workload version, and the other traffic is sent to the old workload version. Set the following parameters:
    
    Request content: set the requirements for the request content to be sent to the new workload version. Only the requests that meet these requirements are sent to the new workload version, and the other requests are sent to the old workload version. You can fill in the URI, Cookie, Header and operating system requirements at the same time, or only one or several of them.
    
    URI: set the matching method of the URI and the content to be matched. That is, the URI accessed by the request traffic must match the entered content according to the selected matching method.
    
    Cookie: set the matching method of the Cookie and the content to be matched. That is, the entered content must be matched in the Cookie of the request traffic according to the selected matching method.
    
    Header: set the matching method of the Header and the content to be matched. That is, the entered content must be matched in the Header of the request traffic according to the selected matching method.
    
    Operating system: specify the operating systems whose request traffic can be sent to the new version. The default value is all operating systems, and Windows, Linux, Mac OS, Android and iOS can be specified.
    Note: The following three matching methods are supported:
    
    Exact match: the request URI/Cookie/Header must match the specified content exactly before it can be sent to the new version.
    
    Prefix match: the request URI/Cookie/Header must meet the specified prefix requirement before it can be sent to the new version.
    
    Regex match: the request URI/Cookie/Header must match the specified regular expression before it can be sent to the new version.
Monitor the canary release.
After the canary release task is created, in the ZStack Zaku main menu, click Container Orchestration > Microservices Governance > Microservices Application. On the Microservices Application page, click the microservices application for which the canary release has been performed to go to the canary release page of the microservices application details, where you can view the details of the canary release task and the traffic monitoring between the new and old versions.
Adjust the traffic policy.
In the ZStack Zaku main menu, click Container Orchestration > Microservices Governance > Microservices Application. On the Microservices Application page, click the microservices application for which the canary release has been performed to go to the canary release page of the microservices application details, and click Modify Policy. The Modify Policy page is displayed. You can adjust the traffic policy according to the actual situation of the canary release, referring to the steps for creating a canary release task.
Take over all traffic and take a version offline.
After you confirm that the features of the new version are stable, you can let the new version take over all traffic. If a problem occurs with the new version, the old version can take back all traffic. In the ZStack Zaku main menu, click Container Orchestration > Microservices Governance > Microservices Application. On the Microservices Application page, click the microservices application for which the canary release has been performed to go to the canary release page of the microservices application details, select the version that is to take over all traffic, and click Take Over All Traffic. All request traffic is then sent to this version. After that, you can click Take Version Offline to take the version that has no traffic offline and delete the workload corresponding to this version.

Service Topology

General

The service topology visually displays the invocation and dependency relationships between microservices applications in the current namespace, together with traffic monitoring data. Historical and real-time topology maps can be viewed visually, and traffic management rules such as load balancing, connection pool and circuit breaking can be configured for microservices applications.

Viewing the Topology Map

In the ZStack Zaku main menu, select Container Orchestration > Microservices Governance > Service Topology to enter the Service Topology page.

By default, the service topology displays the topology map of the microservices applications under the selected namespace of the selected cluster for the last 1 minute. The following is supported:

Displaying the requests per second, request success rate, request latency and number of pods of a workload.
Refreshing automatically every minute to obtain the latest data and display it in real time.
Selecting a time period to view the topology of the selected period.
Note: If there is no traffic between the microservices applications during the selected period, the topology map displays only the nodes, without connection lines.
The connection lines between nodes are green, yellow or red, which shows the request success rate intuitively. The color thresholds of the request success rate are: green (greater than or equal to 99.9%), yellow (greater than or equal to 80% and less than 99.9%) and red (less than 80%).
Zooming in, zooming out and full-screen viewing.

Traffic Management

In the ZStack Zaku main menu, select Container Orchestration > Microservices Governance > Service Topology to enter the Service Topology page. On the topology map, click the microservices application or workload for which traffic management is to be performed, and the Traffic Management page is displayed.

You can refer to the following example to enter the required information:

Load balancing: select whether to configure load balancing parameters. It is disabled by default. If it is enabled, set the following parameters:
- Load balancing policy: select the load balancing policy. Four policies are supported: least requests, round robin, random and session persistence. The default policy is least requests.
  Note:
  - Least requests: sends the access traffic to the pod that has the fewest requests currently.
  - Round robin: sends the access traffic to each pod in turn.
  - Random: sends the access traffic to any pod randomly.
  - Session persistence: based on a hash algorithm, assigns the traffic that meets the conditions to the same pod, to ensure session continuity and consistency.
  If you select session persistence, the traffic that meets the conditions is assigned to the same pod based on a hash algorithm, to ensure session continuity and consistency. Set the following parameters:
  - Session persistence algorithm: set the session persistence algorithm. Three algorithms are supported: based on HTTP Header hash, based on HTTP Cookie hash and based on source IP address hash. The default algorithm is based on HTTP Header hash.
    If you select based on HTTP Header hash, the session is kept according to the information in the Header, and the requests that have the same specified key value in the Header are sent to the same pod. Set the following parameters:
    
    HTTP Header key: set the name of the specified Header key to be used for the HTTP Header hash.
    If you select based on HTTP Cookie hash, the session is kept according to the Cookie information, and the requests that have the same specified information in the Cookie are sent to the same pod. Set the following parameters:
    
    Cookie name: set the Cookie name to be used for the HTTP Cookie hash.
    
    Cookie path: optional. Set the Cookie path to be used for the HTTP Cookie hash.
    
    Cookie validity period: optional. Set the validity period of the Cookie to be used for the HTTP Cookie hash. Unit: second.
    If you select based on source IP address hash, the session is kept according to the HTTP source IP address information, and the requests from the same source IP address are sent to the same pod.
Connection pool: select whether to configure connection pool parameters. It is disabled by default. If it is enabled, set the following parameters:
- Max pending requests: set the maximum number of pending requests of the connection pool. It can only be a positive integer.
- Max requests: set the maximum number of requests allowed by the connection pool. It can only be a positive integer.
- Max requests per connection: set the maximum number of requests allowed per connection. It can only be a positive integer.
  Note: If the max requests per connection is set to 1, session persistence is disabled.
- Max retries: set the maximum number of retries. It can only be a positive integer.
- Connection timeout: set the connection timeout period. Unit: second. It can only be a positive integer.
Circuit breaking: select whether to enable circuit breaking. It is disabled by default. If it is enabled, set the following parameters:
Note: Circuit breaking is a mechanism that passively keeps HTTP services healthy. When the requests sent to a pod return 5xx response errors consecutively and the specified number of times is reached, this pod is ejected. During the ejection, client requests are not sent to this pod.
- Number of consecutive 5xx errors: specify after how many consecutive 5xx error responses a pod is ejected. It can only be a positive integer.
- Detection interval: set the detection interval. Unit: second. It can only be a positive integer.
- Min ejection duration: set the minimum ejection duration. Unit: second. It can only be a positive integer. The ejection duration of a pod = the min ejection duration * the number of times that this pod has been ejected.
- Max ejection percent: set the maximum ejection percentage. It can only be an integer from 1 to 100. The number of pods that can be ejected = the total number of pods * the max ejection percent. When the calculation result is not an integer, it is rounded down automatically.

Trace Tracking

General

Trace tracking integrates Jaeger to provide queries of the call chains between services and to monitor key metrics of the services in a call chain, such as the call status and the call duration, in an all-round way. This helps you understand the response of each node in the business request chain, so that you can quickly locate a problem and the module where it occurs.

Viewing Call Chain Data

In the ZStack Zaku main menu, select Container Orchestration > Microservices Governance > Trace Tracking to enter the Trace Tracking page. You can query call chains by service name, TraceID and request time, and a custom time period is supported. Each data entry shows one request operation, including the access time, the request duration, the number of spans and the information of each span.

Click a request to go to the details page, where you can view the detailed information of the request.

PreviousConfiguration Management NextArtifact Repository