Each pod in Kubernetes clusters has its own IP address. However, pods are frequently created and deleted. Therefore, it is not practical to directly expose pods to external access. The Service resource decouples the frontend from the backend to provide a loosely-coupled microservices architecture. This topic describes how to create Services to expose applications by using the Container Service for Kubernetes (ACK) console or kubectl.
Manage Services in the ACK console
- Log on to the ACK console and click Clusters in the left-side navigation pane.
- On the Clusters page, click the name of a cluster and choose in the left-side navigation pane.
- On the Services page, click Create.
- In the Create Service dialog box, configure the parameters of the Service.
Parameter Description Name Enter a name for the Service. Type The type of Service. This parameter specifies how the Service is accessed. Valid values: - Cluster IP: the ClusterIP type Service. This type of Service is exposed by using the internal IP address of the cluster. This is the default value. If you select this option, the Service is accessible only from within the cluster. Note The Headless Service check box is displayed only when you set Type to Cluster IP. If you select this check box, you can use a headless Service to interface with other service discovery mechanisms, without being tied to the implementation of service discovery in Kubernetes.
- Node Port: The NodePort type Service. This type of Service is accessed by using the IP address and a static port of each node. A NodePort Service can be used to route requests to a ClusterIP Service. The ClusterIP Service is automatically created by the system. You can access a NodePort Service from outside the cluster by sending requests to
<NodeIP>:<NodePort>
.Note This option is supported only by ACK clusters. Serverless Kubernetes (ASK) clusters do not support this option. - Server Load Balancer: The LoadBalancer type Service. This type of Service uses Internet-facing Server Load Balancer (SLB) instances or internal-facing SLB instances to enable external access or internal access. You can also use a LoadBalancer Service to route traffic to NodePort Services or ClusterIP Services.
- Create SLB Instance: You can click Modify to change the specification of the SLB instance.
- Use Existing SLB Instance: You can select an existing SLB instance.
Note You can create an SLB instance or use an existing SLB instance. You can also associate an SLB instance with more than one Service. However, you must take note of the following limits:- If you use an existing SLB instance, the listeners of the SLB instance overwrite the listeners of the Service.
- The SLB instance that is created for a Service cannot be shared by other Services. If you use the SLB instance to expose other Services, the SLB instance may be deleted. Only SLB instances that are manually created in the console or by calling the API can be used to expose multiple Services.
- Kubernetes Services that share the same SLB instance must use different frontend listening ports. Otherwise, port conflicts may occur.
- If you use one SLB instance to expose multiple Services, Kubernetes uses listener names and vServer group names as unique identifiers. Do not modify the names of listeners or vServer groups.
- You cannot share SLB instances across clusters.
External Traffic Policy Select a policy to distribute external traffic. For more information about the external traffic policy, see Differences between external traffic policies. - Local: routes traffic only to pods on the node where the Service is deployed.
- Cluster: the network traffic can be routed to pods on other nodes in the cluster.
Note The External Traffic Policy parameter is available only if you set Type to Node Port or Server Load Balancer.Backend Select the backend application that you want to associate with the Service. If you do not select a backend application, no Endpoint objects are created. For more information, see Services-without-selectors. Port Mapping Specify a Service port and a container port. The Service port corresponds to the port
field in the YAML file and the container port corresponds to thetargetPort
field in the YAML file. The container port must be the same as the one that is exposed in the backend pod.Annotations Add one or more annotations to the Service to modify the configuration of the SLB instance. You can select Custom Annotation or Alibaba Cloud Annotation from the Type drop-down list. For example, the annotation service.beta.kubernetes.io/alicloud-loadbalancer-bandwidth:2
specifies that the maximum bandwidth of the Service is 2 Mbit/s. This limits the amount of traffic that flows through the Service. For more information about Service annotations, see Use annotations to configure load balancing.Label Add one or more labels to the Service. Labels are used to identify the Service. - Cluster IP: the ClusterIP type Service. This type of Service is exposed by using the internal IP address of the cluster. This is the default value. If you select this option, the Service is accessible only from within the cluster.
- Click Create. On the Services page, you can view the Service that you created.In the Actions column, you can click Details to view the Service details, click Update to update the Service, and click Delete to delete the Service.Note On the details page of the Service, you can click the hyperlink on the right side of External Endpoint to access the backend application.
Manage Services by using kubectl
Service YAML template
apiVersion: v1
kind: Service
metadata:
annotations:
service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "intranet"
labels:
app: nignx
name: my-nginx-svc
namespace: default
spec:
ports:
- port: 80
protocol: TCP
targetPort: 80
selector:
app: nginx
type: LoadBalancer
Parameter | Description |
---|---|
kind | Specifies that the resource object is a Service. |
metadata | Defines the basic information about the Service, such the name, labels, and namespace. |
metadata.annotations | ACK provides rich annotations for you to configure load balancing. In this example, the annotation service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type is set to intranet , which specifies that the Service is accessible over the internal network. For more information, see Use annotations to configure load balancing. |
spec.selector | Defines the label selector of the Service. The Service exposes the pods with labels that match the label selector. |
spec.ports.port | Specifies the Service port that is exposed to the cluster IP address. You can access the Service from within the cluster by sending requests to clusterIP:port . |
spec.ports.targetPort | Specifies the port of the backend pod to receive traffic. The traffic that flows through the Service port is forwarded by kube-proxy to the port (specified by targetPort ) of the backend pod and then transmitted to the containers. |
spec.type | Defines how the Service is accessed.
|
Create a Service
- Create a Service YAML file based on the preceding YAML template. In the following example, a Service YAML file named my-nginx-svc.yaml is created.
- Connect to the cluster by using kubectl or Cloud Shell. For more information, see Obtain the kubeconfig file of a cluster and use kubectl to connect to the cluster and Use kubectl on Cloud Shell to manage ACK clusters.
- Run the following command to create a Service:
kubectl apply -f my-nginx-svc.yaml
- Run the following command to check whether the Service is created:
kubectl get svc my-nginx-svc
Expected output:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE my-nginx-svc LoadBalancer 172.21.XX.XX 192.168.XX.XX 80:31599/TCP 5m
Update a Service
- Method 1: Run the following command to update a Service:
kubectl edit service my-nginx-svc
- Method 2: Manually delete a Service, modify the YAML file, and then recreate the Service.
kubectl apply -f my-nginx-svc.yaml
View a Service
Run the following command to view a Service:
kubectl get service my-nginx-svc
Expected output:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
my-nginx-svc LoadBalancer 172.21.XX.XX 192.168.XX.XX 80:31599/TCP 5m
Delete a Service
kubectl delete service my-nginx-svc
Differences between external traffic policies
Flannel
- Local: This policy routes traffic only to pods on the node where the Service is deployed.
- Cluster: Traffic can be routed to pods on other nodes in the cluster.

The following table describes the differences between the Local policy and the Cluster policy.
Item | Local | Cluster |
---|---|---|
Backend servers | Only the nodes on which the backend pods are deployed are added to SLB instances as backend servers. | All nodes in the cluster are added to SLB instances as backend servers. |
SLB resource quotas | This policy consumes a small amount of SLB resources and does not require high SLB resource quotas. For more information about SLB resource quotas, see Quotas. | This policy requires high SLB resource quotas because all nodes in the cluster are added to SLB instances as backend servers. For more information about SLB resource quotas, see Quotas. |
Access to the IP address of an SLB instance | Only the nodes on which the backend pods are deployed can access the IP address of an SLB instance. | All nodes in the cluster can access the IP address of an SLB instance. |
Load balancing among pods | By default, load balancing among pods is disabled. To enable load balancing among pods, set the scheduling algorithm to weighted round-robin (WRR) by adding the annotation | By default, load balancing among pods is enabled. |
Source IP preservation | Supported | Not supported |
Session persistence | Supported | Not supported |
Terway-Eniip
If the cluster uses the Terway-Eniip network plug-in, traffic is directly forwarded to backend pods, regardless of which external traffic policy is used.

The following table describes the differences between the Local policy and the Cluster policy.
Item | Local | Cluster |
---|---|---|
Backend servers | Pods can be added to SLB instances as backend servers. | |
SLB resource quotas | This policy consumes a small amount of SLB resources and does not require high SLB resource quotas. For more information about SLB resource quotas, see Quotas. | |
Access to the IP address of an SLB instance | Only the nodes on which the backend pods are deployed can access the IP address of an SLB instance. | All nodes in the cluster can access the IP address of an SLB instance. |
Load balancing among pods | By default, load balancing among pods is enabled. | |
Source IP preservation | Supported | |
Session persistence | Supported |