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.
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-----
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 Avi Load Balancer. So, you are free to express your preferences using this CRD without any knowledge of the Avi 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:
LB_ALGORITHM_CONSISTENT_HASH
LB_ALGORITHM_CORE_AFFINITY
LB_ALGORITHM_FASTEST_RESPONSE
LB_ALGORITHM_FEWEST_SERVERS
LB_ALGORITHM_LEAST_CONNECTION
SLB_ALGORITHM_LEAST_LOAD
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 Avi 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 Avi 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 Avi 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 Avi 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 Avi 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 Avi 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