Minikube上的Kubernetes Ingress Nginx失败 [英] Kubernetes Ingress nginx on Minikube fails

查看:279
本文介绍了Minikube上的Kubernetes Ingress Nginx失败的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在Ubuntu 18.04上的minikube v1.13.0和在Docker 19.03.8上的Kubernetes v1.19.0.使用helm/helmfile("v3.3.4").Ubuntu VM在Win10上运行的VM-Workstation上,网络设置为NAT,所有内容都在我的家庭wifi网络中.

我正在尝试使用 ingress-backend stable/nginx-ingress 1.36.0 .我的确在ingress/charts文件夹中有 nginx-ingress-1.36.0.tgz ,并且我有ingress/启用了 minikube插件启用了ingress .

在启用minikube上的入口之前,所有内容都将成功部署(没有错误),但是服务/LB仍处于待处理状态:

  ClusterIP 10.101.41.156< none>8080/TCP入口控制器-nginx-入口控制器-控制器LoadBalancer 10.98.157.222< pending>80:30050/TCP,443:32294/TCP 

在minikube上启用入口之后,现在出现此连接被拒绝错误:

  STDERR:错误:升级失败:无法修补"ingress-service"服务与Ingress类型:发生内部错误:调用webhook"validate.nginx.ingress.kubernetes.io"失败:发布"https://ingress-nginx-controller-admission.kube-system.svc:443/extensions/v1beta1/ingresses?timeout= 30s":拨打tcp 10.105.131.220:443:connect:连接被拒绝组合输出:错误:升级失败:无法修补"ingress-service"服务与Ingress类型:发生内部错误:调用webhook"validate.nginx.ingress.kubernetes.io"失败:发布"https://ingress-nginx-controller-admission.kube-system.svc:443/extensions/v1beta1/ingresses?timeout= 30s":拨打tcp 10.105.131.220:443:connect:连接被拒绝 

我不知道IP 10.105.131.220是什么-看起来像pvt IP .不是我的minikube IP,VM IP或笔记本电脑IP,我无法对其进行ping操作.

但是一切仍然可以正常部署-但负载均衡器仍显示待处理.

更新

基于文档,我错过了其中一个步骤

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

我停止/删除了Minkube并重做了所有内容,现在错误消失了,但是负载均衡器仍然是< pending>

解决方案

默认情况下,所有 minikube 之类的解决方案都不会为您提供 LoadBalancer .云解决方案(如EKS,Google Cloud,Azure)通过在后台单独的LB中旋转来自动为您完成.这就是为什么您看到待处理状态的原因.

解决方案:

  1. 使用在minikube上使用MetalLB

MetalLB 挂接到您的Kubernetes集群中,并提供网络负载均衡器实现.简而言之,它允许您在未在云提供商上运行的集群中创建类型为 LoadBalancer 的Kubernetes服务,因此不能简单地使用付费产品提供负载均衡器.

安装:

  kubectl apply -f https://raw.githubusercontent.com/google/metallb/v0.8.1/manifests/metallb.yaml创建名称空间/metallb系统podsecuritypolicy.policy/扬声器创建服务帐户/控制器已创建服务帐户/发言人已创建clusterrole.rbac.authorization.k8s.io/metallb-system:控制器已创建clusterrole.rbac.authorization.k8s.io/metallb-system:扬声器已创建创建了role.rbac.authorization.k8s.io/config-watcherclusterrolebinding.rbac.authorization.k8s.io/metallb-system:控制器已创建clusterrolebinding.rbac.authorization.k8s.io/metallb-system:扬声器已创建已创建rolebinding.rbac.authorization.k8s.io/config-watcher 

  1. 使用 minikube隧道

LoadBalancer类型的服务可以通过minikube隧道公开命令.它必须在单独的终端窗口中运行,以保持LoadBalancer正在运行.终端中的Ctrl-C可用于终止清理网络路由的过程.

minikube隧道作为一个进程运行,使用群集的IP在主机上创建到群集的服务CIDR的网络路由地址作为网关.tunnel命令公开外部IP直接访问主机操作系统上运行的任何程序.

minikube v1.13.0 on Ubuntu 18.04 with Kubernetes v1.19.0 on Docker 19.03.8. Using helm/helmfile ("v3.3.4"). The Ubuntu VM is on VM-Workstation running on Win10, networking set as NAT, everything in my home wifi network.

I am trying to use ingress-backend stable/nginx-ingress 1.36.0 . I do have the nginx-ingress-1.36.0.tgz in the ingress/charts folder, and I have ingress/enabled minikube addons enable ingress.

Before I had enabled ingress on minikube, everything will get deployed successfully (no errors) but the service/LB stayed pending:

  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 

After I enabled ingress on minikube, I now get this connection refused error:

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

I don't know what is this IP 10.105.131.220 - looks like pvt IP. It is not my minikube IP, or my VM IP or my laptop IP, I cant ping it.

But it all still deploys fine- but the Load Balancer still shows pending.

Update

I had missed one of the Steps based on documentation

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

I stopped/deleted minkube and redid everything, now the error is gone, but the loadbalancer is still <pending>

解决方案

By default all solutions like minikube does not provide you LoadBalancer. Cloud solutions like EKS, Google Cloud, Azure do it for you automatically by spinning in the background separate LB. Thats why you see Pending status.

Solutions:

  1. use MetalLB on minikube

MetalLB hooks into your Kubernetes cluster, and provides a network load-balancer implementation. In short, it allows you to create Kubernetes services of type LoadBalancer in clusters that don’t run on a cloud provider, and thus cannot simply hook into paid products to provide load-balancers.

Installation:

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. use minikube tunnel

Services of type LoadBalancer can be exposed via the minikube tunnel command. It must be run in a separate terminal window to keep the LoadBalancer running. Ctrl-C in the terminal can be used to terminate the process at which time the network routes will be cleaned up.

minikube tunnel runs as a process, creating a network route on the host to the service CIDR of the cluster using the cluster’s IP address as a gateway. The tunnel command exposes the external IP directly to any program running on the host operating system.

这篇关于Minikube上的Kubernetes Ingress Nginx失败的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆