之前搭建并使用了微軟云Azure托管的K8S平臺AKS，最近又在華為云上搭建了CCE，加上測驗使用的AWS和阿里云的K8S平臺，逐漸掌握了一些主流公有云廠商基于K8S原生服務的使用方式，學而不思則罔，如果實踐是檢驗真理的唯一標準，那實踐后的總結就是在創造真理，K8S涉及的內容太多，其中網路最為復雜，而網路又分集群入口、出口網路，以及Pod間的Networkpolicy等等，光是Calico網路模型估計就能連載幾篇，本文主要針對公有云托管模式下的K8S集群對外暴露服務的Ingress，廢話少說，開整
我們都知道K8S中作業負載有很多種，最常用的是無狀態負載（Depolyment),其他還包括有狀態負載(StatetfulSet),守護行程(DaemonSet)以及各種任務(Job和CronJob),不同的作業負載適合不同的場景，這里不過多贅述，作業負載呼叫的最小單元是Pod，負載通過副本數量控制Pod數量，而作業負載需要被訪問或者訪問別的負載，這時候就引入了Service的概念，K8S集群內部可以直接通過Service名稱進行訪問，但Service是基于四層TCP和UDP協議轉發的，而在實際使用場景中，四層Service無法滿足應用層存在的大量HTTP/HTTPS訪問需求，因此又引入了Ingress的概念來暴露服務，使用方式如下：
對于自建K8S集群來說，負載均衡器可能需要自己實作,比如F5、Nginx、LVS等，而負載均衡作為公有云最常見的PaaS服務，顯然只要和托管的K8S平臺結合一下就OK了，你能想到，K8S官方和公有云廠商顯然早就看穿一切了，于是K8S官方的Service型別從Nodeport，ClusterIP，又加入了Loadbalancer型別，而公有云廠商也支持通過YAML創建云上服務，比如Azure的beta版service.beta.kubernetes.io/azure-load-balancer-internal: "true"，這樣一來事情就變得簡單了，不過好像上圖有個概念忘記說明了，那就是Ingress Controller，這是一個抽象的概念，你可以這樣理解：Ingress資源：一組基于域名或URL把請求轉發到指定Service實體的訪問規則，是Kubernetes的一種資源物件，Ingress實體被存盤在物件存盤服務etcd中，通過介面服務實作增、刪、改、查的操作，
Ingress Controller：請求轉發的執行器，用以實時監控資源物件Ingress、Service、End-point、Secret（主要是TLS證書和Key）、Node、ConfigMap的變化，決議Ingress定義的規則并負責將請求轉發到相應的后端Service，
這個Ingress Controller需要借助一些插件實作，比如最常用的NGINX Ingress Controller，HAProxy也是一種，而公有云廠商大都會自研網路插件，說是自研，其實就是在托管的K8S集群上幫你實作了很多插件的功能，這樣一來，大多云廠商的托管平臺就會出現兩種服務的暴露方式，一種是使用開源Ingress-controller插件
第二種是使用自研的網路插件：
這兩種模式云廠商給的區別都模棱兩可，通過使用大概總結如下：
1.Ingress-controller高可用：
1.ELB型別的高可用由廠商負責，因為會保證ELB的SLA以及Master節點的性能
2.Nginx型別的服務插件需要自己保證服務高可用，可以使用node污點或者守護行程的方式實作
2.ELB和Service型別兼容：
1.ELB型別的ELB（有點繞）其實是七層的負載均衡，因為是直接呼叫Service，所以這種型別呼叫的Service需要是Nodeport或者Loadbalancer型別，ClusterIp型別是不可以的，而Nodeport型別的服務只要節點能被訪問，就意味著這個服務也能被訪問，那也就是說Node如果系結了公網IP，它上面的服務還用啥ingress了，直接都可以訪問了，所以這種模式需要配合權限控制來使用
2.Nginx型別的ELB是四層的，它只需把請求透傳過來就可以，真正起作用的是部署的Nginx-Ingress，所以這種型別呼叫的service任何型別都可以
補充：華為的四層和七層的ELB都是一個服務，主要看你怎么用，而Azure的四層叫ALB，七層卻叫Application gateway，這可不是注冊API的那個服務，那個服務它叫API Management service，真是馬虎不得啊，AWS七層的叫ALB，四層的叫NLB（是不有又漲知識了）
3.日志Log：
1.網安法最常見的兩個要求，日志保存六個月和保留訪問的源IP，ELB型別的主要日志都在PaaS級別的ELB服務，實作這兩個要求簡直小case
2.Nginx型別的就麻煩了，四層的負載均衡幾乎沒有任何有意義的日志，而且它還會做NAT，使后端的應用捕獲不到訪問源IP，所以你需要對它進行設定，而且這還不算完，你還要把這個源ip在集群安全組下放行，要不然根本進不來集群
補充：監控等metric指標同樣適用，根本區別就是公有云PaaS服務和自建負載的區別
4.路由規則配置：
1.ELB型別的捕獲日志是很方便，但是配置規則就是基于ELB服務本身，不支持路由重定向
2.Nginx型別的就方便多了，你只要會配置Nginx.conf就可以了，nginx本身的那些規則都支持
5.其他區別：
1.ELB型別一個集群支持多個ELB實體，Nginx型別一個集群只支持一個ELB實體
2.ELB型別占用Master節點，不占用作業節點，Nginx型別占用Worker節點，需要Nginx組件運行成本
如果你使用主流公有云托管的K8S平臺，同時又要暴露你的服務，那你大概率會遇到同樣的問題，但是服務網格Istio使用Istio Gateway，可以理解它是Ingress的加強版，比如灰度發布的流量比例控制就是靠它實作的(有時間再細講，這都是后話了），K8S復雜又強大，這只是它的冰山一角，如果你管理的核心應用（幾千臺節點）正運行在K8S上，那你一定幸運的發現了很多細微的問題，時間總是把一部分人推向海邊，使他們成為最早看見太陽的那一批人，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/394126.html
標籤：其他