tencent cloud

Service CLB Configuration
Download PDF
Last updated: 2024-12-23 11:41:09
Service CLB Configuration
Last updated: 2024-12-23 11:41:09
Download PDF

TkeServiceConfig

TkeServiceConfig is a Custom Resource Definition (CRD) provided by TKE. TkeServiceConfig can help you configure LoadBalancer-type Services more flexibly and manage various CLB configurations in them.

Use cases

CLB parameters and features that cannot be defined by Service YAML semantics can be configured through TkeServiceConfig.

Configuration instructions

TkeServiceConfig can help you quickly perform CLB configuration. Through the Service annotation service.cloud.tencent.com/tke-service-config:<config-name>, you can specify the target configuration and apply it to the Service.
Note：
TkeServiceConfig resources and the Service need to be in the same namespace.
TkeServiceConfig does not help you directly configure or modify protocols and ports. You need to describe protocols and ports in the configuration in order to deliver the specified configuration to the listener. You can declare multiple sets of listener configurations in a single TkeServiceConfig. Currently, configurations are mainly provided for CLB health check and backend access. When the protocol and port are specified, the configuration will be accurately delivered to the corresponding listener:
spec.loadBalancer.l4Listeners.protocol: Layer-4 protocol
spec.loadBalancer.l4Listeners.port: Listening port

Associated Actions Between Service and TkeServiceConfig

1. During the creation of a Loadbalancer-type Service, if you set annotation service.cloud.tencent.com/tke-service-config-auto: "true", <ServiceName>-auto-service-config will be automatically created. Alternatively, you can specify your own created TkeServiceConfig through service.cloud.tencent.com/tke-service-config:<config-name>. These two annotations cannot be used at the same time, and the manually specified <config-name> cannot be suffixed with -auto-service-config and -auto-ingress-config.
2. The automatically created TkeServiceConfig has the following sync behaviors:
When a layer-4 listener is added during Service resource update, if there is no corresponding TkeServiceConfig configuration segment for the listener or forwarding rule, Service-Controller will automatically add the corresponding TkeServiceConfig configuration segment.
When a layer-4 listener is deleted, Service-Controller will automatically delete the corresponding TkeServiceConfig segment.
When Service resources are deleted, the corresponding TkeServiceConfig will also be deleted.
When you modify the default TkeServiceConfig of the Service, the TkeServiceConfig content will also be applied to the CLB.
3. You can also refer to the following complete TkeServiceConfig configuration and create your own desired CLB configuration. Services will import the configuration through the annotation service.cloud.tencent.com/tke-service-config:<config-name>.
4. A manually created TkeServiceConfig has the following sync behaviors:
When you add a configuration annotation in the Service, the CLB will immediately set synchronization.
When you delete a configuration annotation in the Service, the CLB will remain unchanged.
When you modify the TkeServiceConfig configuration, the CLB of the Service that imported the configuration will set synchronization based on the new TkeServiceConfig.
If the Service listener does not find the corresponding configuration, the listener will not be modified.
If the Service listener finds the corresponding configuration but the configuration does not contain specified attributes, the listener will not be modified.

Complete Configuration Reference

apiVersion: cloud.tencent.com/v1alpha1
kind: TkeServiceConfig
metadata:
  name: sample # Configuration name
  namespace: default # Configuration namespace
spec:
  loadBalancer:
    l4Listeners: # Layer-4 rule configuration, applicable to Service listener configuration.
    - protocol: TCP # Layer-4 rule for protocol ports anchoring the Service. Required. Enumerated value: TCP|UDP.
      port: 80 # Required. Value range: 1-65535.
      deregisterTargetRst: true # Optional. Boolean. Bidirectional RST switch. Recommended for non-direct connection type Services. Non-direct connection Services will be relayed through NodePort. Not enabling bidirectional RST may cause business interruption after cluster nodes are taken offline.
      session: # Configuration related to session persistence. Optional.
        enable: true # Indicates whether to enable session persistence. Required. Boolean.
        sessionExpireTime: 100 # Session persistence duration. Optional. Default value: 30. Value range: 30-3600. Unit: second.
      healthCheck: # Configuration related to health check. Optional.
        enable: true # Indicates whether to enable health check. Required. Boolean.
        checkType: "TCP" # Health check type. Optional. Enumerated value: TCP|HTTP|CUSTOM (only applicable to TCP/UDP listeners, where UDP listeners only support CUSTOM; if using custom health check functionality, this field is required).
        intervalTime: 10 # Health check probe interval. Optional. Default value: 5. Value range: 5-300. Unit: second.
        healthNum: 2 # Healthy threshold, indicating the number of consecutive healthy health check results that it takes to indicate normal forwarding. Optional. Default value: 3. Value range: 2-10. Unit: times.
        unHealthNum: 3 # Unhealthy threshold, indicating the number of consecutive unhealthy health check results that it takes to indicate a forwarding exception. Optional. Default value: 3. Value range: 2-10. Unit: times.
        timeout: 10 # Health check response timeout threshold. This should be less than the health check interval. Optional. Default value: 2. Value range: 2-60. Unit: second.
        httpCode: 31 # Health check status code. Optional. Default value: 31. Value range: 1-31. Only applicable to HTTP/HTTPS forwarding rules and HTTP health check methods for TCP listeners. 1 indicates that a return value of 1xx after probing represents health, 2 indicates that 2xx represents health, 4 indicates that 3xx represents health, 8 indicates that 4xx represents health, and 16 indicates that 5xx represents health. If multiple return codes are desired to represent health, add the corresponding values.
        httpCheckPath: "/" # Health check path. Optional. Only applicable to HTTP/HTTPS forwarding rules and HTTP health check methods for TCP listeners.
        httpCheckDomain: "" # Health check domain. Optional. Default is the domain of the layer-7 rule (only applicable to HTTP/HTTPS forwarding rules and HTTP health check methods for TCP listeners).
        httpCheckMethod: "HEAD" # Health check method (only applicable to HTTP/HTTPS forwarding rules and HTTP health check methods for TCP listeners). Default value: HEAD. Value range: HEAD or GET.
        httpVersion: "HTTP/1.1" # Custom probe related parameters. When the health check protocol CheckType is HTTP, this field is required and represents the HTTP version of the backend service: HTTP/1.0, HTTP/1.1; (only applicable to TCP listeners).
        sourceIpType: 0 # Health check probe source. 0 (VIP as source IP) 1 (100.64 as source IP). For domain-based CLB, the default value is 1 and can only be 1. For non-domain-based CLB, the default value may vary. Check the CLB console configuration page to see if VIP probe mode is available. If available, the default value is 0; otherwise, it is 1. For more details, see https://www.tencentcloud.com/document/product/214/53639
      scheduler: WRR # Request forwarding method. WRR, LEAST_CONN, and IP_HASH indicate polling by weight, least connections, and hashing by IP address, respectively. Optional. Enumerated value: WRR | LEAST_CONN.

Example

Sample deployment: jetty-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: jetty
  name: jetty-deployment
  namespace: default
spec:
  progressDeadlineSeconds: 600
  replicas: 3
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: jetty
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: jetty
    spec:
      containers:
      - image: jetty:9.4.27-jre11
        imagePullPolicy: IfNotPresent
        name: jetty
        ports:
        - containerPort: 80
          protocol: TCP
        - containerPort: 443
          protocol: TCP
        resources: {}
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30

Sample Service: jetty-service.yaml

apiVersion: v1
kind: Service
metadata:
  annotations:
    service.cloud.tencent.com/tke-service-config: jetty-service-config
    # Specify the existing tke-service-config
    # service.cloud.tencent.com/tke-service-config-auto: "true" 
    # Automatically create a `tke-service-config`
  name: jetty-service
  namespace: default
spec:
  ports:
  - name: tcp-80-80
    port: 80
    protocol: TCP
    targetPort: 80
  - name: tcp-443-443
    port: 443
    protocol: TCP
    targetPort: 443
  selector:
    app: jetty
  type: LoadBalancer
This sample includes the following configurations:
The Service is of the public network LoadBalancer type, with two TCP services declared: one on port 80 and the other on port 443.
The jetty-service-config CLB configuration is used.

TkeServiceConfig sample: jetty-service-config.yaml

apiVersion: cloud.tencent.com/v1alpha1
kind: TkeServiceConfig
metadata:
  name: jetty-service-config
  namespace: default
spec:
  loadBalancer:
    l4Listeners:
    - protocol: TCP
      port: 80
      deregisterTargetRst: true
      healthCheck:
        enable: false
    - protocol: TCP
      port: 443
      session:
        enable: true
        sessionExpireTime: 3600
      healthCheck:
        enable: true
        intervalTime: 10
        healthNum: 2
        unHealthNum: 2
        timeout: 5
      scheduler: WRR
This sample includes the following configurations: The name is jetty-service-config, and in the layer-4 listener configuration, two configuration segments are declared:
1. The TCP listener of port 80 will be configured. Health check is disabled.
2. The TCP listener of port 443 will be configured.
Health check is enabled, with the health check interval set to 10s, the healthy threshold set to 2 times, the unhealthy threshold also set to 2 times, and the timeout threshold set to 5s.
The session persistence feature is enabled, with the timeout period set to 3,600s.
The forwarding policy is configured as "weighted round robin".

kubectl configuration commands

$ kubectl apply -f jetty-deployment.yaml
$ kubectl apply -f jetty-service.yaml
$ kubectl apply -f jetty-service-config.yaml

$ kubectl get pods
NAME                                READY   STATUS    RESTARTS   AGE
jetty-deployment-8694c44b4c-cxscn   1/1     Running   0          8m8s
jetty-deployment-8694c44b4c-mk285   1/1     Running   0          8m8s
jetty-deployment-8694c44b4c-rjrtm   1/1     Running   0          8m8s

$ kubectl get service jetty-service
NAME    TYPE           CLUSTER-IP       EXTERNAL-IP       PORT(S)                      AGE
jetty   LoadBalancer   10.127.255.209   150.158.220.237   80:31338/TCP,443:32373/TCP   2m47s

# Get the `TkeServiceConfig` configuration list
$ kubectl get tkeserviceconfigs.cloud.tencent.com
NAME                   AGE
jetty-service-config   52s

# Update and modify the `TkeServiceConfig` configuration
$ kubectl edit tkeserviceconfigs.cloud.tencent.com jetty-service-config
tkeserviceconfig.cloud.tencent.com/jetty-service-config edited

Was this page helpful?
You can also Contact Sales or Submit a Ticket for help.
Yes
No

Feedback