先聲明一下：我所在的公司是一個小團隊，做物聯網相關的，前後端、硬體、測試加起來也就五六十個人左右；本人的崗位是Java開發（兼DBA、運維。。。）；我進公司時整個項目的部署架構為 簡單jar包部署微服務集群形式；去年公司將部分服務使用docker進行部署；因為現在服務稍微有點多導致容器管理起來也比較 ...
先聲明一下：我所在的公司是一個小團隊，做物聯網相關的，前後端、硬體、測試加起來也就五六十個人左右；本人的崗位是Java開發（兼DBA、運維。。。）；我進公司時整個項目的部署架構為 簡單jar包部署微服務集群形式；去年公司將部分服務使用docker進行部署；因為現在服務稍微有點多導致容器管理起來也比較難，再加上我們公司沒有專門的運維人員，所以現在打算使用雲商的k8s來對容器統一進行管理。因為運維相關的事情我一直在負責，上周老大讓我畫一下用k8s部署介面調用鏈路圖，所以我便順便總結了一下，以下大部分內容為我自己理解，如果有什麼不對的地方還請大家多多指出。
一.常見服務部署架構
1.傳統伺服器jar運行部署（公司之前使用的部署方式）
服務部署架構圖
優點
- 學習成本低：只需要掌握Linux命令即可操作，不需要掌握其他特殊命令；
缺點
- 隔離性差： 1.各個集群中所有服務共用相同運行環境，如果環境發生錯誤將會影響集群當前節點上所有的服務；2.如果其中某一個服務發生死鎖、記憶體泄漏等異常，此服務部署的所有節點（伺服器）的記憶體/CPU可能會被占滿，也將影響整個集群的其他服務，導致所有應用不可用；[之前一個項目CPU占用過高進而影響到節點上所有的服務]
- 部署步驟繁瑣：想要部署一個服務，必須得一臺一臺的進行部署；
- 有操作風險：開發人員直接操作伺服器，有存在誤操作的風險（sudo rm -rf /*）。
- 服務啟動速度慢。
2.docker 容器化部署（公司目前使用的部署方式）
服務部署架構圖
優點
- 使用方便：只需要拉取鏡像、運行鏡像 兩步操作即可運行一個服務;
- 隔離性好：一個容器一個運行環境，互不影響，運行時分配好記憶體，如果某一個服務出現記憶體泄漏、CPU占用高等問題，只會影響當前容器，不會觸及到其他容器;
- 快速回滾：當前版本如果出現問題，可以快速的拉取前一個容器的版本，如果使用上面那個部署形式則需要使用git回滾完，再重新打包部署;
- 系統利用率高：docker對系統資源的利用率更高，無論是應用執行速度，記憶體損耗或者文件存儲速度，都要比傳統虛擬機技術更高效。因此，相比虛擬機技術，一個相同配置的主機往往可以運行更多數量的應用;
- 啟動服務的速度更快。
缺點
- 管理麻煩：隨著業務的不斷發展，微服務不斷的增加，導致容器太多管理麻煩，增加運維成本；
- 誤操作風險：跟上面那一張部署方式一樣，開發人員直接操作伺服器，有一定的風險；
- 學習成本：稍微需要一點容器相關的知識，需要學習docker常見的一些命令
- 其他的暫時沒太關心。
3.k8s容器化部署（現在公司需要升級的部署方式）
服務部署架構圖
名詞解釋
- Node：單台主機，可以是物理的或虛擬的電腦。結點分為主結點(master)和工作結點(worker) – 個人理解：一個節點就是一臺伺服器（實例）
- Master：k8s 集群控制節點，對集群進行調度管理，接受集群外用戶去集群操作請求
- Pod ：K8s中的工作單元，服務運行的最小單元。每個Pod中包含一至多個容器；一個Pod的容器在K8s集群中有相同的地址和埠範圍，即容器暴露於K8s集群的埠號不可重覆- 個人理解：一個每個Pod就是k8s虛擬出來的一個微型伺服器，它有自己的虛擬IP、埠等等
- Deployment：無狀態工作負載，個人理解：就是管理Pod的，負載Pod的擴縮容等操作。
- StatefulSet：有狀態工作負載，與Deployment一樣。不同點在於 Deployment的Pod名稱,主機名稱 ,存儲等都是隨機,不穩定的，所以不適合資料庫等需要持久化的伺服器運行，而StatefulSet就可以。
優點
- 自動部署和回滾：我們可以直接通過k8s控制台一鍵實現目標版本代碼的回滾、部署。
- 服務發現和負載均衡：Kubernetes 可以使用 DNS 名稱或自己的 IP 地址來曝露容器。 如果進入容器的流量很大， Kubernetes 可以負載均衡並分配網路流量，從而使部署穩定。
- 自我修復：Kubernetes 將重新啟動失敗的容器、替換容器、殺死不響應用戶定義的運行狀況檢查的容器。
- 不需要直接操作伺服器：控制台操作，簡化了部署流程，減少了運維成本，開發人員無需關註伺服器運維相關事情。
- 資源調度：當node節點上的CPU、記憶體不夠用的時候，可以擴充node節點，新建的pod就會被調度到新擴充的node節點上。
- 故障遷移：當某一個node節點關機或掛掉後，node節點上的服務會自動轉移到另一個node節點上，這個過程所有服務不中斷
- 資源隔離：可以通過創建開發、測試、預發、生產等命名空間實現不同環境的隔離，各環境之間互不影響。
- 擴縮容方便：只需要在控制台調整每個Deployment中Pod的數量就可以實現自動擴縮容。
- 減少了公司運維成本
- Docker有的其他優點。
缺點
- 部署麻煩（自己搭建）
- 占用資源多（自己搭建）
- 運維成本高（自己搭建）
綜上所述：咱們使用雲商搭建好的k8s，所以說目前對我們來說沒有什麼缺點 -- 嘿嘿~。
二．k8s部署、服務調用鏈路相關
1.簡介
就不介紹了，有興趣的可以看一下官方文檔：https://kubernetes.io/zh-cn/docs/concepts/overview/
2.基本概念
Pod里是容器，Pod被ReplicaSet管理，ReplicaSet控制pod的數量；
ReplicaSet被Deployment管理，Deployment控制pod應用的升級、回滾，當然也能控制pod的數量。
Service提供一個統一固定入口，負責將前端請求轉發給Pod
3.調用鏈路
1.目前公司前後端服務調用鏈路
前端
1、 前端訪問功能變數名稱；
2、 功能變數名稱DNS解析到部署前端項目的伺服器（集群：則解析到集群對應的SLB負載均衡公網IP上—SLB負責具體將請求打在某一臺伺服器上）；
3、 被請求的伺服器用Nginx通過功能變數名稱加目錄的形式將請求轉發到不同的前端項目。
後端介面
1、 訪問api介面
2、 功能變數名稱DNS解析到部署網關伺服器（集群：則解析到集群對應的SLB負載均衡公網IP上—SLB負責具體將請求打在某一臺伺服器上）；
3、 被請求的伺服器用Nginx將請求轉發到當前伺服器的Gateway網關
4、 網關對請求介面進行鑒權、匹配路由等操作。
5、 通過Nacos自帶負載均衡Ribbon負載到具體某一個應用服務
6、 返回結果請求結束。
2.使用k8s部署後，前後端調用鏈路
前端
1、SLB監聽80和443埠。
2、請求進來進行功能變數名稱DNS解析，解析到集群暴露出來的公網SLB的IP上。
3、經過nginx Ingress 轉發匹配請求路徑，將請求轉發到不同的Server(一個Server對應一個Deployment，對應一個項目)上。
4、Server會通過k8s自身的負載均衡演算法將請求負載到某一個Pod上面（這一步k8s內部有一個負載均衡選擇具體服務的哪一個Pod）
5、訪問到具體的Pod，返回結果。
後臺介面
1、 SLB監聽80和443埠。
2、 請求進來進行功能變數名稱DNS解析，解析到集群暴露出來的公網SLB的IP上。
3、 經過nginx Ingress 轉發到對應的gateway網關Server上。
4、 Server會通過k8s自身的負載均衡演算法將請求負載到某一個網關Pod上面。
5、 網關對請求介面進行鑒權、匹配路由等操作。
6、 通過Nacos自帶負載均衡Ribbon負載到具體某一個應用服務
7、 返回結果請求結束。
4.阿裡雲流水線 + Kubernetes 鏡像升級部署實踐
K8s鏡像部署
先進行鏡像構建 如下兩步操作並運行流水線
在k8s管理界面的 [工作負載] --> [無狀態] 目錄根據需要部署的環境切換命名空間，如：測試環境(namespace-dev)
創建對應的 Deployment 與 pod
點擊右上角“使用鏡像創建”、對k8s編排掌握好的可以直接使用 yaml 創建，推薦使用鏡像創建。
a.填寫對應的應用服務信息
b.選擇對應的鏡像和版本（剛纔創建的）
其他的不需要填、如果有提示不能為空的直接刪掉就可以了
c.下一步直接點擊創建、完成後出來到無狀態目錄下找到創建的Deployment，點擊去 ---> 容器組 --> 點進去 ---> 日誌 （進行日誌查看）
k8s鏡像升級
回到流水線頁面在構建鏡像的基礎上新建一個 部署任務--Kubernetes 鏡像升級，註意: 命名空間、Deployment名稱、容器名稱 不要填錯。
這樣就完成了k8s鏡像的升級
本文來自博客園，作者：Tom-shushu，轉載請註明原文鏈接：https://www.cnblogs.com/Tom-shushu/p/16913567.html
