AKO currently creates an SNI child virtual service to a parent shared virtual service for the secure hostname when shard virtual service size is LARGE or MEDIUM or SMALL. The SNI VS is used to bind the hostname to a sslkeycert object. The sslkeycert object is used to terminate the secure traffic on NSX Advanced Load Balancer service engine.

On the SNI virtual service, AKO creates httppolicyset rules to route the terminated (insecure) traffic to the appropriate pool object using the host/path specified in the rules section of this ingress object.

With Enhanced Virtual Hosting support in NSX Advanced Load Balancer, virtual hosting on virtual service can be enabled irrespective of SNI. Also, the SNI can only handle HTTPS (HTTP over SSL) traffic whereas EVH children can handle both HTTP and HTTPS traffic. For each unique host in LARGE or MEDIUM or SMALL shard VS size, an EVH child virtual service is created. This is applicable for both secure and insecure FQDNs. Layer 4 virtual services and TLS passthrough works the same way as the SNI model .

With DEDICATED shard VS size, AKO will create a normal virtual service (no virtual hosting enabled) for each unique host for secure/insecure ingress/route. AKO will apply all host rule specific settings, SSL profile, SSL KeyandCertificate on virtual service. Redirecting traffic to appropriate pool will be done using a httppolicyset object attached to virtual service. For secure ingress, there will httppolicyset attached to virtual service which will redirect traffic from port 80 to 443.

With EVH enabled host rule CRD’s can be applied to insecure ingress as well.

Naming of NSX Advanced Load Balancer Objects with EVH enabled

Starting with NSX Advanced Load Balancer Controller 20.1.6, all object names have a max length limitation of 255 characters. To avoid object name lengths beyond 255 characters, AKO will name all EVH object names, except the parent virtual service, VIP names and advancedL4 object names, using a SHA1 encoding logic.

Shared Virtual Service Names

The shared VS names are derived based on a combination of fields to keep it unique per Kubernetes cluster/OpenShift cluster. This is the only object in NSX Advanced Load Balancer that does not derive its name from any of the Kubernetes/OpenShift objects.

ShardVSName = clusterName + "--Shared-L7-EVH-" + <shardNum>

Here,

  • clusterName is the value specified in values.yaml during install

  • Shared-L7-EVH is a constant identifier for shared virtual services

  • shardNum is the number of the shared virtual service generated based on hostname based shards.

EVH child Virtual Service Names

For shard VS size LARGE, MEDIUM, SMALL, child VS naming convention is:

vsName = clusterName + "--" + encoded-value

For DEDICATED shard VS size, VS naming convention is:

vsName = clusterName + "--" + encoded-value + "-EVH"

EVH Pool Names

poolName = clusterName + "--" + encoded-value

EVH Pool Group Names

poolgroupname = clusterName + "--" + encoded-value