Поделиться через


Пометки для Ingress Controller шлюза приложений

Вы можете аннотировать ресурс входа 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 string nil
appgw.ingress.kubernetes.io/backend-hostname string nil
appgw.ingress.kubernetes.io/health-probe-hostname string 127.0.0.1
appgw.ingress.kubernetes.io/health-probe-port int32 80
appgw.ingress.kubernetes.io/health-probe-path string /
appgw.ingress.kubernetes.io/health-probe-status-codes string 200-399
appgw.ingress.kubernetes.io/health-probe-interval int32 30 (секунд)
appgw.ingress.kubernetes.io/health-probe-timeout int32 30 (секунд)
appgw.ingress.kubernetes.io/health-probe-unhealthy-threshold int32 3
appgw.ingress.kubernetes.io/ssl-redirect bool false
appgw.ingress.kubernetes.io/connection-draining bool false
appgw.ingress.kubernetes.io/connection-draining-timeout int32 (секунд) 30
appgw.ingress.kubernetes.io/use-private-ip bool false
appgw.ingress.kubernetes.io/override-frontend-port bool false
appgw.ingress.kubernetes.io/cookie-based-affinity bool false
[appgw.ingress.kubernetes.io/request-timeout]
(время ожидания запроса) int32 (секунд) 30
appgw.ingress.kubernetes.io/use-private-ip bool false
appgw.ingress.kubernetes.io/backend-protocol string http http, https
appgw.ingress.kubernetes.io/hostname-extension string nil
appgw.ingress.kubernetes.io/waf-policy-for-path string nil
appgw.ingress.kubernetes.io/appgw-ssl-certificate string nil
appgw.ingress.kubernetes.io/appgw-ssl-profile string nil
appgw.ingress.kubernetes.io/appgw-trusted-root-certificate string nil
appgw.ingress.kubernetes.io/rewrite-rule-set string nil
appgw.ingress.kubernetes.io/rewrite-rule-set-custom-resource
appgw.ingress.kubernetes.io/rule-priority int32 nil

Префикс пути к серверной части

Следующая заметка позволяет переписать внутренний путь, указанный в ресурсе входящего трафика с указанным префиксом. Используйте его для предоставления служб, конечные точки которых отличаются от имен, используемых для их описания в ресурсе входа.

Использование

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.

Использование

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 для правила маршрутизации запросов.

Дальнейшие действия