Each pod in Kubernetes clusters has an 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. In the left-side navigation pane, click Clusters.
On the Clusters page, click the name of the cluster that you want to manage and choose in the left-side navigation pane.
On the Services page, click Create in the upper-right corner.
In the Create Service dialog box, configure the following parameters.
Parameter
Description
Name
Enter a name for the Service.
Type
The type of the 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 within the cluster.
NoteThe Headless Service check box is displayed only if 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>
.NoteThis option is supported only by ACK clusters. ACK Serverless 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.
NoteYou can create an SLB instance or use an existing SLB instance. You can also associate an SLB instance with multiple Services. 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 listener ports. Otherwise, port conflicts 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.
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.
External Traffic Policy
Select a policy to distribute external traffic. For more information about external traffic policies, see Differences between external traffic policies.
Local: routes traffic only to pods on the node where the Service is deployed.
Cluster: routes traffic to pods on other nodes in the cluster.
NoteThe External Traffic Policy parameter is available only if you set Type to Node Port or Server Load Balancer.
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 port 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 only if you set Type to Server Load Balancer. For example, you can use the annotation
service.beta.kubernetes.io/alicloud-loadbalancer-bandwidth:2
to set the maximum bandwidth of the Service to 2 Mbit/s in order to limit the amount of traffic that flows through the Service. For more information about annotations, see Add annotations to the YAML file of a Service to configure CLB instances.Label
Add one or more labels to the Service. Labels are used to identify a Service.
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.
NoteOn 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 |
| Specifies that the resource object is a Service. |
| Defines the basic information about the Service, such as the name, labels, and namespace. |
| ACK provides rich annotations for you to configure load balancing. In this example, the annotation |
| Defines the label selector of the Service. The Service exposes the pods whose labels match the label selector. |
| Specifies the Service port that is exposed with the cluster IP address. You can access the Service from within the cluster by sending requests to |
| Specifies the port of the backend pod to receive traffic. The traffic that flows through the Service |
| 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
Run the following command to delete a Service:
kubectl delete service my-nginx-svc
Differences between external traffic policies
The features of external traffic policies vary based on the network plug-in that is used by the cluster. This section compares the features of external traffic policies when the cluster uses the Flannel or Terway-Eniip network plug-in.
Log on to the ACK console. On the Clusters page, click the name of the cluster that you want to manage. On the Basic Information tab, you can view the network plug-in of the cluster in the Cluster Information section.
Flannel
If the cluster uses the Flannel network plug-in, the NodePort Services on nodes forward traffic to the backend pods.
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 |