You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/application-gateway/ingress-controller-annotations.md
+76-53Lines changed: 76 additions & 53 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,35 +5,33 @@ services: application-gateway
5
5
author: greg-lindsay
6
6
ms.service: application-gateway
7
7
ms.topic: article
8
-
ms.date: 3/18/2022
8
+
ms.date: 10/26/2022
9
9
ms.author: greglin
10
10
---
11
11
12
-
# Annotations for Application Gateway Ingress Controller
12
+
# Annotations for Application Gateway Ingress Controller
13
13
14
-
## Introductions
15
-
16
-
The Kubernetes Ingress resource can be annotated with arbitrary key/value pairs. AGIC relies on annotations to program Application Gateway features, which are not configurable via the Ingress YAML. Ingress annotations are applied to all HTTP setting, backend pools, and listeners derived from an ingress resource.
14
+
The Kubernetes Ingress resource can be annotated with arbitrary key/value pairs. AGIC relies on annotations to program Application Gateway features, which aren't configurable using the Ingress YAML. Ingress annotations are applied to all HTTP settings, backend pools, and listeners derived from an ingress resource.
17
15
18
16
## List of supported annotations
19
17
20
-
For an Ingress resource to be observed by AGIC, it **must be annotated** with `kubernetes.io/ingress.class: azure/application-gateway`. Only then AGIC will work with the Ingress resource in question.
18
+
For an Ingress resource to be observed by AGIC, it **must be annotated** with `kubernetes.io/ingress.class: azure/application-gateway`. Only then AGIC works with the Ingress resource in question.
21
19
22
-
| Annotation Key | Value Type | Default Value | Allowed Values
20
+
| Annotation Key | Value Type | Default Value | Allowed Values|
This annotation allows the backend path specified in an ingress resource to be rewritten with prefix specified in this annotation. This allows users to expose services whose endpoints are different than endpoint names used to expose a service in an ingress resource.
34
+
The following annotation allows the backend path specified in an ingress resource to be rewritten with prefix specified in this annotation. It allows users to expose services whose endpoints are different than endpoint names used to expose a service in an ingress resource.
In the example above, we have defined an ingress resource named `go-server-ingress-bkprefix` with an annotation `appgw.ingress.kubernetes.io/backend-path-prefix: "/test/"` . The annotation tells application gateway to create an HTTP setting, which will have a path prefix override for the path `/hello` to `/test/`.
65
65
66
-
> [!NOTE]
67
-
> In the above example we have only one rule defined. However, the annotations are applicable to the entire ingress resource, so if a user had defined multiple rules, the backend path prefix would be set up for each of the paths specified. Thus, if a user wants different rules with different path prefixes (even for the same service) they would need to define different ingress resources.
66
+
In the previous example, you've defined an ingress resource named `go-server-ingress-bkprefix` with an annotation `appgw.ingress.kubernetes.io/backend-path-prefix: "/test/"`. The annotation tells application gateway to create an HTTP setting, which has a path prefix override for the path `/hello` to `/test/`.
67
+
68
+
> [!NOTE]
69
+
> In the above example, only one rule is defined. However, the annotations are applicable to the entire ingress resource, so if a user defined multiple rules, the backend path prefix would be set up for each of the paths specified. If a user wants different rules with different path prefixes (even for the same service), they would need to define different ingress resources.
68
70
69
71
## TLS Redirect
70
72
71
73
Application Gateway [can be configured](./redirect-overview.md)
72
74
to automatically redirect HTTP URLs to their HTTPS counterparts. When this
73
75
annotation is present and TLS is properly configured, Kubernetes Ingress
74
-
controller will create a [routing rule with a redirection configuration](./redirect-http-to-https-portal.md#add-a-routing-rule-with-a-redirection-configuration)
75
-
and apply the changes to your Application Gateway. The redirect created will be HTTP `301 Moved Permanently`.
76
+
controller creates a [routing rule with a redirection configuration](./redirect-http-to-https-portal.md#add-a-routing-rule-with-a-redirection-configuration)
77
+
and applies the changes to your Application Gateway. The redirect created will be HTTP `301 Moved Permanently`.
`connection-draining`: This annotation allows users to specify whether to enable connection draining.
111
-
`connection-draining-timeout`: This annotation allows users to specify a timeout after which Application Gateway will terminate the requests to the draining backend endpoint.
114
+
`connection-draining`: This annotation allows us to specify whether to enable connection draining.
115
+
`connection-draining-timeout`: This annotation allows us to specify a timeout, after which Application Gateway terminates the requests to the draining backend endpoint.
This annotation allows to specify the request timeout in seconds after which Application Gateway will fail the request if response is not received.
185
+
The following annotation allows you to specify the request timeout in seconds, after which Application Gateway fails the request if response is not received.
This annotation allows us to specify whether to expose this endpoint on Private IP of Application Gateway.
219
+
The following annotation allows you to specify whether to expose this endpoint on Private IP of Application Gateway.
207
220
208
221
> [!NOTE]
209
-
> * Application Gateway doesn't support multiple IPs on the same port (example: 80/443). Ingress with annotation `appgw.ingress.kubernetes.io/use-private-ip: "false"` and another with `appgw.ingress.kubernetes.io/use-private-ip: "true"` on `HTTP` will cause AGIC to fail in updating the Application Gateway.
210
-
> * For Application Gateway that doesn't have a private IP, Ingresses with `appgw.ingress.kubernetes.io/use-private-ip: "true"` will be ignored. This will reflected in the controller logs and ingress events for those ingresses with `NoPrivateIP` warning.
211
-
222
+
> * Application Gateway doesn't support multiple IPs on the same port (example: 80/443). Ingress with annotation `appgw.ingress.kubernetes.io/use-private-ip: "false"` and another with `appgw.ingress.kubernetes.io/use-private-ip: "true"` on `HTTP` will cause AGIC to fail while updating the Application Gateway.
223
+
> * For Application Gateway that doesn't have a private IP, Ingresses with `appgw.ingress.kubernetes.io/use-private-ip: "true"` is ignored. This is reflected in the controller logs and ingress events for those ingresses with `NoPrivateIP` warning.
This annotation allows us to specify the protocol that Application Gateway should use while talking to the Pods. Supported Protocols: `http`, `https`
257
+
The following annotation allows you to specify the protocol that Application Gateway should use while communicating with the pods. Supported Protocols are `http` and `https`.
241
258
242
259
> [!NOTE]
243
-
> * While self-signed certificates are supported on Application Gateway, currently, AGIC only support `https` when Pods are using certificate signed by a well-known CA.
244
-
> * Make sure to not use port 80 with HTTPS and port 443 with HTTP on the Pods.
260
+
> While self-signed certificates are supported on Application Gateway, currently AGIC only supports `https` when pods are using a certificate signed by a well-known CA.
261
+
>
262
+
> Don't use port 80 with HTTPS and port 443 with HTTP on the pods.
0 commit comments