在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: extensions/v1beta1 kind: Ingress metadata:name: my-ingress spec:backend: // 哪個都不匹配時，走這個兜底的ServiceserviceName: otherservicePort: 8080rules:- host: foo.mydomain.comhttp:paths:- backend:serviceName: fooservicePort: 8080- host: mydomain.comhttp:paths:- path: /bar/backend:serviceName: barservicePort: 8080

在本地實踐Ingress
上面說了很多理論，下面我們可以通過一個簡單的Demo進行演示，我本地使用的是 Docker Desktop 自帶的K8S集群，至于為啥用它，沒別的就是簡單。

要使用 Ingress ，那么集群里就得先有個 Ingress-Controller ，我們先來安裝一個 Nginx-Ingress-Controller （其本質上就是一個Nginx Server）：

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.0.0/deploy/static/provider/cloud/deploy.yaml
執行上述命令后，其實會在本地集群的 ingress-nginx 命名空間里，安裝三個創建 nginx-controller 的 Pod :

? ~ kubectl get pods -n ingress-nginx NAME READY STATUS RESTARTS AGE ingress-nginx-admission-create-n59dn 0/1 Completed 2 49d ingress-nginx-admission-patch-hft52 0/1 Completed 3 49d ingress-nginx-controller-68649d49b8-nlch7 1/1 Running 77 49d

前兩個 admission 相關的 Pod 是給 nignx controller 做配置用的，執行完就退出，第三個才是運行著 nginx-controlelr 的 Pod 。

我之前幾次在本地試驗 Ingress 沒有成功，就是因為這個 nignx-controller 沒有正常啟動起來。一個常見的錯誤是 nginx controller 這個 Pod 拉取鏡像 k8s.gcr.io/ingress-nginx/controller:v0.46.0@sha256:… 的速度非常慢，所以我們最好是在安裝控制器前先通過 docker pull 命令把這個鏡像拉到本地。

在本地安裝完Ingress控制器后，為了演示方便，之前本地搭建 Nacos 時做過一個 Service ， Nacos 是阿里巴巴出的一個可以做自動配置和服務注冊的組件，自帶Web管理界面，正好可以拿它來演示。

下面我想能通過 dev.nacos.com 訪問 nacos-service ，最終讓 nacos-service 把流量路由給后端安裝了 Nacos 服務的 Pod ，這個 Ingress 可以這么聲明

//ingress.yaml apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata:name: nacos-ingressannotations:kubernetes.io/ingress.class: "nginx" spec:rules:- host: dev.nacos.comhttp:paths:- path: /backend:serviceName: nacos-serviceservicePort: 8848

在集群里應用這個 Ingress 后

# 執行下面兩個命令 # kubectl apply -f nacos-ingress.yaml # kubectl get ingress ? ~ kubectl get ingress NAME CLASS HOSTS ADDRESS PORTS AGE nacos-ingress <none> dev.nacos.com localhost 80 54d

再在本地hosts文件里綁定上

127.0.0.1 dev.nacos.com # 本地K8S集群的IP是127.0.0.1

就能通過域名訪問到 Nacos 服務的管理界面

為了不影響閱讀，Service、Deployment這些聲明文件，我放在了GitHub 倉庫里，鏈接如下：https://github.com/kevinyan815/LearningKubernetes

生產集群 Ingress 怎么做高可用
上面我們聊了 Ingress 怎么暴露服務，以及在本地怎么實踐演練用 Ingress 暴露服務，那么有的人肯定會好奇，在生產集群里 Ingress 是怎么做高可用的呢？域名解析應該怎么綁定呢？

正常的生產環境，因為 Ingress 是公網的流量入口，所以壓力比較大肯定需要多機部署。一般會在集群里單獨出幾臺 Node ，只用來跑 Ingress-Controller ，可以使用 deamonSet 的讓節點創建時就安裝上 Ingress-Controller ，在這些Node上層再做一層負載均衡，把域名的DNS解析到負載均衡IP上。

考慮到多業務線服務相互不影響的話，還需要讓不同的業務線的轉發規則注入到不同的 Ingress 里，這個通過我們上面聲明Ingress時的注解 annotations:kubernetes.io/ingress.class 就能實現。

其實每家公司的方案肯定不一樣，尤其是解析鏈路里加上高防Waf的話，會更復雜，由于我不是專業運維，也只是知道一些大概的思路，如果有專業的大佬歡迎留言，讓我們共同進步一下。

最后
其實這個主題我一直想寫，之前斷斷續續嘗試了兩三次才在本地把 Ingress 這套跑通，搞明白。希望今天的文章能幫大家進行一下 Ingress 知識的分析，如果想自己掌握、想明白，還是需要把文章好好看看，親自實踐一下演示的例子，以及多復習復習前面關于Service的知識才行。

如果你喜歡文章的內容，請關注Remi醬，點贊在看分享給更多人吧。

總結

以上是生活随笔為你收集整理的在K8S上的Web服务该怎么做域名解析呢?的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。