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.
ServiceTypes allows you to specify what kind of service you want. The default type is
ServiceTypes values and their behaviors are as follows:
ClusterIPservice, to which the
NodePortservice routes, is automatically created. You can access the
NodePortservice from outside the cluster by requesting
NodePortservice or directly forwarded to a pod in a VPC-CNI network.
Services of the
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.
The following table describes four service access modes that TKE provides based on
|Access Method||Service Type||Description|
|Node Port Access||NodePort||
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.
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.
tke-clusterId = <ClusterId>: identifies the cluster that uses the resource.
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
The following lists service-related operations and features. For more information, see the corresponding documents.
For more information about services, see Kubernetes Service.