Kubernetes,GCE,负载均衡,SSL

Ste*_*eve 5 ssl load-balancing nginx kubernetes

为了序言,我正在研究GCE和Kuberenetes.我的目标只是通过SSL公开我的集群上的所有微服务.理想情况下,它与通过type ='LoadBalancer'公开部署并获得单个外部IP时的工作方式相同.这是我的目标,但SSL不适用于那些基本负载均衡器.

根据我的研究,目前最好的解决方案是建立一个nginx入口控制器,使用入口资源和服务来公开我的微服务.下面是我对这个过程的理解所绘制的图表.

在此输入图像描述

我已经把这一切都成功地通过HTTP工作了.我从这里部署了默认的nginx控制器:https://github.com/kubernetes/contrib/tree/master/ingress/controllers/nginx.以及默认后端的默认后端和服务.我自己的微服务的入口有规则设置为我的域名和路径:/.

这是成功的,但有两件事让我感到困惑.

  1. 当我为后端(微服务)公开服务资源时,我使用了一个指南type ='NodePort',另一个只是放了一个端口来访问服务.两者都将目标端口设置为后端应用程序端口.我尝试了这两种方式,它们似乎都有效.指南一来自上面的链接.指南2:http://blog.kubernetes.io/2016/03/Kubernetes-1.2-and-simplifying-advanced-networking-with-Ingress.html.这有什么区别?

  2. 另一个困惑点是我的入口总是有两个IP.我最初的思考过程是应该只有一个外部ip,这将击中我的入口,然后由nginx指导路由.或者是ip直接到nginx?无论如何,创建的第一个IP地址似乎给了我预期的结果,因为访问第二个IP失败了.

尽管我的困惑,似乎在HTTP上工作得很好.通过HTTPS而不是那么多.起初,当我通过https发出Web请求时,事情就会挂起.我在我的防火墙规则上打开了443,这似乎有效但我会打到我的默认后端而不是我的微服务.

阅读引导我从Kubernetes docs:目前Ingress资源只支持http规则.这可以解释为什么我要使用默认后端,因为我的规则仅适用于HTTP.但是,如果是这样,我应该如何使用这种方法进行SSL?

我注意到的另一件事是,如果我编写一个没有规则的入口资源并给它我想要的后端,我仍然会被定向到我原来的默认后端.这更奇怪,因为kubectl描述更新并声明我的默认后端是我想要的后端...

任何帮助或指导将不胜感激.谢谢!

小智 5

因此,对于#2,您可能最终配置了Google HTTP(S)LoadBalancer,可能是因为您缺少kubernetes.io/ingress.class: "nginx"此处所述的注释:https://github.com/kubernetes/contrib/tree/master/ingress/controllers/nginx#running-multiple-ingress-controllers.

GKE拥有自己的入口控制器,您需要通过在nginx部署上粘贴该注释来覆盖它.这篇文章对这些东西有很好的解释.

kubernetes文档有什么不错的描述NodePort手段-基本上,该服务将从高范围分配在群集中的每个节点端口和节点会转发流量从该端口为你服务.这是在不同环境中设置负载平衡器的一种方法,但对于您的方法,这不是必需的.您可以省type略微服务服务的字段,并为其分配默认类型,即ClusterIP.

至于SSL,它可能是一些不同的东西.我会确保你已经像在nginx控制器文档中描述的那样设置了秘密,例如使用tls.certtls.key字段.

我还要检查nginx控制器的日志 - 找出它正在运行的pod kubectl get pods,然后拖尾它的日志:kubectl logs nginx-pod-<some-random-hash> -f.这将有助于确定您是否错误配置了任何内容,例如服务是否配置了任何端点.大多数时候我搞砸了入口的东西,这是由于服务/部署的一些非常基本的错误配置.

您还需要为指向LoadBalancer的静态IP的主机名设置DNS记录,或者使用cURL的-H 标记 ping您的服务,就像在文档中一样,否则您最终可能会被路由到默认的后端404.