В чем разница между типами сервисов ClusterIP, NodePort и LoadBalancer в Kubernetes?

ClusterIP предоставляет следующее:

• spec.clusterIp:spec.ports[*].port

Вы можете получить доступ к этой службе только внутри кластера. Доступен через spec.clusterIp порт. Если установлен spec.ports[*].targetPort, он будет маршрутизировать от порта к targetPort. CLUSTER-IP, который вы получаете при вызове kubectl get services, - это IP, назначенный этой службе внутри кластера.

NodePort предоставляет следующее:

• <NodeIP>:spec.ports[*].nodePort
• spec.clusterIp:spec.ports[*].port

Если вы обращаетесь к этой службе на nodePort с внешнего IP-адреса узла, он направит запрос на spec.clusterIp:spec.ports[*].port, который, в свою очередь, направит его на ваш spec.ports[*].targetPort, если он установлен. К этой услуге также можно получить доступ так же, как и к ClusterIP.

Ваши NodeIP - это внешние IP-адреса узлов. Вы не можете получить доступ к своей службе из spec.clusterIp:spec.ports[*].nodePort.

LoadBalancer предоставляет следующее:

• spec.loadBalancerIp:spec.ports[*].port
• <NodeIP>:spec.ports[*].nodePort
• spec.clusterIp:spec.ports[*].port

Вы можете получить доступ к этой службе с IP-адреса вашего балансировщика нагрузки, который направляет ваш запрос на nodePort, который, в свою очередь, направляет запрос на порт clusterIP. Вы можете получить доступ к этой службе, как к службе NodePort или ClusterIP.

Чтобы прояснить для всех, кто ищет, в чем разница между 3 на более простом уровне. Вы можете предоставить свою службу с минимальным уровнем ClusterIp (в кластере k8s) или более широким с помощью NodePort (внутри кластера, внешнего по отношению к кластеру k8s) или LoadBalancer (внешний мир или что-то еще, что вы определили в своем LB).

Воздействие ClusterIp ‹Воздействие NodePort‹ Воздействие LoadBalancer

• ClusterIp
  Предоставьте службу через кластер k8s с помощью ip/name:port
• NodePort
  Предоставлять услуги через виртуальные машины внутренней сети, также внешние по отношению к k8s ip/name:port
• LoadBalancer
  Предоставьте сервис через Внешний мир или через то, что вы определили в своем LB.

ClusterIP: службы доступны для модулей / служб в кластере
Если я создаю службу с именем myservice в пространстве имен по умолчанию типа: ClusterIP, тогда будет создан следующий предсказуемый статический DNS-адрес для службы. :

myservice.default.svc.cluster.local (или просто myservice.default, или по модулям в пространстве имен по умолчанию будет работать только myservice)

И это DNS-имя может быть разрешено только модулями и службами внутри кластера.

NodePort: службы доступны для клиентов в той же локальной сети / клиентов, которые могут пинговать узлы хоста K8s (и модули / службы в кластере) (обратите внимание, что для безопасности ваши узлы хоста k8s должны находиться в частной подсети, поэтому клиенты Интернет не сможет получить доступ к этой службе)
Если я создам службу под названием mynodeportservice в пространстве имен mynamespace типа: NodePort в кластере Kubernetes с 3 узлами. Затем будет создана служба типа: ClusterIP, и она будет доступна клиентам внутри кластера по следующему предсказуемому статическому DNS-адресу:

mynodeportservice.mynamespace.svc.cluster.local (или просто mynodeportservice.mynamespace)

Для каждого порта, который mynodeportservice прослушивает на nodeport, будет случайным образом выбран диапазон от 30000 до 32767. Таким образом, внешние клиенты, находящиеся за пределами кластера, могут воздействовать на эту службу ClusterIP, которая существует внутри кластера. Допустим, у наших 3 узловых узлов K8s есть IP-адреса 10.10.10.1, 10.10.10.2, 10.10.10.3, служба Kubernetes прослушивает порт 80, а случайно выбранный Nodeport был 31852.

Клиент, который существует вне кластера могут посещать 10.10.10.1:31852, 10.10.10.2:31852 или 10.10.10.3:31852 (поскольку NodePort прослушивается каждым узлом хоста Kubernetes) Kubeproxy перенаправит запрос на порт 80 mynodeportservice.

LoadBalancer: сервисы доступны для всех, кто подключен к Интернету * (общая архитектура - L4 LB публично доступен в Интернете, помещая его в DMZ или предоставляя ему как частный, так и общедоступный IP-адрес, а узлы хоста k8s находятся на частном подсеть)
(Примечание. Это единственный тип сервиса, который не работает в 100% реализаций Kubernetes, например, в «голом железе» Kubernetes, он работает, когда Kubernetes имеет интеграцию с облачным провайдером.)

Если вы сделаете mylbservice, то будет создана виртуальная машина L4 LB (также будет неявно порождена IP-служба кластера и служба NodePort). На этот раз наш NodePort - 30222. Идея состоит в том, что L4 LB будет иметь общедоступный IP-адрес 1.2.3.4 и будет балансировать нагрузку и перенаправлять трафик на 3 хост-узла K8s, у которых есть частные IP-адреса. (10.10.10.1:30222, 10.10.10.2:30222, 10.10.10.3:30222), а затем Kube Proxy перенаправит его службе типа ClusterIP, которая существует внутри кластера.

Вы также спросили: использует ли тип службы NodePort по-прежнему ClusterIP? Да *
Или NodeIP действительно является IP-адресом, обнаруженным при запуске узлов kubectl get? Также да *

Давайте проведем параллель между Основами:
Контейнер находится внутри модуля. стручок находится внутри набора реплик. набор реплик находится внутри развертывания.
Аналогично:
Служба ClusterIP является частью службы NodePort. Служба NodePort является частью службы балансировки нагрузки.

На этой диаграмме, которую вы показали, клиент будет модулем внутри кластера.

Предположим, вы создали виртуальную машину Ubuntu на своем локальном компьютере. Это IP-адрес 192.168.1.104.

Вы входите в виртуальную машину и устанавливаете Kubernetes. Затем вы создали модуль, на котором запущен образ nginx.

1. Если вы хотите получить доступ к этому модулю nginx внутри своей виртуальной машины, вы создадите ClusterIP, привязанный к этому модулю, например:

$ kubectl expose deployment nginxapp --name=nginxclusterip --port=80 --target-port=8080

Затем в своем браузере вы можете ввести IP-адрес nginxclusterip с портом 80, например:

http://10.152.183.2:80

2. Если вы хотите получить доступ к этому модулю nginx с вашего хост-компьютера, вам нужно будет открыть свое развертывание с помощью NodePort. Например:

$ kubectl expose deployment nginxapp --name=nginxnodeport --port=80 --target-port=8080 --type=NodePort

Теперь с вашего хост-компьютера вы можете получить доступ к nginx, например:

http://192.168.1.104:31865/

На моей панели они выглядят так:

На диаграмме ниже показаны основные взаимосвязи.

1. clusterIP: IP-адрес, доступный внутри кластера (через узлы в кластере d).

nodeA : pod1 => clusterIP1, pod2 => clusterIP2
nodeB : pod3 => clusterIP3.

pod3 может общаться с pod1 через свою сеть clusterIP.

2. nodeport: чтобы сделать поды доступными извне кластера через nodeIP: nodeport, он создаст / сохранит clusterIP выше в качестве своей сети clusterIP.

nodeA => nodeIPA : nodeportX
nodeB => nodeIPB : nodeportX

вы можете получить доступ к службе на pod1 либо через nodeIPA: nodeportX, либо через nodeIPB: nodeportX. Любой способ будет работать, потому что kube-proxy (который установлен на каждом узле) получит ваш запрос и распространит его [перенаправить (термин iptables)] по узлам, используя сеть clusterIP.

3. Балансировщик нагрузки

в основном просто помещаем LB впереди, чтобы входящий трафик распределялся на nodeIPA: nodeportX и nodeIPB: nodeportX, а затем продолжайте процесс с номером 2 выше.

Практическое понимание.

Я создал 2 службы: 1 для NodePort и другой для ClusterIP.

Если бы я хотел получить доступ к службе внутри кластера (с главного или любого рабочего узла), то оба будут доступны.

Теперь, если я хотел получить доступ к службам извне кластера, чем Nodeport, доступен только не ClusterIP.

Здесь вы можете увидеть, что localhost не прослушивает порт 80, даже мой контейнер nginx прослушивает порт 80.

Да, это единственное отличие.

Практический пример использования

Предположим, вам нужно создать в своем кластере архитектуру, указанную ниже. Я думаю, это довольно часто.

Теперь пользователь будет общаться только с внешним интерфейсом на каком-то порту. Бэкэнд и БД всегда скрыты от внешнего мира.

И не забудьте новый тип службы (из документа k8s):

ExternalName: сопоставляет Сервис с содержимым поля externalName (например, foo.bar.example.com), возвращая запись CNAME с ее значением. Никакого проксирования не настроено.

Примечание. Для использования типа ExternalName вам потребуется kube-dns версии 1.7 или CoreDNS версии 0.0.8 или выше.