Недавно меня спросили, в чем разница между NodePorts, LoadBalancers и Ingress. Это все разные способы передачи внешнего трафика в кластер.
Давайте посмотрим, чем они отличаются и когда использовать каждый.
Примечание: рекомендации предназначены для Движок Google Кубернетес .
Если вы работаете в другом облаке, на собственном сервере, на мини-кубе или где-то еще, различия будут. Я не вдаюсь в технические подробности.
Если вам нужны подробности, пожалуйста, свяжитесь официальная документация .
КластерIP
ClusterIP — это служба Kubernetes по умолчанию.Он предоставляет службу внутри кластера, к которой могут получить доступ другие приложения внутри кластера.
Внешний доступ отсутствует. YAML для службы ClusterIP выглядит следующим образом:
Зачем я говорю о сервисе ClusterIP, если к нему невозможно получить доступ из Интернета? Есть способ: использовать прокси Kubernetes!apiVersion: v1 kind: Service metadata: name: my-internal-service selector: app: my-app spec: type: ClusterIP ports: - name: http port: 80 targetPort: 80 protocol: TCP
Запустите прокси-сервер Kubernetes:
$ kubectl proxy --port=8080Теперь вы можете использовать Kubernetes API для доступа к этому сервису, используя схему: http://localhost:8080/api/v1/proxy/namespaces/ /услуги/ : / Мы используем этот адрес для доступа к вышеуказанному сервису: http://localhost:8080/api/v1/proxy/namespaces/default/services/my-internal-service:http/
Когда использовать?
Существует несколько сценариев использования прокси-сервера Kubernetes для доступа к сервисам.Отладка сервисов или подключение к ним напрямую с ноутбука для других целей Разрешение внутреннего трафика, отображение внутренних панелей и т.д. Поскольку этот метод требует запуска kubectl от имени аутентифицированного пользователя, его не следует использовать для предоставления доступа к службам в Интернете или для производственных служб.
НодПорт
Служба NodePort — это самый примитивный способ направить внешний трафик на службу.NodePort, как следует из названия, открывает указанный порт для всех узлов (виртуальных машин), и трафик на этот порт перенаправляется в службу.
YAML для службы NodePort выглядит следующим образом: apiVersion: v1
kind: Service
metadata:
name: my-nodeport-service
selector:
app: my-app
spec:
type: NodePort
ports:
- name: http
port: 80
targetPort: 80
nodePort: 30036
protocol: TCP
По сути, служба NodePort имеет два отличия от обычной службы ClusterIP. Во-первых, тип NodePort. Существует дополнительный порт под названием nodePort, который определяет, какой порт открыть на узлах.
Если мы не укажем этот порт, он выберет случайный.
В большинстве случаев позвольте Kubernetes самому выбрать порт. Как он говорит думаю , с выбором портов все не так просто.
Когда использовать?
Метод имеет множество недостатков: К порту подключается только одна служба Доступны только порты 30000–32767. Если IP-адрес хоста/виртуальной машины изменится, вам придется это выяснить.По этим причинам я не рекомендую использовать этот метод в производстве для прямого предоставления сервиса.
Но если вам безразлична постоянная доступность услуги, а уровень затрат – нет, этот способ для вас.
Хорошим примером такого приложения является демо-версия или временная заглушка.
Балансировщик нагрузки
Сервис LoadBalancer — это стандартный способ предоставления услуги в Интернете.На ГКЕ он развернёт Балансировщик сетевой нагрузки Который предоставит IP-адрес.
Этот IP-адрес будет направлять весь трафик на службу.
Когда использовать?
Если вы хотите предоставить службу напрямую, это метод по умолчанию.Весь трафик по указанному порту будет направлен на сервис.
Никакой фильтрации, никакой маршрутизации и т. д. Это означает, что мы можем направлять в сервис такие типы трафика, как HTTP, TCP, UDP, Websockets, gRPC и тому подобное.
! Но есть один недостаток.
Каждой службе, которую мы предоставляем с помощью LoadBalancer, нужен собственный IP-адрес, который может стоить немалых денег.
Вход
В отличие от приведенных примеров, Ingress сам по себе не является сервисом.Он находится перед несколькими сервисами и действует как «интеллектуальный маршрутизатор» или точка входа в кластер.
Существуют различные типы контроллеров Ingress с богатыми возможностями.
Контроллер GKE работает по умолчанию.
Балансировщик нагрузки HTTP(S) .
У вас одновременно будет доступ к маршрутизации к серверным службам на основе путей и поддоменов.
Например, мы отправляем все, что есть на foo.yourdomain.com, в сервис foo, а путь yourdomain.com/bar/ со всеми вложениями — в сервис bar. 
YAML для объекта Ingress в GKE с Балансировщик нагрузки HTTP L7 следующее: apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: my-ingress
spec:
backend:
serviceName: other
servicePort: 8080
rules:
- host: foo.mydomain.com
http:
paths:
- backend:
serviceName: foo
servicePort: 8080
- host: mydomain.com
http:
paths:
- path: /bar/*
backend:
serviceName: bar
servicePort: 8080
Когда использовать? С одной стороны, Ingress — один из лучших способов предоставления услуг.
С другой стороны, это один из самых сложных.
Существует множество Ingress-контроллеров: Облачный балансировщик нагрузки Google , Нгинкс , Контур , Истио и другие.
Существуют также плагины для контроллеров Ingress, например сертификат-менеджер , который автоматически предоставляет сертификаты SSL для служб.
Ingress хорошо подходит для предоставления доступа к нескольким службам на одном IP-адресе, когда все службы используют общий протокол L7 (обычно HTTP).
Используя встроенную интеграцию GCP, вы платите только за один балансировщик нагрузки.
А поскольку Ingress умный, вы получаете множество функций «из коробки» (таких как SSL, аутентификация, маршрутизация и т. д.).
Спасибо за схемы Ахмет Альп Балкан .
Это не самая технически точная диаграмма, но она хорошо иллюстрирует, как работает NodePort. Оригинал: Kubernetes NodePort против LoadBalancer против Ingress? Когда мне следует использовать что? .
Теги: #Системное администрирование #Kubernetes #DevOps #ingress #микросервисы #балансировка нагрузки #сервисы
-
Деловой Интернет. Первый День
19 Oct, 24 -
Быстрый Доступ К Приложениям Из Dock
19 Oct, 24 -
Wwdc 2014: Личный Опыт
19 Oct, 24
