Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Вы можете аннотировать ресурс входа Kubernetes с произвольными парами ключей и значений. Контроллер входящего трафика для Шлюза приложений (AGIC) полагается на аннотации для настройки функций Шлюза приложений Azure, которые не могут быть сконфигурированы через YAML-файл для входящего трафика. Заметки входящего трафика применяются ко всем параметрам HTTP, серверным пулам и прослушивателям, производным от ресурса входящего трафика.
Совет
Рассмотрите Application Gateway for Containers в качестве решения для Kubernetes Ingress. Дополнительные сведения см. в разделе Краткое руководство: развертывание Шлюза приложений для контроллера контейнеров ALB.
Список поддерживаемых заметок
Чтобы AGIC наблюдал за ресурсом Ingress, ресурс должен быть аннотирован с kubernetes.io/ingress.class: azure/application-gateway.
Префикс пути к серверной части
Следующая заметка позволяет переписать внутренний путь, указанный в ресурсе входящего трафика с указанным префиксом. Используйте его для предоставления служб, конечные точки которых отличаются от имен, используемых для их описания в ресурсе входа.
Использование
appgw.ingress.kubernetes.io/backend-path-prefix: <path prefix>
Пример
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: go-server-ingress-bkprefix
annotations:
kubernetes.io/ingress.class: azure/application-gateway
appgw.ingress.kubernetes.io/backend-path-prefix: "/test/"
spec:
rules:
- http:
paths:
- path: /hello/
pathType: Exact
backend:
service:
name: go-server-service
port:
number: 80
В предыдущем примере определяется ресурс входа с именем go-server-ingress-bkprefix с аннотацией с именем appgw.ingress.kubernetes.io/backend-path-prefix: "/test/". Примечания сообщает Шлюз приложений создать параметр HTTP, имеющий префикс пути, переопределенный для пути /hello/test/.
В примере определяется только одно правило. Однако заметки применяются ко всему ресурсу ingress. Поэтому при определении нескольких правил необходимо настроить префикс внутреннего пути для каждого из указанных путей. Если требуется разные правила с различными префиксами пути (даже для одной службы), необходимо определить различные ресурсы входящего трафика.
Имя узла бэкенда
Используйте следующую аннотацию, чтобы указать имя узла, которое Шлюз приложений должен использовать при взаимодействии с подами.
Использование
appgw.ingress.kubernetes.io/backend-hostname: "internal.example.com"
Пример
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: go-server-ingress-timeout
annotations:
kubernetes.io/ingress.class: azure/application-gateway
appgw.ingress.kubernetes.io/backend-hostname: "internal.example.com"
spec:
rules:
- http:
paths:
- path: /hello/
backend:
service:
name: store-service
port:
number: 80
pathType: Exact
Настраиваемая проба работоспособности
Шлюз приложений можно настроить для отправки пользовательской пробы работоспособности в пул внутренних адресов. При наличии приведенных ниже заметок контроллер входящего трафика Kubernetes создает пользовательскую пробу для мониторинга серверного приложения. Затем контроллер применяет изменения к шлюзу приложений.
-
health-probe-hostname: эта аннотация разрешает пользовательское доменное имя в пробе работоспособности. -
health-probe-port: эта заметка настраивает пользовательский порт для пробы работоспособности. -
health-probe-path: эта заметка определяет путь для пробы работоспособности. -
health-probe-status-codes: эта заметка позволяет пробе работоспособности принимать различные коды состояния HTTP. -
health-probe-interval: эта аннотация определяет интервал выполнения проверки работоспособности. -
health-probe-timeout: эта заметка определяет время ожидания пробы работоспособности до сбоя пробы работоспособности. -
health-probe-unhealthy-threshold: эта заметка определяет, сколько проб работоспособности должно завершиться ошибкой, чтобы серверная часть была помечена как неработоспособная.
Использование
appgw.ingress.kubernetes.io/health-probe-hostname: "contoso.com"
appgw.ingress.kubernetes.io/health-probe-port: 80
appgw.ingress.kubernetes.io/health-probe-path: "/"
appgw.ingress.kubernetes.io/health-probe-status-codes: "100-599"
appgw.ingress.kubernetes.io/health-probe-interval: 30
appgw.ingress.kubernetes.io/health-probe-timeout: 30
appgw.ingress.kubernetes.io/health-probe-unhealthy-threshold: 2
Пример
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: go-server-ingress
annotations:
kubernetes.io/ingress.class: azure/application-gateway
appgw.ingress.kubernetes.io/health-probe-hostname: "contoso.com"
appgw.ingress.kubernetes.io/health-probe-port: 81
appgw.ingress.kubernetes.io/health-probe-path: "/probepath"
appgw.ingress.kubernetes.io/health-probe-status-codes: "100-599"
appgw.ingress.kubernetes.io/health-probe-interval: 31
appgw.ingress.kubernetes.io/health-probe-timeout: 31
appgw.ingress.kubernetes.io/health-probe-unhealthy-threshold: 2
spec:
rules:
- http:
paths:
- path: /
pathType: Exact
backend:
service:
name: go-server-service
port:
number: 80
Перенаправление TLS
Вы можете настроить Шлюз приложений для автоматического перенаправления URL-адресов HTTP на своих коллег HTTPS. При наличии этой аннотации и правильной настройке TLS, контроллер входящего трафика Kubernetes создает правило маршрутизации с настройками перенаправления. Затем контроллер применяет изменения к вашему экземпляру шлюза приложений. Созданное перенаправление — HTTP 301 Moved Permanently.
Использование
appgw.ingress.kubernetes.io/ssl-redirect: "true"
Пример
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: go-server-ingress-redirect
annotations:
kubernetes.io/ingress.class: azure/application-gateway
appgw.ingress.kubernetes.io/ssl-redirect: "true"
spec:
tls:
- hosts:
- www.contoso.com
secretName: testsecret-tls
rules:
- host: www.contoso.com
http:
paths:
- backend:
service:
name: websocket-repeater
port:
number: 80
Завершение подключений
Используйте следующие аннотации, если хотите применить отвод подключений.
-
connection-draining: эта заметка указывает, следует ли включить очистку подключений. -
connection-draining-timeout: эта заметка указывает время ожидания, после которого Шлюз приложений завершает запросы к осушившей серверной конечной точке.
Использование
appgw.ingress.kubernetes.io/connection-draining: "true"
appgw.ingress.kubernetes.io/connection-draining-timeout: "60"
Пример
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: go-server-ingress-drain
annotations:
kubernetes.io/ingress.class: azure/application-gateway
appgw.ingress.kubernetes.io/connection-draining: "true"
appgw.ingress.kubernetes.io/connection-draining-timeout: "60"
spec:
rules:
- http:
paths:
- path: /hello/
pathType: Exact
backend:
service:
name: go-server-service
port:
number: 80
Привязанность на основе файлов cookie
Используйте следующую аннотацию, чтобы включить привязку на основе файлов cookie.
Использование
appgw.ingress.kubernetes.io/cookie-based-affinity: "true"
Пример
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: go-server-ingress-affinity
annotations:
kubernetes.io/ingress.class: azure/application-gateway
appgw.ingress.kubernetes.io/cookie-based-affinity: "true"
spec:
rules:
- http:
paths:
- path: /hello/
pathType: Exact
backend:
service:
name: go-server-service
port:
number: 80
Истекло время ожидания запроса
Используйте следующую заметку, чтобы указать время ожидания запроса в секундах. После истечения времени ожидания Шлюз приложений завершает запрос, если ответ не получен.
Использование
appgw.ingress.kubernetes.io/request-timeout: "20"
Пример
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: go-server-ingress-timeout
annotations:
kubernetes.io/ingress.class: azure/application-gateway
appgw.ingress.kubernetes.io/request-timeout: "20"
spec:
rules:
- http:
paths:
- path: /hello/
pathType: Exact
backend:
service:
name: go-server-service
port:
number: 80
Использование частного IP-адреса
Используйте следующую аннотацию, чтобы указать, следует ли выставлять эту конечную точку на частном IP-адресе шлюза приложений.
Для экземпляра шлюза приложений, который не имеет частного IP-адреса, входы с appgw.ingress.kubernetes.io/use-private-ip: "true" игнорируются. Журналы контроллера и события входящего трафика для этих входящего трафика отображают NoPrivateIP предупреждение.
Использование
appgw.ingress.kubernetes.io/use-private-ip: "true"
Пример
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: go-server-ingress-privateip
annotations:
kubernetes.io/ingress.class: azure/application-gateway
appgw.ingress.kubernetes.io/use-private-ip: "true"
spec:
rules:
- http:
paths:
- path: /
pathType: Exact
backend:
service:
name: go-server-service
port:
number: 80
Переопределение порта фронт-энда
Используйте следующую заметку, чтобы настроить внешний прослушиватель для использования портов, отличных от 80 для HTTP и 443 для HTTPS.
Если порт находится в пределах авторизованного диапазона Application Gateway (от 1 до 64999), прослушиватель создается на этом конкретном порту. Если в заметке задан недопустимый порт или нет порта, конфигурация использует значение по умолчанию 80 или 443.
Использование
appgw.ingress.kubernetes.io/override-frontend-port: "port"
Пример
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: go-server-ingress-overridefrontendport
annotations:
kubernetes.io/ingress.class: azure/application-gateway
appgw.ingress.kubernetes.io/override-frontend-port: "8080"
spec:
rules:
- http:
paths:
- path: /hello/
backend:
service:
name: store-service
port:
number: 80
pathType: Exact
Примечание.
Внешние запросы должны быть целевыми http://somehost:8080 вместо http://somehost.
Серверный протокол
Используйте следующее, чтобы указать протокол, который Шлюз приложений должен использовать при обмене данными с подами. Поддерживаются протоколы HTTP и HTTPS.
Хотя самозаверяющие сертификаты поддерживаются в шлюзе приложений, AGIC в настоящее время поддерживает HTTPS только в том случае, если поды используют сертификат, подписанный известным центром сертификации.
Не используйте порт 80 с HTTPS и порт 443 с HTTP на подах.
Использование
appgw.ingress.kubernetes.io/backend-protocol: "https"
Пример
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: go-server-ingress-timeout
annotations:
kubernetes.io/ingress.class: azure/application-gateway
appgw.ingress.kubernetes.io/backend-protocol: "https"
spec:
rules:
- http:
paths:
- path: /
pathType: Exact
backend:
service:
name: go-server-service
port:
number: 443
Расширение имени узла
Вы можете настроить Шлюз приложений для принятия различных имен хостов. Используйте аннотацию hostname-extension для определения нескольких имен узлов, включая подстановочные имена узлов. Это действие добавляет имена узлов в полное доменное имя, определенное в сведениях о входящего spec.rules.host трафика на интерфейсном прослушивателе, поэтому он настроен в качестве многосайтового прослушивателя.
Использование
appgw.ingress.kubernetes.io/hostname-extension: "hostname1, hostname2"
Пример
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: go-server-ingress-multisite
annotations:
kubernetes.io/ingress.class: azure/application-gateway
appgw.ingress.kubernetes.io/hostname-extension: "hostname1, hostname2"
spec:
rules:
- host: contoso.com
http:
paths:
- path: /
pathType: Exact
backend:
service:
name: go-server-service
port:
number: 443
В предыдущем примере слушатель настраивается для приема трафика для имен узлов hostname1.contoso.com и hostname2.contoso.com.
Политика WAF для пути
Используйте следующую заметку, чтобы подключить существующую политику брандмауэра веб-приложения (WAF) к путям списка для узла в ресурсе входящего трафика Kubernetes, который заносится в заметки. Политика WAF применяется как к URL-адресам, так /ad-server и /auth к URL-адресам.
Использование
appgw.ingress.kubernetes.io/waf-policy-for-path: "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/SampleRG/providers/Microsoft.Network/applicationGatewayWebApplicationFirewallPolicies/AGICWAFPolcy"
Пример
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: ad-server-ingress
annotations:
kubernetes.io/ingress.class: azure/application-gateway
appgw.ingress.kubernetes.io/waf-policy-for-path: "/subscriptions/abcd/resourceGroups/rg/providers/Microsoft.Network/applicationGatewayWebApplicationFirewallPolicies/adserver"
spec:
rules:
- http:
paths:
- path: /ad-server
backend:
service:
name: ad-server
port:
number: 80
pathType: Exact
- path: /auth
backend:
service:
name: auth-server
port:
number: 80
pathType: Exact
SSL-сертификат Шлюз приложений
SSL-сертификат можно настроить для Шлюза приложений из локального файла сертификата PFX или ссылки на неверсионированный секретный идентификатор Azure Key Vault. Если заметка присутствует с именем сертификата и сертификат предварительно установлен в Шлюз приложений, контроллер входящего трафика Kubernetes создает правило маршрутизации с прослушивателем HTTPS и применяет изменения к экземпляру Шлюз приложений. Вы также можете использовать заметку appgw-ssl-certificate вместе с заметкой ssl-redirect в случае перенаправления SSL.
Примечание.
appgw-ssl-certificate Заметка игнорируется, если спецификация TLS определена входящего трафика одновременно. Если требуется разные сертификаты с разными узлами (завершение нескольких сертификатов TLS), необходимо определить различные ресурсы входящего трафика.
Использование
appgw.ingress.kubernetes.io/appgw-ssl-certificate: "name-of-appgw-installed-certificate"
Пример
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: go-server-ingress-certificate
annotations:
kubernetes.io/ingress.class: azure/application-gateway
appgw.ingress.kubernetes.io/appgw-ssl-certificate: "name-of-appgw-installed-certificate"
spec:
rules:
- host: www.contoso.com
http:
paths:
- backend:
service:
name: websocket-repeater
port:
number: 80
профиль SSL Шлюз приложений
Профиль SSL можно настроить на экземпляре Шлюз приложений на прослушиватель. Когда аннотация присутствует с именем профиля и профиль предварительно установлен в Application Gateway, контроллер входного трафика Kubernetes создает правило маршрутизации с HTTPS-слушателем и применяет изменения к вашему экземпляру Application Gateway.
Использование
appgw.ingress.kubernetes.io/appgw-ssl-certificate: "name-of-appgw-installed-certificate"
appgw.ingress.kubernetes.io/appgw-ssl-profile: "SampleSSLProfile"
Пример
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: go-server-ingress-certificate
annotations:
kubernetes.io/ingress.class: azure/application-gateway
appgw.ingress.kubernetes.io/appgw-ssl-certificate: "name-of-appgw-installed-certificate"
appgw.ingress.kubernetes.io/appgw-ssl-profile: "SampleSSLProfile"
spec:
rules:
- host: www.contoso.com
http:
paths:
- backend:
service:
name: websocket-repeater
port:
number: 80
Доверенный корневой сертификат шлюза приложений
Теперь вы можете настроить собственные корневые сертификаты, чтобы они стали доверенными для Шлюза приложений при помощи AGIC. Вы можете использовать заметку appgw-trusted-root-certificate вместе с заметкой backend-protocol , чтобы указать сквозное шифрование SSL. Если указать несколько корневых сертификатов, разделите их запятыми; например, name-of-my-root-cert1,name-of-my-root-cert2.
Использование
appgw.ingress.kubernetes.io/backend-protocol: "https"
appgw.ingress.kubernetes.io/appgw-trusted-root-certificate: "name-of-my-root-cert1"
Пример
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: go-server-ingress-certificate
annotations:
kubernetes.io/ingress.class: azure/application-gateway
appgw.ingress.kubernetes.io/backend-protocol: "https"
appgw.ingress.kubernetes.io/appgw-trusted-root-certificate: "name-of-my-root-cert1"
spec:
rules:
- host: www.contoso.com
http:
paths:
- backend:
service:
name: websocket-repeater
port:
number: 80
Переопределение набора правил
Используйте следующую заметку, чтобы назначить существующее правило перезаписи соответствующему правилу маршрутизации запросов.
Использование
appgw.ingress.kubernetes.io/rewrite-rule-set: <rewrite rule set name>
Пример
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: go-server-ingress-bkprefix
annotations:
kubernetes.io/ingress.class: azure/application-gateway
appgw.ingress.kubernetes.io/rewrite-rule-set: add-custom-response-header
spec:
rules:
- http:
paths:
- path: /
pathType: Exact
backend:
service:
name: go-server-service
port:
number: 8080
Перезапись ресурса настраиваемого набора правил
Примечание.
В выпуске Шлюз приложений для контейнеров представлено множество изменений производительности, устойчивости и функций. Рассмотрите использование шлюза приложений для контейнеров при следующем развертывании.
Правила переписывания URL для Application Gateway for Containers можно найти в этой статье о Gateway API и этой статье о Ingress API. Вы можете найти правила перезаписи заголовков для Шлюза приложений для контейнеров в этой статье об API шлюза.
Шлюз приложений позволяет переписать выбранное содержимое запросов и ответов. С помощью этой функции можно преобразовать URL-адреса, изменить параметры строки запроса и изменить заголовки запросов и ответов. Эту функцию можно также использовать для добавления условий, чтобы убедиться, что URL-адрес или указанные заголовки перезаписываются только при выполнении определенных условий. Ресурс пользовательского набора правил для перезаписи добавляет эту функцию в AGIC.
HTTP-заголовки позволяют клиенту и серверу передавать дополнительную информацию вместе с запросом или ответом. Перезаписав эти заголовки, можно выполнить важные задачи, такие как добавление полей заголовков, связанных с безопасностью (например, HSTS или X-XSS-Protection), удаление полей заголовков ответа, которые могут отображать конфиденциальную информацию и удалять сведения о портах из X-Forwarded-For заголовков.
С помощью возможности перезаписи URL-адресов можно:
- Переопределите имя узла, путь и строку запроса URL-адреса запроса.
- Выберите переписать URL-адрес всех запросов или только запросов, которые соответствуют одному или нескольким заданным условиям. Эти условия основаны на свойствах запроса и ответа (заголовок запроса, заголовок ответа и переменные сервера).
- Решите, как маршрутизировать запрос на основе или исходного, или переписанного URL-адреса.
Примечание.
Эта функция поддерживается с версии 1.6.0-rc1. Используйте appgw.ingress.kubernetes.io/rewrite-rule-set, что позволяет использовать существующий набор правил перезаписи на Шлюзе приложений.
Использование
appgw.ingress.kubernetes.io/rewrite-rule-set-custom-resource
Пример
apiVersion: appgw.ingress.azure.io/v1beta1
kind: AzureApplicationGatewayRewrite
metadata:
name: my-rewrite-rule-set-custom-resource
spec:
rewriteRules:
- name: rule1
ruleSequence: 21
conditions:
- ignoreCase: false
negate: false
variable: http_req_Host
pattern: example.com
actions:
requestHeaderConfigurations:
- actionType: set
headerName: incoming-test-header
headerValue: incoming-test-value
responseHeaderConfigurations:
- actionType: set
headerName: outgoing-test-header
headerValue: outgoing-test-value
urlConfiguration:
modifiedPath: "/api/"
modifiedQueryString: "query=test-value"
reroute: false
Приоритет правил
Следующая заметка позволяет контроллеру входящего трафика Шлюз приложений явно задать приоритет связанных правил маршрутизации запросов.
Использование
appgw.ingress.kubernetes.io/rule-priority:
Пример
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: go-server-ingress-rulepriority
annotations:
kubernetes.io/ingress.class: azure/application-gateway
appgw.ingress.kubernetes.io/rule-priority: 10
spec:
rules:
- http:
paths:
- path: /
pathType: Exact
backend:
service:
name: go-server-service
port:
number: 8080
В предыдущем примере задан приоритет 10 для правила маршрутизации запросов.