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

k8s 在企業中的應用場景

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

可移植: 支持公有云，私有云，混合云，多重云（multi-cloud）

可擴展: 模塊化，插件化，可掛載，可組合

自動化: 自動部署，自動重啟，自動復制，自動伸縮/擴展

自動化運維平臺

對于中小型企業，為了降本增效，使用 k8s 來構建一套自動化運維平臺，提供了應用部署，規劃，更新，維護的一種機制。

對于大型互聯網公司更要使用容器化部署。現在服務器越來越多，不可能都人工部署，需要使用自動化的運維平臺來監控服務，來實現自動服務化的部署、運維。

充分利用服務器資源

假設現在有一個開發量為 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

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

服務無縫遷移

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

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

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

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

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

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

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

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

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

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

容器化部署問題：

如何對服務橫向擴展？

容器宕機怎么辦？如何恢復？

重新發布版本如何更新且更新后不影響業務？

如何監控容器？

容器如何調度創建？

數據安全性如何保證？

使用 k8s 管理容器，以上問題都能夠完美的解決

云架構 & 云原生

云 和 k8s 的關系

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

k8s：用來管理云中的容器

云架構

iaas：基礎設施即服務

用戶角度：租用（購買或分配權限）云主機，用戶不用考慮網絡、DNS、存儲和硬件環境等方面的問題。
運營商角度：提供網絡、DNS、存儲等這樣的服務就叫做基礎設置服務

paas：平臺即服務

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

saas：軟件即服務

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

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

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

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

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

云原生

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

容器化：所有的服務都必須部署在容器中。

微服務：web 服務架構是微服務架構

CI/CD：可持續交互和可持續部署

DevOps：開發和運維密不可分

kubernetes 架構原理

k8s 的歷史

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

k8s 的架構

k8s 集群（Cluster）

一個 master 對應一群 node 節點

master 節點

api server：相當于 k8s 的網關，所有的指令請求都必須經過 api server

scheduler：調度器，使用調度算法，把請求資源調度到某個 node 節點

controller：控制器，維護 k8s 資源對象（CRUD：添加、刪除、更新、修改）

etcd：存儲資源對象（可以服務注冊、發現等等）

node 節點

docker：運行容器的基礎環境，容器引擎

kubelet：每個 node 節點都有一份kubelet，在 node 節點上的資源操作指令由 kuberlet 來執行，scheduler 把請求交給api ，然后 api sever 再把信息指令數據存儲在 etcd 里，于是 kuberlet 會掃描 etcd 并獲取指令請求，然后去執行

kube-proxy：代理服務，負載均衡

fluentd：日志收集服務

pod：k8s 管理的基本單元（最小單元），pod 內部是容器。k8s 不直接管理容器，而是管理 pod

回顧架構特點

k8s 是用來管理容器的，但是不直接操作容器，最小的操作單元是 pod（間接管理容器）

一個 master 對應一群 node 節點。

master 節點不存儲容器，只負責調度，網關，控制器，資源對象存儲等

容器存儲在 node 節點 的 pod 內部

pod 內部可以有一個或多個容器

kubelet 負責本地的 pod 的維護，CRUD

kube-proxy 負責負載均衡，在多個 pod 間負載均衡

審核編輯：郭婷