Add user-defined annotations

This page applies to:

HAProxy Kubernetes Ingress Controller 3.2 and newer
HAProxy Enterprise Kubernetes Ingress Controller 3.2 and newer

With user-defined annotations, you can extend the functionality of HAProxy Kubernetes Ingress Controller in custom ways. User-defined annotations attach to the metadata of your Kubernetes resources and are translated into one or many lines of HAProxy configuration. They can be simple, but they can also enable advanced use cases through templating expressions. You can restrict which namespaces, resource kinds, and configuration sections your annotations are available to, and you can define validation logic that ensures users set your annotations correctly.

Prerequisites Jump to heading

Before continuing, ensure that you’ve performed these steps:

Install the ValidationRules custom resource definition:
- Install the Community ValidationRules custom resource definition.
- Install the Enterprise ValidationRules custom resource definition.
When deploying the ingress controller, add the startup argument --custom-validation-rules=<namespace>/<validationrules-name>, where validationrules-name is the name you’ll assign to your ValidationRules custom resource. With Helm, you can set it with extraArgs, as shown in this example:
```
myvals.yaml
yaml
controller:
  extraArgs:
    - --custom-validation-rules=haproxy-controller/example-annotations
```
```
myvals.yaml
yaml
controller:
  extraArgs:
    - --custom-validation-rules=haproxy-controller/example-annotations
```

Add a backend annotation Jump to heading

Create a ValidationRules resource to contain the definitions of your user-defined annotations for backends.

Add a ValidationRules custom resource.
```
example-annotations.yaml
yaml
apiVersion: ingress.v3.haproxy.org/v3
kind: ValidationRules
metadata:
  name: example-annotations
  namespace: haproxy-controller
spec:
  prefix: "example.com"
  validation_rules:
    retries:
      section: backend
      type: int
      rule: "value >= 1 && value <= 10"
```
```
example-annotations.yaml
yaml
apiVersion: ingress.v3.haproxy.org/v3
kind: ValidationRules
metadata:
  name: example-annotations
  namespace: haproxy-controller
spec:
  prefix: "example.com"
  validation_rules:
    retries:
      section: backend
      type: int
      rule: "value >= 1 && value <= 10"
```
- prefix indicates the prefix for your annotations. It’s best to use your organization’s domain, such as example.com. When using your custom annotation, you’ll use backend.<prefix>/<annotation-name>. By default, user-defined annotations apply to backends, but you can change that by setting the section field to all, frontend, or backend.
- validation_rules contains one or more user-defined annotations. In this example, we’re creating an annotation named retries that can have an integer value between 1 and 10. Use the variable value in expressions. This validation logic is implemented via Common Expression Language. You can add more annotations beneath validation_rules.
Annotations that set section to backend can be attached to Service resources, Ingress resources, and the haproxy-kubernetes-ingress ConfigMap. They take precendence in that order.
- When attached to a Service resource, annotations apply to the associated backend.
- When attached to the ConfigMap resource, annotations apply to all backends.
- When attached to an Ingress resource, annotations apply to the associated backend. We don’t recommend this because multiple Ingress resources can apply to the same HAProxy backend, presenting the chance of conflicting annotations. To use annotations on Ingress resources, you must set the startup argument --enable-custom-annotations-on-ingress.

Apply the changes with kubectl.

nix
kubectl apply -f example-annotations.yaml

nix
kubectl apply -f example-annotations.yaml

output
text
validationrules.ingress.v3.haproxy.org/example-annotations created

output
text
validationrules.ingress.v3.haproxy.org/example-annotations created

Use the annotation on a Service resource:

example-service.yaml
yaml
kind: Service
apiVersion: v1
metadata:
  name: http-echo
  annotations:
    backend.example.com/retries: "3"
...

example-service.yaml
yaml
kind: Service
apiVersion: v1
metadata:
  name: http-echo
  annotations:
    backend.example.com/retries: "3"
...

nix
kubectl apply -f example-service.yaml

nix
kubectl apply -f example-service.yaml

The ingress controller logs will show the update.

nix
kubectl logs -n haproxy-controller <haproxy-kubernetes-ingress pod>

nix
kubectl logs -n haproxy-controller <haproxy-kubernetes-ingress pod>

output
text
2025/12/11 17:54:18 INFO    annotations/cfgSnippetHandler.go:105 [transactionID=43d89ca1-999d-40cf-beb0-d5add7f6286d] reload required : config snippet from {example.com/retries %!s(int=2)} has been updated

output
text
2025/12/11 17:54:18 INFO    annotations/cfgSnippetHandler.go:105 [transactionID=43d89ca1-999d-40cf-beb0-d5add7f6286d] reload required : config snippet from {example.com/retries %!s(int=2)} has been updated

The generated HAProxy configuration will add retries to the backend associated with the Service resource.

haproxy
backend default_svc_http-echo_http
  ...
  ###_config-snippet_### BEGIN
  ## example.com/retries ###
  retries 3
  ###_config-snippet_### END

haproxy
backend default_svc_http-echo_http
  ...
  ###_config-snippet_### BEGIN
  ## example.com/retries ###
  retries 3
  ###_config-snippet_### END

If there was a validation error, the line will be commented out, with the error included.

haproxy
backend default_svc_myapp_http
  ...
  ###_config-snippet_### BEGIN
  ### example.com/retries ###
  # ERROR: invalid integer format for 'three': strconv.ParseInt: parsing "three": invalid syntax
  ###_config-snippet_### END

haproxy
backend default_svc_myapp_http
  ...
  ###_config-snippet_### BEGIN
  ### example.com/retries ###
  # ERROR: invalid integer format for 'three': strconv.ParseInt: parsing "three": invalid syntax
  ###_config-snippet_### END

Add a frontend annotation Jump to heading

Create a ValidationRules resource to contain the definitions of your user-defined annotations for frontends.

Add a ValidationRules custom resource.

example-annotations.yaml
yaml
apiVersion: ingress.v3.haproxy.org/v3
kind: ValidationRules
metadata:
  name: example-annotations
  namespace: haproxy-controller
spec:
  prefix: "example.com"
  validation_rules:
    maxconn:
      section: frontend
      type: int
      resources:
        - http
        - https
      rule: "value >= 10 && value <= 1000000"

example-annotations.yaml
yaml
apiVersion: ingress.v3.haproxy.org/v3
kind: ValidationRules
metadata:
  name: example-annotations
  namespace: haproxy-controller
spec:
  prefix: "example.com"
  validation_rules:
    maxconn:
      section: frontend
      type: int
      resources:
        - http
        - https
      rule: "value >= 10 && value <= 1000000"

prefix indicates the prefix for your annotations. It’s best to use your organization’s domain, such as example.com. When using your custom annotation, you’ll use frontend.<prefix>/<annotation-name>.
resources sets the frontends your annotation will apply to. Frontend names are http, https, and stats.
validation_rules contains one or more user-defined annotations. In this example, we’re creating an annotation named maxconn that can have an integer value between 10 and 1000000. Use the variable value in expressions. This validation logic is implemented via Common Expression Language. You can add more annotations beneath validation_rules.

Annotations that set section to frontend can be attached to the haproxy-kubernetes-ingress ConfigMap.

Apply the changes with kubectl.

nix
kubectl apply -f example-annotations.yaml

nix
kubectl apply -f example-annotations.yaml

output
text
validationrules.ingress.v3.haproxy.org/example-annotations created

output
text
validationrules.ingress.v3.haproxy.org/example-annotations created

To add your annotation to the ConfigMap, you can either:

Add the annotation using kubectl annotate:

nix
kubectl annotate configmap haproxy-kubernetes-ingress --namespace haproxy-controller frontend.example.com/maxconn=10000

nix
kubectl annotate configmap haproxy-kubernetes-ingress --namespace haproxy-controller frontend.example.com/maxconn=10000

Or, use kubectl edit to modify the ConfigMap:

nix
kubectl edit configmap haproxy-kubernetes-ingress --namespace haproxy-controller

nix
kubectl edit configmap haproxy-kubernetes-ingress --namespace haproxy-controller

Use the annotation on the ConfigMap, then save the file.

configmap.yaml
yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: haproxy-kubernetes-ingress
  namespace: haproxy-controller
  annotations:
    frontend.example.com/maxconn: "10000"

configmap.yaml
yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: haproxy-kubernetes-ingress
  namespace: haproxy-controller
  annotations:
    frontend.example.com/maxconn: "10000"

The ingress controller logs will show the update.

nix
kubectl logs -n haproxy-controller <haproxy-kubernetes-ingress pod>

nix
kubectl logs -n haproxy-controller <haproxy-kubernetes-ingress pod>

output
text
2025/12/12 21:00:45 INFO    controller/global.go:123 [transactionID=abae4313-eb2c-4a33-b881-8e315edf992d] reload required : Frontend config-snippet updated: <nil slice> != [### example.com/maxconn ### maxconn 10000]

output
text
2025/12/12 21:00:45 INFO    controller/global.go:123 [transactionID=abae4313-eb2c-4a33-b881-8e315edf992d] reload required : Frontend config-snippet updated: <nil slice> != [### example.com/maxconn ### maxconn 10000]

The generated HAProxy configuration will add maxconn to the frontend.

haproxy
frontend http
  ...
  ###_config-snippet_### BEGIN
  ## example.com/maxconn ###
  maxconn 10000
  ###_config-snippet_### END

haproxy
frontend http
  ...
  ###_config-snippet_### BEGIN
  ## example.com/maxconn ###
  maxconn 10000
  ###_config-snippet_### END

If there was a validation error, the line will be commented out, with the error included.

haproxy
###_config-snippet_### BEGIN
### example.com/maxconn ###
# ERROR: validation failed for rule 'maxconn' with value '0'. 
# Failed part: 'value >= 10'
### custom annotations end ###
###_config-snippet_### END

haproxy
###_config-snippet_### BEGIN
### example.com/maxconn ###
# ERROR: validation failed for rule 'maxconn' with value '0'. 
# Failed part: 'value >= 10'
### custom annotations end ###
###_config-snippet_### END

Syntax Jump to heading

The validation_rules section in a ValidationRules resource supports the following syntax.

yaml
timeout-server: # name of annotation
  section: all # can be all, frontend, backend (default)
  namespaces: # we can limit namespace usage
    - default
    - dev
    - prod
  resources: # limit usage to Service, Frontend or Backend names (list)
    - myservice
  ingresses: # limit usage to specific ingresses
    - myingress
  order_priority: 100 # order of user annotations in config. higher is more priority
  template: "timeout server {{.}}" # template we can use (golang templates)
  type: duration # expected data type for conversion (duration;int;uint;bool;string;float;json;)
  rule: "value > duration('42s') && value <= duration('42m')" # CEL expression

yaml
timeout-server: # name of annotation
  section: all # can be all, frontend, backend (default)
  namespaces: # we can limit namespace usage
    - default
    - dev
    - prod
  resources: # limit usage to Service, Frontend or Backend names (list)
    - myservice
  ingresses: # limit usage to specific ingresses
    - myingress
  order_priority: 100 # order of user annotations in config. higher is more priority
  template: "timeout server {{.}}" # template we can use (golang templates)
  type: duration # expected data type for conversion (duration;int;uint;bool;string;float;json;)
  rule: "value > duration('42s') && value <= duration('42m')" # CEL expression

Examples Jump to heading

In this section, you’ll find other examples of creating user-defined annotations.

Integer Jump to heading

Here, we define an annotation named max-keep-alive-queue that expects an integer value. You can use the variable value to perform validation logic. In this example, we enforce the rule that the value must be between 10 and 1000000.

example-annotations.yaml
yaml
apiVersion: ingress.v3.haproxy.org/v3
kind: ValidationRules
metadata:
  name: example-annotations
  namespace: haproxy-controller
spec:
  prefix: "example.com"
  validation_rules:
    max-keep-alive-queue:
      section: backend
      type: int
      rule: "value >= 1 && value <= 100"

example-annotations.yaml
yaml
apiVersion: ingress.v3.haproxy.org/v3
kind: ValidationRules
metadata:
  name: example-annotations
  namespace: haproxy-controller
spec:
  prefix: "example.com"
  validation_rules:
    max-keep-alive-queue:
      section: backend
      type: int
      rule: "value >= 1 && value <= 100"

Usage:

example-service.yaml
yaml
kind: Service
apiVersion: v1
metadata:
  name: http-echo
  annotations:
    backend.example.com/max-keep-alive-queue: "10"
...

example-service.yaml
yaml
kind: Service
apiVersion: v1
metadata:
  name: http-echo
  annotations:
    backend.example.com/max-keep-alive-queue: "10"
...

Boolean Jump to heading

Booleans work well for HAProxy directives that don’t accept any arguments, such as option forwardfor. In this example, we use template to control the generated configuration line. The templating language is implemented via Golang templates. The annotation can be set to true only.

example-annotations.yaml
yaml
apiVersion: ingress.v3.haproxy.org/v3
kind: ValidationRules
metadata:
  name: example-annotations
  namespace: haproxy-controller
spec:
  prefix: "example.com"
  validation_rules:
    option-forwardfor:
      section: backend
      type: bool
      template: "option forwardfor"
      rule: "value == true"

example-annotations.yaml
yaml
apiVersion: ingress.v3.haproxy.org/v3
kind: ValidationRules
metadata:
  name: example-annotations
  namespace: haproxy-controller
spec:
  prefix: "example.com"
  validation_rules:
    option-forwardfor:
      section: backend
      type: bool
      template: "option forwardfor"
      rule: "value == true"

Usage:

example-service.yaml
yaml
kind: Service
apiVersion: v1
metadata:
  name: http-echo
  annotations:
    backend.example.com/option-forwardfor: "true"
...

example-service.yaml
yaml
kind: Service
apiVersion: v1
metadata:
  name: http-echo
  annotations:
    backend.example.com/option-forwardfor: "true"
...

Time duration Jump to heading

Some HAProxy directives expect a value indicating a time duration. The rule in this example uses the duration function to check that the value is between 1 minute and 1 hour. Consult the HAProxy Configuration Manual entry for Time format, but note that HAProxy supports days with d, but Common Expression Language doesn’t, so d isn’t allowed here.

example-annotations.yaml
yaml
apiVersion: ingress.v3.haproxy.org/v3
kind: ValidationRules
metadata:
  name: example-annotations
  namespace: haproxy-controller
spec:
  prefix: "example.com"
  validation_rules:
    timeout-tunnel:
      section: backend
      type: duration
      template: "timeout tunnel {{.}}"
      rule: "value > duration('1m') && value <= duration('1h')"

example-annotations.yaml
yaml
apiVersion: ingress.v3.haproxy.org/v3
kind: ValidationRules
metadata:
  name: example-annotations
  namespace: haproxy-controller
spec:
  prefix: "example.com"
  validation_rules:
    timeout-tunnel:
      section: backend
      type: duration
      template: "timeout tunnel {{.}}"
      rule: "value > duration('1m') && value <= duration('1h')"

Usage:

example-service.yaml
yaml
kind: Service
apiVersion: v1
metadata:
  name: http-echo
  annotations:
    backend.example.com/timeout-tunnel: "30m"
...

example-service.yaml
yaml
kind: Service
apiVersion: v1
metadata:
  name: http-echo
  annotations:
    backend.example.com/timeout-tunnel: "30m"
...

JSON object Jump to heading

When you set type to json, your annotation can accept a JSON object. This allows you to set multiple values by referring to the keys of a JSON object in template, such as {{.hdr}} and {{.domain}} in this example.

Also in this example, we define a rule that makes those JSON fields mandatory through the in keyword and performs other validation, including checking against regular expressions that the given .domain value is either a domain name or an IPv4 address.

example-annotations.yaml
yaml
apiVersion: ingress.v3.haproxy.org/v3
kind: ValidationRules
metadata:
  name: example-annotations
  namespace: haproxy-controller
spec:
  prefix: "example.com"
  validation_rules:
    http-request-set-header-X-Request-ID:
      section: backend
      type: json
      template: "http-request set-header X-Request-ID %[unique-id] if { hdr({{.hdr}}) -i {{.domain}} }"
      rule: "'hdr' in value && 'domain' in value && ((value.hdr == 'host' && value.domain.matches('^([a-zA-Z0-9-]+\\\\.)+[a-zA-Z]{2,}$')) || (value.hdr == 'ip' && value.domain.matches('^((25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\\\\.){3}(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)$')))"

example-annotations.yaml
yaml
apiVersion: ingress.v3.haproxy.org/v3
kind: ValidationRules
metadata:
  name: example-annotations
  namespace: haproxy-controller
spec:
  prefix: "example.com"
  validation_rules:
    http-request-set-header-X-Request-ID:
      section: backend
      type: json
      template: "http-request set-header X-Request-ID %[unique-id] if { hdr({{.hdr}}) -i {{.domain}} }"
      rule: "'hdr' in value && 'domain' in value && ((value.hdr == 'host' && value.domain.matches('^([a-zA-Z0-9-]+\\\\.)+[a-zA-Z]{2,}$')) || (value.hdr == 'ip' && value.domain.matches('^((25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\\\\.){3}(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)$')))"

Usage:

example-service.yaml
yaml
kind: Service
apiVersion: v1
metadata:
  name: http-echo
  annotations:
    backend.example.com/http-request-set-header-X-Request-ID: '{"hdr":"host", "domain":"example.com"}'
...

example-service.yaml
yaml
kind: Service
apiVersion: v1
metadata:
  name: http-echo
  annotations:
    backend.example.com/http-request-set-header-X-Request-ID: '{"hdr":"host", "domain":"example.com"}'
...

Or set it as a multi-line string:

example-service.yaml
yaml
kind: Service
apiVersion: v1
metadata:
  name: http-echo
  annotations:
    backend.example.com/http-request-set-header-X-Request-ID: |
      {
        "hdr":"host",
        "domain":"example.com"
      }
...

example-service.yaml
yaml
kind: Service
apiVersion: v1
metadata:
  name: http-echo
  annotations:
    backend.example.com/http-request-set-header-X-Request-ID: |
      {
        "hdr":"host",
        "domain":"example.com"
      }
...

This will generate:

haproxy
backend default_svc_http-echo_http
  ...
  ###_config-snippet_### BEGIN
  ## example.com/http-request-set-header-X-Request-ID ###
  http-request set-header X-Request-ID %[unique-id] if { hdr(host) -i example.com }
  ###_config-snippet_### END

haproxy
backend default_svc_http-echo_http
  ...
  ###_config-snippet_### BEGIN
  ## example.com/http-request-set-header-X-Request-ID ###
  http-request set-header X-Request-ID %[unique-id] if { hdr(host) -i example.com }
  ###_config-snippet_### END

Multiple lines Jump to heading

To generate multiple lines of HAProxy configuration, add line breaks to your template.

example-annotations.yaml
yaml
apiVersion: ingress.v3.haproxy.org/v3
kind: ValidationRules
metadata:
  name: example-annotations
  namespace: haproxy-controller
spec:
  prefix: "example.com"
  validation_rules:
    timeouts:
      section: backend
      type: json
      template: |
        timeout server {{.server}}
        timeout server-fin {{.server_fin}}
        timeout tarpit {{.tarpit}}
      rule: |
        'server' in value && value.server.matches('^[0-9]+[smh]?$') &&
        'server_fin' in value && value.server_fin.matches('^[0-9]+[smh]?$') &&
        'tarpit' in value && value.tarpit.matches('^[0-9]+[smh]?$')

example-annotations.yaml
yaml
apiVersion: ingress.v3.haproxy.org/v3
kind: ValidationRules
metadata:
  name: example-annotations
  namespace: haproxy-controller
spec:
  prefix: "example.com"
  validation_rules:
    timeouts:
      section: backend
      type: json
      template: |
        timeout server {{.server}}
        timeout server-fin {{.server_fin}}
        timeout tarpit {{.tarpit}}
      rule: |
        'server' in value && value.server.matches('^[0-9]+[smh]?$') &&
        'server_fin' in value && value.server_fin.matches('^[0-9]+[smh]?$') &&
        'tarpit' in value && value.tarpit.matches('^[0-9]+[smh]?$')

Usage:

example-service.yaml
yaml
kind: Service
apiVersion: v1
metadata:
  name: http-echo
  annotations:
    backend.example.com/timeouts: |
      {
        "server": "42s",
        "server_fin": "10s",
        "tarpit": "5s"
      }
...

example-service.yaml
yaml
kind: Service
apiVersion: v1
metadata:
  name: http-echo
  annotations:
    backend.example.com/timeouts: |
      {
        "server": "42s",
        "server_fin": "10s",
        "tarpit": "5s"
      }
...

This will generate:

haproxy
backend default_svc_http-echo_http
  ...
  ###_config-snippet_### BEGIN
  ### example.com/timeouts ###
  timeout server 42s
  timeout server-fin 10s
  timeout tarpit 5s
  ###_config-snippet_### END

haproxy
backend default_svc_http-echo_http
  ...
  ###_config-snippet_### BEGIN
  ### example.com/timeouts ###
  timeout server 42s
  timeout server-fin 10s
  timeout tarpit 5s
  ###_config-snippet_### END

Predefined template variables Jump to heading

When using the json type, you get access to predefined template variables that are derived from the ingress controller’s environment.

Variable	Description
`BACKEND`	The name of the `backend` in the HAProxy configuration.
`INGRESS`	The name of the Ingress resource.
`NAMESPACE`	The Ingress resource’s namespace.
`POD_IP`	The pod’s cluster IP address from `status.podIP`.
`POD_NAME`	The pod’s name from `metadata.name`.
`POD_NAMESPACE`	The pod’s namespace from `metadata.namespace`.
`SERVICE`	The name of the Service resource.

Let’s use these variables along with others that we define to set a preamble above the generated configuration.

example-annotations.yaml
yaml
apiVersion: ingress.v3.haproxy.org/v3
kind: ValidationRules
metadata:
  name: example-annotations
  namespace: haproxy-controller
spec:
  prefix: "example.com"
  validation_rules:
    retries:
      section: backend
      type: json
      template: |
        # ==============================================
          # user annotation, owner: {{.owner}} - Reason: {{.reason}} for {{.BACKEND}}
          # namespace {{.NAMESPACE}}, ingress {{.INGRESS}}, service {{.SERVICE}}
          # POD_NAME {{.POD_NAME}}, POD_NAMESPACE {{.POD_NAMESPACE}}, POD_IP {{.POD_IP}}
          # ==============================================
          retries {{.retries}}
          # ==============================================
      rule: |
        'owner' in value &&
        'reason' in value &&
        'retries' in value && int(value.retries) >= 1 && int(value.retries) <= 10

example-annotations.yaml
yaml
apiVersion: ingress.v3.haproxy.org/v3
kind: ValidationRules
metadata:
  name: example-annotations
  namespace: haproxy-controller
spec:
  prefix: "example.com"
  validation_rules:
    retries:
      section: backend
      type: json
      template: |
        # ==============================================
          # user annotation, owner: {{.owner}} - Reason: {{.reason}} for {{.BACKEND}}
          # namespace {{.NAMESPACE}}, ingress {{.INGRESS}}, service {{.SERVICE}}
          # POD_NAME {{.POD_NAME}}, POD_NAMESPACE {{.POD_NAMESPACE}}, POD_IP {{.POD_IP}}
          # ==============================================
          retries {{.retries}}
          # ==============================================
      rule: |
        'owner' in value &&
        'reason' in value &&
        'retries' in value && int(value.retries) >= 1 && int(value.retries) <= 10

Usage:

example-service.yaml
yaml
kind: Service
apiVersion: v1
metadata:
  name: http-echo
  annotations:
    backend.example.com/retries: '{ "retries": 3, "owner": "jsmith", "reason": "user annotation demo" }'

example-service.yaml
yaml
kind: Service
apiVersion: v1
metadata:
  name: http-echo
  annotations:
    backend.example.com/retries: '{ "retries": 3, "owner": "jsmith", "reason": "user annotation demo" }'

This will generate:

haproxy
backend default_svc_http-echo_http
  ...
  ###_config-snippet_### BEGIN                                             
  ### example.com/retries ###                                                                    
  # ==============================================                                   
  # user annotation, owner: jsmith - Reason: user annotation demo for default_svc_http-echo_http
  # namespace default, ingress example-ingress, service http-echo                        
  # POD_NAME haproxy-kubernetes-ingress-64c4ddbc9b-bdq5c, POD_NAMESPACE haproxy-controller, POD_IP 10.244.0.5 
  # ============================================== 
  retries 3
  # ==============================================              
  ###_config-snippet_### END

haproxy
backend default_svc_http-echo_http
  ...
  ###_config-snippet_### BEGIN                                             
  ### example.com/retries ###                                                                    
  # ==============================================                                   
  # user annotation, owner: jsmith - Reason: user annotation demo for default_svc_http-echo_http
  # namespace default, ingress example-ingress, service http-echo                        
  # POD_NAME haproxy-kubernetes-ingress-64c4ddbc9b-bdq5c, POD_NAMESPACE haproxy-controller, POD_IP 10.244.0.5 
  # ============================================== 
  retries 3
  # ==============================================              
  ###_config-snippet_### END

Product Documentation

API Documentation

Configuration Documentation

Install on Amazon EKS

Add user-defined annotations

Prerequisites Jump to heading

Add a backend annotation Jump to heading

Add a frontend annotation Jump to heading

Syntax Jump to heading

Examples Jump to heading

Integer Jump to heading

Boolean Jump to heading

Time duration Jump to heading

JSON object Jump to heading

Multiple lines Jump to heading

Predefined template variables Jump to heading

Install on Amazon EKS

Product Documentation

API Documentation

Configuration Documentation

Prerequisites Jump to heading #

Add a backend annotation Jump to heading #

Add a frontend annotation Jump to heading #

Syntax Jump to heading #

Examples Jump to heading #

Integer Jump to heading #

Boolean Jump to heading #

Time duration Jump to heading #

JSON object Jump to heading #

Multiple lines Jump to heading #

Predefined template variables Jump to heading #

Privacy Settings

Prerequisites Jump to heading

Add a backend annotation Jump to heading

Add a frontend annotation Jump to heading

Syntax Jump to heading

Examples Jump to heading

Integer Jump to heading

Boolean Jump to heading

Time duration Jump to heading

JSON object Jump to heading

Multiple lines Jump to heading

Predefined template variables Jump to heading