Skip to main content
General Service is used to deploy continuously running HTTP applications, tool APIs, and custom container services. It provides resource, port, gateway, Health Check, and version management. To deploy model engines and multi-role inference workloads, see Create an LLM Inference Service.

​
Prerequisites

  • You have obtained the required permissions and quota for the target Region, Cluster, Project Group, and resource pool.
  • You have prepared a fixed-version image, startup command, application port, and minimal validation request.
  • Persistent data has been planned for an authorized Volume, and external dependencies and authentication methods have been confirmed.
  • For stateful applications, you have assessed multiple replicas, parallel operation of new and old versions, and data schema compatibility.

​
1. Go to the Create page

  1. Go to Inference > General Service.
  2. Select Region, Cluster, and Project Group.
  3. Click Create.

​
2. Enter configuration information

​
Basic information

​
Resource Information

The total resources required by the service are calculated based on the specifications of each replica and the number of replicas.

​
Environment Information

The cmd and mount configuration use paths inside the container. The application must listen on an address accessible from outside the container. If it listens only on 127.0.0.1, it typically cannot be accessed through the gateway.

​
Enhanced Features

​
Gateway Configuration

General services are accessible through the platform’s shared gateway by default. To use a custom domain name or configure different ingress paths by port, click Add Gateway and select Independent Gateway. Before configuring an independent gateway, complete the following preparations:
  • Resolve the custom domain name to the gateway ingress of the current cluster.
  • Prepare the domain certificate and HTTPS access policy.
  • In Port Configuration, add the service ports that the standalone gateway needs to forward.
The same domain name can be forwarded to different ports through different entry paths, or separate domain names can be configured for different ports. The gateway configuration should be consistent with the service’s actual protocol, port, path, authentication method, and Base URL settings.

​
Monitor Information

Used to compare error rates, latency, and resource usage before and after release.

​
3. Submit Creation

Click Create. After submission, view the Status in the general service list. When the service has not entered Running, view the workload details, events, image pull status, storage mounts, and startup logs to confirm that the instance is ready.

​
4. Verify Access

After the service enters Running, follow these steps to verify that the access path and service responses meet expectations:
  1. Go to the Overview tab on the service details page. Under Endpoint, click View Details. In Endpoint Information Details, view link addresses such as Shared Gateway and In-Cluster Access (VPC) by port. If authentication is enabled for the service, also obtain the platform-generated token.
  2. Send a minimal request based on the actual protocol, port, entry path, and authentication method. If multiple ports are configured for the service, verify each port that needs to be exposed externally. When authentication is enabled, include Authorization in the request header. When Base URL is enabled, confirm that the service can process request paths with a prefix.
  3. Confirm that the required volume read/write operations, external dependencies, and authentication flow are functioning properly.
  4. Record the error rate, latency, and resource usage as a baseline for comparison during subsequent updates or canary releases.
Passing the Health Check only indicates that the platform probe has succeeded; it does not guarantee that service requests will succeed. Route production traffic only after the expected ready capacity has been reached and minimum request validation has passed.

​
Next Actions

After the service passes the initial verification, you can continue with the following actions based on subsequent objectives:
  • Release or roll back a service version: Low-risk, validated changes can be released directly. When the target version needs to be validated first, use canary release and, based on the validation results, continue the rollout, roll back, or clean up the old version. For more information, see Release and Roll Back General Services.
  • Manage running services: View service Endpoints and workloads, or as needed, update the dedicated gateway, bring services online or offline, restart services, configure scheduled policies, share, or Delete services. For more information, see Manage General Services.