You can deploy various containers in Kubernetes. Some of them provide layer-7 network services externally over HTTP or HTTPS, and others provide layer-4 network services over TCP or UDP. Service resources defined in Kubernetes are used to manage access to layer-4 network services in a cluster.
You can specify the Service type with Kubernetes ServiceType, which defaults to ClusterIP. ServiceType values and their behaviors are described as follows:
Value
Note
ClusterIP
Exposes the Service on a cluster-internal IP. Choosing this value makes the Service only reachable from within the cluster. This is the default value of ServiceType.
NodePort
Expose the service through the IP and static port (NodePort) on each cluster node. NodePort services route to ClusterIP services, which are automatically created. By requesting <NodeIP>:<NodePort>, the NodePort service can be accessed from outside the cluster. It is not recommended to provide services directly through cluster nodes or even the public network in production environments, except for testing and non-production environments. From a security perspective, using this type exposes cluster nodes directly, making them vulnerable to attacks. Cluster nodes are generally considered dynamic and scalable, and using this type creates coupling between the service's external address and the cluster nodes.
LoadBalancer
Exposes the Service externally or privately by using a CLB instance. The CLB can be routed to NodePort or directly forwarded to containers in the VPC-CNI network.
ClusterIP and NodePort Services usually behave in the same way in external clusters or those provided by cloud vendors. LoadBalancer Services are exposed by using a cloud vendor's load balancer and will have additional load balancer capabilities provided by the cloud vendor, for example, control of the network type of the load balancer and adjustment of weights of bound real servers. For more information, see Service Management.
Service Access Methods
You can use the following service access methods provided by TKE based on the above definition of ServiceTypes:
Access Method
Service Type
Note
Public network forwarding cluster
LoadBalancer
In Loadbalance mode of the Service, public IPs can directly access backend Pods. This method is applicable to web frontend Services.
A created Service can be accessed from outside the cluster with the "CLB instance domain name or IP + Service port" or from within the cluster with the "Service name + Service port".
Note: The architecture of Tencent Cloud Load Balancer (CLB) instances was upgraded on March 6, 2023. After the upgrade, public network CLB instances provide services through domain names. The VIP dynamically changes with business requests, and the console no longer displays VIP addresses. Please refer to the Announcement of Domain Name-Based Public Network CLB Launch.
For CLB users registered after the upgrade, the domain name-based CLB architecture is adopted by default.
Existing users can choose to continue using their current load balancing services without being affected by the upgrade. If you need to upgrade your load balancing service, you must upgrade both Tencent Cloud CLB and TKE; otherwise, the synchronization of all public network Service/Ingress types in TKE may be affected. For details on CLB upgrade operations, see Domain Name-Based Load Balancer Upgrade Guide. To upgrade the Service/Ingress component version in TKE, please contact us through Online Consultation.
VPC
LoadBalancer
In Loadbalance mode of the Service, private IPs can directly access backend Pods by specifying the service.kubernetes.io/qcloud-loadbalancer-internal-subnetid: subnet-xxxxxxxx annotation.
A created Service can be accessed from outside the cluster with the "CLB instance domain name or IP + Service port" or from within the cluster with the "Service name + Service port".
Access through the node port
NodePort
This access method maps node ports to containers and is supported for TCP, UDP, and Ingress. It can be used for customizing upper-layer load balancer forwarding to nodes.
A created Service can be accessed with the "CVM instance IP + node port".
Access from within the cluster only
ClusterIP
In ClusterIP mode of the Service, Service IPs are automatically assigned for access from within the cluster. This method can be used for database services such as MySQL, so as to ensure service network isolation.
A created Service can be accessed with the "Service name + Service port".
CLB Concepts
How a Service works
In a Tencent Cloud container cluster, the Service Controller add-on syncs your Service resources when you create, modify, or delete Service resources, cluster nodes or service endpoints change, or add-on containers drift or restart.
The Service Controller add-on will create CLB resources and configure listeners and real servers based on the description of the Service resource. When you delete the Service resource, it will repossess the CLB resources.
Service lifecycle management
The external service capabilities of a Service rely on the resources provided by the CLB instance. Service resource management matters to a Service, which will use the following labels during the resource lifecycle management:
tke-createdBy-flag = yes: Indicates that the resource is created by TKE.
tke-clusterId = <ClusterId>: Identifies the cluster that uses the resource.
Note
The above tags are read-only for users. Please do not modify or delete them, as doing so may result in resource leakage.
If you use an existing CLB instance, the Service will only use but not delete the instance.
If deletion protection is enabled or a private connection is used for the load balancer, the load balancer will not be deleted when the Service is removed.
When a LoadBalancer type Service resource is created in the cluster, the corresponding load balancer's lifecycle begins. The load balancer's lifecycle ends when the Service resource is deleted or the load balancer is rebuilt. During this period, the load balancer continuously synchronizes with the Service resource description. When users switch the network access of the Service, such as from public network to Cluster IP, VPC private network to Cluster IP, or Cluster IP to an existing load balancer, these operations involve the deletion or termination of the load balancer. The working principle of the LoadBalancer type Service is illustrated in the following diagram:
Service precautions
Service has a field: .spec.externalTrafficPolicy. kube-proxy filters the target service endpoints based on the spec.internalTrafficPolicy setting. When its value is set to Local, only the local service endpoints on the node are selected. When its value is set to Cluster or left as default, Kubernetes selects all service endpoints. For more information, see Kubernetes documentation.
If the Service uses the Local method, there will be a stream interruption when a Pod is scheduled from a TKE node to a super node, or from a super node to a TKE node, because the Service will select only a local service endpoint.
High-risk operations on a Service
Use a traditional CLB instance (not recommended).
Modify or delete a CLB instance label added by TKE, purchase a new CLB instance, and recover the label.
Rename a CLB listener managed by TKE in the CLB console.
Service features
For more information on Service operations and features, see the following documents:
