0

我们目前有一个设置，其中我们的 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），我不完全确定我们如何可以避免退出集群。

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

如果我从根本上误解了某个特定组件，我将很高兴得到纠正！

4

1 回答 1

4

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

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

但是，更重要的是，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 地址。

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

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

于 2018-03-18T14:14:01.420 回答