Kubernetes、GCE、负载均衡、SSL
Kubernetes, GCE, Load balancing, SSL
作为序言，我正在研究 GCE 和 Kuberenetes。我的目标只是通过 SSL 公开集群上的所有微服务。理想情况下，它的工作方式与您通过 type=‘LoadBalancer’ 公开部署并获得单个外部 IP 时的工作方式相同。这是我的目标，但 SSL 不适用于那些基本的负载均衡器。
根据我的研究，目前最好的解决方案是设置一个 nginx 入口控制器，使用入口资源和服务来公开我的微服务。下面是我根据自己对这个过程的理解画的图。
我已经掌握了这一切来成功地通过 HTTP 工作。我从这里部署了默认的 nginx 控制器：https://github.com/kubernetes/contrib/tree/master/ingress/controllers/nginx。以及默认后端和默认后端服务。我自己的微服务的入口有规则设置为我的域名和路径：/。
这是成功的，但有两件事让我有点困惑。
当为我的后端（微服务）公开服务资源时，我遵循的一个指南使用了 type=‘NodePort’，而另一个只是放置了一个端口来访问服务。两者都将目标端口设置为后端应用程序端口。我尝试了这两种方式，它们似乎都有效。指南一来自上面的 link。指南 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 发出网络请求时，一切都会挂起。我在我的防火墙规则上打开了 443，这似乎有效，但是我会点击我的默认后端而不是我的微服务。
阅读让我从 Kubernetes 文档中了解到：目前 Ingress 资源仅支持 http 规则。
这也许可以解释为什么我会点击默认后端，因为我的规则仅适用于 HTTP。但如果是这样，我应该如何将这种方法用于 SSL？
我注意到的另一件事是，如果我编写一个没有规则的入口资源并为其提供我想要的后端，我仍然会被定向到我原来的默认后端。这更奇怪，因为 kubectl describe ing updated 并声明我的默认后端是我想要的后端...
任何帮助或指导将不胜感激。谢谢！
因此，对于 #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 部署上来覆盖它。 This article 对此有很好的解释。
kubernetes docs 很好地描述了 NodePort 的含义 - 基本上，该服务将从集群中每个节点上的高范围分配一个端口，节点将从该端口到您的服务。这是在不同环境中设置负载均衡器的一种方法，但对于您的方法而言，这不是必需的。您可以省略微服务服务的 type 字段，它将被分配默认类型，即 ClusterIP.
至于 SSL，它可能是一些不同的东西。我会确保您已经按照他们在 nginx controller docs 中描述的那样设置了 Secret，例如 tls.cert 和 tls.key 字段。
我还会检查 nginx 控制器的日志 - 找出它是哪个 pod 运行 和 kubectl get pods 一样，然后跟踪它的日志：kubectl logs nginx-pod-<some-random-hash> -f。这将有助于查明您是否配置错误，例如服务是否没有配置任何端点。大多数时候我搞砸了入口的东西，这是由于 Services/Deployments 的一些非常基本的错误配置。
您还需要为指向 LoadBalancer 的静态 IP 的主机名设置 DNS 记录，或者使用 cURL 的 -H flag as they do in the docs ping 您的服务，否则您可能最终会得到路由到默认后端 404.
直接回答你的问题，因为这就是重点...免责声明：我是一个新手，所以对这一切持保留态度。
关于#2，下面的博客 post 我 link 建议以下架构：
- 创建部署 nginx 控制器的部署 pods
- 创建类型为 LoadBalancer 的服务和将流量路由到控制器的静态 IP pods
- 创建一个供 nginx 控制器使用的入口资源 pods
- 创建一个由 nginx 控制器使用的秘密 pods 来终止 SSL
- 还有其他东西
据我了解，http 与 https 的问题发生在 nginx 控制器 pods 上。我所有的入口规则也是 http，但是 nginx 入口控制器强制使用 SSL 并处理所有这些，在控制器处终止 SSL，以便它下面的所有东西，所有入口的东西，都可以是 HTTP。我拥有所有的 http 规则，但我通过 LoadBalancer 服务的所有流量都被迫使用 SSL。
再说一次，我是个 n00b。对这一切持保留态度。我说的是外行人的话，因为我是一个外行人，试图弄清楚这一切。
我在寻找我自己的问题的一些答案时遇到了你的问题。我 运行 遇到了很多你 运行 遇到的相同问题（考虑到已经过去的时间，我假设是过去时）。我想向您（and/or 其他有类似问题的人）推荐一个博客 post，我发现它在学习 nginx 控制器时很有帮助。到目前为止（我仍处于早期阶段并且正在使用 post），post 中的所有内容都有效。
你现在可能已经过了这些东西，因为已经过去几个月了。但也许这会对其他人有所帮助，即使它对您没有帮助：
https://daemonza.github.io/2017/02/13/kubernetes-nginx-ingress-controller/
它帮助我了解了需要创建哪些资源，如何部署控制器pods，以及如何公开控制器pods（为控制器创建一个 LoadBalancer 服务pods 使用静态 IP），并强制使用 SSL。它帮助我跨越了几个障碍并通过了 "how do all the moving parts fit together"。
Kubernetes 技术文档对于如何使用每个部分很有帮助，但不一定像这个博客 post 那样将它们全部列出并拼凑在一起。免责声明：尽管博客 post 中的模型可能不是最好的方法（我没有足够的经验来进行调用），但它确实帮助我至少获得了一个 nginx 的工作示例强制使用 SSL 的入口控制器。
希望这最终能对某人有所帮助。
安德鲁
作为序言，我正在研究 GCE 和 Kuberenetes。我的目标只是通过 SSL 公开集群上的所有微服务。理想情况下，它的工作方式与您通过 type=‘LoadBalancer’ 公开部署并获得单个外部 IP 时的工作方式相同。这是我的目标，但 SSL 不适用于那些基本的负载均衡器。
根据我的研究，目前最好的解决方案是设置一个 nginx 入口控制器，使用入口资源和服务来公开我的微服务。下面是我根据自己对这个过程的理解画的图。
我已经掌握了这一切来成功地通过 HTTP 工作。我从这里部署了默认的 nginx 控制器：https://github.com/kubernetes/contrib/tree/master/ingress/controllers/nginx。以及默认后端和默认后端服务。我自己的微服务的入口有规则设置为我的域名和路径：/。
这是成功的，但有两件事让我有点困惑。
当为我的后端（微服务）公开服务资源时，我遵循的一个指南使用了 type=‘NodePort’，而另一个只是放置了一个端口来访问服务。两者都将目标端口设置为后端应用程序端口。我尝试了这两种方式，它们似乎都有效。指南一来自上面的 link。指南 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 发出网络请求时，一切都会挂起。我在我的防火墙规则上打开了 443，这似乎有效，但是我会点击我的默认后端而不是我的微服务。
阅读让我从 Kubernetes 文档中了解到：目前 Ingress 资源仅支持 http 规则。 这也许可以解释为什么我会点击默认后端，因为我的规则仅适用于 HTTP。但如果是这样，我应该如何将这种方法用于 SSL？
我注意到的另一件事是，如果我编写一个没有规则的入口资源并为其提供我想要的后端，我仍然会被定向到我原来的默认后端。这更奇怪，因为 kubectl describe ing updated 并声明我的默认后端是我想要的后端...
任何帮助或指导将不胜感激。谢谢！
因此，对于 #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 部署上来覆盖它。 This article 对此有很好的解释。
kubernetes docs 很好地描述了 NodePort 的含义 - 基本上，该服务将从集群中每个节点上的高范围分配一个端口，节点将从该端口到您的服务。这是在不同环境中设置负载均衡器的一种方法，但对于您的方法而言，这不是必需的。您可以省略微服务服务的 type 字段，它将被分配默认类型，即 ClusterIP.
至于 SSL，它可能是一些不同的东西。我会确保您已经按照他们在 nginx controller docs 中描述的那样设置了 Secret，例如 tls.cert 和 tls.key 字段。
我还会检查 nginx 控制器的日志 - 找出它是哪个 pod 运行 和 kubectl get pods 一样，然后跟踪它的日志：kubectl logs nginx-pod-<some-random-hash> -f。这将有助于查明您是否配置错误，例如服务是否没有配置任何端点。大多数时候我搞砸了入口的东西，这是由于 Services/Deployments 的一些非常基本的错误配置。
您还需要为指向 LoadBalancer 的静态 IP 的主机名设置 DNS 记录，或者使用 cURL 的 -H flag as they do in the docs ping 您的服务，否则您可能最终会得到路由到默认后端 404.
直接回答你的问题，因为这就是重点...免责声明：我是一个新手，所以对这一切持保留态度。
关于#2，下面的博客 post 我 link 建议以下架构：
- 创建部署 nginx 控制器的部署 pods
- 创建类型为 LoadBalancer 的服务和将流量路由到控制器的静态 IP pods
- 创建一个供 nginx 控制器使用的入口资源 pods
- 创建一个由 nginx 控制器使用的秘密 pods 来终止 SSL
- 还有其他东西
据我了解，http 与 https 的问题发生在 nginx 控制器 pods 上。我所有的入口规则也是 http，但是 nginx 入口控制器强制使用 SSL 并处理所有这些，在控制器处终止 SSL，以便它下面的所有东西，所有入口的东西，都可以是 HTTP。我拥有所有的 http 规则，但我通过 LoadBalancer 服务的所有流量都被迫使用 SSL。
再说一次，我是个 n00b。对这一切持保留态度。我说的是外行人的话，因为我是一个外行人，试图弄清楚这一切。
我在寻找我自己的问题的一些答案时遇到了你的问题。我 运行 遇到了很多你 运行 遇到的相同问题（考虑到已经过去的时间，我假设是过去时）。我想向您（and/or 其他有类似问题的人）推荐一个博客 post，我发现它在学习 nginx 控制器时很有帮助。到目前为止（我仍处于早期阶段并且正在使用 post），post 中的所有内容都有效。
你现在可能已经过了这些东西，因为已经过去几个月了。但也许这会对其他人有所帮助，即使它对您没有帮助：
https://daemonza.github.io/2017/02/13/kubernetes-nginx-ingress-controller/
它帮助我了解了需要创建哪些资源，如何部署控制器pods，以及如何公开控制器pods（为控制器创建一个 LoadBalancer 服务pods 使用静态 IP），并强制使用 SSL。它帮助我跨越了几个障碍并通过了 "how do all the moving parts fit together"。
Kubernetes 技术文档对于如何使用每个部分很有帮助，但不一定像这个博客 post 那样将它们全部列出并拼凑在一起。免责声明：尽管博客 post 中的模型可能不是最好的方法（我没有足够的经验来进行调用），但它确实帮助我至少获得了一个 nginx 的工作示例强制使用 SSL 的入口控制器。
希望这最终能对某人有所帮助。
安德鲁