在 Kubernetes 中路由内部流量？答案

【问题标题】：Routing internal traffic in Kubernetes?在 Kubernetes 中路由内部流量？
【发布时间】：2017-10-12 16:06:29
【问题描述】：

我们目前有一个设置，我们的 mesos/marathon 集群中的应用程序希望访问可能驻留在或不驻留在 mesos/marathon 集群中的服务。外部流量进入集群是通过位于 Traefik 实例集群前面的 Amazon ELB 完成的，然后它通过传入的 HTTP Host 标头选择适当的容器实例集进行负载平衡，与本质上是多对多- 一个配置的主机头与特定容器实例的关联。内部到内部的流量实际上也由相同的路由处理，因为与给定服务关联的 DNS 记录映射到我们的 mesos/marathon 集群内部和外部的同一个 ELB。我们还可以让多个 DNS 记录指向同一个容器集。

此设置有效，但会导致看似不必要的网络流量和对我们的 ELB 以及 Traefik 集群的负载，好像容器中的应用程序或其他组件能够自行确定他们希望调用的服务位于他们所在的特定 mesos/marathon 集群中，并适当地调用集群内部位于容器集前面的东西，或直接调用特定容器本身。

根据我对 Kubernetes 的理解，Kubernetes 提供了服务的概念，它本质上可以作为一组 pod 的前端，基于服务应该匹配哪些 pod 的配置。但是，我不完全确定我们可以让 Kubernetes 集群中的应用程序透明地知道将网络流量引导到服务 IP 的机制。我认为可以通过将 Envoy 代理流量用于服务名称（例如，<application-name>.<cluster-name>.company.com）来解决其中的一些问题，但是如果我们有一个映射到之前的 DNS 条目的 CNAME（例如， <application-name>.company.com)，我不完全确定如何避免退出集群。

有没有解决这两种情况的好方法？我们试图避免让我们的应用程序的逻辑必须了解它位于特定的集群中，并且希望应用程序之外的组件能够适当地执行路由。

如果我从根本上误解了某个特定组件，我将非常感谢您的指正！

【问题讨论】：

标签： kubernetes istio envoyproxy

【解决方案1】：

当您在集群中使用服务到服务通信时，您使用的是Service 抽象，它类似于一个静态点，它将流量引导到正确的 pod。

服务端点只能在集群内部通过其 IP 或内部 DNS 名称使用，由内部 Kubernetes DNS 服务器提供。因此，为了在集群内部进行通信，您可以使用像 <servicename>.<namespace>.svc.cluster.local 这样的 DNS 名称。

但是，更重要的是，Service 有一个静态 IP 地址。

所以，现在您可以将该静态 IP 作为 hosts 记录添加到集群内的 Pod 中，以确保它们将在集群内相互通信。

为此，您可以使用HostAlias 功能。下面是一个配置示例：

apiVersion: v1
kind: Pod
metadata:
  name: hostaliases-pod
spec:
  restartPolicy: Never
  hostAliases:
  - ip: "10.0.1.23"
    hostnames:
    - "my.first.internal.service.example.com"
  - ip: "10.1.2.3"
    hostnames:
    - "my.second.internal.service.example.com"
  containers:
  - name: cat-hosts
    image: busybox
    command:
    - cat
    args:
    - "/etc/hosts"

因此，如果您将内部服务 IP 与服务的公共 FQDN 结合使用，那么来自您的 pod 的所有流量将 100% 位于集群内，因为应用程序将使用内部 IP 地址。

另外，您可以使用upstream DNS 服务器，它包含相同的别名，但想法是相同的。使用单独区域的上游 DNS，解析将像这样工作：

有了新版本的 Kubernetes，它使用 Core DSN 提供 DNS 服务，并且具有更多的功能，它会更简单一些。

【讨论】：