tencent cloud

masukan

Service CLB Configuration

Terakhir diperbarui:2024-08-08 14:50:28

    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
    
    Hubungi Kami

    Hubungi tim penjualan atau penasihat bisnis kami untuk membantu bisnis Anda.

    Dukungan Teknis

    Buka tiket jika Anda mencari bantuan lebih lanjut. Tiket kami tersedia 7x24.

    Dukungan Telepon 7x24