Kubernetes Ingress: Nginx Ingress Edition

В Kubernetes некоторые приложения должны быть общедоступными. Возможно, это веб-приложение или что-то еще, что должно быть доступно извне, за пределами частной сети. В любом случае, вам понадобится способ взаимодействия с приложением.

В Kubernetes есть несколько вариантов. Один из них — контроллер Ingress.

В этой статье блога вы узнаете о том, что такое Ingress, как он вписывается в Kubernetes и как начать работу с ним прямо сейчас.

Предварительные условия

Чтобы следовать этой статье, у вас должны быть:

• Установлен Minikube ИЛИ у вас уже есть кластер Kubernetes, запущенный на месте или в облаке.

Что такое Ingress?

Как приложение достигает публичного интернета, скажем, с помощью развертывания Kubernetes или Kubernetes Pod? Для этого используется служба Kubernetes Service. Служба Kubernetes может подключить к ней балансировщик нагрузки, независимо от того, где вы находитесь — в облаке или на месте, чтобы люди (клиенты, заказчики, вы сами и т.д.) могли получить доступ к приложению в публичном режиме.

Дело в том, что это означает, что каждая служба Kubernetes имеет свой балансировщик нагрузки. Это может оказаться дорогостоящим и отнимать много времени.

Именно здесь в игру вступают контроллеры Ingress. Ingress Controller — это специализированный балансировщик нагрузки, на который вы можете направить свою службу Kubernetes, указав имя службы и путь, по которому вы хотите, чтобы служба была достигнута.

Например, ниже приведен фрагмент манифеста:

ingressClassName: nginx-example
  rules:
  - http:
      paths:
      - path: /testpath
        pathType: Prefix
        backend:
          service:
            name: test
            port:
              number: 80

Обратите внимание на несколько моментов:

• Существует связка path ключ/значение, которая показывает, по какому пути вы сможете добраться до приложения через балансировщик нагрузки. Это может выглядеть примерно так: http://load_balancer_name/testpath.
• Существует связка ключ/значение service, которая указывает на имя службы Kubernetes и порт, на котором работает служба. В данном случае имя службы test.

По сути, это означает, что у вас есть служба Kubernetes, которую вы создали под названием test. Служба test настроена в Nginx Ingress, а способ, которым вы достигаете службы, — это переход по пути /testpath.

Зачем это нужно?

В предыдущем разделе вы узнали о том, что такое Ingress. Теперь давайте поговорим о том, зачем он нужен.

Вот несколько моментов, которые следует иметь в виду.

• Облачные балансировщики нагрузки стоят дорого
• Если вы используете локальное решение, скорее всего, вам придется настраивать BGP, чтобы не сталкиваться с ARP-запросами.
• Кто хочет управлять несколькими облачными балансировщиками нагрузки?
• Кто хочет управлять BGP?

Для многих команд было бы гораздо проще иметь несколько служб Kubernetes без балансировщика нагрузки для каждой из них, а вместо этого иметь один балансировщик нагрузки, на который указывает каждая служба. Это очень похоже на то, что мы делаем с приложениями, которые не являются контейнерными. Например, подумайте об обратном прокси-сервере Nginx. В обратном прокси у вас есть несколько имен серверов, путей, портов и т.д., а люди могут обращаться к приложениям через один адрес (обратный прокси).

Еще один факт заключается в том, что облачные балансировщики нагрузки могут быть дорогими. Согласно документации AWS: $0,0225 за час (или неполный час) работы балансировщика нагрузки приложений. Хотя это небольшое число, оно увеличивается, если у вас есть приложение, работающее годами, и у вас есть несколько приложений, каждое из которых имеет свой собственный балансировщик нагрузки.

Начало работы с Nginx Ingress

Как и для всех ресурсов Kubernetes, для Nginx Ingress существует Kind/Spec и API. API относится к группе Named API Group.

KIND:     IngressClass                                                               
VERSION:  networking.k8s.io/v1

Давайте разберемся не только с тем, как установить Nginx Ingress, но и с тем, как начать его использовать.

Установка контроллера Ingress

Для установки контроллера Ingress все зависит от того, какую платформу вы используете. Методы установки в целом одинаковы, например, использование диаграммы Helm для установки Nginx Ingress, но некоторые опции и флаги могут отличаться в зависимости от того, какой облачный или локальный сервис Kubernetes вы используете.

Для целей этой статьи в блоге вы можете использовать установку Minikube, если у вас на локальной машине запущен Minikube. Вы можете найти инструкции здесь.

Если вы хотите установить Nginx Ingress в другом месте, например, в AKS или EKS, посмотрите руководства по установке здесь и пройдите весь путь шаг за шагом.

Запуск контроллера Ingress

Теперь, когда Nginx Ingress установлен, давайте рассмотрим, как запустить приложение для использования Nginx Ingress.

Прежде всего, вам понадобится приложение для входа в систему. Чтобы запустить его, вы можете использовать версию Nginx без статического состояния с помощью образа Docker nginx:latest. Приведенный ниже манифест Kubernetes Manifest будет создан:

• спецификацию развертывания Nginx
• спецификацию развертывания службы

apiVersion: apps/v
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginxdeployment
  replicas: 2
  template:
    metadata:
      labels:
        app: nginxdeployment
    spec:
      containers:
      - name: nginxdeployment
        image: nginx:latest
        imagePullPolicy: Never
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: nginxservice
spec:
  selector:
    app: nginxdeployment
  ports:
    - protocol: TCP
      port: 80

Сохраните приведенный выше Kubernetes Manifest в выбранном вами месте (например, на рабочем столе) и выполните следующую команду:

kubectl create -f deployment.yaml

Если вы запустите kubectl get pods, вы должны увидеть запущенные стручки Nginx.

Далее вам понадобится Kubernetes Manifest для создания Ingress Controller, который вы найдете ниже. Обратите внимание на несколько вещей:

• Имя службы Kubernetes Service совпадает с именем службы, которую вы создали в предыдущем Kubernetes Manifest. Это потому, что Ingress Controller должен указывать на Kubernetes Service.
• Хост указывается на localhost, предполагая, что вы используете Minikube.
• Порт 8080.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-nginxservice-a
spec:
  ingressClassName: nginx-servicea
  rules:
  - host: localhost
    http:
      paths:
      - path: /nginxappa
        pathType: Prefix
        backend:
          service:
            name: nginxservice
            port:
              number: 8080

Сохраните манифест Ingress как ingress.yaml и выполните следующую команду:

kubectl create -f ingress.yaml

После завершения откройте веб-браузер и перейдите на localhost:8080. Вы увидите, что приложение Nginx теперь запущено.

Поздравляем! Вы официально установили свой первый контроллер Ingress.

Другие контроллеры Ingress

Хотя Nginx Ingress является одним из самых популярных ингресс контроллеров, существует несколько других, от проектов с открытым исходным кодом до крупных организаций, создающих собственную реализацию ингресс контроллеров. Ниже приведен список ingress-контроллеров, который взят непосредственно с сайта Kubernetes: https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/.

• AKS Application Gateway Ingress Controller — это ингресс-контроллер, который настраивает Azure Application Gateway.
• Ambassador API Gateway — ингресс-контроллер на базе Envoy.
• Apache APISIX ingress controller — ингресс-контроллер на базе Apache APISIX.
• Avi Kubernetes Operator обеспечивает балансировку нагрузки L4-L7 с помощью VMware NSX Advanced Load Balancer.
• BFE Ingress Controller — ингресс-контроллер на базе BFE.
• Citrix ingress controller работает с Citrix Application Delivery Controller.
• Contour — ингресс-контроллер на базе Envoy.
• EnRoute — API-шлюз на базе Envoy, который может работать как ингресс-контроллер.
• Easegress IngressController — API-шлюз на базе Easegress, который может работать как ингресс-контроллер.
• F5 BIG-IP Container Ingress Services for Kubernetes позволяет использовать Ingress для настройки виртуальных серверов F5 BIG-IP.
• Gloo — это ингресс-контроллер с открытым исходным кодом на базе Envoy, который предлагает функции API-шлюза.
• HAProxy Ingress — это ингресс-контроллер для HAProxy.
• HAProxy Ingress Controller для Kubernetes также является ингресс-контроллером для HAProxy.
• Istio Ingress — это ингресс-контроллер на базе Istio.
• Kong Ingress Controller для Kubernetes — это ингресс-контроллер, управляющий шлюзом Kong.
• NGINX Ingress Controller for Kubernetes работает с веб-сервером NGINX (в качестве прокси).
• Pomerium Ingress Controller основан на Pomerium, который предлагает контекстно-зависимую политику доступа.
• Skipper HTTP-маршрутизатор и обратный прокси для композиции сервисов, включая такие варианты использования, как Kubernetes Ingress, разработанный как библиотека для создания собственного прокси.
• Traefik Kubernetes Ingress provider — это контроллер ингресса для прокси Traefik.
• Tyk Operator расширяет Ingress с помощью пользовательских ресурсов, чтобы привнести в Ingress возможности управления API. Tyk Operator работает с Open Source Tyk Gateway & Tyk Cloud control plane.
• Voyager — это контроллер ингресса для HAProxy.

Как вы можете видеть, существует множество вариантов. Лучший способ понять, какой из них выбрать для вашей организации, — это понять, что лежит в основе инфраструктуры. Например, если ваша организация использует все свое сетевое оборудование через F5 и у вас есть корпоративная поддержка F5, использование ингресс-контроллера F5 может быть не такой уж плохой идеей. Если ваша организация глубоко погружена в экосистему Kong, имеет смысл использовать ингресс-контроллер Kong.

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