Kubernetes为不同的应用程序提供服务

Question

我正在使用Kubernetes开发应用程序部署环境,我希望能够基于主要Web应用程序的Git引用来启动整个应用程序堆栈的副本,​​例如"master"和"my-topic-branch".我希望应用程序堆栈的这些副本在同一个集群中共存.我可以创建Kubernetes服务,复制控制器和使用"gitRef"标签的pod来隔离堆栈,但堆栈中的一些pod相互依赖(通过Kubernetes服务),我看不到一种简单,干净的方式来限制暴露给pod的服务.

有两种方法可以实现,我可以想到,但两者都不理想:

• 将每个堆栈放在单独的Kubernetes命名空间中.这提供了最干净的隔离,因为没有资源名称冲突,并且应用程序可以拥有它们依赖于硬编码的服务的DNS主机名,但似乎违反了文档中关于命名空间的说明^†:

  没有必要使用多个名称空间来分隔略有不同的资源,例如同一软件的不同版本:使用标签来区分同一名称空间中的资源.

  这是有道理的,因为将应用程序堆栈放在不同的资源中会否定标签选择器的所有有用性.我只是使用Git引用命名命名空间,而根本不需要过滤所有其他资源.

• 为应用程序堆栈的每个副本创建每个服务的副本,例如"mysql-master"和"mysql-my-topic-branch".这样做的好处是,所有应用程序堆栈可以在同一名称空间中共存,但缺点是无法在需要它们的应用程序中对服务的DNS主机名进行硬编码,例如,如果Web应用程序的目标是主机名"mysql",则无论如何它实际解析的MySQL Kubernetes服务的哪个实例.我需要使用一些机制将正确的主机名注入pod中,或者让它们以某种方式自己解决.

基本上我想要的是一种告诉Kubernetes的方法,"将此服务的主机名仅公开给具有给定标签的pod,并使用给定的主机名将其公开给特定服务".这将允许我使用第二种方法,而无需使用应用程序级逻辑来确定要使用的正确主机名.

实现我追求的目标的最佳途径是什么？

[†] http://kubernetes.io/v1.1/docs/user-guide/namespaces.html

Answer 1

我认为有关将不同版本放在不同命名空间中的文档有点不正确.事实上,命名空间就像这样完全分开.您应该将应用程序的每个"跟踪"或部署阶段的完整版本放入其自己的命名空间中.

然后,您可以使用硬编码服务名称 - " http:// myservice / " - 因为DNS将默认解析为本地名称空间.

对于入口我已经在GitHub问题上复制了我的答案,关于跨命名空间的入口.

您应该使用我们小组用于Ingresses的方法.

可以认为Ingress不如LoadBalancer,只是一个文档,指定同一命名空间中的 URL和服务之间的一些映射.

一个例子,来自我们使用的真实文档:

  apiVersion: extensions/v1beta1
  kind: Ingress
  metadata:
    name: ingress
    namespace: dev-1
  spec:
    rules:
    - host: api-gateway-dev-1.faceit.com
      http:
        paths:
        - backend:
            serviceName: api-gateway
            servicePort: 80
          path: /
    - host: api-shop-dev-1.faceit.com
      http:
        paths:
        - backend:
            serviceName: api-shop
            servicePort: 80
          path: /
    - host: api-search-dev-1.faceit.com
      http:
        paths:
        - backend:
            serviceName: api-search
            servicePort: 8080
          path: /
    tls:
    - hosts:
      - api-gateway-dev-1.faceit.com
      - api-search-dev-1.faceit.com
      - api-shop-dev-1.faceit.com
      secretName: faceitssl

我们为每个轨道的每个命名空间创建其中一个.

然后,我们有一个带有Ingress Controller的命名空间,它运行自动配置的NGINX pod.另一个AWS负载均衡器指向这些在NodePort上运行的pod,使用DaemonSet最多运行并且至少在群集中的每个节点上运行一个.

因此,流量将被路由:

Internet - > AWS ELB - > NGINX(在节点上) - > Pod

我们在使用Ingress时保持名称空间之间的隔离.使用一个入口来命中多个名称空间是不正确甚至是明智的.鉴于它们的设计方式,它没有意义.解决方案是使用每个命名空间的一个入口和一个实际进行路由的集群范围入口控制器.

所有Ingress都是Kubernetes是一个包含一些数据的对象.由Ingress控制器来完成路由.

有关入口控制器的更多信息,请参阅此处的文档.