Ingress

Ingress

@showconfig

Среди ServiceTypes, упомянутых в этой главе, наиболее часто используются NodePort и LoadBalancer. Для LoadBalancer ServiceType, мы должны иметь поддержку от базовой инфраструктуры. Даже после поддержки, мы не можем хотеть использовать его для каждого обслуживания, по мере того как ресурсы LoadBalancer ограничены и они могут увеличить цены значительно. Управление NodePort ServiceType также может быть сложным время от времени, так как мы должны постоянно обновлять наши настройки прокси и отслеживать назначенные порты. В этой главе мы рассмотрим Ingress, который является еще одним методом, который мы можем использовать для доступа к нашим приложениям из внешнего мира.

С помощью Services, правил маршрутизации присоединяются к заданной Services. Они существуют до тех пор, пока Service существует. Если мы можем каким-то образом разъединить правила маршрутизации от приложения, мы можем обновить наше приложение, не беспокоясь о его внешнем доступе. Это можно сделать с помощью Ingress.

Определение с сайта kubernetes.io:

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

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

  • TLS (Transport Layer Security)
  • Name-based virtual hosting 
  • Path-based routing
  • Custom rules.

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

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: web-ingress
  namespace: default
spec:
  rules:
  - host: blue.example.com
    http:
      paths:
      - backend:
          serviceName: webserver-blue-svc
          servicePort: 80
  - host: green.example.com
    http:
      paths:
      - backend:
          serviceName: webserver-green-svc
          servicePort: 80

По данным примера мы предоставили выше, запросы пользователей как blue.example.com и green.example.com пойдут в ту же степень конечной точки, а оттуда они будут направлены webserver-blue-svc, и webserver-green-svc, соответственно. Здесь мы видели пример правила Ingress виртуального хостинга на основе имен.

У нас также могут быть правила Fan Out Ingress, в которых мы отправляем запросы, например example.com/blue и example.com/green, которые будут перенаправлены на webserver-blue-svc и webserver-green-svc соответственно.

Ресурс Ingress не выполняет никакой пересылки запросов самостоятельно. Вся магия выполняется с помощью Ingress Controller.

Ingress Controller

Ingress Controller — это приложение, которое следит за сервером API главного узла за изменения в ресурсах Ingress и соответственно обновляет балансировку нагрузки уровня 7. У Kubernetes есть разные Ingress Controllers, и, при необходимости, мы можем также строить свои собственные. Контроллеры нагрузки GCE L7 и Nginx Ingress Controller являются примерами Ingress Controllers.

Запустите Ingress Controller с помощью Minikube

Minikube v0.14.0 и выше отправляет установку Nginx Ingress Controller в качестве дополнения. Его можно легко включить, выполнив следующую команду:

$ minikube addons enable ingress

Deploy an Ingress Resource

После развертывания Ingress Controller мы можем создать ресурс Ingress с помощью команды kubectl create. Например, если мы создадим файл webreserver-ingress.yaml с содержимым, то для создания ресурса Ingress мы будем использовать следующую команду:

$ kubectl create -f webserver-ingress.yaml

Access Services Using Ingress

Когда мы только что создали ресурс Ingress, мы должны теперь получить доступ к службам webserver-blue-svc или webserver-green-svc, используя URL-адреса blue.example.com и green.example.com. Поскольку наша текущая настройка находится на Minikube, нам нужно будет обновить файл конфигурации хоста (/etc/hosts на Mac и Linux) на нашей рабочей станции до IP-адреса Minikube для этих URL-адресов:

$ cat /etc/hosts
127.0.0.1    localhost
::1       localhost
192.168.99.100 blue.example.com green.example.com 

Как только это будет сделано, мы можем открыть blue.example.com и green.example.com в браузере и получить доступ к приложению.


Report Page