Add Service#

This document will guide you through creating a ServiceMesh service or OpenTelemetry service.

#Prerequisites

1. The current namespace has been added to the service mesh. Please refer to Add Namespaces for instructions.
2. The workload type is a Deployment, and there is a one-to-one association with a Service.

#Add ServiceMesh service

#Steps

1. In the left navigation bar, click Service List.

2. Click Add Service.

3. Refer to the following instructions to configure the relevant parameters.

Parameter	Description
Deployment	The Deployment in the current namespace on the Container Platform, which is the compute component running the service.
Internal Routing	Information about the internal route that is one-to-one associated with the selected Deployment, supporting modifications to the route's protocol and container name. Internal Routing must meet the following conditions: - Only one internal route is associated with the selected Deployment, and this route is exclusively linked to that Deployment. - The type of the internal route is either NodePort or ClusterIP. - The service only supports HTTP, HTTP2, gRPC, TCP protocols. Do not add unsupported internal route protocols, as this may cause service invocation errors.
Sidecar Configuration	Under Service Mesh or Composite governance modes, a Sidecar will be automatically injected into the added service. This means that when the service Pod starts, a Sidecar container will also start within the Pod to take over the traffic in and out of the service and manage and govern the service. You can control the resource allocation for the Sidecar through resource configuration. You can configure the log level of the Sidecar. You can configure traffic passthrough as needed.
Cross-cluster Service Discovery	Note: This parameter is visible only when the current service mesh is a multi-cluster service mesh (at least 2 clusters). Whether to expose the service to all clusters managed by the mesh, allowing any service or gateway in other clusters under the mesh to directly access the current service. The Cross-cluster Service Discovery switch is a global (mesh-wide) parameter. Changing the switch state for any service with the same name under the mesh will affect all services with the same name (services with the same name as the internal route associated with the selected Deployment) across all clusters. Explanation: Services with the same name refer to services in different clusters managed by the service mesh, within namespaces with the same name; the successfully added service and the internal route associated with the selected Deployment are named the same. When the switch is turned on, after the service is successfully added: If there is no service in any other managed cluster with an internal route name matching the one associated with the selected Deployment, an internal route with the same name will be synchronously created in the respective cluster for service discovery. When creating the same name internal route in other clusters: If there is no namespace with the same name as the current namespace in the cluster, this will lead to the failure of internal route creation, thereby failing to provide cross-cluster service discovery capabilities. If there is an existing internal route with the same name as the one associated with the selected Deployment in a namespace (with the same name as the current namespace), the existing internal route will be used. Note: If the existing internal route has different configuration details from the current selected Deployment's associated internal route, cross-cluster service discovery may not be achievable. The Cross-cluster Service Discovery switch for all services with the same name in the mesh across all clusters will be turned on.

1. Click Add.

   After the service is successfully added:

   • (Under the Service Mesh governance method) A service with the same name as the Service will be generated in the service list.

   • The platform will automatically update the Pod template parameters of the service's Deployment, adding or updating the app: <service name> label.
     It is recommended not to modify these labels directly in the YAML file.

   • Restart the service's Deployment.
     During the restart process, as long as at least one Pod of the Deployment is in the Running state, the service is Online; otherwise, the service is Offline.

#Add OpenTelemetry Service

#Steps

1. In the left navigation bar, click Service List.

2. Click Add Service. In the governance method popup, select OpenTelemetry.

3. Refer to the following instructions to configure the relevant parameters.

Parameter	Description
Deployment	The Deployment deployed under the current namespace of the Container Platform, which is the computing component running the service.
Service Name	Under the OpenTelemetry governance method, you need to set the service name. Note: When the metadata.labels of the selected Deployment contains the asm.cpaas.io/msname: xxx label, the Service Name defaults to the value of this label and cannot be modified.

4. Click Add.

   After the service is successfully added:

   • Under OpenTelemetry or Composite governance modes, the service (Java 8+) will by default be injected with the OpenTelemetry Java Agent, enabling the platform to non-intrusively collect service telemetry data and JVM monitoring data.

   • The opentelemetry-operator component will intercept the creation of service Pods and add the Java Agent configuration.

   • Restart the service's Deployment.
     During the restart process, as long as at least one Pod of the Deployment is in the Running state, the service is Online; otherwise, the service is Offline.