如何为面向公众的Web应用程序设置DNS和入口控制器？

Question

我正在尝试了解kubernetes中的入口和入口控制器的概念。但是我不确定最终产品的外观。这是我不太了解的内容：

给定我在某个地方有一个正在运行的Kubernetes集群，该集群带有一个主节点，该节点运行控制平面和etcd数据库。除此之外，我有3个工作程序节点-每个工作程序节点都有一个带有相应DNS A记录（worker{1,2,3}.domain.tld）的公共IPv4地址，并且可以完全控制我的DNS服务器。我希望我的用户通过访问我的Web应用程序www.domain.tld。因此，我将wwwCNAME 指向了一个工作程序节点（我看到我的入口控制器即已调度到worker1一个，所以我将其指向worker1.domain.tld）。

现在，当我计划一个工作负载时，该工作负载由2个前端容器和1个数据库容器组成，其中1个用于前端服务，1个用于数据库服务。从现在的理解来看，我需要一个指向前端服务的入口控制器来实现某种负载平衡。这里有两个问题：

1. 并非仅在一个工作节点上运行入口控制器就没有意义，以通过其服务在内部对两个前端Pod进行负载平衡？最佳实践是在集群中的每个工作节点上运行入口控制器吗？

2. 无论出于何种原因，运行入口控制器的工作人员都会死亡，并将其重新安排给其他工作人员。所以入口点将到达另一个IPv4地址，对吗？从尝试通过访问前端的用户角度来看，www.domain.tld必须更新此DNS条目，对吗？为何如此？我是否需要在某个地方运行支持kubernetes的特定DNS服务器？我不了解DNS服务器和kubernetes集群之间的连接。

额外的问题：如果我运行更多的入口控制器副本（分布在多个工作进程中），我是否在这里采用基于DNS轮询的方法，将多个IPv4地址绑定到一个DNS条目？或实现HA的最佳解决方案是什么？我不想在工作人员共享相同IP地址的地方使用负载平衡IP地址。

Answer 1

给定我在某个地方有一个正在运行的Kubernetes集群，该集群带有一个主节点，该节点运行控制平面和etcd数据库。除此之外，我有3个工作节点-每个工作节点都有一个带有相应DNS A记录的公共IPv4地址（worker {1,2,3} .domain.tld），并且可以完全控制我的DNS服务器。我希望我的用户通过www.domain.tld访问我的Web应用程序。因此，我将www CNAME指向其中一个工作程序节点（我看到我的入口控制器即已调度到worker1一个，因此将其指向worker1.domain.tld）。

现在，当我计划一个工作负载时，该工作负载由2个前端容器和1个数据库容器组成，其中1个用于前端服务，1个用于数据库服务。从现在的理解来看，我需要一个指向前端服务的入口控制器来实现某种负载平衡。这里有两个问题：

1. 并非仅在一个工作节点上运行入口控制器就没有意义，以通过其服务在内部对两个前端Pod进行负载平衡？最佳实践是在集群中的每个工作节点上运行入口控制器吗？

是的，这是一个好习惯。对于负载平衡器而言，具有多个吊舱对于确保高可用性非常重要。例如，如果运行ingress-nginx控制器，则可能应将其部署到多个节点。

2. 无论出于何种原因，运行入口控制器的工作人员都会死亡，并将其重新安排给其他工作人员。所以入口点将到达另一个IPv4地址，对吗？从试图通过www.domain.tld访问前端的用户角度来看，必须更新此DNS条目，对吗？为何如此？我是否需要在某个地方运行支持kubernetes的特定DNS服务器？我不了解DNS服务器和kubernetes集群之间的连接。

是的，IP将更改。是的，这需要在您的DNS服务器中进行更新。

有几种方法可以解决此问题：

1. 假设客户将处理中断。您可以按循环列出所有负载均衡器节点，并假定客户端将回退。这适用于某些协议，但是通常暗示超时和问题，通常不应该使用，特别是因为当k8s计算出它会创建/删除LB条目时，您仍然需要手动更新记录

2. 自动配置外部DNS服务器。这可以通过external-dns项目来完成，该项目可以与大多数流行的DNS服务器同步，包括标准RFC2136动态更新，还可以与Amazon，Google，Azure等云提供商进行同步。

额外的问题：如果我运行更多的入口控制器副本（分布在多个工作进程中），我是否在这里采用基于DNS轮询的方法，将多个IPv4地址绑定到一个DNS条目？或实现HA的最佳解决方案是什么？我不想在工作人员共享相同IP地址的地方使用负载平衡IP地址。

是的，您基本上应该进行DNS轮询。我认为外部DNS也会在这里做正确的事情。

另一种选择是执行某种 ECMP。这可以通过使两个负载平衡器“宣布”相同的IP空间来实现。但是，这是高级配置，可能没有必要。BGP / ECMP和DNS更新之间存在一些有趣的折衷，请参阅此保管箱工程文章以获取有关这些更新的更深入讨论。

最后，请注意，CoreDNS正在考虑实现公共DNS记录，该记录可以在Kubernetes中本机解决，而无需外部资源。

Answer 2

仅在一个工作节点上运行入口控制器对于通过其服务对两个前端 pod 进行内部负载平衡是没有意义的吗？在集群中的每个工作节点上运行入口控制器是最佳实践吗？

Ingress的副本数量不会影响负载均衡的质量。但对于 HA，您可以运行 1 个以上的控制器副本。

无论出于何种原因，运行入口控制器的工作人员死亡，并且它会被重新安排给另一个工作人员。那么入口点将位于另一个 IPv4 地址，对吗？从尝试通过 www.domain.tld 访问前端的用户角度来看，必须更新此 DNS 条目，对吗？为何如此？我是否需要在某处运行特定的 kubernetes 感知 DNS 服务器？我不明白DNS服务器和kubernetes集群之间的连接。

是的，它将在另一个 IPv4 上。是的，应该为此更新 DNS。Kubernetes 中没有包含这方面的标准工具。是的，您需要运行外部 DNS 并以某种方式手动管理其上的记录（通过某些工具或脚本）。

Kubernetes 集群内部的 DNS 服务器和外部 DNS 服务器是完全不同的东西。集群内部的DNS服务器只提供集群内部的解析以进行服务发现。Kubernetes 不知道任何有关从外部网络访问集群的信息，至少在裸机上是这样。在云中，它可以管理一些人员（例如负载均衡器）以自动化外部访问管理。

我运行更多入口控制器副本（分布在多个工作进程中）是否可以在此处使用绑定到一个 DNS 条目的多个 IPv4 地址执行基于 DNS 循环的方法？或者实现 HA 的最佳解决方案是什么。

DNS 循环在这种情况下有效，但如果其中一个节点发生故障，您的客户端将在连接到该节点时遇到问题，因此您需要找到某种方法来移动/删除该节点的 IP。

如果您可以为此准备一个环境，@jjo 提供的 HA 解决方案并不是实现您想要的最糟糕的方法。如果没有，您应该选择其他东西，但最佳实践是使用基础设施提供的负载均衡器。它会基于多个专用服务器、负载平衡 IP 还是其他东西 - 这并不重要。

Answer 3

您描述的行为实际上是一个 LoadBalancer（Kubernetes 中的一个Service）type=LoadBalancer，当您在云提供商之上运行 Kubernetes 时，它是“自然”提供的。

从您的描述来看，您的集群似乎位于裸机（真实金属或虚拟金属）上，一种可能的方法（对我有用）是：

• 部署https://github.com/google/metalb

  • 这是您的外部 IP 将通过speaker-xxx部署DaemonSet到每个工作节点的 pod“生存”（HA）的地方
  • 根据您的分机 L2/L3 设置，您需要在L3 (BGP) 或L2 (ARP) 模式之间进行选择
  • 仅供参考，我已经在边界路由器成功使用了L2模式 + 简单 proxyarp

• 部署nginx-ingress控制器，其Serviceastype=LoadBalancer

  • 这将使 Metallb 将分配的 IP“登陆”（实际上：L3 或 L2“通告”...）
  • 仅供参考，我成功地将其与CNI一起kube-router使用进行了测试，效果是eg将被重定向到--advertise-loadbalancer-ip<LB_IP>:80ingress-nginx Service NodePort

• 将您的 DNS 指向 ingress-nginx LB IP，即显示的内容： kubectl get svc --namespace=ingress-nginx ingress-nginx -ojsonpath='{.status.loadBalancer.ingress[].ip}{"\n"}'

  • 仅供参考，您还可以使用假 DNSing快速测试它（http://A.B.C.D.xip.io/作为A.B.C.D您的公共 IP 地址）