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

Question

我试图理解kubernetes中的入口控制器和入口控制器的概念。但我不太确定最终产品应该是什么样子。以下是我不完全理解的：

假设我有一个运行中的Kubernetes集群，其中有一个主节点，它运行控制平面和etcd数据库。此外，我有大约3个工作节点-每个工作节点都有一个公共IPv4地址和相应的DNS A记录(worker{1,2,3}.domain.tld)，并且我完全控制了我的DNS服务器。我希望我的用户通过www.domain.tld访问我的web应用程序。因此，我将www CNAME指向一个工作节点(我看到我的入口控制器被调度到worker1 1，所以我将它指向worker1.domain.tld)。

现在，当我调度一个工作负载时，包括两个前端吊舱和一个数据库吊舱，其中一个是前端服务，一个是数据库服务。从现在所了解的情况来看，我需要一个入口控制器来指向前端服务来实现某种负载平衡。这里有两个问题：

1. 仅仅在一个工作节点上运行入口控制器不是没有意义的，通过它的服务在内部负载平衡两个前端吊舱吗？在集群中的每个工作节点上运行入口控制器是最佳实践吗？
2. 不管出于什么原因，运行入口控制器的工人会死掉，然后被重新安排到另一个工人身上。所以入口点将位于另一个IPv4地址，对吗？从试图通过www.domain.tld访问前端的用户角度来看，必须更新这个DNS条目，对吗？怎么会这样呢？我需要在某个地方运行特定的kubernetes感知的DNS服务器吗？我不明白DNS服务器和kubernetes集群之间的连接。

附加问题:如果我运行更多的入口控制器副本(分布于多个工作人员)，我是否在这里执行基于DNS循环的方法，将多个IPv4地址绑定到一个DNS条目？或者实现HA的最佳解决方案是什么。我不想使用负载平衡IP地址，其中工作人员共享相同的IP地址。

Answer 1

假设我有一个运行中的Kubernetes集群，其中有一个主节点，它运行控制平面和etcd数据库。此外，我有大约3个工作节点-每个工作节点都有一个公共的IPv4地址，并有一个相应的DNS记录( worker {1,2,3}.domain.tld)，并且我完全控制了我的DNS服务器。我希望我的用户通过www.domain.tld访问我的web应用程序。因此，我将www指向一个工作节点(我看到我的入口控制器被调度到worker1 1，所以我将它指向worker1.domain.tld)。 现在，当我调度一个工作负载时，包括两个前端吊舱和一个数据库吊舱，其中一个是前端服务，一个是数据库服务。从现在所了解的情况来看，我需要一个入口控制器来指向前端服务来实现某种负载平衡。这里有两个问题：

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

是的，这是个很好的练习。为负载均衡器配备多个吊舱对于确保高可用性非常重要。例如，如果运行进口nginx控制器，可能应该将其部署到多个节点。

1. 不管出于什么原因，运行入口控制器的工人会死掉，然后被重新安排到另一个工人身上。所以入口点将位于另一个IPv4地址，对吗？从试图通过www.domain.tld访问前端的用户角度来看，必须更新这个DNS条目，对吗？怎么会这样呢？我需要在某个地方运行特定的kubernetes感知的DNS服务器吗？我不明白DNS服务器和kubernetes集群之间的连接。

是的，IP会改变的。是的，这需要在您的DNS服务器中更新。

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

1. 假设客户会处理停电问题。您可以在循环中列出所有负载均衡器节点，并假定客户端将出现退步。这适用于某些协议，但主要意味着超时和问题，一般不应该使用，特别是当k8s显示它将创建/删除LB条目时，仍然需要手动更新记录。
2. 自动配置外部DNS服务器。这可以通过外部-dns项目来完成，它可以与大多数流行的DNS服务器同步，包括标准的RFC2136动态更新，但也包括像亚马逊、谷歌、Azure等云提供商。

附加问题:如果我运行更多的入口控制器副本(分布于多个工作人员)，我是否在这里执行基于DNS循环的方法，将多个IPv4地址绑定到一个DNS条目？或者实现HA的最佳解决方案是什么。我不想使用负载平衡IP地址，其中工作人员共享相同的IP地址。

是的，你基本上应该做DNS循环。我认为外部-dns在这里也会做正确的事情。

另一种选择是执行某种ECMP。这可以通过让两个负载平衡器“宣布”相同的IP空间来实现。然而，这是一种高级配置，这可能不是必要的。在BGP/ECMP和DNS更新之间有一些有趣的权衡，有关这些的更深入的讨论，请参见这个dropbox工程岗位。

最后，请注意，CoreDNS正在研究在没有外部资源的情况下，可以在Kubernetes中本地解决这个问题的实现公共DNS记录。

Answer 2

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

入口副本的数量不会影响负载平衡的质量。但是对于HA，您可以运行一个以上的控制器副本。

不管出于什么原因，运行入口控制器的工人会死掉，然后被重新安排到另一个工人身上。所以入口点将位于另一个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解决方案并不是实现您想要的最糟糕的方法。如果不是，您应该选择其他方法，但最佳实践是使用由基础结构提供的负载均衡器。它是基于几个专用服务器，还是负载平衡it，还是其他什么--这并不重要。

Answer 3

您描述的行为实际上是一个LoadBalancer (在Kubernetes中使用type=LoadBalancer的Service )，这是在云提供商之上运行Kubernetes时“自然”提供的。

从您的描述来看，您的集群似乎位于裸金属上(无论是真金属还是虚拟金属)，一种可能的方法(对我有用)将是：

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

- this is where your external IP will "live" (HA'd), via the `speaker-xxx` pods deployed as `DaemonSet` to each worker node
- depending on your extn L2/L3 setup, you'll need to choose between _L3_ (BGP) or _L2_ (ARP) modes
- fyi I've successfully used _L2_ mode + simple proxyarp at the border router

​

• 部署nginx-ingress控制器，其Service作为type=LoadBalancer

- this will make metallb to "land" (actually: L3 or L2 "advertise" ...) the assigned IP to the nodes
- fyi I successfully tested it together with `kube-router` using `--advertise-loadbalancer-ip` as CNI, the _effect_ will be that e.g. `<LB_IP>:80` will be redirected to the `ingress-nginx` `Service` `NodePort`

​

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

- fyi you can also quickly test it using _fake_ _DNSing_ with `http://A.B.C.D.xip.io/` (`A.B.C.D` being your public IP addr)

​