【问题标题】:Kubernetes: how to expose multiple microservices?Kubernetes:如何暴露多个微服务?
【发布时间】:2020-06-18 19:19:29
【问题描述】:

我有一些 dockerized 微服务,每个都在某个端口上侦听 http 请求,并且我将这些部署形式化为 kubernetes yaml 文件

但是,我想不出一个可行的策略来在互联网上公开我的部署(就 kubernetes 服务而言)

每个部署都有多个副本,因此我假设每个部署都应该有一个匹配的负载均衡器服务以将其暴露给外部

现在我想不出将这些微服务明智地暴露在互联网上的策略......这就是我的想法:

  1. 整个集群暴露在一个域名上,服务是子域

    • 说集群在k8s.mydomain.com可用
    • 每个负载均衡器服务(公开相应的微服务)都应该可由子域访问
      • auth-server.k8s.mydomain.com
      • profile-server.k8s.mydomain.com
      • questions-board.k8s.mydomain.com
      • 因此对每个子域的请求将被负载平衡到匹配部署的副本
    • 那么我该如何实现这个设置呢?这是可取的吗?
      • 我可以将每个负载均衡器公开为一个子域吗?这是自动完成的吗?
      • 或者我需要入口控制器吗?
      • 我找错树了吗?
      • 我正在寻找有关如何公开作为微服务镶嵌的单个应用程序的一般建议
  2. 每个服务都暴露在同一个 ip/域上,但每个服务都有自己的端口

    • 也许整个集群都可以通过 k8s.mydomain.com 再次访问
    • 我可以将每个端口映射到不同的负载平衡器吗?
      • k8s.mydomain.com:8000 映射到 auth-server-loadbalancer
      • k8s.mydomain.com:8001 映射到 profile-server-loadbalancer
    • 这可能吗?与上面的策略 1 相比,它似乎不太稳健且不太理想
  3. 每个服务都暴露在自己的 ip/域上?

    • 也许每个服务都指定了一个静态 ip,而我的域有 A 记录以手动方式将每个子域指向每个这些 ip?
    • 我如何知道要使用哪个静态 IP?在生产中?在本地开发中?

也许我在概念化这个错误?整个 kubernetes 集群可以映射到一个 ip/domain 吗?

在 Kubernetes 中公开一堆微服务的最简单方法是什么?另一方面,在生产中公开微服务的最稳健/最理想的方式是什么?在 minikube 中,我是否需要不同的本地发展策略? (我只是要编辑/etc/hosts 很多)

谢谢你的建议,干杯

【问题讨论】:

    标签: docker kubernetes microservices


    【解决方案1】:

    我认为第一个选项是迄今为止最好的。

    您的Ingress 可能如下所示:

    apiVersion: networking.k8s.io/v1beta1
    kind: Ingress
    metadata:
      name: name-virtual-host-ingress
    spec:
      rules:
      - host: auth-server.k8s.mydomain.com
        http:
          paths:
          - backend:
              serviceName: service1
              servicePort: 80
      - host: profile-server.k8s.mydomain.com
        http:
          paths:
          - backend:
              serviceName: service2
              servicePort: 80
    
      - host: questions-board.k8s.mydomain.com
        http:
          paths:
          - backend:
              serviceName: service3
              servicePort: 80
    

    您可以在 Kubernetes 文档中阅读有关 IngressName based virtual hosting 的更多信息。

    您还可以使用多个Ingress Controllers,具体取决于您最终设置集群的位置。您提到您将在 Minikube 上进行测试,所以我认为 nginx ingress 将是一个不错的选择。

    如果您正在考虑管理您的流量,您可以考虑istio

    这是一个很好的指南Setting up HTTP(S) Load Balancing with Ingress 和另一个曾经Configuring Domain Names with Static IP Addresses

    【讨论】:

    • 非常感谢,按照您的建议,我已经成功地在 minikube 本地设置了这个入口(必须启用 minikube 附带的入口插件),然后也在 azure 上(必须使用 helm 安装 nginx-ingress) -- 干杯!
    【解决方案2】:

    第一种方法通常是每个人都遵循的格式,即每个微服务都有自己的子域。您可以使用 Kubernetes 入口实现相同的功能(例如 Nginx Ingress https://kubernetes.github.io/ingress-nginx/

    它们也不必在同一个域中,即您可以同时拥有*.example.com*.example2.com

    第二种方法无法扩展,因为可用端口数量有限,并且在非标准端口上运行也有其自身的问题。

    【讨论】:

      【解决方案3】:

      使用入口:

      https://kubernetes.io/docs/concepts/services-networking/ingress/#types-of-ingress

      通过入口,您可以将子域分配给不同的服务,或者您可以通过一些 url 重写来为不同上下文根下的所有服务提供服务。

      我不建议使用不同的端口公开服务。非标准端口还有其他问题。

      【讨论】:

        猜你喜欢
        • 2016-03-25
        • 2019-02-17
        • 2021-10-04
        • 2020-08-11
        • 2021-08-13
        • 1970-01-01
        • 1970-01-01
        • 2017-04-16
        • 2018-11-21
        相关资源
        最近更新 更多