kubernetes基礎知識之ingress和External IP

在kubernetes中，ingress可以配置提供服務外部通路的URL。

Ingress有兩大元件：ingress-controller和ingress。ingress-controller通過與kubernetes API去互動，動态去感覺叢集中ingress的規則變化，然後讀取它，按照它自己的模闆，生成一段Nginx配置，再寫入Nginx Pod裡面，最後reload一下。最新版本中，kubernetes已經将nginx與ingress-controller合并為一個元件，是以nginx無需單獨部署，隻需要部署ingress-controller即可。

Ingress的工作原理：

1.ingress-controller通過和kubernetes API-Server去互動，動态地去感覺kubernetes叢集中ingress的規則變化。

2.然後讀取它，按照自定義的規則，規則就是寫明了哪個域名對應哪個service，生成一段nginx配置。

3.再寫到nginx-ingress-controller的pod裡面，這個ingress-controller的pod裡面運作着一個nginx服務，控制器會把生成的配置寫入/etc/nginx.conf配置檔案中。

4.然後reload一下，使配置生效。以達到域名區配置設定置和動态更新的作用。

在使用普通的service的時候，叢集中每個節點的kube-proxy在監聽service和endpoint的變化時，會動态地修改相關的iptables的轉發規則。用戶端在通路時通過iptables設定的規則進行路由轉發達到通路服務的目的。

而ingress跳過了kube-proxy這一層，通過ingress-controller中的代理配置進行路由轉發達到通路目标服務的目的。

實際上可以把ingress controller 看成一個擁有預設處理後端的代理。根據ingress的配置動态修改代理的配置檔案，以實作按照ingress規則轉發請求的功能。

每建立一個service,kubernetes會自動建立一個同名的endpoint出來，我們可以通過指令檢視：

kubectl get endpoints --all-namespaces

External IP是為了解決如何從外部通路叢集服務的問題。

對于NodePort類型的服務，PORT表示的内容是叢集IP的内部端口:節點端口/TCP。可以通過以下方式通路服務：

①：CLUSTER-IP:叢集内部端口

②：任意一個node IP的節點端口。

對于LoadBalancer類型的服務，負載均衡器的對外IP位址為：EXTERNAL-IP。可以通過這個位址通路服務：

curl http://EXTERNAL-IP。

External IP是為了解決如何從外部通路service服務的問題。外部通路服務有兩種方法：

1.通過設定NodePort到實體機，同時設定service的類型為NortPort。

2.通過設定LoadBalancer映射到雲服務上提供的LoadBalancer位址。這種用法僅用于公有雲服務提供商的雲平台設定service的場景。對這個service的請求會通過LoadBalancer轉發到後端pod上，負載分發的實作方式依賴于雲服務商提供的LoadBalancer的實作機制。

-----我是華麗的分隔線-----

需要service的原因：

1.pod ip會變化，比如删除之後。service是pod的代理，我們用戶端需要通路pod中部署的應用，隻需要通路service ，service就會把請求代理到pod。

2.pod IP在kubernetes叢集之外無法通路，隻能建立service。這個service是可以在外部通路的，service的類型需要建立為NodePort的類型。

service可以了解成一個固定的接入層，用戶端可以通路service的IP:Port，這樣service可以代理請求到service關聯的後端pod上。

一般四層代理用service,七層代理用Ingress。

service依賴于元件coredns，coredns是一個dns伺服器，建立的service可以通過coredns把請求的服務service生成一個FQDN全品質域名。FQDN的格式是：

${Service_name}.${namespace}.svc.cluster.local

請求這個FQDN全品質域名的時候，和請求CLUSTER-IP是一個效果。

service還依賴一個元件，是kube-proxy元件。建立的service是有IP的，是一個虛拟的IP位址。建立的這個虛拟的IP是存在IPVS或者是iptables規則裡面的。kube-proxy負責監聽建立的service，kube-proxy會把新建立的service生成的IP儲存到ipvs或者iptables規則裡面。一般ipvs比iptables效率高，開啟了ipvs就會存在ipvs規則裡面，否則存在iptables規則裡面。

Service找pod需要标簽選擇器label selector。service靠kube-proxy把用戶端的請求代理到後端pod上面。kube-proxy是一個代理，可以做一些負載均衡政策，比如輪詢、權重輪訓等來決定把service的用戶端請求代理到哪個後端的pod裡面。并且kube-proxy會把service的IP轉發到ipvs或者iptables規則裡面。

service的工作原理：

基于同一個模闆，也就是控制器建立的pod都有一樣的标簽。

建立service的時候，在service裡面定義了一個label selector标簽選擇器。标簽選擇器會選擇标簽關聯的pod。

用戶端通路service，service通過label selector标簽選擇器找到關聯的pod。

建立service的時候，也會建立一個endpoint的資源。

可以通過kubectl get endpoints --all-namespaces檢視到。

建立service的時候，會建立一個同名的endpoint的資源對象。endpoint裡面注冊的是pod的IP和端口。

隻要建立的service，關聯了pod的标簽，那麼注冊的pod的IP和端口，就會寫到endpoint的對象裡面。隻要建立的pod能被service關聯到，就會寫入endpoint對象裡。

通路的時候，請求到達service。一般會由endpoint把請求代理到pod後端。具體把請求代理到哪個後端pod，是通過kube-proxy元件去實作的。kube-proxy元件，相當于負載均衡的元件，會生成iptables規則。service和哪個pod關聯，靠輪詢、權重輪詢等，是靠kube-proxy實作，service裡面定義的label selector是用來查找pod的。查找到pod之後，會儲存到endpoint這個資源對象裡。service接收請求後會根據endpoint裡面記錄的對象，把請求分發到多個pod上，endpoint裡面有多個pod。

分發請求的時候，具體按照什麼政策分發，靠kube-proxy負載均衡實作。

老虎tiger

鼓勵的話語：有識才有膽，有膽才有識。知識要和膽量相結合！