Хабрахабр

[Перевод] Kubernetes NodePort vs LoadBalancer vs Ingress? Когда и что использовать?

Все это разные способы получить внешний трафик в кластер. Недавно меня спросили, в чем разница между NodePorts, LoadBalancers и Ingress. Давайте посмотрим, чем они отличаются, и когда использовать каждый из них.

Если вы работаете в другом облаке, на собственном сервере, на миникубе или чем-то еще, будут отличия. Примечание: рекомендации рассчитаны на Google Kubernetes Engine. Если хотите подробностей, обратитесь к официальной документации. Я не углубляюсь в технические детали.

ClusterIP

Он обеспечивает сервис внутри кластера, к которому могут обращаться другие приложения внутри кластера. ClusterIP — сервис Kubernetes по умолчанию. Внешнего доступа нет.

YAML для сервиса ClusterIP выглядит следующим образом:

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! С чего я заговорил о сервисе ClusterIP, если к нему нельзя получить доступ из интернета?

Запускаем прокси-сервер Kubernetes:

$ kubectl proxy --port=8080

Теперь можно выполнять навигацию по API Kubernetes для доступа к этому сервису, используя схему:

http://localhost:8080/api/v1/proxy/namespaces//services/<SERVICE-NAME>:<PORT-NAME>/

Используем этот адрес для доступа к вышеуказанному сервису:

http://localhost:8080/api/v1/proxy/namespaces/default/services/my-internal-service:http/

Когда использовать?

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

Поскольку этот метод требует запуска kubectl в качестве аутентифицированного пользователя, не следует использовать его для предоставления доступа к сервису в интернете или для продакшен-сервисов.

NodePort

NodePort, как следует из названия, открывает указанный порт для всех Nodes (виртуальных машин), и трафик на этот порт перенаправляется сервису. Сервис 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. По сути, сервис NodePort имеет два отличия от обычного сервиса ClusterIP. Если мы не укажем этот порт, он выберет случайный. Существует дополнительный порт, называемый nodePort, который указывает, какой порт открыть на узлах. Как говорит thockin, с выбором портов все не так просто. В большинстве случаев дайте Kubernetes самому выбрать порт.

Когда использовать?

Метод имеет множество недостатков:
На порт садится только один сервис
Доступны только порты 30000–32767
Если IP-адрес узла/виртуальной машины изменяется, придется разбираться

Но если постоянная доступность сервиса вам безразлична, а уровень затрат — нет, этот метод для вас. По этим причинам я не рекомендую использовать этот метод в продакшн, чтобы напрямую предоставлять доступ к сервису. Хороший пример такого приложения — демка или временная затычка.

LoadBalancer

На GKE он развернет Network Load Balancer, который предоставит IP адрес. Сервис LoadBalancer — стандартный способ предоставления сервиса в интернете. Этот IP адрес будет направлять весь трафик на сервис.

Когда использовать?

Весь трафик указанного порта будет направлен на сервис. Если вы хотите раскрыть сервис напрямую, это метод по умолчанию. Это означает, что мы можем направить на сервис такие виды трафика как HTTP, TCP, UDP, Websockets, gRPC и тому подобное. Нет фильтрации, нет маршрутизации и т.д.

Но есть один недостаток. ! Каждому сервису, который мы раскрываем с помощью LoadBalancer, нужен свой IP-адрес, что может влететь в копеечку.

Ingress

Он стоит перед несколькими сервисами и действует как «интеллектуальный маршрутизатор» или точка вхождения в кластер. В отличие от приведенных примеров, Ingress сам по себе не сервис.

Есть разные типы контроллеров Ingress с богатыми возможностями.

Вам одновременно будет доступна маршрутизация в бекенд сервисы на основе путей и субдоменов. Контроллер GKE по умолчанию запускает HTTP(S) Load Balancer. Например, все на foo.yourdomain.com отправляем в сервис foo, а путь yourdomain.com/bar/ со всеми вложениями — в сервис bar.

YAML для объекта Ingress на GKE с L7 HTTP Load Balancer выглядит следующим образом:

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-контроллеров, такие как cert-manager, который автоматически предоставляет SSL-сертификаты для сервисов. Существует множество контроллеров Ingress: Google Cloud Load Balancer, Nginx, Contour, Istio и прочие.

Используя встроенную интеграцию GCP, вы платите только за один балансировщик нагрузки. Ingress хорош при раскрытии нескольких сервисов на одном IP-адресе, когда все сервисы используют общий протокол L7 (обычно HTTP). А поскольку Ingress «умный», вы из коробки получаете множество функций (например, SSL, Auth, Routing и т.д.)

За диаграммы спасибо Ahmet Alp Balkan.

Это не самая технически точная диаграмма, но она хорошо иллюстрирует работу NodePort.

When should I use what?. Оригинал: Kubernetes NodePort vs LoadBalancer vs Ingress?

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть