首页 文章

Kubernetes，GCE，负载均衡，SSL

提问于
浏览 次
4

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

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

enter image description here

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

这很成功，但有两件事让我感到困惑 .

  • 当暴露我的后端（微服务）的服务资源时，我跟着使用了一个指南type ='NodePort'而另一个只是放了一个端口来到达服务 . 两者都将目标端口设置为后端应用程序端口 . 我尝试了两种方式，它们似乎都有效 . 指南一来自上面的链接 . 指南2：http://blog.kubernetes.io/2016/03/Kubernetes-1.2-and-simplifying-advanced-networking-with-Ingress.html . 这有什么区别？

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

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

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

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

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

ssl nginx load-balancing kubernetes

2 回答

  • 5

    因此，对于＃2，你've probably ended up provisioning a Google HTTP(S) LoadBalancer, probably because you'缺少 kubernetes.io/ingress.class: "nginx" 注释，如下所述：https://github.com/kubernetes/contrib/tree/master/ingress/controllers/nginx#running-multiple-ingress-controllers .

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

    kubernetes docs对 NodePort 的含义有很好的描述 - 基本上，服务将在群集中的每个节点上从高范围分配端口，节点将从该端口转发流量到您的服务 . 它没有必要's one way of setting up load balancers in different environments, but for your approach it' . 您可以省略微服务服务的 type 字段，并为其分配默认类型，即 ClusterIP .

    至于SSL，它可能是一些不同的东西 . 我会确保你已经按照他们在nginx controller docs中的描述设置了秘密，例如使用 tls.cert 和 tls.key 字段 .

    我'd also check the logs of the nginx controller - find out which pod it'与 kubectl get pods 一样运行，然后尾随它的日志： kubectl logs nginx-pod-<some-random-hash> -f . 这将有助于找出你是否搞砸了入口的东西，这是由于服务/部署的一些非常基本的错误配置 .

    您'll also need to set up a DNS record for your hostname pointed at the LoadBalancer'的静态IP，或者使用cURL的 -H flag as they do in the docs ping您的服务，否则您最终可能会被路由到默认的后端404 .

    回复于
  • 1

    直接回答你的问题，因为这就是重点......免责声明：我是一个n00b，所以要把这一切都拿出来 .

    关于＃2，我链接到下面的博客文章提出了以下架构：

    • 创建部署nginx控制器窗格的部署

    • 使用LoadBalancer类型和将流量路由到控制器窗格的静态IP创建服务

    • 创建由nginx控制器窗格使用的入口资源

    • 创建一个由nginx控制器pod使用以终止SSL的秘密

    • 和其他东西一样

    根据我的理解，http vs https的内容与nginx控制器pod一起发生 . 我的所有入口规则也都是http，但是nginx入口控制器强制使用SSL并处理所有这些，在控制器上终止SSL，以使其下面的所有内容（所有入口内容）都可以是HTTP . 我有所有的http规则，但我通过LoadBalancer服务的所有流量都被迫使用SSL .

    再一次，我是一个n00b . 拿这一切都是一粒盐 . 我说的是外行人的说法，因为我是一个外行人试图弄清楚这一切 .

    我在寻找自己的答案时遇到了你的问题的问题 . 我遇到了很多你遇到的相同问题（考虑到已经过去的时间，我假设过去时） . 我想指出你（和/或其他有类似问题的人）到博客文章，我发现在学习nginx控制器时很有帮助 . 到目前为止（我还处于早期阶段和使用帖子的中间），帖子中的所有内容都有效 .

    你可能已经过了这个东西，现在已经过了几个月了 . 但也许这会帮助别人，即使它没有帮助你：

    https://daemonza.github.io/2017/02/13/kubernetes-nginx-ingress-controller/

    它帮助我了解需要创建哪些资源，如何部署控制器pod，以及如何公开控制器pod（使用静态IP为控制器pod创建LoadBalancer服务），还强制使用SSL . 它帮助我跳过了几个障碍并超越了“所有运动部件如何组合在一起” .

    Kubernetes技术文档对于如何使用每个部分很有帮助，但并不一定就像这篇博文所做的那样全部拼出来 . 免责声明：博客文章中的模型可能不是最好的方式（我没有足够的经验来进行调用），但它确实帮助我至少得到一个强制的nginx入口控制器的工作示例SSL .

    希望这最终有助于某人 .

    安德鲁

    回复于

相关问题