Пожалуйста, пример Kubernetes внешний адрес против внутренних адресов

Question

В среде vmware должен ли внешний адрес заполняться IP-адресом виртуальной машины (или хостов)?

У меня есть три кластера, и я обнаружил, что только те, кто использует «облачного провайдера», имеют внешние адреса при запуске kubectl get nodes -o wide. Насколько я понимаю, плагин «провайдера облака» (GCP, AWS, Vmware и т. Д.) - это то, что назначает публичный IP-адрес для узла.

KOPS развернут на GCP = внешний адрес - это реальные общедоступные IP-адреса узлов.

Kubeadm развернут на vwmare с использованием облачного провайдера vmware = внешний адрес совпадает с внутренним адресом (частный диапазон).

Kubeadm развернут, НЕТ облачного провайдера = нет внешнего ip.

Я спрашиваю, потому что у меня есть инструмент, который очищает / api / v1 / node и затем взаимодействует с каждым хостом, который находит, используя "внешний ip". Это работает только с моими первыми двумя кластерами.

Мой инструмент работает в локальной сети кластеров. Должен ли он быть нацелен на «внутренний ip»? Другими словами, является ли внутренний ip ВСЕГДА IP-адресом виртуальной машины или физического хоста (при установке на голое железо).

Спасибо

Answer 1

Baremetal не будет иметь "extrenal-IP" для узлов, а "internal-ip" будет IP-адресом узлов.Вы запускаете команду из той же сети для вашего локального кластера, поэтому вы должны иметь возможность использовать этот внутренний IP-адрес для доступа к узлам по мере необходимости.

При использовании k8s на baremetal внешние IP и функции loadbalancer не работаютне существует изначально.Если вы хотите выставить «Внешний IP», заключите его в кавычки, потому что в большинстве случаев это все еще будет адрес 10.XXX, из вашего кластера без метала вам нужно будет установить что-то вроде MetalLB.

https://github.com/google/metallb