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
Description
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
Exposes the Service on each node's IP at a static port (NodePort). The NodePort Service will be routed to the ClusterIP Service that will be created automatically. It can be accessed from outside the cluster through the <NodeIP>:<NodePort> request. We recommend you not provide external and even public network services directly through cluster nodes in the production environment, as using NodePort will expose cluster nodes directly to attacks. Generally, cluster nodes are dynamic and can be added or removed, and using NodePort will couple them with addresses providing external services.
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. A LoadBalancer services is 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
Description
Public network
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 CLB was upgraded on March 6, 2023. After the upgrade, public network CLB instances deliver services through domain names. The VIP of a CLB instance is no longer displayed in the console. This is because as service traffic increases, the VIP changes dynamically. For more information, see [March 6, 2023] Notice: Domain Name-Based CLB Available on Public Networks.
For CLB users registered after the upgrade, the domain name-based CLB architecture is adopted by default.
If your account was registered before the upgrade, you can choose whether to use the original CLB architecture. To use the upgraded architecture, you need to upgrade both CLB and TKE, or else, public network Service/Ingress add-ons will not be properly synchronized in TKE. For information about how to upgrade CLB, see Directions for Upgrading to Domain Name-Based CLB. For information about the upgraded TKE Service/Ingress add-on versions, please submit a ticket.
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.
If this label exists, the corresponding resource will be deleted when the Service is terminated.
If this label does not exist, only the listener resources in the CLB instance but not the CLB instance itself will be deleted when the Service is terminated.
tke-clusterId = <ClusterId>: Identifies the cluster that uses the resource.
If the ClusterId is correct, the corresponding label will be deleted when the Service is terminated.
Note
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 CLB, the CLB will not be deleted when services are deleted.
When a Service of the LoadBalancer type is created, the lifecycle of the corresponding CLB instance starts; when the Service is deleted or the CLB instance is recreated, the lifecycle ends. During the lifecycle, the CLB instance will be continuously synchronized based on the description of the Service. The CLB instance will be recreated or terminated if you switch the network for accessing the Service (public network > VPC, VPC > public network, or between VPC subnets) or replace the CLB instance. A Service of the LoadBalancer type works as follows:
Service precautions
Each Service has the .spec.externalTrafficPolicy field. The kube-proxy filters the endpoints it routes to based on the .spec.externalTrafficPolicy setting. When the field is set to Local, Kubernetes considers only a node's local endpoints. When the field is set to Cluster (default value), or is not set, Kubernetes considers all endpoints. For more information, see the Service Internal Traffic Policy Kubernetes document.
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:
Yes
No
Was this page helpful?