Compute
Elastic Cloud Server
Huawei Cloud Flexus
Bare Metal Server
Auto Scaling
Image Management Service
Dedicated Host
FunctionGraph
Cloud Phone Host
Huawei Cloud EulerOS
Networking
Virtual Private Cloud
Elastic IP
Elastic Load Balance
NAT Gateway
Direct Connect
Virtual Private Network
VPC Endpoint
Cloud Connect
Enterprise Router
Enterprise Switch
Global Accelerator
Management & Governance
Cloud Eye
Identity and Access Management
Cloud Trace Service
Resource Formation Service
Tag Management Service
Log Tank Service
Config
OneAccess
Resource Access Manager
Simple Message Notification
Application Performance Management
Application Operations Management
Organizations
Optimization Advisor
IAM Identity Center
Cloud Operations Center
Resource Governance Center
Migration
Server Migration Service
Object Storage Migration Service
Cloud Data Migration
Migration Center
Cloud Ecosystem
KooGallery
Partner Center
User Support
My Account
Billing Center
Cost Center
Resource Center
Enterprise Management
Service Tickets
HUAWEI CLOUD (International) FAQs
ICP Filing
Support Plans
My Credentials
Customer Operation Capabilities
Partner Support Plans
Professional Services
Analytics
MapReduce Service
Data Lake Insight
CloudTable Service
Cloud Search Service
Data Lake Visualization
Data Ingestion Service
GaussDB(DWS)
DataArts Studio
Data Lake Factory
DataArts Lake Formation
IoT
IoT Device Access
Others
Product Pricing Details
System Permissions
Console Quick Start
Common FAQs
Instructions for Associating with a HUAWEI CLOUD Partner
Message Center
Security & Compliance
Security Technologies and Applications
Web Application Firewall
Host Security Service
Cloud Firewall
SecMaster
Anti-DDoS Service
Data Encryption Workshop
Database Security Service
Cloud Bastion Host
Data Security Center
Cloud Certificate Manager
Edge Security
Situation Awareness
Managed Threat Detection
Blockchain
Blockchain Service
Web3 Node Engine Service
Media Services
Media Processing Center
Video On Demand
Live
SparkRTC
MetaStudio
Storage
Object Storage Service
Elastic Volume Service
Cloud Backup and Recovery
Storage Disaster Recovery Service
Scalable File Service Turbo
Scalable File Service
Volume Backup Service
Cloud Server Backup Service
Data Express Service
Dedicated Distributed Storage Service
Containers
Cloud Container Engine
SoftWare Repository for Container
Application Service Mesh
Ubiquitous Cloud Native Service
Cloud Container Instance
Databases
Relational Database Service
Document Database Service
Data Admin Service
Data Replication Service
GeminiDB
GaussDB
Distributed Database Middleware
Database and Application Migration UGO
TaurusDB
Middleware
Distributed Cache Service
API Gateway
Distributed Message Service for Kafka
Distributed Message Service for RabbitMQ
Distributed Message Service for RocketMQ
Cloud Service Engine
Multi-Site High Availability Service
EventGrid
Dedicated Cloud
Dedicated Computing Cluster
Business Applications
Workspace
ROMA Connect
Message & SMS
Domain Name Service
Edge Data Center Management
Meeting
AI
Face Recognition Service
Graph Engine Service
Content Moderation
Image Recognition
Optical Character Recognition
ModelArts
ImageSearch
Conversational Bot Service
Speech Interaction Service
Huawei HiLens
Video Intelligent Analysis Service
Developer Tools
SDK Developer Guide
API Request Signing Guide
Terraform
Koo Command Line Interface
Content Delivery & Edge Computing
Content Delivery Network
Intelligent EdgeFabric
CloudPond
Intelligent EdgeCloud
Solutions
SAP Cloud
High Performance Computing
Developer Services
ServiceStage
CodeArts
CodeArts PerfTest
CodeArts Req
CodeArts Pipeline
CodeArts Build
CodeArts Deploy
CodeArts Artifact
CodeArts TestPlan
CodeArts Check
CodeArts Repo
Cloud Application Engine
MacroVerse aPaaS
KooMessage
KooPhone
KooDrive

Configuring Advanced Forwarding Rules for a LoadBalancer Ingress

Updated on 2025-02-18 GMT+08:00

Ingresses offer diverse forwarding rules that can match listeners based on different request parameters like HTTP request methods, headers, query strings, CIDR blocks, and cookies. Each listener is associated with an ELB access port. This facilitates flexible service distribution and resource allocation.

Figure 1 How an advanced forwarding rule operates

Prerequisites

  • A CCE standard or Turbo cluster is available, and the cluster version meets the following requirements:
    • v1.23: v1.23.18-r10 or later
    • v1.25: v1.25.16-r0 or later
    • v1.27: v1.27.16-r0 or later
    • v1.28: v1.28.13-r0 or later
    • v1.29: v1.29.8-r0 or later
    • v1.30: v1.30.4-r0 or later
    • Other clusters of later versions
  • The cluster can be accessed using kubectl. For details, see Connecting to a Cluster Using kubectl.

Notes and Constraints

Using kubectl

  1. Use kubectl to access the cluster. For details, see Connecting to a Cluster Using kubectl.
  2. Create a YAML file named ingress-test.yaml. The file name can be customized.

    vi ingress-test.yaml
    An example YAML file of an ingress created using an existing load balancer is as follows:
    apiVersion: networking.k8s.io/v1 
    kind: Ingress 
    metadata: 
      annotations: 
        kubernetes.io/elb.class: performance
        kubernetes.io/elb.id: ab53c3b2-xxxx-xxxx-xxxx-5ac3eb2887be
        kubernetes.io/elb.port: '80'
        # Access the svc-hello1 service. Ensure that this service is available.
        kubernetes.io/elb.conditions.svc-hello1: |  
            [ 
              { 
                "type": "Method", 
                "methodConfig": { 
                  "values": [ 
                    "GET", 
                    "POST" 
                  ] 
                } 
              }, 
              { 
                "type": "Header", 
                "headerConfig": { 
                  "key": "gray-hello", 
                  "values": [ 
                    "value1", 
                    "value2" 
                  ] 
                } 
              }, 
              { 
                "type": "Cookie", 
                "cookieConfig": { 
                  "values": [ 
                    { 
                      "key": "querystringkey1", 
                      "value": "querystringvalue2" 
                    }, 
                    { 
                      "key": "querystringkey3", 
                      "value": "querystringvalue4" 
                    } 
                  ] 
                } 
              }, 
              { 
                "type": "QueryString", 
                "queryStringConfig": { 
                  "key": "testKey", 
                  "values": [ 
                    "testValue" 
                  ] 
                } 
              }, 
              { 
                "type": "SourceIp", 
                "sourceIpConfig": { 
                  "values": [ 
                    "192.168.0.0/16", 
                    "172.16.0.0/16" 
                  ] 
                } 
              } 
            ] 
      name: ingress-test 
    spec: 
      ingressClassName: cce 
      rules: 
       - http: 
          paths: 
          - path: /hello1 
            pathType: ImplementationSpecific 
            backend: 
              service: 
                name: svc-hello1 
                port: 
                  number: 80
    Table 1 Annotations for advanced forwarding rules

    Parameter

    Type

    Description

    kubernetes.io/elb.conditions.${svc_name}

    String

    Configure an advanced forwarding rule. ${svc_name} indicates the Service name, which can contain a maximum of 48 characters.

    If the annotation value is set to [], the advanced forwarding rule is deleted.

    An annotation value is in the form of a JSON array. For details, see Table 2.

    NOTICE:

    The rules in a condition array are connected by an AND relationship, while the values in the same rule block are connected by an OR relationship. For example, if both Method and QueryString are configured, the target traffic can be distributed only when both rules are met. However, if the Method value is GET or POST, the target traffic can be distributed only when both rules are met and the Method value must be GET or POST.

    Table 2 Array structure

    Parameter

    How to Use

    Example

    type

    Matching type. Options:

    • Method: HTTP requests are forwarded based on the matched method. This parameter must be used with methodConfig. This parameter can be configured only once.
    • Header: HTTP requests are forwarded based on the matched header. This parameter must be used with headerConfig.
    • Cookie: HTTP requests are forwarded based on the matched cookie. This parameter must be used with cookieConfig.
    • QueryString: HTTP requests are forwarded based on the matched character string. This parameter must be used with queryStringConfig.
    • SourceIp: HTTP requests are forwarded based on the matched CIDR block. This parameter must be used with sourceIpConfig. This parameter can be configured only once.

    None

    methodConfig

    An HTTP request method that is used to forward requests. This parameter is used only when type is set to Method.

    Multiple request methods can be concurrently configured, including GET, POST, PUT, DELETE, PATCH, HEAD, and OPTIONS.

    You only need to configure values (an array) for methodConfig.

    {
      "type": "Method",
      "methodConfig": {
         "values": [
            "GET",
            "POST"
         ]
      }
    }

    headerConfig

    An HTTP request header that is used to forward requests. This parameter is used only when type is set to Header.

    • A key can only contain letters, digits, underscores (_), and hyphens (-).

      The first letter of the User-agent and Connection HTTP request headers must be capitalized.

    • Multiple values can be configured for a key. A value can only contain letters, digits, and special characters (!#$%&'()*+,.\/:;<=>?@[]^-_'{|}~). Asterisks (*) and question marks (?) can be used as wildcard characters.

    You can only configure one key for each headerConfig rule. If you need multiple keys, configure multiple headerConfig rules.

    {
      "type": "Header",
      "headerConfig": {
         "key": "gray-hello",
         "values": [
            "value1",
            "value2"
         ]
      } 
    }

    cookieConfig

    A cookie that is used to forward requests. This parameter is used only when type is set to Cookie. A cookie consists of a key and a value, which must be configured separately.

    • A key can contain 1 to 100 characters and cannot start or end with a space.
    • A value can contain 1 to 100 characters. Configure a value for each key.

    You can enter multiple key-value pairs that can contain letters, digits, and special characters (!%'"()*+,./:=?@^-_`~).

    When configuring cookieConfig, you can configure multiple key-value pairs in values, and these pairs will have an OR relationship with each other.

    { 
      "type": "Cookie", 
      "cookieConfig": { 
         "values": [ 
            { 
              "key": "querystringkey1", 
              "value": "querystringvalue2" 
            }, 
            { 
               "key": "querystringkey3", 
               "value": "querystringvalue4" 
            } 
         ] 
      } 
    }

    queryStringConfig

    A character string that is used to forward requests. If the character string in a request matches the one in the configured forwarding rule, the request will be forwarded. This parameter is used only when type is set to QueryString.

    A query string consists of a key and one or more values. Configure the key and values separately.

    • A key can only contain letters, digits, and special characters (!$'()*+,./:;=?@^-_').
    • Multiple values can be configured for a key. A value can only contain letters, digits, and special characters (!$'()*+,./:;=?@^-_'). Asterisks (*) and question marks (?) can be used as wildcard characters.

    You can only configure one key for each queryStringConfig rule. If you need multiple keys, configure multiple QueryStringConfig rules.

    { 
       "type": "QueryString", 
       "queryStringConfig": { 
          "key": "testKey", 
          "values": [ 
              "testValue" 
          ] 
       } 
    }

    sourceIpConfig

    A CIDR block that is used to forward requests. This parameter is used only when type is set to SourceIp.

    Example CIDR block: 192.168.1.0/24 or 2020:50::44/127

    You only need to configure values (an array) for sourceIpConfig.

    { 
       "type": "SourceIp", 
       "sourceIpConfig": { 
          "values": [ 
             "192.168.0.0/16", 
             "172.16.0.0/16" 
          ] 
       } 
    }

  3. Create an ingress.

    kubectl create -f ingress-test.yaml

    If information similar to the following is displayed, the ingress has been created:

    ingress/ingress-test created

  4. Check the created ingress.

    kubectl get ingress
    If information similar to the following is displayed, the ingress has been created:
    NAME          CLASS    HOSTS     ADDRESS          PORTS   AGE
    ingress-test  cce      *         121.**.**.**     80      10s

We use cookies to improve our site and your experience. By continuing to browse our site you accept our cookie policy. Find out more

Feedback

Feedback

Feedback

0/500

Selected Content

Submit selected content with the feedback