Интеграция сетки служб с шлюзом приложений для контейнеров

Сервисные сетки обрабатывают восточно-западный трафик между службами и часто используют взаимный TLS (mTLS) для обеспечения безопасности. Если службам требуется внешний доступ (северо-южный трафик), шлюз входящего трафика упрощает подключение. Шлюз приложений для контейнеров предоставляет расширение сетки служб, которое автоматизирует управление жизненным циклом сертификатов и снижает сложность конфигурации.

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

Чтобы упростить взаимодействие с сеткой служб из-за пределов кластера Kubernetes, шлюз приложений для контейнеров (Application Gateway for Containers) имеет дополнительное расширение сетки служб, которое можно установить вместе с контроллером приложения балансировки нагрузки (ALB). Это расширение может значительно снизить эксплуатационные издержки, автоматив управление жизненным циклом сертификатов и упростить настройку входящего трафика.

Ниже приведена схема интеграции шлюза приложений для контейнеров с сеткой служб Istio.

Расширение сервисной сетки для контроллера ALB

Расширение контроллера ALB Istio состоит из двух pod'ов, развернутых в активной / резервной конфигурации, чтобы обеспечить устойчивость во время сбоя узла, управлять жизненным циклом сертификатов между шлюзом приложений для контейнеров и Istio, а также автоматически обрабатывать конфигурацию mTLS для служб, участвующих в сетке служб.

Установка расширения сетки службы контроллера ALB для Istio

Установите расширение сетки сервисов ALB Controller с помощью диаграммы Helm после развертывания контроллера ALB (надстройка или Helm). Расширение сетки службы контроллера ALB устанавливается с помощью отдельной диаграммы helm.

Команда Helm, приведённая ниже, может использоваться для установки расширения.

HELM_NAMESPACE='<namespace for deployment>'
CONTROLLER_NAMESPACE='azure-alb-system'
RESOURCE_GROUP='<your resource group name>'
AKS_NAME='<your aks cluster name>'

az aks get-credentials --resource-group $RESOURCE_GROUP --name $AKS_NAME

helm install alb-controller-servicemesh-extension oci://mcr.microsoft.com/application-lb/charts/alb-controller-servicemesh-extension \
     --namespace $HELM_NAMESPACE \
     --version 1.11.1

Проверка установки контроллера балансировки нагрузки

Убедитесь, что поды расширения службы ALB Controller готовы, как указано префиксом alb-controller-istio-extension.

kubectl get pods -n azure-alb-system

Вы увидите следующие выходные данные:

Интеграция с Istio

Шлюз приложений для контейнеров поддерживает интеграцию с Istio версии 1.24 и более поздней.

После установки расширения сетки контроллера контроллера ALB, если Istio установлен, интеграция сетки служб попытается подготовить боковую панель для интеграции с сеткой.

Если до Istio установлена сетка службы контроллера ALB, необходимо перезапустить развертывание расширения сетки службы контроллеров ALB. Перезапуск развертывания сетки службы контроллера балансировки нагрузки можно выполнить с помощью команды: kubectl rollout restart deployment/alb-controller-istio-extension

Маршрутизация трафика в сетку служб Istio

Выполните следующие пять действий, чтобы настроить сетку служб Istio с помощью шлюза приложений для контейнеров:

• Определение пространства имен для сайдкар-внедрения в Istio
• Включение mTLS для служб в этом пространстве имен
• Развертывание примера приложения для тестирования (необязательно)
• Определение ресурса шлюза
• Определение ресурса HTTPRoute

Определение пространства имен

В зависимости от того, как установлен Istio, необходимо настроить метку конфигурации, используемую для включения сайдкара Istio.

apiVersion: v1
kind: Namespace
metadata:
  name: test-infra
  labels:
    istio-injection: enabled

kubectl get configmap -n aks-istio-system | grep asm-

istio-asm-1-27                        2      90m
istio-sidecar-injector-asm-1-27       2      90m

az aks show --resource-group <rg> --name <cluster> --query "serviceMeshProfile"

{
  "istio": {
    "certificateAuthority": null,
    "components": {
      "egressGateways": null,
      "ingressGateways": [
        {
          "enabled": null,
          "mode": "Internal"
        },
        {
          "enabled": null,
          "mode": "External"
        }
      ]
    },
    "revisions": [
      "asm-1-27"
    ]
  },
  "mode": "Istio"
}

apiVersion: v1
kind: Namespace
metadata:
  name: test-infra
  labels:
    istio.io/rev: asm-1-27 # Istio version obtained previously

Включите обработку mTLS для служб в пространстве имен

В этом примере мы определим настраиваемый PeerAuthentication ресурс Istio, чтобы требовать mTLS для входящих подключений к службам в test-infra пространстве имен.

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: test-infra
spec:
  mtls:
    mode: STRICT

Развертывание примера приложения (необязательно)

На этом шаге мы подготовим некоторые тестовые ресурсы, чтобы проверить комплексный сценарий. Если у вас есть собственное приложение, этот шаг можно пропустить.

Примените следующий файл deployment.yaml в кластере, чтобы создать пример веб-приложения, чтобы продемонстрировать отправку трафика в часть приложения сетки службы Istio.

kubectl apply -f https://raw.githubusercontent.com/MicrosoftDocs/azure-docs/refs/heads/main/articles/application-gateway/for-containers/examples/traffic-split-scenario/deployment.yaml

Эта команда создает следующее в вашем кластере:

• Пространство имен с именем test-infra
• Две службы, называются backend-v1, backend-v2, в пространстве имен test-infra
• Два развертывания, называются backend-v1 и backend-v2 в пространстве имен test-infra

Определение ресурса шлюза

kubectl apply -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: gateway-01
  namespace: test-infra
  annotations:
    alb.networking.azure.io/alb-namespace: alb-test-infra
    alb.networking.azure.io/alb-name: alb-test
spec:
  gatewayClassName: azure-alb-external
  listeners:
  - name: http
    port: 80
    protocol: HTTP
    allowedRoutes:
      namespaces:
        from: All
EOF

После создания ресурса шлюза убедитесь, что состояние действительно, слушатель запрограммирован, и шлюзу назначен адрес.

kubectl get gateway gateway-01 -n test-infra -o yaml

Пример выходных данных успешного создания шлюза.

status:
  addresses:
  - type: Hostname
    value: xxxx.yyyy.alb.azure.com
  conditions:
  - lastTransitionTime: "2023-06-19T21:04:55Z"
    message: Valid Gateway
    observedGeneration: 1
    reason: Accepted
    status: "True"
    type: Accepted
  - lastTransitionTime: "2023-06-19T21:04:55Z"
    message: Application Gateway For Containers resource has been successfully updated.
    observedGeneration: 1
    reason: Programmed
    status: "True"
    type: Programmed
  listeners:
  - attachedRoutes: 0
    conditions:
    - lastTransitionTime: "2023-06-19T21:04:55Z"
      message: ""
      observedGeneration: 1
      reason: ResolvedRefs
      status: "True"
      type: ResolvedRefs
    - lastTransitionTime: "2023-06-19T21:04:55Z"
      message: Listener is accepted
      observedGeneration: 1
      reason: Accepted
      status: "True"
      type: Accepted
    - lastTransitionTime: "2023-06-19T21:04:55Z"
      message: Application Gateway For Containers resource has been successfully updated.
      observedGeneration: 1
      reason: Programmed
      status: "True"
      type: Programmed
    name: gateway-01-http
    supportedKinds:
    - group: gateway.networking.k8s.io
      kind: HTTPRoute

Определение ресурса HTTPRoute

После создания шлюза создайте HTTPRoute

kubectl apply -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: traffic-split-mesh-route
  namespace: test-infra
spec:
  parentRefs:
  - name: gateway-01
    namespace: test-infra
  rules:
  - backendRefs:
    - name: backend-v1
      port: 8080
EOF

После создания ресурса HTTPRoute убедитесь, что маршрут принимается, а ресурс Шлюз приложений для контейнеров запрограммирован.

kubectl get httproute traffic-split-mesh-route -n test-infra -o yaml

Убедитесь, что состояние ресурса Шлюз приложений для контейнеров успешно обновлено.

status:
  parents:
  - conditions:
    - lastTransitionTime: "2023-06-19T22:18:23Z"
      message: ""
      observedGeneration: 1
      reason: ResolvedRefs
      status: "True"
      type: ResolvedRefs
    - lastTransitionTime: "2023-06-19T22:18:23Z"
      message: Route is Accepted
      observedGeneration: 1
      reason: Accepted
      status: "True"
      type: Accepted
    - lastTransitionTime: "2023-06-19T22:18:23Z"
      message: Application Gateway For Containers resource has been successfully updated.
      observedGeneration: 1
      reason: Programmed
      status: "True"
      type: Programmed
    controllerName: alb.networking.azure.io/alb-controller
    parentRef:
      group: gateway.networking.k8s.io
      kind: Gateway
      name: gateway-01
      namespace: test-infra

Проверка доступа к приложению.

Теперь мы готовы отправить определённый трафик к нашему примерному приложению через полное доменное имя, назначенное фронтенду. Чтобы получить полное доменное имя, используйте следующую команду:

fqdn=$(kubectl get gateway gateway-01 -n test-infra -o jsonpath='{.status.addresses[0].value}')

Для выполнения команды curl с использованием данного FQDN должны возвращаться ответы от серверов или подов, как настроено в HTTPRoute.

curl http://$fqdn

Затем давайте удалим ресурс PeerAuthentication, чтобы имитировать удаление MTLS.

kubectl delete PeerAuthentication default -n test-infra

При повторном выполнении команды curl вы увидите код ответа HTTP 503, указывающий на сбой согласования mTLS между шлюзом приложений для контейнеров и тестируемым приложением (так как тестовое приложение больше не ожидает взаимной проверки подлинности).

Pricing

Включение интеграции сервисной сетки осуществляется без дополнительной платы.

Ограничения

• API Ingress не поддерживается; рассмотрите возможность миграции на Gateway API.