通俗易懂 k8s (1)：kubernetes 架構及應用場景

        kubernetes，簡稱 K8s，是用 8 代替中間 8 個字符 “ubernete” 而成的縮寫，是一個開源的，用於管理雲平臺中多個主機上的容器化的應用，Kubernetes 的目標是讓部署容器化的應用簡單並且高效(powerful)，Kubernetes 提供了應用部署，規劃，更新，維護的一種機制。

        以下爲本人學習 k8s 的筆記，這篇博客是筆記的第一部分。

1. k8s 在企業中的應用場景

首先我們瞭解一下 k8s 的三個基本特點：

• 可移植: 支持公有云，私有云，混合雲，多重雲（multi-cloud）
• 可擴展: 模塊化，插件化，可掛載，可組合
• 自動化: 自動部署，自動重啓，自動複製，自動伸縮/擴展

1.1 自動化運維平臺

• 對於中小型企業，爲了降本增效，使用 k8s 來構建一套自動化運維平臺，提供了應用部署，規劃，更新，維護的一種機制。
• 對於大型互聯網公司更要使用容器化部署。現在服務器越來越多，不可能都人工部署，需要使用自動化的運維平臺來監控服務，來實現自動服務化的部署、運維。

1.2 充分利用服務器資源

舉例說明

        假設現在有一個開發量爲 200 個的請求，服務器配置爲 2cpus 4G

        靜態請求：150（訪問 CDN，Nginx，cache 等）

        動態請求：50（訪問數據庫，需要把數據讀入內存）

估算服務器資源（只考慮內存，不考慮程序響應時間RT，不考慮CPU切換時間）

• 假設一個靜態請求進程佔用2M，一個動態請求進程佔用10M，則這200個請求併發佔用：150×2M + 50×10M = 800M 內存

• 可以支持的 QPS (批發量，每秒查詢率) 爲：200×4=800（因爲 800 M× 4 < 4G）

  因此如果要充分利用服務器資源，需要達到 QPS=800，此時佔用內存 3.2G（剩下 0.8G 給 OS 等）

• 實際上：800QPS 無法達到，還要考慮 RT、CPU 切換、內存等因素，那就保守把 QPS=300，但這時沒能充分利用服務器的資源。更何況當下服務器配置可不止 2cpus 4G

• 容器化解決方案，在服務器部署多個容器，容器當中運行着我們部署的各種服務
  

1.3 服務無縫遷移

        在開發環境開發，然後拿到測試環境去測試，但往往一上線就會有 bug，因爲應用的運行、配置、管理、所有生存週期將與當前操作系統綁定，所以生產環境的不一致就可能導致錯誤。

        使用容器化解決方案，每個應用可以被打包成一個容器鏡像（紅色圈起來表示把服務部署在容器中），使用容器可以在 開發 或 測試 的階段，爲應用創建容器鏡像，這些鏡像能夠完全脫離環境，每個應用不需要與其餘的應用堆棧組合，也不依賴於生產環境基礎結構，這使得從研發到測試、生產能提供一致環境。使用 kubernetes 來管理這些容器，便能夠實現服務的無縫遷移。

2. 服務部署模式變遷 & 服務部署變化問題的思考

2.1 服務部署模式是如何變遷的

• 物理機：傳統的應用部署方式是通過插件或腳本來安裝應用。這樣做的缺點是應用的運行、配置、管理、所有生存週期將與當前操作系統綁定，這樣做並不利於應用的升級更新/回滾等操作。

• 虛擬化 (虛擬機)：當然上面的問題可以通過創建虛擬機的方式來實現某些功能，但是虛擬機本身就很佔用資源，並不利於可移植性。（就是把服務部署在虛擬機中，達到分隔物理資源的作用——充分利用服務器資源）

• 容器部署：每個容器之間互相隔離，每個容器有自己的文件系統 ，容器之間進程不會相互影響，能區分計算資源。相對於虛擬機，容器能快速部署，由於容器與底層設施、機器文件系統解耦的，所以它能在不同雲、不同版本操作系統間進行遷移。而且更輕量級、運行效率更快。

2.2 服務部署模式變化，帶來了哪些問題

前提條件：SOA 架構，微服務架構模式下，服務拆分越來越多，部署維護的服務越來越多，該如何管理？

• 虛擬機服務部署方式（通過 openstack 軟件提供可視化的方式來管理虛擬機）
• 容器化部署模式（通過 k8s 軟件管理容器，其實容器也可以看成一個虛擬機，只不過更輕量級）

容器化部署問題：

• 如何對服務橫向擴展？
• 容器宕機怎麼辦？如何恢復？
• 重新發布版本如何更新且更新後不影響業務？
• 如何監控容器？
• 容器如何調度創建？
• 數據安全性如何保證？

使用 k8s 管理容器，以上問題都能夠完美的解決 ✿✿ヽ(°▽°)ノ✿

3. 雲架構 & 雲原生

3.1 雲 和 k8s 的關係

雲：使用容器構建的一套服務集羣網絡，雲是由很多的容器構成。

k8s：用來管理雲中的容器

3.2 雲架構

• iaas：基礎設施即服務

  用戶角度：租用（購買或分配權限）雲主機，用戶不用考慮網絡、DNS、存儲和硬件環境等方面的問題。

  運營商角度：提供網絡、DNS、存儲等這樣的服務就叫做基礎設置服務

• paas：平臺即服務

  在平臺上提供了很多服務，如 MySQL 服務、Redis 服務、MQ 服務、Elasticsearch 服務等等

• saas：軟件即服務

  釘釘、財務管理等等，一些軟件維護工作都是由運行商來做，用戶只管體驗軟件提供的服務就行了。

• serverless：server 服務，less 無 —— 無服務 不需要服務器

  站在用戶角度考慮問題，用戶只需要使用雲服務器即可。

  在雲服務器上的所有的基礎環境、軟件環境都不需要考慮和維護，非常方便。

未來開發的趨勢都是 severless，企業都構建了自己的私有云或者公有云環境。使用 k8s 構建非常方便。

3.3 雲原生

爲了讓應用程序（項目，服務軟件）都運行在雲上的解決方案，這樣方案叫做雲原生，有以下特點：

• 容器化：所有的服務都必須部署在容器中。
• 微服務：web 服務架構是微服務架構
• CI/CD：可持續交互和可持續部署
• DevOps：開發和運維密不可分

4. kubernetes 架構原理

4.1 k8s 的歷史

        k8s 是由 Google 公司 用go 語言開發的。google 在全球有相當多的服務器，當然需要一個管理軟件。Google內部本身就有一個叫 borg 的系統雲平臺管理工具，已經使用了十幾年。後來參照 borg 系統架構開發了 k8s，主要用它來編排、管理容器，爲容器化的應用提供部署運行、資源調度、服務發現和動態伸縮等一系列完整功能，提高了大規模容器集羣管理的便捷性。

4.2 k8s 的架構

4.2.1 k8s 集羣（Cluster）

• 一個 master 對應一羣 node 節點

4.2.2 master 節點

• api server：相當於 k8s 的網關，所有的指令請求都必須經過 api server
• scheduler：調度器，使用調度算法，把請求資源調度到某個 node 節點
• controller：控制器，維護 k8s 資源對象（CRUD：添加、刪除、更新、修改）
• etcd：存儲資源對象（可以服務註冊、發現等等）

4.2.3 node 節點

• docker：運行容器的基礎環境，容器引擎
• kubelet：每個 node 節點都有一份kubelet，在 node 節點上的資源操作指令由 kuberlet 來執行，scheduler 把請求交給api ，然後 api sever 再把信息指令數據存儲在 etcd 裏，於是 kuberlet 會掃描 etcd 並獲取指令請求，然後去執行
• kube-proxy：代理服務，負載均衡
• fluentd：日誌收集服務
• pod：k8s 管理的基本單元（最小單元），pod 內部是容器。k8s 不直接管理容器，而是管理 pod

4.3 回顧架構特點

• k8s 是用來管理容器的，但是不直接操作容器，最小的操作單元是 pod（間接管理容器）
• 一個 master 對應一羣 node 節點。
• master 節點不存儲容器，只負責調度，網關，控制器，資源對象存儲等
• 容器存儲在 node 節點 的 pod 內部
• pod 內部可以有一個或多個容器
• kubelet 負責本地的 pod 的維護，CRUD
• kube-proxy 負責負載均衡，在多個 pod 間負載均衡

第二篇：通俗易懂 k8s (2)：認識 k8s 核心組件原理