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

  1. Log on to the ACK console and click Clusters in the left-side navigation pane.
  2. On the Clusters page, click the name of a cluster and choose Network > Services in the left-side navigation pane.
  3. On the Services page, click Create.
  4. In the Create Service dialog box, configure the parameters of the Service.
    ParameterDescription
    NameEnter a name for the Service.
    TypeThe 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 PolicySelect 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.
    BackendSelect 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 MappingSpecify 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 the targetPort field in the YAML file. The container port must be the same as the one that is exposed in the backend pod.
    AnnotationsAdd 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.
    LabelAdd one or more labels to the Service. Labels are used to identify the Service.
  5. 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
ParameterDescription
kindSpecifies that the resource object is a Service.
metadataDefines the basic information about the Service, such the name, labels, and namespace.
metadata.annotationsACK 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.selectorDefines the label selector of the Service. The Service exposes the pods with labels that match the label selector.
spec.ports.portSpecifies 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.targetPortSpecifies 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.typeDefines how the Service is accessed.
  • LoadBalancer: The Service is exposed by using an SLB instance. If you do not associate an existing SLB instance with the Service, the system automatically creates one. By default, the automatically created SLB instance is Internet-facing. You can set service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type to intranet to create a Service for internal access and an internal-facing SLB instance for this Service. For more information, see Use an existing SLB instance to expose an application and Use an automatically created SLB instance to expose an application.
  • ClusterIP: exposes the Service within the cluster. A ClusterIP Service is accessible from within the cluster.
  • NodePort: maps a node port to the backend Service. You can access the Service from outside the cluster by sending requests to NodeIP:NodePort.
  • ExternalName: maps the Service to a DNS server.

Create a Service

  1. 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.
  2. 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.
  3. Run the following command to create a Service:
    kubectl apply -f my-nginx-svc.yaml
  4. 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.
Note Log on to the Container Service for Kubernetes (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.
External traffic policy

The following table describes the differences between the Local policy and the Cluster policy.

ItemLocalCluster
Backend serversOnly 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 quotasThis 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 instanceOnly 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 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-scheduler:"wrr" to the Service YAML file.

By default, load balancing among pods is enabled.
Source IP preservationSupported Not supported
Session persistenceSupported 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.

terway

The following table describes the differences between the Local policy and the Cluster policy.

ItemLocalCluster
Backend serversPods can be added to SLB instances as backend servers.
SLB resource quotasThis 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 instanceOnly 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 podsBy default, load balancing among pods is enabled.
Source IP preservationSupported
Session persistenceSupported