對Kurbernetes中服務暴露方法的一些理解和說明
由于最近在進一步整理和學習云原生解決方案的相關材料，原來一直沒太理解清楚的就是kurbernetes中的網絡和服務暴露方式。最近又查找資料進一步學習了下。
業務場景說明
在前面談DevOps解決方案的時候就談到，一個完整的DevOps持續集成和交付過程，需要和容器云集成，來實現自動化部署，動態彈性伸縮，環境遷移等能力。
一個DevOps支撐平臺離不開和容器化PaaS平臺的集成，即最終的編譯構建完成的內容形成鏡像并放到鏡像倉庫，后續部署，環境遷移，資源擴展基于鏡像倉庫進行快速的拷貝和復制。對于Docker容器一般會和K8S結合來實現資源的動態調度，集群管理能力。
在原來談的時候僅僅談到通過K8s來完成部署和資源動態擴展的時候會從此一個VIP虛擬地址提供給應用模塊訪問使用，而這里沒有進行展開，今天主要是結合場景進一步展開說明。
場景說明：
我們以整個應用實際有兩個微服務模塊來舉例，一個是UserMgr微服務，一個是OrderMgr訂單管理微服務，這個兩個微服務都通過k8s自動化部署到容器云環境。同時我們假設，每個微服務都動態擴展了2個副本Pod，即形成了三個Pod節點。
在這種情況下，我們不可能直接去訪問Pod IP，一個是Pod IP本身就會動態變化，一個是集群擴展后本身同一個微服務已經存在多個副本Pod IP。
因此我們需要通過Service來訪問。
Kubernetes Service 定義了這樣一種抽象：一個 Pod 的邏輯分組，一種可以訪問它們的策略 —— 通常稱為微服務。 這一組 Pod 能夠被 Service 訪問到，通常是通過 Label Selector實現的。比如上面的UserMgr微服務，我們可以給它打一個UserMgr的標簽，然后相同的標簽自動聚合到一個Service邏輯分組上面。
內部模塊間服務訪問-ClusterIP
剛才我們談到，整個業務場景里面有UserMgr和OrderMgr兩個微服務，那么這兩個微服務之間的訪問屬于Kurbernetes集群內部的訪問。
在這種集群內部訪問場景下，即通過Service的ClusterIP即可。
注意ClusterIP本身是一個虛擬IP，無法Ping通，對于該IP的訪問請求實際是基于IPTables路由表和KubeProxy最終路由到具體的Pod實例節點上面。即：
Request-》ClusterIP-》IPTables+KubeProxy-》Pod Instance
如下圖：
在iptables代理模式下，對每個Service，它會安裝iptables規則，從而捕獲到達該Service的clusterIP(虛擬IP)和端口的請求，進而將請求重定向到Service的一組backend中某個上面。對于每個Endpoints對象，它也會安裝iptables規則，這個規則會選擇一個backend Pod。默認的策略是，隨機選擇一個backend。
對外提供服務-NodePort方式
如果需要對外提供服務，實際上有NodePort，LoadBalancer和Ingress多種方式。下面分別來對這幾種方式做下說明。
NodePort方式主要通過每個節點IP加端口的形式暴露端口，訪問任意一個node ip都可以訪問到(前提沒有指定node調度策略)，其中端口可以通過apiserver的配置文件可以看到端口暴露范圍。
比如還是上面的兩個微服務模塊部署下去后，對于8001端口可以配置為訪問UserMgr這個微服務模塊。即：10.0.0.1:8001， 10.0.0.1:8002，10.0.0.1:8003。
對于NodePort這種模式，實際上仍然是將請求轉發到Service上面，再通過Service路由到具體的Pod實例節點上面。唯一差異在于NodeIP是可以訪問到的IP地址。
這三個地址都可以訪問到用戶管理這個微服務。注意一個port端口映射到一個微服務上面，比如8001映射到UserMgr微服務，8002映射到8002微服務。上面三個地址都可以外部訪問到，如果客戶端要統一訪問，統一接入到類似Ngnix反向代理就可以了。
但是這種方式存在問題即如果新增加了Node節點，我們需要在集群或負載均衡上新增加配置信息，其次就是Node本身是附屬在虛擬機上面，如果整個IaaS環境的虛擬機重啟后IP地址可能發生變化，那么這個時候又需要手工進行配置。
對外提供服務-LoadBalancer方式
這種方式主要是利用其他第三方的LB暴露服務的，阿里云或者亞馬遜的LB等等。在這種方式下注意對于每一個微服務都會消耗一個IP，因此可能帶來公有云費用的問題。其次，也不容易形成了要給統一的服務訪問出口。
在這種方式下，來自外部負載均衡器的流量將直接達到 backend Pod 上，不過實際它們是如何工作的，這要依賴于云提供商。 在這些情況下，將根據用戶設置的 loadBalancerIP 來創建負載均衡器。
對外提供服務-Ingress方式
Ingress資源對象，用于將不同URL的訪問請求轉發到后端不同的Service,以實現HTTP層的業務路由機制。Kubernetes使用一個Ingress策略定義和一個具體的Ingress Controller,兩者結合并實現了一個完整的Ingress負載均衡器。
Ingress Controller將基于Ingress規則將客戶請求直接轉發到Service對應的后端Endpoint上，這樣會跳過kube-proxy的轉發功能，kube-proxy 不再起作用。
對于Ingress完全可以理解為整個Kurbernetes集群對外的一個網關或代理出口。把它理解為一個對外的API網關也沒有問題。通過Ingress可以接入和注冊各個微服務，微服務的IP訪問地址意義，通過后面不同的路徑和url來區分具體路由到哪個微服務上面。
對于Ingress網關的選型
可以參考：https://www.cnblogs.com/upyun/p/12372107.html
該篇文章給出了一個對比圖如下：
可以看到，當前Kong API網關本身也有了Kurbernetes插件后，形成了Kong Ingress，即既滿足了集群節點的對外暴露，同時又包括了Kong網關的一些核心能力，包括服務注冊發現，限流熔斷，安全等能力都可以滿足日常對API管理的需要。
簡單來說，如果你是將內部微服務的API接口暴露出去給前端APP用，那么采用Kong Ingress應該是一個不錯的選擇。同時Kong ingress 還有一個非常大的優點，他提供了一些 API、服務的定義，去抽象成 K8S 的 CRD，所以可以很方便地通過 K8S ingress 配置，同步到 Kong 的集群。
參考：https://github.com/Kong/kubernetes-ingress-controller/tree/main/docs
在DevOps集成中能做什么?
對于API網關和DevOps的協同，我在前面做過思考和整理如下。
我們首先看下什么時候需要涉及到API網關，在我們最初的概念里面是當一個業務應用需要對外發布API接口服務能力，這個對外發布可能是外部其它合作伙伴使用，也可能是我們自己的APP前端使用，只要存在這種場景往往就涉及到API網關的使用。
在一個大型項目的多團隊協同下可以看到，如果都采用微服務架構，我們實際建議的是每個團隊都是自己獨立的微服務注冊中心，負責團隊內部多個微服務模塊之間的API接口調用，這些API接口調用走注冊中心即可。但是涉及到跨團隊協同的API接口服務，那么就需要注冊到API網關進行統一管理。
簡單來說就是，對外發布API或者跨團隊API接口調用都需要涉及將API注冊接入到網關管理。
對于一個微服務模塊和API網關的協同，包括了提供API接口服務注冊和接入到網關，也包括了從網關調用API接口服務消費。因此需要從API注冊接入和API消費調用兩個方面來談協同。
API注冊接入
對于整個DevOps過程可以看到，底層是Docker容器+K8s資源調度，在我們編排流水線的時候涉及到編譯構建和打包，部署等各個動作。實際上可以看到在完成自動部署后接口服務會暴露一個k8s提供出來的動態ip訪問地址。而我們需要做的是將這個ip地址提供出來的訪問接口，注冊和接入到網關。
在整個過程搞清楚后，實際上我可以有兩種方式來處理API注冊接入。
- 在部署節點，增加自定義腳本編寫，通過自定義運行的腳本來完成API接口服務的注冊。
- 增加接口注冊流水線編排節點，在部署節點完成后，編排注冊節點，在API注冊節點定義接口注冊內容。
由于整個DevOps流水線設計和執行偏開發人員使用，可以看到，采用第一種方式往往更加靈活。唯一的就是在定義某一個流水線的時候，需要預先規劃好需要接入和注冊的接口內容。
而在DevOps支撐平臺雖然不需要完整的API網關管控功能，但是最好還是增加一個功能，就是能夠在DevOps支撐平臺查詢到當前已經注冊和接入了哪些接口服務，注冊接入后提供的代理服務地址是什么，是哪個微服務模塊注冊接入的該服務等基本服務目錄信息。
基于前面思考，后續我們考慮就是實現Kong Ingress和K8s集群的集成，對于需要要注冊的接口服務先寫入配置文件，然后在K8s進行微服務部署或動態節點擴展的時候，通過API調用，將接口服務自動注冊到API網關上面，實現對外訪問。
API消費調用
注意在采用了API網關后帶來的一個好處就是，API網關本身提供出來的API訪問地址的IP是固定的，不會隨著每次微服務模塊的自動構建和部署動態變化。對于API網關我們會提前先部署到測試環境和生產環境，在網關部署完成后再開始進行各個微服務模塊的持續集成和部署操作。
因此一個微服務模塊需要訪問其它微服務模塊哪些接口，一個方法是每次都調用服務注冊中心去查詢具體的服務訪問地址，一個方法就是本身要將訪問地址存在在本地配置文件。更好的方法是：
- 首先調用先訪問服務注冊中心，獲取服務訪問地址，并存在到本地配置文件
- 在發現本地配置文件已經有服務訪問地址后，不再從服務注冊中心調用，除非得到地址變更消息通知
在這個確定后，微服務模塊本身的構建打包和部署，實際上和原來沒有和API網關協同是完全一樣的，只是配置文件訪問地址固定為了API網關提供的地址而已。如何知道API網關提供了哪些地址，即我們談到的可以在API網關的管控平臺查詢，也可以在DevOps平臺提供的服務目錄查詢功能上進行查詢。
