Я новичок в Kubernetes и у меня есть некоторые сомнения. Я установил кластер Kubernetes, состоящий из одного мастера / узла и одного узла. Я развернул очень простое приложение на основе NodeJS, используя Deployment вид с 2 репликами. Затем я представил его как услугу kubectl expose deployment my-app --port=80.
Теперь мои сервисы выглядят так:
root@sw-kubernetes01:~# kubectl get services
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
my-app 192.168.100.167 <none> 80/TCP 10m
kubernetes 192.168.100.1 <none> 443/TCP 1h
Предполагается, что я должен получить доступ к своему приложению, перейдя в http://192.168.100.167:? Я получаю ошибку тайм-аута. В противном случае, как я могу получить внешний IP-адрес для доступа к сервису извне?
Я знаю, что если я объявлю услугу как type: NodePort, Я могу получить доступ к своему приложению, используя IP-адрес узлов, не существует ли способа автоматической балансировки нагрузки между модулями?
Если вы работаете с локальным кластером, вы можете использовать --type=NodePort
kubectl expose deployment my-app --port=80 --type=NodePort
а затем grep для порта
kubectl get svc my-service -o yaml | grep nodePort
и вы можете просмотреть это, используя IP-адрес кластера и порт, который выводится из предыдущего результата grep.
Если вы работаете в GCE, EC2 или OpenStack, создание балансировщика нагрузки и создание балансировщика нагрузки обычно занимает минуту или две. EXTERNAL_IP поле для заполнения. IP-адрес в этом поле - это тот, который вы должны использовать для доступа к своей службе.
Если вы не используете GCE, EC2 или OpenStack, функция внешнего балансировщика нагрузки не будет работать для вас, поскольку Kubernetes не знает, как создать его в вашей среде.
Как уже было предложено в вопросе, вы можете получить доступ к NodePort сервис с использованием порта, предоставленного
kubectl get svc my-service -o yaml | grep nodePort
и любой из IP-адресов общедоступных узлов. Однако эти запросы не обязательно должны попадать на узел с IP-адресом, который вы использовали для запроса. Фактически, эти запросы маршрутизируются внутри кластера на любой из модулей, связанных с сервисом. Итак, здесь присутствует некоторая балансировка нагрузки.