2. Select a region, and click Create in the upper left corner of the page.
3. On the Create service mesh page, fill in configurations related to mesh creation as required. For the description of the configuration items, see Configuration Item Description for Mesh Creation. Then, click Next: Confirm information.
4. On the Confirm information page, confirm that the creation configurations are correct and click Submit to start the mesh creation process.
5. After the mesh creation process is complete, view the service mesh instance in the list.
Configuration Item Description for Mesh Creation
Configuration Item
Description
Required
Mesh name
Name of the service mesh to be created.
Yes
Region
Region where the service mesh control plane runs. The region where the control plane runs can be different from the region where the service workload (such as a cluster) is located. It is recommended to select a region close to the region where the service workload (cluster) is located.
Yes
Mesh component version
Control plane and data plane version. Tencent Cloud Mesh is compatible with the latest two major versions of the Istio community.
Yes
Mesh mode
Deployment mode of components related to the service mesh control plane. For a managed mesh, the control plane components are managed and maintained by Tencent Cloud. For a stand-alone mesh, the control plane components are deployed in a cluster you specified, and you need to manage and maintain the control plane components in the cluster. The Managed mesh option is available by default. A stand-alone mesh can be used after being added to an allowlist. To apply for a stand-alone mesh, submit a ticket.
Yes
Egress traffic mode
Policy for the external access to services in the mesh. Two options are available: Registry Only (access to only services automatically discovered by the mesh and manually registered services is allowed) and Allow Any(access to any address is allowed).
Yes
Service discovery
Cluster for implementing automatic service discovery. The cluster must meet constraints such as version, permission, and IP range conflict.
No
Sidecar auto-injection
Namespace into which sidecars are automatically injected. After this field is enabled, sidecars will be automatically injected into all service workloads in the selected namespace. Auto-injection will take effect only for newly created service workloads. Sidecars will be injected into existing service workloads only after the workloads are restarted. If you need to further customize sidecar injection exceptions, see Custom Sidecar Injection.
No
External request bypasses sidecar
Corresponding to excludeIPRanges. By default, sidecars takes over all the traffic in the current pod. If you want the access from a specific IP address not to pass through the sidecar proxy, you can configure this field. After configuration, Istio features such as traffic management and observability will not be performed on the request traffic from the IP range. After the configurations are modified, they take effect only for newly added pods, and for existing pods only after the pods are restarted.
No
Sidecar readiness guarantee
Use the HoldApplicationUntilProxyStarts feature to configure a service container to wait for sidecars to complete the startup before starting. This configuration ensures that a pod in the service container that depends on the sidecars can run normally.
No
Sidecar stop protection
After this field is enabled, a sidecar needs to wait for the process in the service container to be completely terminated before stopping, which increases the pod stop time. It is recommended to enable this field for the service whose service process cannot be shut down at any time. For Istio versions earlier than 1.12, Tencent Cloud Mesh uses the preset container prestop script to check that there is no more service process before allowing the service container to exit. If a user configures other prestop scripts, this feature will be interfered with. For versions later than 1.12, this feature is implemented by the new feature EXIT_ON_ZERO_ACTIVE_CONNECTIONS.
No
Custom sidecar resources
By default, Tencent Cloud Mesh configures a resource limit of up to 2 cores and 1 GB for a sidecar container, which are sufficient in most cases. When the scale of your mesh increases or the logic in the sidecar increases, the default resource limit may be insufficient. You can modify the resource limit based on your service requirements.
No
Ingress gateway
Ingress gateway to be created for the mesh. If the selected cluster is a TKE/TKE Serverless cluster, an ingress gateway of the CLB type is created by default. In this case, CLB-related items need to be configured. If the cluster is a manually registered cluster, only a gateway service of the LoadBalancer type is created because it is not determined whether the cluster supports CLB.
No
Egress gateway
If you need to manage the outgoing traffic of the mesh in a centralized manner, such as unified egress, unified authentication, and rule configurations, you need to create an egress gateway. After this field is enabled, an egress gateway service of the ClusterIP type will be automatically created for you.
No
Gateway deployment mode
Two options are available: Normal mode and Exclusive mode. For details, see Gateway Deployment Modes.
No
Gateway auto-scale policy
HPA policy for the gateway that is deployed in the specified cluster.
No
Network resource definition
Pod resource limit customized for the ingress/egress gateway.
No
Consumer end
Monitoring metric backend service of the mesh. Currently, interworking with TMP is supported. After configuration, monitoring metrics will be reported to TMP. The Tencent Cloud Mesh console displays metrics based on the TMP data source. You can also view the metrics independently on the TMP console. If a consumer end is not configured for the monitoring metrics, the mesh cannot use monitoring features such as displaying monitoring metrics and topologies.
No
Consumer end
Call tracing backend service of the mesh. Currently, interworking with APM is supported. After configuration, tracing data will be reported to APM from sidecars. The Tencent Cloud Mesh console displays tracing data based on the APM data source. You can also view the data independently on the APM console. If a consumer end is not configured for call tracing, the mesh cannot use features such as viewing traces.
No
Trace sampling rate
Sampling rate at which the mesh collects data and persists in conducting call tracing. The resources consumed by sidecars during data collection and reporting are positively related to the bandwidth and data volume. Set the sampling rate as required. It is recommended to set the sampling rate to 100% for development and test environments, and 1% for production environments.
No
Range
To avoid unnecessary overhead, Tencent Cloud Mesh supports enabling sidecar logs for a specific gateway or namespace.
No
Log format
Tencent Cloud Mesh supports logs in JSON or TXT format.
No
Output template
Field settings for sidecar logs. There are two formats of predefined templates: default and enhanced. Compared with the fields output in the default format, the fields output in the enhanced format are added with Trace ID. If you need to further modify the field settings, customize the log fields by referring to Envoy's Standard Specifications.
No
Consumer end
Sidecar log backend service. Currently, interworking with CLS is supported. After this field is enabled, a log collection component will be deployed on cluster nodes to ensure normal use of the feature.
Yes
No
Was this page helpful?