NetScaler ingress controller

HTTP use cases

This topic covers various HTTP use cases that you can configure on NetScaler using smart annotations for services of type LoadBalancer and ingress.

HTTP configurations for NetScaler can be specified in an entity called HTTP profile, which is a collection of HTTP settings. The HTTP profile can then be associated with services or virtual servers that can use these HTTP configurations.

HTTP profile support for services of type LoadBalancer

NetScaler Ingress Controller provides the following service annotations for HTTP profile for services of type LoadBalancer. You can use these annotations to define the HTTP settings for NetScaler.

Service annotation Description
service.citrix.com/frontend-httpprofile Use this annotation to create the front-end HTTP profile (client plane).
service.citrix.com/backend-httprofile Use this annotation to create the back-end HTTP profile (server plane).

User-defined HTTP profiles

Using service annotations for HTTP, you can create custom profiles with the same name as that of content switching virtual server or service group and bind these profiles to the corresponding content switching virtual server (frontend-httpprofile) or service group (backend-httpprofile).

Service annotation Sample
service.citrix.com/frontend-httpprofile service.citrix.com/frontend-httpprofile: '{"http2direct" : "enabled", "altsvc" : "enabled"}'
service.citrix.com/backend-httpprofile service.citrix.com/backend-httpprofile: '{"http2direct" : "enabled", "altsvc" : "enabled"}'

Built-in HTTP profiles

Built-in HTTP profiles do not create any profiles but bind a given profile name in the annotation to the corresponding virtual server (frontend-httpprofile) and the service group (backend-httpprofile).

The following examples are for built-in HTTP profiles.

service.citrix.com/frontend-httpprofile: "http_preconf_profile"

service.citrix.com/backend-httpprofile: '{"apache" : "http_preconf_profile"}'

Example: Service of type LoadBalancer with HTTP profile configuration

In this example, HTTP profiles are configured for a sample application tea-beverage. This application is deployed and exposed using a service of type LoadBalancer using the following YAML file.

Note:

For information about exposing services of type LoadBalancer, see service of type LoadBalancer.

Deploy a sample application (tea-beverage.yaml) using the following command:

kubectl apply -f - <<EOF apiVersion: apps/v1 kind: Deployment metadata: name: tea-beverage labels: name: tea-beverage spec: selector: matchLabels: name: tea-beverage replicas: 2 template: metadata: labels: name: tea-beverage spec: containers: - name: tea-beverage image: quay.io/sample-apps/hotdrinks:latest ports: - name: tea-80 containerPort: 80 - name: tea-443 containerPort: 443 imagePullPolicy: Always --- apiVersion: v1 kind: Service metadata: name: tea-beverage annotations: service.citrix.com/service-type-0: 'HTTP' service.citrix.com/frontend-ip: 10.105.158.194 service.citrix.com/frontend-httpprofile: '{"http2direct" : "enabled", "altsvc" : "enabled"}' service.citrix.com/backend-httpprofile: '{"http2direct" : "enabled", "altsvc" : "enabled"}' spec: type: LoadBalancer ports: - name: tea-80 port: 80 targetPort: 80 selector: name: tea-beverage EOF

After the application is deployed, the corresponding entities and profiles are created on NetScaler. Run the following commands on NetScaler to verify the same: show cs vserver k8s-tea-beverage_80_default_svc and show servicegroup k8s-tea-beverage_80_sgp_f4lezsannvu7tk2ftpjbhi4hza2tvdnk.

# show cs vserver k8s-tea-beverage_80_default_svc k8s-tea-beverage_80_default_svc (10.105.158.194:80) - HTTP Type: CONTENT State: UP Last state change was at Wed May 8 06:44:11 2024 Time since last state change: 0 days, 00:04:24.740 Client Idle Timeout: 180 sec Down state flush: ENABLED Disable Primary Vserver On Down : DISABLED Comment: uid=2TZGFGG3JKYS2D7KWJIPS7ODTL5D4S7IMU5K6GETMXHXRDE2WIAQ==== HTTP profile name: k8s-tea-beverage_80_default_svc Appflow logging: ENABLED Port Rewrite : DISABLED State Update: DISABLED Default: k8s-tea-beverage_80_lbv_f4lezsannvu7tk2ftpjbhi4hza2tvdnk Content Precedence: RULE Vserver IP and Port insertion: OFF L2Conn: OFF Case Sensitivity: ON Authentication: OFF 401 Based Authentication: OFF Push: DISABLED Push VServer: Push Label Rule: none HTTP Redirect Port: 0 Dtls : OFF Persistence: NONE Listen Policy: NONE IcmpResponse: PASSIVE RHIstate: PASSIVE Traffic Domain: 0 1) Default Target LB: k8s-tea-beverage_80_lbv_f4lezsannvu7tk2ftpjbhi4hza2tvdnk Hits: 0 Done
# show servicegroup k8s-tea-beverage_80_sgp_f4lezsannvu7tk2ftpjbhi4hza2tvdnk k8s-tea-beverage_80_sgp_f4lezsannvu7tk2ftpjbhi4hza2tvdnk - HTTP State: ENABLED Effective State: UP Monitor Threshold : 0 Max Conn: 0 Max Req: 0 Max Bandwidth: 0 kbits Use Source IP: NO Client Keepalive(CKA): NO Monitoring Owner: 0 TCP Buffering(TCPB): NO HTTP Compression(CMP): NO Idle timeout: Client: 180 sec Server: 360 sec Client IP: DISABLED Cacheable: NO SC: ??? SP: OFF Down state flush: ENABLED Monitor Connection Close : NONE Appflow logging: ENABLED HTTP profile name: k8s-tea-beverage_80_sgp_f4lezsannvu7tk2ftpjbhi4hza2tvdnk ContentInspection profile name: ??? Process Local: DISABLED Traffic Domain: 0 Comment: "lbsvc:tea-beverage,svcport:80,ns:default" 1) 10.146.107.146:30092 State: UP Server Name: 10.146.107.146 Server ID: None Weight: 1 Order: Default Last state change was at Wed May 8 06:44:25 2024 Time since last state change: 0 days, 00:04:51.610 Monitor Name: tcp-default State: UP Passive: 0 Probes: 59 Failed [Total: 0 Current: 0] Last response: Success - TCP syn+ack received. Response Time: 0.000 millisec 2) 10.146.107.147:30092 State: UP Server Name: 10.146.107.147 Server ID: None Weight: 1 Order: Default Last state change was at Wed May 8 06:44:45 2024 Time since last state change: 0 days, 00:04:31.690 Monitor Name: tcp-default State: UP Passive: 0 Probes: 56 Failed [Total: 2 Current: 0] Last response: Success - TCP syn+ack received. Response Time: 0.000 millisec Done

Note:

The HTTP profile is supported for single-port services.

Configure HTTP profiles using Ingress annotations

The following table lists the HTTP use cases with sample annotations:

Use case Sample annotation
Configuring HTTP/2




ingress.citrix.com/frontend-httpprofile: '{"http2" : "enabled"}'
ingress.citrix.com/frontend-httpprofile: '{"http2direct" : "enabled"}'
ingress.citrix.com/frontend-httpprofile: '{"http2direct" : "enabled", "altsvc" : "enabled"}'
ingress.citrix.com/backend-httpprofile: '{"apache" : {"http2" : "enabled"}}'
ingress.citrix.com/backend-httpprofile: '{"apache" : {"http2direct" : "enabled"}}'
ingress.citrix.com/backend-httpprofile: '{"apache" : {"http2direct" : "enabled", "altsvc" : "enabled"}}'
Handling HTTP session timeouts




ingress.citrix.com/frontend-httpprofile: '{"reqtimeout" : "10", "reqtimeoutaction" : "drop"}'
ingress.citrix.com/frontend-httpprofile: '{"reqtimeout" : "10", "adpttimeout" : "enabled"}'
ingress.citrix.com/frontend-httpprofile: '{"reusepooltimeout" : "20000"}'
ingress.citrix.com/backend-httpprofile: '{"apache" : {"reqtimeout" : "10", "reqtimeoutaction" : "drop"}}'
ingress.citrix.com/backend-httpprofile: '{"apache" : {"reqtimeout" : "10", "adpttimeout" : "enabled"}}'
ingress.citrix.com/backend-httpprofile: '{"apache" : {"reusepooltimeout" : "20000"}}'

Note:

The above Ingress annotations can also be used with service annotations in the format described earlier.

Configuring HTTP/2

NetScaler configures HTTP/2 on the client side and on the server side. For more information, see HTTP/2 support on NetScaler. For an HTTP load balancing configuration, NetScaler uses one of the following methods to start communicating with the client/server using HTTP/2.

NetScaler provides configurable options in an HTTP profile for the HTTP/2 methods. These HTTP/2 options can be applied to the client side and the server side of an HTTPS or HTTP load balancing setup. NetScaler Ingress Controller provides annotations to configure the HTTP profile on NetScaler. You use these annotations to configure the various HTTP load balancing configuration on NetScaler to communicate with the client/server using HTTP/2.

Note:

  • In the following method descriptions, client and server are generals terms for an HTTP/2 connection. For example, for a load balancing setup of a NetScaler using HTTP/2, NetScaler acts as a server on the client side and acts as a client to the server side.
  • Ensure that the HTTP/2 service side global parameter (HTTP2Serverside) is enabled on NetScaler.

HTTP/2 upgrade

In this method, a client sends an HTTP/1.1 request to a server. The request includes an upgrade header, which asks the server for upgrading the connection to HTTP/2. If the server supports HTTP/2, the server accepts the upgrade request and notifies it in its response. The client and the server start communicating using HTTP/2 after the client receives the upgrade confirmation response.

Using the annotations for HTTP profiles, you can configure the HTTP/2 upgrade method on NetScaler. The following sample annotation configures the HTTP/2 upgrade method on NetScaler:

ingress.citrix.com/frontend-httpprofile: '{"http2" : "enabled"}'

ingress.citrix.com/backend-httpprofile: '{"apache" : {"http2" : "enabled"}}'

Direct HTTP/2

In this method, a client directly starts communicating to a server in HTTP/2 instead of using the HTTP/2 upgrade method. If the server does not support HTTP/2 or is not configured to directly accept HTTP/2 requests, it drops the HTTP/2 packets from the client. This method is helpful if the admin of the client device already knows that the server supports HTTP/2.

Using the annotations for HTTP profiles, you can configure the direct HTTP/2 method on NetScaler. The following is a sample annotation of the HTTP profile to configure the direct HTTP/2 method on NetScaler:

ingress.citrix.com/frontend-httpprofile: '{"http2direct" : "enabled"}'

ingress.citrix.com/backend-httpprofile: '{"apache" : {"http2direct" : "enabled"}}'

Direct HTTP/2 using Alternative Service (ALT-SVC)

In this method, a server advertises that it supports HTTP/2 to a client by including an Alternative Service (ALT-SVC) field in its HTTP/1.1 response. If the client is configured to understand the ALT-SVC field, the client and the server start directly communicating using HTTP/2 after the client receives the response.

The following is a sample annotation for the HTTP profile to configure the direct HTTP/2 using alternative service (ALT-SVC) method on NetScaler:

ingress.citrix.com/frontend-httpprofile: '{"http2direct" : "enabled", "altsvc" : "enabled"}'

ingress.citrix.com/backend-httpprofile: '{"apache" : {"http2direct" : "enabled", "altsvc" : "enabled"}}'

Handling HTTP session timeouts

Various timeouts can be configured to handle different types of HTTP requests and also mitigate attacks such as Slowloris DDOS attack, where you want to restrict client-initiated connections. On NetScaler, you can configure the following timeouts for such scenarios:

  • reqTimeout and reqTimeoutAction
  • adptTimeout
  • reusePoolTimeout

reqTimeout and reqTimeoutAction

In NetScaler, you can configure the HTTP request timeout value and the request timeout action using the reqTimeout and reqTimeoutAction parameters in the HTTP profile. The reqTimeout value is set in seconds and the HTTP request must complete within the specified time in the reqTimeout parameter. If the HTTP request does not complete within the defined time, the specified request timeout action in the reqTimeoutAction is performed. The minimum timeout value that you can set is 0 and the maximum is 86400. By default, the timeout value is set to 0.

Using the reqTimeoutAction parameter, you can specify the type of action that must be taken in case the HTTP request timeout value (reqTimeout) elapses. You can specify the following actions:

  • RESET
  • DROP

Using the annotations for HTTP profiles, you can configure the HTTP request timeout and HTTP request timeout action. The following sample annotation of the HTTP profile is used to configure the HTTP request timeout and HTTP request timeout action on NetScaler:

ingress.citrix.com/frontend-httpprofile: '{"reqtimeout" : "10", "reqtimeoutaction" : "drop"}'

ingress.citrix.com/backend-httpprofile: '{"apache" : {"reqtimeout" : "10", "reqtimeoutaction" : "drop"}}'

adptTimeout

Instead of using a set timeout value for the requested sessions, you can also enable adptTimeout. The adptTimeout parameter adapts the request timeout as per the flow conditions. If enabled, the request timeout is increased or decreased internally and applied on the flow. By default, this parameter is set to DISABLED.

Using annotations for HTTP profiles, you can enable or disable the adpttimeout parameter as following:

ingress.citrix.com/frontend-httpprofile: '{"reqtimeout" : "10", "adpttimeout" : "enabled"}'

ingress.citrix.com/backend-httpprofile: '{"apache" : {"reqtimeout" : "10", "adpttimeout" : "enabled"}}'

reusePoolTimeout

You can configure a reuse pool timeout value to flush any idle server connections from the reuse pool. If the server is idle for the configured time, then the corresponding connections are flushed.

The minimum timeout value that you can set is 0 and the maximum is 31536000. By default, the timeout value is set to 0.

Using annotations for HTTP profiles, you can configure the required timeout value as follows:

ingress.citrix.com/frontend-httpprofile: '{"reusepooltimeout" : "20000"}'

ingress.citrix.com/backend-httpprofile: '{"apache" : {"reusepooltimeout" : "20000"}}'

Example for applying HTTP profile using Ingress annotation

This example shows how to apply HTTP profiles.

  1. Deploy the front-end ingress resource with the HTTP profile. In this Ingress resource, back end and TLS are not defined.

    kubectl apply -f - <<EOF apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: frontend-ingress annotations: ingress.citrix.com/insecure-termination: "allow" ingress.citrix.com/frontend-ip: "10.221.36.190" ingress.citrix.com/frontend-httpprofile: '{"reqtimeout" : "10", "adpttimeout" : "enabled"}' spec: tls: - hosts: rules: - host: EOF
  2. Deploy the secondary ingress resource with the same front-end IP address. In this Ingress resource, back end and TLS are defined, which creates the load balancing resource definition.

    kubectl apply -f - <<EOF apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: backend-ingress annotations: ingress.citrix.com/insecure-termination: "allow" ingress.citrix.com/frontend-ip: "10.221.36.190" spec: tls: - secretName: <hotdrink-secret> rules: - host: hotdrink.beverages.com http: paths: - path: / pathType: Prefix backend: service: name: frontend-hotdrinks port: number: 80 EOF
  3. After the ingress resources are deployed, the corresponding entities and profiles are created on NetScaler. Run the following command on NetScaler to verify the same: show cs vserver k8s-10.221.36.190_443_ssl.

# show cs vserver k8s-10.221.36.190_443_ssl k8s-10.221.36.190_443_ssl (10.221.36.190:443) - SSL Type: CONTENT State: UP Last state change was at Wed Apr 3 04:50:56 2024 Time since last state change: 0 days, 00:00:31.590 Client Idle Timeout: 180 sec Down state flush: ENABLED Disable Primary Vserver On Down : DISABLED Comment: uid=IIFGNN4JZ4LBQ7VCBTX6DN7TIBGGOU3OD2OBIC7MB73O2B2FNL2Q==== **HTTP profile name: k8s-10.221.36.190_443_ssl** Appflow logging: ENABLED State Update: DISABLED Default: Content Precedence: RULE Vserver IP and Port insertion: OFF L2Conn: OFF Case Sensitivity: ON Authentication: OFF 401 Based Authentication: OFF Push: DISABLED Push VServer: Push Label Rule: none HTTP Redirect Port: 0 Dtls : OFF Persistence: NONE Listen Policy: NONE IcmpResponse: PASSIVE RHIstate: PASSIVE Traffic Domain: 0 1) Content-Switching Policy: k8s-backend_80_csp_2k75kfjrr6ptgzwtncozwxdjqrpbvicz Rule: HTTP.REQ.HOSTNAME.SERVER.EQ("hotdrink.beverages.com") && HTTP.REQ.URL.PATH.SET_TEXT_MODE(IGNORECASE).STARTSWITH("/") Priority: 200000008 Hits: 0 Done

Note:

For various HTTP parameters supported on NetScaler, refer to NetScaler 14.1 REST APIs - NITRO Documentation for HTTP profiles. The key and value that you pass in the JSON format must match the values in the NITRO format.