Яка різниця між типами послуг ClusterIP, NodePort та LoadBalancer в Kubernetes?

1 - Я читаю документацію і я трохи плутаю формулювання. Він говорить:

КластерIP : службу на внутрішній IP-кластер. Вибір цього значення робить послугу доступною лише з кластеру. Це ServiceType за замовчуванням

NodePort : відкриває послугу на IP-адресу кожного вузла на статичному порту (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або я повністю пропускаю точку?

КластерIP пропонує наступне:

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

Ви можете отримати доступ до цієї послуги лише під час кластеру. Він доступний зі свого spec.clusterIpпорту. Якщо параметр spec.ports[*].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-адреси вузлів. Ви не можете отримати доступ до своєї послуги з <ClusterIP>:spec.ports[*].nodePort.

LoadBalancer виставляє наступне:

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

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

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

Експозиція ClusterIp <експозиція NodePort <експозиція LoadBalancer

• Служба ClusterIp
  Expose через кластер k8s зip/name:port
• Служба NodePort
  Expose через VM внутрішньої мережі також зовнішня до k8sip/name:port
• LoadBalancer
  Розкрийте послугу через Зовнішній світ або все, що ви визначили у своєму LB.

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

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

І цю назву DNS можна вирішити лише за допомогою служб і служб всередині кластеру.

NodePort: Служби доступні клієнтам у тій самій локальній мережі / клієнтам, які можуть пінг-хостинг вузлів K8s (і стручки / послуги в кластері) (Примітка. Для безпеки вузли вузлів k8s повинні знаходитись у приватній підмережі, таким чином клієнти в Інтернеті виграють я не зможу дістатися до цієї послуги)
Якщо я зроблю службу під назвою mynodeportservice у просторі імен мій типу типу: NodePort на 3-вузловому Kubernetes Cluster. Тоді буде створена Служба типу: ClusterIP, і вона буде доступна клієнтам всередині кластера за такою передбачуваною статичною DNS-адресою:

mynodeportservice.mynamespace.svc.cluster.local (або просто mynodeportservice.mynamespace)

Для кожного порту, який mynodeportservice прослуховує на вузлі, у діапазоні 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 Host) Kubeproxy передасть запит на порт 80 mynodeportservice.

LoadBalancer: Служби доступні всім, підключеним до Інтернету * (Загальна архітектура L4 LB є загальнодоступною в Інтернеті, розміщуючи її в DMZ або надаючи їй приватний і загальнодоступний IP-вузли, а вузли хостів k8s знаходяться в приватній підмережі)
( Примітка. Це єдиний тип сервісу, який не працює в 100% реалізації Kubernetes, як, наприклад, Kubernetes з чистого металу; він працює, коли Kubernetes має інтеграцію постачальників хмарних технологій.)

Якщо ви робите mylbservice, тоді буде породжений VM 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, отримує вузли? Також так *

Дозволяє провести паралель між Основами:
контейнер знаходиться всередині стручка. стручок знаходиться всередині реплікації. реплікація знаходиться всередині розгортання.
Так само:
Служба ClusterIP є частиною служби NodePort. Послуга NodePort є частиною служби балансування навантаження.

На цій діаграмі, яку ви показали, Клієнт був би стручком всередині кластера.

Припустимо, ви створили UMM Ubuntu на своїй локальній машині. Його IP-адреса - 192.168.1.104 .

Ви входите у VM та встановлюєте Kubernetes. Потім ви створили стручок, де на ньому працює зображення nginx.

1- Якщо ви хочете отримати доступ до цього струга nginx всередині вашого віртуального комп'ютера, ви створите, наприклад, кластер, пов'язаний з цим стручком:

$ 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 - це типовий сервіс у Kubernetes, який надає вам послугу всередині кластеру. Використовуючи це, інші програми з кластеру можуть отримати доступ до послуги через проксі-сервер Kubernetes.

Слід зазначити, що цей вид послуг не повинен використовуватися для викриття виробничих послуг. Однак його можна використовувати для

• налагодження інтеграції між службами;
• доступ до внутрішніх служб, які відкривають дані, пов’язані з бізнесом (моніторинг інформаційних панелей).

Шлях, що надходить до запиту, полягає в наступному: трафік -> проксі-сервер K8s -> служба K8s (ClusterIP) -> стручки і відображається на наступному малюнку.

2. NodePort - це найпримітивніший спосіб прийняти зовнішній трафік та переслати його сервісам kubernetes. Як випливає з назви, тип послуги NodePort відкриває певний порт для всіх Віртуальних машин, які насправді є вузлами Kubernetes, щоб дозволити трафік, який він відправляється на цей конкретний порт, пересилати до служби.

Тип послуги NodePort має деякі недоліки:

• необхідно мати лише один сервіс на порт;
• якщо ip віртуальної машини буде змінено, деякі зміни потрібно зробити в кластері;
• може використовуватися лише порт між 3000-32767

Цей запит йде наступним чином: трафік -> порт, відкритий на віртуальній машині -> служба K8s (NodePort) -> стручки, і він відображається на наступному малюнку:

3. LoadBalancer - це стандартний спосіб відкрити послугу в Інтернеті. Якщо ваше бажання полягає в тому, щоб безпосередньо піднести послугу і весь трафік на певному порту, який потрібно залишити для сервісу, то це такий спосіб зробити. Також тип послуги LoadBalancer не передбачає фільтрації та маршрутизації. Крім того, ви можете відправити на нього TCP, UDP, HTTP gRPC-трафік.

Нижня сторона: у кожної служби, що відкривається через LoadBalancer, буде своя IP-адреса, і кожна послуга буде виставлена ​​через одного LoadBalancer, який може стати дорогим.

Запит має такий шлях: трафік -> LoadBalancer -> Служба K8s -> стручки і відображається на наступному малюнку.

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

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

pod3 може спілкуватися з pod1 через свою кластерну мережу.

2. nodeport: щоб зробити доступними стручки ззовні кластера через nodeIP: nodeport, він створить / збереже кластерIP вище як свою мережу clusterIP.

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

Ви можете отримати доступ до служби на pod1 або через nodeIPA: nodeportX АБО nodeIPB: nodeportX. Будь-який спосіб буде працювати, тому що kube-proxy (який встановлений у кожному вузлі) отримає ваш запит і поширюватиме його [перенаправляти (термін iptables)] по вузлах, використовуючи кластерну мережу.

3. Балансир навантаження

в основному просто виставляючи LB попереду, так що вхідний трафік розподіляється на nodeIPA: nodeportX і nodeIPB: nodeportX, а потім продовжуйте з потоком процесу № 2 вище.