在K8S上的Web服务该怎么做域名解析呢?

在K8S上的Web服务该怎么做域名解析呢?

我们这个系列的文章一直都在学习和掌握K8S各种组成部分在集群里的角色、作用和使用场景，那么针对今天这个主题任务「给K8S上的Web服务做域名解析」你觉得应该使用什么组件来完成呢？

之前使用 Ingress ，那么有人会问为啥不能用 NodePort 这种方式呢？今天的文章我们就来详细探讨一下这些相关的问题：

为什么 NodePort 这种暴露服务的方式不适合用来给服务做域名解析。
怎么使用 Ingress 暴露Web服务（会给大家做一个Demo进行演示）。
生产集群 Ingress 怎么做高可用。
为什么NodePort不适合做域名解析
NodePort 类型的 Service 是向集群外暴露服务的最原始方式，也是最好让人理解的。 NodePort ，顾名思义，会在所有节点（宿主机或者是VM）上打开一个特定的端口，发送到这个端口的任何流量都会转发给 Service 。

NodePort Service 的原理可以用下面这个图表示：

上图我们顺着流量的流向箭头从下往上看，流量通过 NodeIP+NodePort 的方式进入集群，上图三个节点的30001上的流量都会转发给Service，再由Service给到后端端点 Pod 。

NodePort Service的优点是简单，好理解，通过IP+端口的方式就能访问，但是它的缺点也很明显，比如：

每向外暴露一个服务都要占用所有Node的一个端口，如果多了难以管理。

NodePort的端口区间固定，只能使用30000–32767间的端口。

如果Node的IP发生改变，负载均衡代理需要跟着改后端端点IP才行。

怎么使用Ingress暴露Web服务

在K8S的这些组件中 Ingress 不是一种 Service 。相反，它位于多个 Service 的前端，给这些 Service 充当“智能路由代理”或集群的入口点（entrypoint）。

在 Service 前面加上 Ingress ，集群中需要有 Ingress-Controller 才行。如果是自建K8S集群，通常使用 nginx-ingress 作为控制器，它使用 NGINX 服务器作为反向代理来把流量路由给后面的 Service 。

通过 Ingress 可以对后端 Service 进行基于域名和URL路径的路由。例如，您可以将 foo.yourdomain.com 上的所有内容发送到 foo Service，将 yourdomain.com/bar/ 路径下的所有内容发送到 bar Service。

我们可以把这张图和上面NodePort原理图做一个比较，看看两者的区别。上面这个示意图对应的Ingress资源声明文件差不多应该长这个样子：

apiVersion: