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

Создание неуправляемого контроллера входящего трафика

Сводка

Контроллер входа является программным компонентом, который предоставляет для служб Kubernetes обратный прокси, настраиваемую маршрутизацию трафика и завершение TLS-соединений. Используйте ресурсы входящего трафика Kubernetes для настройки правил входящего трафика и маршрутов для отдельных служб Kubernetes. При использовании контроллера входящего трафика и правил входящего трафика можно использовать один IP-адрес для маршрутизации трафика в несколько служб в кластере Kubernetes.

В этой статье описывается, как установить и настроить контроллер входящего трафика NGINX в кластере Службы Azure Kubernetes (AKS). Затем вы запускаете два приложения в кластере AKS, и каждое приложение доступно по одному IP-адресу.

Внимание

Для входа в AKS используйте надстройку маршрутизации приложений. Дополнительные сведения см. в статье Managed nginx Ingress с надстройкой маршрутизации приложений.

Примечание.

Два контроллера входящего трафика с открытым кодом для Kubernetes основаны на NGINX: один поддерживается сообществом Kubernetes (kubernetes/ingress-nginx), а один поддерживается NGINX, Inc. (nginxinc/kubernetes-ingress). В этой статье используется контроллер входящего трафика сообщества Kubernetes.

Перед началом работы

  • В этой статье используется Helm 3 для установки контроллера входящего трафика NGINX в поддерживаемой версии Kubernetes. Убедитесь, что вы используете последний выпуск Helm и имеете доступ к репозиторию Helm ingress-nginx. Действия, описанные в этой статье, могут быть несовместимы с предыдущими версиями диаграммы Helm, контроллера входящего трафика NGINX или Kubernetes.
  • В этой статье предполагается наличие у вас существующего кластера AKS с интегрированной записью в реестре контейнеров Azure (ACR). Дополнительные сведения о создании кластера AKS с интегрированным ACR см. в статье "Проверка подлинности с помощью реестра контейнеров Azure" из службы Azure Kubernetes.
  • Конечная точка работоспособности API Kubernetes, healthz, устарела в версии 1.16 Kubernetes. Можно заменить эту конечную точку на конечные точки livez и readyz. См. конечные точки API Kubernetes для проверки работоспособности, чтобы определить, какую конечную точку использовать в вашем сценарии.
  • Если вы используете Azure CLI, эта статья требует, чтобы вы использовали Azure CLI версии 2.0.64 или более поздней. Чтобы узнать версию, выполните команду az --version. Если вам нужно установить или обновить, см. статью [Установка Azure CLI][azure-cli-install].
  • Если вы используете Azure PowerShell, в этой статье требуется, чтобы вы работали с Azure PowerShell версии 5.9.0 или более поздней. Чтобы узнать версию, выполните команду Get-InstalledModule -Name Az. Если вам необходимо выполнить установку или обновление, см. статью об установке Azure PowerShell.

Базовая конфигурация контроллера входящего трафика

Чтобы создать базовый контроллер входящего трафика NGINX без настройки значений по умолчанию, используйте Helm. Следующая конфигурация использует конфигурацию по умолчанию для простоты. Можно добавить параметры для настройки развертывания, например --set controller.replicaCount=3.

Примечание.

Чтобы включить сохранение IP-адресов источника клиента для запросов к контейнерам в кластере, добавьте --set controller.service.externalTrafficPolicy=Local в команду установки Helm. Исходный IP-адрес клиента хранится в заголовке запроса в разделе X-Forwarded-For. При использовании контроллера входящего трафика с включенным сохранением IP-адресов источника клиента сквозная передача TLS не будет работать.

NAMESPACE=ingress-basic

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update

helm install ingress-nginx ingress-nginx/ingress-nginx \
  --create-namespace \
  --namespace $NAMESPACE \
  --set controller.service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-health-probe-request-path"=/healthz \
  --set controller.service.externalTrafficPolicy=Local

Примечание.

В этом руководстве установите service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path на значение /healthz. Этот параметр означает, что если код ответа для запросов к /healthz не является 200, весь контроллер входящего трафика останавливается. Вы можете изменить значение на другой URI, чтобы он соответствовал вашему сценарию. Вы не можете удалить эту часть или отменить определение значения, иначе остановится контроллер входного трафика. Пакет ingress-nginx, используемый в этом учебном пособии и предоставляемый официальными источниками Kubernetes, всегда возвращает 200 ответный код для запросов /healthz. Он разработан как серверная часть по умолчанию, чтобы пользователи могли быстро приступить к работе, если только правило входа не изменит это.

Настраиваемая конфигурация контроллера входящего трафика

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

Импортируйте изображения, используемые Helm-чартом, в ваш ACR

Чтобы управлять версиями образов, импортируйте их в собственный реестр контейнеров Azure. В чарте Helm контроллера ingress NGINX используются три образа контейнеров. Для импорта этих образов в ACR используйте команду az acr import.

REGISTRY_NAME=<REGISTRY_NAME>
SOURCE_REGISTRY=registry.k8s.io
CONTROLLER_IMAGE=ingress-nginx/controller
CONTROLLER_TAG=v1.8.1
PATCH_IMAGE=ingress-nginx/kube-webhook-certgen
PATCH_TAG=v20230407
DEFAULTBACKEND_IMAGE=defaultbackend-amd64
DEFAULTBACKEND_TAG=1.5

az acr import --name $REGISTRY_NAME --source $SOURCE_REGISTRY/$CONTROLLER_IMAGE:$CONTROLLER_TAG --image $CONTROLLER_IMAGE:$CONTROLLER_TAG
az acr import --name $REGISTRY_NAME --source $SOURCE_REGISTRY/$PATCH_IMAGE:$PATCH_TAG --image $PATCH_IMAGE:$PATCH_TAG
az acr import --name $REGISTRY_NAME --source $SOURCE_REGISTRY/$DEFAULTBACKEND_IMAGE:$DEFAULTBACKEND_TAG --image $DEFAULTBACKEND_IMAGE:$DEFAULTBACKEND_TAG

Примечание.

Помимо импорта в ACR образов контейнеров, туда также можно импортировать чарты Helm. Дополнительные сведения см. в статье Отправка чартов Helm в Реестр контейнеров Azure и их извлечение оттуда.

Создание контроллера входящего трафика

Чтобы создать контроллер входящего трафика, используйте Helm для установки ingress-nginx. Контроллер Ingress необходимо разместить на узле Linux. Узлы Windows Server не должны запускать контроллер Ingress. Укажите селектор узлов с помощью --set nodeSelector параметра, чтобы сообщить планировщику Kubernetes запустить контроллер входящего трафика NGINX на узле под управлением Linux.

Для обеспечения избыточности разверните две реплики контроллеров входящего трафика NGINX с помощью --set controller.replicaCount параметра. Чтобы максимально эффективно использовать реплики контроллера внешнего доступа, убедитесь, что в кластере AKS больше одного узла.

В следующем примере создается пространство имен Kubernetes для ресурсов Ingress с именем ingress-basic, и оно предназначено для работы в этом пространстве имен. Укажите пространство имен для своего собственного окружения по мере необходимости. Если ваш кластер AKS не поддерживает управление доступом на основе ролей Kubernetes, добавьте строку --set rbac.create=false в команды Helm.

Примечание.

Чтобы включить сохранение IP-адресов источника клиента для запросов к контейнерам в кластере, добавьте --set controller.service.externalTrafficPolicy=Local в команду установки Helm. Исходный IP-адрес клиента хранится в заголовке запроса в разделе X-Forwarded-For. При использовании контроллера входящего трафика с включенным сохранением IP-адресов источника клиента сквозная передача TLS не будет работать.

# Add the ingress-nginx repository
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update

# Set variable for ACR location to use for pulling images
ACR_LOGIN_SERVER=<REGISTRY_LOGIN_SERVER>

# Use Helm to deploy an NGINX ingress controller
helm install ingress-nginx ingress-nginx/ingress-nginx \
    --version 4.7.1 \
    --namespace ingress-basic \
    --create-namespace \
    --set controller.replicaCount=2 \
    --set controller.nodeSelector."kubernetes\.io/os"=linux \
    --set controller.image.registry=$ACR_LOGIN_SERVER \
    --set controller.image.image=$CONTROLLER_IMAGE \
    --set controller.image.tag=$CONTROLLER_TAG \
    --set controller.image.digest="" \
    --set controller.admissionWebhooks.patch.nodeSelector."kubernetes\.io/os"=linux \
    --set controller.service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-health-probe-request-path"=/healthz \
    --set controller.service.externalTrafficPolicy=Local \
    --set controller.admissionWebhooks.patch.image.registry=$ACR_LOGIN_SERVER \
    --set controller.admissionWebhooks.patch.image.image=$PATCH_IMAGE \
    --set controller.admissionWebhooks.patch.image.tag=$PATCH_TAG \
    --set controller.admissionWebhooks.patch.image.digest="" \
    --set defaultBackend.nodeSelector."kubernetes\.io/os"=linux \
    --set defaultBackend.image.registry=$ACR_LOGIN_SERVER \
    --set defaultBackend.image.image=$DEFAULTBACKEND_IMAGE \
    --set defaultBackend.image.tag=$DEFAULTBACKEND_TAG \
    --set defaultBackend.image.digest=""

Создание контроллера входящего трафика с помощью внутреннего IP-адреса

По умолчанию контроллер входящего трафика NGINX использует динамический общедоступный IP-адрес. Однако может потребоваться использовать внутреннюю, частную сеть и IP-адрес. Этот подход ограничивает доступ к службам внутренним пользователям без внешнего доступа.

Используйте параметры --set controller.service.loadBalancerIP и --set controller.service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-internal"=true, чтобы назначить внутренний IP-адрес Ingress контроллеру. Укажите собственный внутренний IP-адрес для контроллера входящего трафика. Убедитесь, что этот IP-адрес не используется в вашей виртуальной сети. Если вы используете существующую виртуальную сеть и подсеть, необходимо настроить кластер AKS с правильными разрешениями для управления виртуальной сетью и подсетью. Дополнительные сведения см. в статьях Использование сети kubenet с пользовательскими диапазонами IP-адресов в службе Azure Kubernetes (AKS) и Настройка сети Azure CNI в службе Azure Kubernetes (AKS).

# Add the ingress-nginx repository
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update

# Set variable for ACR location to use for pulling images
ACR_LOGIN_SERVER=<REGISTRY_LOGIN_SERVER>

# Use Helm to deploy an NGINX ingress controller
helm install ingress-nginx ingress-nginx/ingress-nginx \
    --version 4.7.1 \
    --namespace ingress-basic \
    --create-namespace \
    --set controller.replicaCount=2 \
    --set controller.nodeSelector."kubernetes\.io/os"=linux \
    --set controller.image.registry=$ACR_LOGIN_SERVER \
    --set controller.image.image=$CONTROLLER_IMAGE \
    --set controller.image.tag=$CONTROLLER_TAG \
    --set controller.image.digest="" \
    --set controller.admissionWebhooks.patch.nodeSelector."kubernetes\.io/os"=linux \
    --set controller.service.loadBalancerIP=10.224.0.42 \
    --set controller.service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-internal"=true \
    --set controller.service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-health-probe-request-path"=/healthz \
    --set controller.admissionWebhooks.patch.image.registry=$ACR_LOGIN_SERVER \
    --set controller.admissionWebhooks.patch.image.image=$PATCH_IMAGE \
    --set controller.admissionWebhooks.patch.image.tag=$PATCH_TAG \
    --set controller.admissionWebhooks.patch.image.digest="" \
    --set defaultBackend.nodeSelector."kubernetes\.io/os"=linux \
    --set defaultBackend.image.registry=$ACR_LOGIN_SERVER \
    --set defaultBackend.image.image=$DEFAULTBACKEND_IMAGE \
    --set defaultBackend.image.tag=$DEFAULTBACKEND_TAG \
    --set defaultBackend.image.digest=""

Проверка службы подсистемы балансировки нагрузки входящего трафика

Проверьте службу подсистемы балансировки нагрузки с помощью kubectl get services.

kubectl get services --namespace ingress-basic -o wide -w ingress-nginx-controller

При создании службы подсистемы балансировки нагрузки Kubernetes для контроллера входящего трафика NGINX он назначает IP-адрес в разделе EXTERNAL-IP, как показано в следующем примере выходных данных:

NAME                       TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)                      AGE   SELECTOR
ingress-nginx-controller   LoadBalancer   10.0.65.205   EXTERNAL-IP     80:30957/TCP,443:32414/TCP   1m   app.kubernetes.io/component=controller,app.kubernetes.io/instance=ingress-nginx,app.kubernetes.io/name=ingress-nginx

При переходе к внешнему IP-адресу на этом этапе отображается 404-страница. Этот ответ появляется, так как вам по-прежнему нужно настроить подключение к внешнему IP-адресу, который выполняется в следующих разделах.

Запуск демонстрационных приложений для тестирования входящего трафика

Чтобы увидеть контроллер входящего трафика в действии, запустите два демонстрационных приложения в кластере AKS. В этом примере используется kubectl apply для развертывания двух экземпляров простого приложения Hello world .

  1. Создайте файл aks-helloworld-one.yaml и скопируйте в него следующий пример кода YAML.

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: aks-helloworld-one  
spec:
  replicas: 1
  selector:
    matchLabels:
      app: aks-helloworld-one
  template:
    metadata:
      labels:
        app: aks-helloworld-one
    spec:
      containers:
      - name: aks-helloworld-one
        image: mcr.microsoft.com/azuredocs/aks-helloworld:v1
        ports:
        - containerPort: 80
        env:
        - name: TITLE
          value: "Welcome to Azure Kubernetes Service (AKS)"
---
apiVersion: v1
kind: Service
metadata:
  name: aks-helloworld-one  
spec:
  type: ClusterIP
  ports:
  - port: 80
  selector:
    app: aks-helloworld-one

  2. Создайте файл aks-helloworld-two.yaml и скопируйте в него следующий пример кода YAML.

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: aks-helloworld-two  
spec:
  replicas: 1
  selector:
    matchLabels:
      app: aks-helloworld-two
  template:
    metadata:
      labels:
        app: aks-helloworld-two
    spec:
      containers:
      - name: aks-helloworld-two
        image: mcr.microsoft.com/azuredocs/aks-helloworld:v1
        ports:
        - containerPort: 80
        env:
        - name: TITLE
          value: "AKS Ingress Demo"
---
apiVersion: v1
kind: Service
metadata:
  name: aks-helloworld-two  
spec:
  type: ClusterIP
  ports:
  - port: 80
  selector:
    app: aks-helloworld-two

  3. Запустите два демонстрационных приложения с помощью команды kubectl apply:

    kubectl apply -f aks-helloworld-one.yaml --namespace ingress-basic
kubectl apply -f aks-helloworld-two.yaml --namespace ingress-basic

Создание правил маршрутизации входящего трафика

Оба приложения запущены в кластере Kubernetes. Для маршрутизации трафика для каждого приложения создайте ресурс входящего трафика Kubernetes. Ресурс входящего трафика настраивает правила, по которым осуществляется маршрутизация трафика к одному из двух приложений.

В следующем примере трафик, передаваемый на EXTERNAL_IP/hello-world-one, направляется в службу aks-helloworld-one. Трафик, передаваемый на адрес EXTERNAL_IP/hello-world-two, направляется в службу aks-helloworld-two. Трафик, передаваемый на адрес EXTERNAL_IP/static, направляется в службу с именем aks-helloworld-one для статических ресурсов.

  1. Создайте файл hello-world-ingress.yaml и скопируйте в него следующий пример кода YAML:

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: hello-world-ingress
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "false"
    nginx.ingress.kubernetes.io/use-regex: "true"
    nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
  ingressClassName: nginx
  rules:
  - http:
      paths:
      - path: /hello-world-one(/|$)(.*)
        pathType: Prefix
        backend:
          service:
            name: aks-helloworld-one
            port:
              number: 80
      - path: /hello-world-two(/|$)(.*)
        pathType: Prefix
        backend:
          service:
            name: aks-helloworld-two
            port:
              number: 80
      - path: /(.*)
        pathType: Prefix
        backend:
          service:
            name: aks-helloworld-one
            port:
              number: 80
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: hello-world-ingress-static
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "false"
    nginx.ingress.kubernetes.io/rewrite-target: /static/$2
spec:
  ingressClassName: nginx
  rules:
  - http:
      paths:
      - path: /static(/|$)(.*)
        pathType: Prefix
        backend:
          service:
            name: aks-helloworld-one
            port: 
              number: 80

  2. Создайте ресурс входящего трафика, используя команду kubectl apply.

    kubectl apply -f hello-world-ingress.yaml --namespace ingress-basic

Проверка маршрутизации контроллера входящего трафика

Чтобы проверить маршруты для контроллера входящего трафика, перейдите в два приложения. Откройте веб-браузер и перейдите по IP-адресу вашего контроллера входа NGINX, например EXTERNAL_IP. Первое демонстрационное приложение отображается в веб-браузере, как показано в следующем примере:

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

Теперь добавьте к IP-адресу путь /hello-world-two, например EXTERNAL_IP/hello-world-two. Появится второе демонстрационное приложение с пользовательским заголовком:

Скриншот второго демонстрационного приложения, работающего за неуправляемым Ingress-контроллером в AKS.

Тестирование внутреннего IP-адреса

  1. Создайте тестовый модуль pod и подключите к нему сеанс терминала.

    kubectl run -it --rm aks-ingress-test --image=mcr.microsoft.com/dotnet/runtime-deps:6.0 --namespace ingress-basic

  2. Установите curl в контейнере pod с помощью apt-get.

    apt-get update && apt-get install -y curl

  3. Доступ к адресу контроллера входящего трафика Kubernetes с помощью curl, например http://10.224.0.42. Укажите ваш внутренний IP-адрес, который вы указали при развертывании этого контроллера ingress.

    curl -L http://10.224.0.42

    Вы не предоставили путь к адресу, поэтому контроллер входящего трафика по умолчанию соответствует маршруту / . Первое демонстрационное приложение возвращается, как показано в следующем сокращенном примере выходных данных:

    <!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <link rel="stylesheet" type="text/css" href="/static/default.css">
    <title>Welcome to Azure Kubernetes Service (AKS)</title>
[...]

  4. Добавьте путь /hello-world-two к адресу, напримерhttp://10.224.0.42/hello-world-two.

    curl -L -k http://10.224.0.42/hello-world-two

    Второе демонстрационное приложение с настраиваемым заголовком возвращается, как показано в следующем сокращенном примере выходных данных:

    <!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <link rel="stylesheet" type="text/css" href="/static/default.css">
    <title>AKS Ingress Demo</title>
[...]

Очистка ресурсов

В этой статье Helm используется для установки компонентов входного контроля и примеров приложений. При развертывании диаграммы Helm создается множество ресурсов Kubernetes. В эти ресурсы входят поды, развертывания и службы. Чтобы очистить эти ресурсы, можно удалить всё пространство имен образца или удалить отдельные ресурсы.

Удалите образец пространства имен и все ресурсы.

Чтобы удалить весь пример пространства имен, используйте команду kubectl delete и укажите имя пространства имен. Эта команда удаляет все ресурсы в указанном пространстве имен.

kubectl delete namespace ingress-basic

Удаление ресурсов по отдельности

Кроме того, можно удалить отдельные ресурсы, созданные для более детального подхода.

  1. Вывод списка выпусков Helm с помощью helm list команды.

    helm list --namespace ingress-basic

    Найдите диаграммы с именем ingress-nginx и aks-helloworld, как показано в следующем примере выходных данных:

    NAME                    NAMESPACE       REVISION        UPDATED                                 STATUS          CHART                   APP VERSION
ingress-nginx           ingress-basic   1               2020-01-06 19:55:46.358275 -0600 CST    deployed        nginx-ingress-1.27.1    0.26.1

  2. Удалите выпуски с помощью команды helm uninstall.

    helm uninstall ingress-nginx --namespace ingress-basic

  3. Удалите два примера приложений.

    kubectl delete -f aks-helloworld-one.yaml --namespace ingress-basic
kubectl delete -f aks-helloworld-two.yaml --namespace ingress-basic

  4. Удалите маршрут входящего трафика, направленный на образцы приложений.

    kubectl delete -f hello-world-ingress.yaml

  5. Удалите пространство имен с помощью kubectl delete команды и укажите имя пространства имен.

    kubectl delete namespace ingress-basic

Следующие шаги

Сведения о настройке TLS с существующими компонентами ингресс см. в статье Использование TLS с ингресс-контроллером.

См. Надстройка маршрутизации приложений для получения сведений о настройке кластера AKS для использования маршрутизации приложений.

В этой статье рассматриваются некоторые внешние компоненты для AKS. Чтобы узнать больше об этих компонентах, см. следующие страницы проекта:

  • Last updated on