Блог

Главная - Вопросы по программированию - Сбой входа Kubernetes в nginx на Minikube

Сбой входа Kubernetes в nginx на Minikube

#networking #kubernetes #kubernetes-helm #kubernetes-ingress #minikube

#сеть #kubernetes #kubernetes-рулевой #kubernetes-вход #minikube

Вопрос:

minikube версии v1.13.0 в Ubuntu 18.04 с Kubernetes версии v1.19.0 в Docker 19.03.8. С использованием helm / helmfile («v3.3.4»). Виртуальная машина Ubuntu находится на виртуальной рабочей станции, работающей на Win10, сеть установлена как NAT, все в моей домашней сети Wi-Fi.

Я пытаюсь использовать ingress-backend stable/nginx-ingress 1.36.0 . У меня есть nginx-ingress-1.36.0.tgz в папке ingress / charts, и у меня включен ingress / enabled minikube addons enable ingress .

До того, как я включил вход в minikube, все будет успешно развернуто (без ошибок), но service / LB остался в ожидании:

   ClusterIP      10.101.41.156    <none>        8080/TCP  

    ingress-controller-nginx-ingress-controller        LoadBalancer   10.98.157.222    <pending>     80:30050/TCP,443:32294/TCP

После того, как я включил вход в minikube, теперь я получаю эту connection refused ошибку:

 STDERR:
Error: UPGRADE FAILED: cannot patch "ingress-service" with kind Ingress: 
    Internal error occurred: failed calling webhook "validate.nginx.ingress.kubernetes.io": Post "https://ingress-nginx-controller-admission.kube-system.svc:443/extensions/v1beta1/ingresses?timeout=30s": 
    dial tcp 10.105.131.220:443: connect: connection refused
        
COMBINED OUTPUT:
Error: UPGRADE FAILED: cannot patch "ingress-service" with kind Ingress: 
    Internal error occurred: failed calling webhook "validate.nginx.ingress.kubernetes.io": Post "https://ingress-nginx-controller-admission.kube-system.svc:443/extensions/v1beta1/ingresses?timeout=30s":
     dial tcp 10.105.131.220:443: connect: connection refused

Я не знаю, что это за IP 10.105.131.220 — похоже на pvt IP. Это не мой IP-адрес minikube, или мой IP-адрес виртуальной машины, или IP-адрес моего ноутбука, я не могу его пропинговать.

Но все по-прежнему развертывается нормально, но балансировщик нагрузки все еще показывает pending .

Обновить

Я пропустил один из шагов, основанных на документации

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.30.0/deploy/static/mandatory.yaml

Я остановил / удалил minkube и все переделал, теперь ошибка исчезла, но балансировщик нагрузки по-прежнему <pending>

Ответ №1:

По умолчанию все подобные решения minikube вам не предоставляются LoadBalancer . Облачные решения, такие как EKS, Google Cloud, Azure, делают это за вас автоматически, вращая в фоновом режиме отдельный LB. Вот почему вы видите Pending статус.

Решения:

  1. используйте MetalLB на minikube

MetalLB подключается к вашему кластеру Kubernetes и предоставляет реализацию балансировки сетевой нагрузки. Короче говоря, это позволяет создавать сервисы типа Kubernetes LoadBalancer в кластерах, которые не работают на облачном провайдере и, следовательно, не могут просто подключаться к платным продуктам для обеспечения балансировки нагрузки.

Установка:

 kubectl apply -f https://raw.githubusercontent.com/google/metallb/v0.8.1/manifests/metallb.yaml

namespace/metallb-system created
podsecuritypolicy.policy/speaker created
serviceaccount/controller created
serviceaccount/speaker created
clusterrole.rbac.authorization.k8s.io/metallb-system:controller created
clusterrole.rbac.authorization.k8s.io/metallb-system:speaker created
role.rbac.authorization.k8s.io/config-watcher created
clusterrolebinding.rbac.authorization.k8s.io/metallb-system:controller created
clusterrolebinding.rbac.authorization.k8s.io/metallb-system:speaker created
rolebinding.rbac.authorization.k8s.io/config-watcher created
  1. используйте туннель minikube

Службы типа LoadBalancer могут быть доступны с помощью команды туннелирования minikube. Он должен быть запущен в отдельном окне терминала, чтобы поддерживать работу балансировщика нагрузки. Ctrl-C в терминале можно использовать для завершения процесса, после чего сетевые маршруты будут очищены.

minikube tunnel выполняется как процесс, создавая сетевой маршрут на хосте к службе CIDR кластера, используя IP-адрес кластера в качестве шлюза. Команда туннелирования предоставляет внешний IP-адрес непосредственно любой программе, запущенной в операционной системе хоста.

Комментарии:

1. Спасибо, хорошо, я попробую MetalLB. И да, мое первоначальное понимание заключалось в том, что вам нужен облачный провайдер, чтобы получить балансировщик нагрузки, но в некоторой документации указано, что я мог бы сделать это с помощью nginx / ingress. Итак, что в этом хорошего — как / для чего я использую этот nginx / ingress?

2. я считаю, что вам лучше создать второе сообщение и спросить там цель использования nginx / ingress. Огромная тема, и у вас будет много мнений и объяснений. Этот вопрос касается Pending состояния в необлачных решениях

3. Пытался внедрить metallb, пришлось модифицировать мой файл helmfile. Пришлось использовать bitnami / stable. После всего этого: MetalLB is now running in the cluster . ingress-backend bitnami/metallb 0.1.24 . LoadBalancer Services in your cluster are now available on the IPs you defined in MetalLB's configuration . ingress-backend default metallb-0.1.24 0.9.3 . Но я не вижу никакого созданного балансировщика kubectl get services -o wide --all-namespaces нагрузки — я получаю все остальное, но не создан балансировщик нагрузки. Поэтому придется отлаживать / исследовать.

4. Попробовал hello world, как в ссылке, не сработало — балансировщик нагрузки показывает <ожидание> nginx LoadBalancer 10.111.44.136 <pending> 80:31009/TCP 10m

5. настроена карта конфигурации ?