针对不同应用程序轨道的 Kubernetes 服务

Question

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

我可以想到几种方法来实现它，但都不是理想的:

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

  It is not necessary to use multiple namespaces just to separate slightly different resources, such as different versions of the same software: use labels to distinguish resources within the same namespace.

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

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

本质上，我想要的是一种告诉 Kubernetes 的方式，“仅将此服务的主机名公开给具有给定标签的 pod，并以给定的主机名将其公开给它们”用于特定服务。这将允许我使用第二种方法，而无需使用应用程序级逻辑来确定要使用的正确主机名。

实现我所追求的最佳方式是什么？

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

Answer 1

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

然后您可以使用硬编码的服务名称 - “http://myservice/” - 因为 DNS 将默认解析为本地命名空间。

对于 ingresses，我已经从 GitHub issue on cross-namespace ingresses 复制了我的答案。

您应该使用我们小组用于 Ingress 的方法。

不要把 Ingress 想象成 LoadBalancer，而只是一个文档，指定 URL 和服务之间的一些映射在同一个命名空间内。

一个例子，来 self 们使用的真实文档:

  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 在我们集群中的每个节点上最多运行一个，至少一个。

因此，流量随后被路由:

互联网 -> AWS ELB -> NGINX(在节点上) -> Pod

在按预期使用 Ingress 时，我们保持命名空间之间的隔离。使用一个入口来访问多个命名空间是不正确的，甚至是不明智的。考虑到它们的设计方式，这根本没有意义。解决方案是为每个命名空间使用一个入口，并使用一个集群范围的入口 Controller 来实际执行路由。

对于 Kubernetes，Ingress 是一个包含一些数据的对象。由 Ingress Controller 执行路由。

参见文档 here有关 Ingress Controller 的更多信息。