HTTPRule

The developers are the primary users of the HTTPRule CRD. The path matching rules in the ingress or route objects define traffic routing rules to the microservices. The HTTPRule CRD can be used as a complimentary object to control additional layer 7 properties like algorithm, hash, and tls re-encrypt use cases.

Note:

With AKO version 1.11.1, AviInfrasetting is transitioned to version v1beta1. There are no schema changes between version v1alpha1 and v1beta1. AKO 1.11.1 supports both versions v1alpha1 andv1beta1. However, it is recommended to create new CRD objects in v1beta1 and transition the existing objects to this version.

AKO will deprecate v1alpha1 in the upcoming releases.

A sample HTTPRule object is as shown below:

apiVersion: ako.vmware.com/v1beta1
kind: HTTPRule
metadata:
   name: my-http-rule
   namespace: purple-l7
spec:
  fqdn: foo.avi.internal
  paths:
  - target: /foo
    healthMonitors:
    - my-health-monitor-1
    - my-health-monitor-2
    loadBalancerPolicy:
      algorithm: LB_ALGORITHM_CONSISTENT_HASH
      hash: LB_ALGORITHM_CONSISTENT_HASH_SOURCE_IP_ADDRESS
    tls: ## This is a re-encrypt to pool
      type: reencrypt # Mandatory [re-encrypt]
      sslProfile: avi-ssl-profile
      destinationCA:  |-
        -----BEGIN CERTIFICATE-----
        [...]
        -----END CERTIFICATE-----

Note:

The HTTPRule only applies to paths in the Ingress/Route objects which are specified in the same namespace as the HTTPRule CRD.

Usage of the HTTPRule CRD

The HTTPRule CRD does not have any specific semantics for NSX Advanced Load Balancer. So, you are free to express your preferences using this CRD without any knowledge of the NSX Advanced Load Balancer objects. Each HTTPRule CRD must be bound to an FQDN (both secure or insecure) to subscribe to rules for specific hostpath combinations.

Express Load Balancer Algorithm
The load balancer policies are a predefined set of values to choose from.Currently, the following values are supported for load balancer policy:
1. LB_ALGORITHM_CONSISTENT_HASH
2. LB_ALGORITHM_CORE_AFFINITY
3. LB_ALGORITHM_FASTEST_RESPONSE
4. LB_ALGORITHM_FEWEST_SERVERS
5. LB_ALGORITHM_LEAST_CONNECTION
6. SLB_ALGORITHM_LEAST_LOAD
7. LB_ALGORITHM_ROUND_ROBIN
To configure the load balancer policy for a given ingress path,
```
  - target: /foo 
    loadBalancerPolicy:
      algorithm: LB_ALGORITHM_FEWEST_SERVERS
```
This rule is applied to all paths matching /foo and subsets of /foo/xxx. For more information, see Load Balancing Algorithms topicin the VMware NSX Advanced Load Balancer Configuration Guide. The hash field is used when the algorithm is selected as LB_ALGORITHM_CONSISTENT_HASH. Otherwise, it is not applicable. Similarly, a hostHeader field is used only when the hash is selected as LB_ALGORITHM_CONSISTENT_HASH_CUSTOM_HEADER. A sample setting with these fields is shown below:
```
  - target: /foo 
    loadBalancerPolicy:
      algorithm: LB_ALGORITHM_CONSISTENT_HASH
      hash: LB_ALGORITHM_CONSISTENT_HASH_CUSTOM_HEADER
      hostHeader: foo
```
The hostHeader is disregarded if it is specified in any other case. The hash field is disregarded if the algorithm is not LB_ALGORITHM_CONSISTENT_HASH.
Express Application Persistence Profile
HTTPRule CRD can be used to express application persistence profile references. Create the application persistence profile reference in the NSX Advanced Load Balancer Controller prior to this CRD creation.
```
applicationPersistence: cookie-userid-persistence
```
The application persistence profile can be used to maintain stickiness to a server instance based on cookie values, headers, and so on, for a desired duration of time.
Express Health Monitors
The HTTPRule CRD can be used to express health monitor references.Create the health monitor reference in the NSX Advanced Load Balancer Controller prior to this CRD creation.
To express health monitor references, use:
```
healthMonitors:
  - my-health-monitor-1
  - my-health-monitor-2
```
The health monitors can be used to verify server health. A server (Kubernetes pods in this case) is marked as UP only when all the health monitors return successful responses. Health monitors provided here overwrite the default health monitor configuration set by AKO, that is, System-TCP for HTTP/TCP traffic and System-UDP for UDP traffic based on the ingress/service configuration.
Re-encrypt Traffic to the Services
While AKO can terminate TLS traffic, it also provides an option where the users can choose to re-encrypt the traffic between the NSX Advanced Load Balancer SE and the backend application server. The following option is provided for re-encrypt one is by providing a raw certificate using destinationCA or by providing an NSX Advanced Load Balancer PKI Profile reference using the pkiProfile field:
```
    tls: ## This is a re-encrypt to pool
      type: reencrypt # Mandatory [re-encrypt]
      sslProfile: avi-ssl-profile
      destinationCA:  |-
        -----BEGIN CERTIFICATE-----
        [...]
        -----END CERTIFICATE-----
    tls: ## This is a re-encrypt to pool
      type: reencrypt # Mandatory [re-encrypt]
      sslProfile: avi-ssl-profile
      pkiProfile: avi-pki-profile
```
The sslProfile, additionally, can be used to determine the set of SSL versions and ciphers to accept for SSL/TLS terminated connections. If the sslProfile is not defined, AKO defaults to sslProfile System-Standard defined in NSX Advanced Load Balancer.
If re-encrypt occurs, if the destinationCA is specified in the HTTP Rule CRD, as shown in the example, a corresponding PKI profile is created for that pool (host path combination). Also note that only one of PKI profile or destination CA can be provided to configure re-encrypt for a pool corresponding to the host path backend Service.

Status Messages

The status messages are used to give instant feedback on whether a HTTPRule CRD was accepted or rejected.

Example of a HTTP Rule

$ kubectl get httprule
NAME            HOSTRULE                     STATUS     AGE
my-http-rules   default/secure-waf-policy    Accepted   5h34m