如何在 Rancher 2.0 中使用服务发现

对于所有基于容器的环境而言，服务发现都是不可或缺的核心功能之一。使用容器打包和启动应用程序之后，下一步就是使其可以被环境或外部世界中的其他应用程序容器发现。

在本文中，我们将详解 Rancher 2.0 中服务发现功能，并向你展示如何将 Rancher 1.6 功能集映射到最新版本。

Rancher 1.6 中的服务发现

Rancher 1.6 在 Cattle 环境中提供服务发现。Rancher 自己的 DNS 微服务提供了内部 DNS 功能。

Rancher 的内部 DNS 提供以下主要功能：

• 堆栈内和跨堆栈的服务发现

• 堆栈中的所有服务都可以通过<service_name>和<service_name>.<stack_name>跨堆栈解析。

• 容器发现

• 所有容器都通过他们的名字全局解析。

• 创建服务别名

• 为服务添加别名，并使用别名链接到其他服务。

• 发现外部服务

• 指向使用外部 IP 或域名部署在 Rancher 之外的服务。

Rancher 2.0 中的服务发现

Rancher 2.0 使用原生的 Kubernetes DNS 支持为 Kubernetes 工作负载和 pod 提供等效的服务发现。Cattle 用户将能够在不丢失任何功能的情况下复制 Rancher 2.0 中的所有服务发现功能。

与 Rancher 1.6 DNS 微服务类似，Kubernetes 在集群内调度 DNS pod 和服务，并配置 kubelet 以将所有 DNS 查找路由到此 DNS 服务。Rancher 2.0 的 Kubernetes 集群将 skyDNS 部署为 Kubernetes DNS 服务，这是默认 Kube-DNS 实现的一种风格。

服务解析

Rancher 1.6 服务映射到某种类型的 Kubernetes 工作负载，您可以在此了解一个有关流行类型工作负载的简短摘要：

https://rancher.com/docs/rancher/v2.x/en/k8s-in-rancher/workloads/#workloads

Kubernetes 工作负载是指定为工作负载启动的 pod 的部署规则的对象。工作负载对象本身无法通过 DNS 解析为 Kubernetes 集群中的其他对象。要查找和访问工作负载，需要为工作负载创建 Kubernetes 服务。以下是 Kubernetes 服务的一些细节：

https://kubernetes.io/docs/concepts/services-networking/service/

在 Kubernetes 中创建的任何服务都会获得 DNS 名称。为服务创建的 DNS A 记录的格式为 <service_name>.<namespace_name>.svc.cluster.local。服务的 DNS 名称解析为服务的集群 IP。集群 IP 是分配给服务的内部 IP，可在集群内解析。

在 Kubernetes 命名空间内，服务可以使用<service_name> 直接解析，命名空间外部的服务则可以使用<service_name>.<namespace_name>直接解析。这类似于 Rancher 1.6 中堆栈内以及跨堆栈的服务发现。

因此，要查找和访问应用程序工作负载，需要创建一个获取 DNS 记录的服务。

Rancher 通过使用您在 UI 中选择的服务端口和服务类型自动创建服务以及工作负载，同时部署与工作负载名称相同的工作负载和服务名称，从而简化了此过程。如果没有暴露端口，则使用端口 42。这种做法使得工作负载可以通过名称在命名空间内和跨命名空间发现。

例如，如下所示，我使用 Rancher 2.0 UI 在两个名称空间中部署了几个类型为 Deployment 的工作负载。

我可以在 Cluster> Project> Service Discovery 选项卡下看到 Rancher 为工作负载自动创建的相应 DNS 记录。

如下所示，工作负载可供命名空间内和跨命名空间的任何其他工作负载访问。

Pod 解析

在 Kubernetes 集群中运行的各个 pod 也会分配一个 DNS 记录，其格式为 <pod_ip_address>.<namespace_name>.pod.cluster.local。例如，某 pod 的 IP 为 10.42.2.7，它在命名空间default 中，DNS 名称为 cluster.local，则它的 entry 为10-42-2-7.default.pod.cluster.local。

如果是在 pod 规范中设置，也可以使用hostname和subdomain字段解析 Pod。相关内容可以参考 Kubernetes 文档：

https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/

为工作负载和外部服务创建别名

就像您可以为 Rancher 1.6 服务创建别名一样，您也可以使用 Rancher 2.0 对 Kubernetes 工作负载执行相同的操作。同样，您也可以使用 Rancher 2.0 中的主机名或 IP 地址创建指向外部运行服务的 DNS 记录。这些 DNS 记录是 Kubernetes 服务对象。

使用 2.0 UI，导航到 Cluster> Project 视图，然后选择 Service Discovery 选项卡。此处，为您的工作负载创建的所有现有 DNS 记录都将列在每个命名空间下。

单击“Add Record”以创建新的 DNS 记录，并查看链接到外部服务所支持的各种选项，或为另一个工作负载/ DNS 记录/pod 组创建别名。

需要注意的一点是，在创建 DNS 记录的这些选项中，Kubernetes 本身支持以下选项：

• 指向外部主机名

• 指向一组与选择器匹配的 pod

其余功能由 Rancher 利用 Kubernetes 实现：

• 指向外部 IP 地址

• 为另一个 DNS 记录创建别名

• 指向另一个工作负载

从 Docker Compose 到 Kubernetes YAML

现在让我们看看如果我们想要使用 Compose 文件将应用程序从 1.6 迁移到 2.0 而不是通过 2.0 UI 部署它，我们需要怎么做。

上文中介绍过，当我们使用 Rancher 2.0 UI 部署工作负载时，Rancher 会在内部为服务发现创建必要的 Kubernetes ClusterIP服务。但是，如果您是通过 Rancher CLI 或 Kubectl 客户端部署工作负载，那么您应该如何确保完成相同的服务发现行为？

通过 Compose 在命名空间内和跨命名空间进行服务发现

让我们从以下 docker-compose.yml 文件开始，该文件显示了堆栈中的两个服务（foo和bar）。在 Cattle 堆栈中，这两个服务可以使用其服务名称相互访问。

那么，如果我们将这两个服务迁移到 Rancher 2.0 中的命名空间，会发生什么？

我们可以使用 Kompose 工具将此 docker-compose.yml 文件从 Rancher 1.6 转换为 Kubernetes YAML，然后使用 Rancher CLI 在 Kubernetes 集群中部署该应用程序。

现在，此转换会生成* -deployment.yaml文件，使用 Rancher CLI 部署它们会在命名空间内创建相应的工作负载。

这些工作负载可以在命名空间内相互访问吗？我们可以使用 Rancher 2.0 UI 执行工作负载 foo 的 shell，然后看看 ping 另一个工作负载bar是否有效。

没有！原因是我们只创建了Deployment类型的工作负载对象。为了使这些工作负载可被发现，它们每个都需要一个指向它们的ClusterIP类型的服务，该服务将被分配一个 DNS 记录。用于此类服务的 Kubernetes YAML 应如下所示。

请注意，ports是必填字段。因此，我们需要为其提供一些端口号，如此处所示的42。

通过 CLI 部署此服务后，服务foo可以成功 ping 到服务bar了！

因此，如果您使用 Compose-to-Kubernetes-YAML 路由将 1.6 服务迁移到 Rancher 2.0，请确保您还为工作负载部署了相应的ClusterIP服务。相同的解决方案也适用于工作负载的跨命名空间引用。

Compose 的链接／外部链接

如果您是 Cattle 用户，您一定知道在 Rancher 1.6 中，您可以创建指向其他服务的服务链接/别名，并在您的应用程序中使用该别名来发现该链接的目标服务。

例如下面的应用程序，其中Web服务使用别名mongo链接到数据库服务。

使用 Kompose，将此 Compose 文件转换为 Kubernetes YAML 生成相应的部署和服务 YAML 规范。如果您在 docker-compose.yml 中的服务公开端口，Kompose 默认会生成 Kubernetes ClusterIP服务 YAML 规范。

使用 Rancher CLI 部署这些工具会生成必要的工作负载。

但是此处缺少了服务链接mongo，因为 Kompose 转换不支持 docker-compose.yml 文件中的链接。如此一来，工作负载 web 出现了错误，其 pod 继续重新启动，无法解析到数据库服务的mongo链接。

我们如何修复破坏的 DNS 链接？解决方案是创建另一个ClusterIP服务规范，并将其名称设置为 docker-compose 中链接的别名。

部署此服务会创建必要的 DNS 记录，并创建链接mongo，从而使web工作负载可用。

下图显示的就是web工作负载启动的 pod 已进入Running状态。

未来从 SkyDNS 过渡到 CoreDNS

从 Rancher v2.0.7 开始，Rancher 部署了由 Kubernetes 版本 1.10.x 支持的 skyDNS。在 Kubernetes 1.11 及更高版本中，CoreDNS 可以作为 DNS 提供程序安装。我们也正在评估 CoreDNS，它将在 Rancher 的未来版本中作为 skyDNS 的替代品。

结语

本文介绍了如何通过 Kubernetes DNS 功能在 Rancher 2.0 中支持等效的服务发现。在后续文章中，我们将分享 Rancher 2.0 支持的负载均衡功能以及与 Rancher 1.6 相比存在的限制。