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

С Kubernetes есть несколько вариантов. Один из них является Ingress Controller.

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

Предпосылки

Чтобы следить за этой записью в блоге, у вас должно быть:

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

Что такое вход?

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

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

Вот где Ingress Controllers вступают в игру. 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 доллара США за час работы Application Load Balancer (или неполный час). Хотя это небольшое число, оно увеличивается, если у вас есть приложение, работающее годами, и у вас работает несколько приложений, каждое из которых имеет свой собственный балансировщик нагрузки.

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

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

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

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

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

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

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

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

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

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

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

  • Спецификация развертывания 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 в выбранном вами месте (например, на рабочем столе) и выполните следующую команду:

kubectl create -f deployment.yaml

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

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

  • Имя службы Kubernetes совпадает с именем службы, которую вы создали в предыдущем манифесте Kubernetes. Это потому, что Ingress Controller должен указывать на сервис Kubernetes.
  • Хост указывает на 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 Manifest как ingress.yaml и выполните следующую команду:

kubectl create -f ingress.yaml

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

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

Другие контроллеры входящего трафика

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

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

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