Подтвердить что ты не робот

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

1 - Я читаю документацию, и я немного смущен формулировкой. В нем говорится:

ClusterIP. Предоставляет службу на внутреннем IP-кластере. Выбор этого значения делает сервис доступным только внутри кластера. Это стандартный ServiceType

NodePort. Предоставляет услугу на каждом IP-адресе Node на статическом порту (NodePort). Служба ClusterIP, к которой будет направляться служба NodePort, автоматически создается. Вы можете связаться со службой NodePort из-за пределов кластера, запросив <NodeIP>:<NodePort>.

LoadBalancer. Предоставляет внешнюю службу, используя балансировщик загрузки облачных провайдеров. Службы NodePort и ClusterIP, к которым будет маршрутизироваться внешний балансировщик нагрузки, автоматически создаются.

Использует ли тип сервиса NodePort ClusterIP, но только на другом порту, который открыт для внешних клиентов? Таким образом, в этом случае <NodeIP>:<NodePort> совпадает с <ClusterIP>:<NodePort>?

Или это NodeIP на самом деле IP-адрес, найденный при запуске kubectl get nodes, а не виртуальный IP-адрес, используемый для типа службы ClusterIP?

2 - Также на диаграмме из приведенной ниже ссылки:

http://kubernetes.io/images/docs/services-iptables-overview.svg

Есть ли какая-то особая причина, по которой Client находится внутри Node? Я предположил, что он должен быть внутри Cluster в случае типа сервиса ClusterIP.

Если для NodePort была использована одна и та же диаграмма, было бы целесообразно полностью вывести клиента за пределы Node и Cluster, или я полностью не пропущу точку?

4b9b3361

Ответ 1

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

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

Вы можете получить доступ к этой услуге только внутри кластера. Это доступно из его порта spec.clusterIp. Если spec.ports[*].targetPort он будет 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 его на ваш spec.ports[*].targetPort, если установлено. К этой услуге также можно получить доступ так же, как и к ClusterIP.

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

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

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

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

Ответ 2

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

ClusterIp exposure < NodePort exposure < LoadBalancer exposure

ClusterIp    -> Expose service through **k8s cluster** with ip/name:port
NodePort     -> Expose service through **Internal network VM's** also external to k8s ip/name:port
LoadBalancer -> Expose service through **External world** or whatever you defined in your LB.

Ответ 3

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

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

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

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

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

Для каждого порта, который mynodeportservice прослушивает в порте узлов в диапазоне от 30000 до 32767, будет выбран случайным образом. Таким образом, внешние клиенты, находящиеся вне кластера, могут подключиться к той службе ClusterIP, которая существует внутри кластера. Допустим, что наши 3 узла K8 имеют 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. Идея заключается в том, что LB LB будет иметь публичный IP 1.2.3.4, и он будет загружать баланс и перенаправлять трафик на 3 узла K8, которые имеют частные 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 является частью службы балансировки нагрузки.


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

Ответ 4

Предположим, вы создали виртуальную машину 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/

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

enter image description here

Ниже приведена схема основных отношений.

enter image description here

Ответ 5

  1. clusterIP: IP-доступ внутри кластера (через узлы в кластере d).
nodeA : pod1 => clusterIP1, pod2 => clusterIP2
nodeB : pod3 => clusterIP3.

pod3 может общаться с pod1 через их кластер IP-сети.

  1. nodeport: чтобы сделать модули доступными снаружи кластера через nodeIP: nodeport, он создаст/сохранит clusterIP выше в качестве своей кластерной сети IP.
nodeA => nodeIPA : nodeportX
nodeB => nodeIPB : nodeportX

Вы можете получить доступ к службе на pod1 либо через узел IPA: узел порта X ИЛИ узел IPB: узел порта X. В любом случае будет работать, потому что kube-proxy (который установлен на каждом узле) получит ваш запрос и распределит его [перенаправить (термин iptables)] по узлам, использующим сеть clusterIP.

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

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