Basic Service Concepts

You can deploy various containers in a Kubernetes cluster. Some containers use HTTP or HTTPS to provide external Layer-7 network services, and the others use TCP or UDP to provide Layer-4 network services. Kubernetes defines service resources to manage Layer-4 network service access in a cluster.

Kubernetes ServiceTypes allows you to specify what kind of service you want. The default type is ClusterIP. ServiceTypes values and their behaviors are as follows:

• ClusterIP: exposes the service on a cluster-internal IP address. Choosing this value makes the service only reachable from within the cluster. This is the default ServiceType.
• NodePort: exposes the service on each node's IP address at a static port (NodePort). A ClusterIP service, to which the NodePort service routes, is automatically created. You can access the NodePort service from outside the cluster by requesting :. Except in test and non-production environments, we do not recommend that cluster nodes provide external or even public network services. Typically, cluster nodes are dynamic and scalable. When this service type is used, cluster nodes are exposed and can be attacked easily, and the address and cluster node used to provide external services are coupled.
• LoadBalancer: the CLB provided by Tencent Cloud is used to expose the service to the Internet or a VPC. The CLB can be routed to the NodePort service or directly forwarded to a pod in a VPC-CNI network.

Services of the ClusterIP and NodePort types typically behave in the same way in clusters provided by different cloud providers or off-premises clusters. Services of the LoadBalancer type are exposed using the cloud provider's CLB and the service provider provides extra features related to the CLB, for example, controlling the CLB network type and adjusting weights of bound backend nodes. For more information, please see documents related to service management.

Service Access

The following table describes four service access modes that TKE provides based on ServiceTypes definition.

CLB-related Concepts

Service principles

The Service Controller component in a TKE cluster synchronizes users' service resources when a service is created, modified, or deleted, a cluster node or service endpoint is changed, or a pod is shifted or restarted.

Service Controller will create CLB resources and configure listeners and backend nodes based on the service resource description. When you delete cluster service resources, Service Controller will reclaim the corresponding CLB resources.

Service lifecycle management

The external service capabilities of a service depend on resources provided by the CLB. Service resource management is one of the important tasks of a service. A service will use the following labels in resource lifecycle management:

• tke-createdBy-flag = yes: identifies that the resource was created by TKE.
  • With this label, the resource is deleted when the service is destroyed.
  • Without this label, only listener resources in the CLB will be deleted and the CLB will not be deleted when the service is destroyed.
• tke-clusterId = <ClusterId>: identifies the cluster that uses the resource.
  • If ClusterId is correct, the corresponding label will be deleted when the service is destroyed.

If you use an existing CLB for a service, the service will only use the CLB and will not delete the CLB.

When a service of the LoadBalancer type is created, the corresponding CLB lifecycle starts. The CLB lifecycle ends only when the service is deleted or the CLB is rebuilt. In the CLB lifecycle, the CLB is synchronized based on the service description. When you change the service access mode, for example, from Via Internet to Via VPC or from Via VPC to Via Internet or VPC subnet switching or change to use an existing CLB for the service, the CLB will be rebuilt or destroyed.
The following figure shows the working principles of a service of the LoadBalancer type.

High-risk service operations

1. Use a traditional CLB (no recommended)
2. Modify or delete a CLB label added by TKE, and then purchase a new CLB to restore the CLB label.
3. Modify the name of a CLB listener managed by TKE in the CLB console.

Service features

The following lists service-related operations and features. For more information, see the corresponding documents.

• Basic features
• CLB configuration
• Using existing CLBs
• Backend selection

Reference

For more information about services, see Kubernetes Service.