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
<!--NeedCopy-->
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
<!--NeedCopy-->
# 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
<!--NeedCopy-->
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.
-
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 <!--NeedCopy-->
-
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 <!--NeedCopy-->
-
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
<!--NeedCopy-->
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.