文章目錄
K8s是什麼？
K8s就是Kubernetes，因爲K和s之間有8個字母，所以簡稱K8s
K8s是以谷歌內部容器編排管理平臺Borg爲原型的開源實現
- 是一個容器編排管理平臺
- 是一個微服務支撐平臺
- 是一個可移植的雲平臺
K8s作爲容器管理平臺
- 以Pod（容器組）爲基本的編排和調度單元以及聲明式的對象配置模型（控制器、configmap、sercet等）
- 資源配額與分配管理
- 健康檢查、自愈、伸縮與滾動升級
K8s提供了對於微服務的支撐
- 服務發現、服務編排與內部的路由支持
- 服務的快速部署和自動負載均衡
- 提供對“有狀態”服務的支持等
K8s是一個可移植的雲平臺
- 成爲了面向雲原生應用的新的可移植層，即“雲平臺”
- 爲用戶提供簡單且一致化的應用化容器部署、伸縮和管理機制，形成新的、通用的應用雲化模型
- 雲應用支持跨雲遷移
小結：
從雲原生角度，Kubernetes帶來的好處：
- 容器管理，調度和編排：擺脫鎖定，支持跨雲
- 先進的Wordload管理之經驗模型：Pod和controller
- 原生支持微服務抽象：服務註冊、服務發現和自動負載均衡
爲啥子需要K8s
真正的生產型應用會涉及多個容器。這些容器必須跨多個服務器主機進行部署。容器安全性需要多層部署，因此可能會比較複雜。但 Kubernetes 有助於解決這一問題。Kubernetes 可以提供所需的編排和管理功能，以便您針對這些工作負載大規模部署容器。藉助 Kubernetes 編排功能，您可以構建跨多個容器的應用服務、跨集羣調度、擴展這些容器，並長期持續管理這些容器的健康狀況。
K8s的作用
- 跨多臺主機進行容器編排。
- 更加充分地利用硬件，最大程度獲取運行企業應用所需的資源。
- 有效管控應用部署和更新，並實現自動化操作。
- 掛載和增加存儲，用於運行有狀態的應用。
- 快速、按需擴展容器化應用及其資源。
- 對服務進行聲明式管理，保證所部署的應用始終按照部署的方式運行。
- 利用自動佈局、自動重啓、自動複製以及自動擴展功能，對應用實施狀況檢查和自我修復。
隨口說說K8s的架構
一個K8S系統，通常稱爲一個K8S集羣（Cluster）。
這個集羣主要包含兩個部分：
- 一個Master節點（主節點）
- 一堆Node節點（計算節點）
Master節點主要是負責管理和控制。Node節點是工作負載節點，裏面是具體的容器。
關於Master節點
Master節點主要由API Server、Scheduler、Controller manager構成
- API Server：是整個系統對外的接口，提供客戶端和其它組件的調用，Kubernetes 中所有的組件都會和 API Server 進行連接，組件與組件之間一般不進行獨立的連接，都依賴於 API Server 進行消息的傳送
- Scheduler：負責對集羣內部的資源進行調度，可以理解爲調度中心，一個用戶提交的 Container，依據它對 CPU、對 memory 請求大小，找一臺合適的節點，進行放置
- Controller manager：負責管理控制器，比如說對容器進行修復，以及擴容
- etcd：是一個分佈式的一個存儲系統，API Server 中所需要的這些原信息都被放置在 etcd 中，etcd 本身是一個高可用系統，通過 etcd 保證整個 Kubernetes 的 Master 組件的高可用性。
關於Node節點（真正運行業務負載）
Node節點包括Docker、kubelet、kube-proxy、Fluentd、kube-dns（可選），還有就是Pod。
-
Pod
Pod是K8s最基本的操作單元，一個Pod代表着集羣中運行的一個進程，其內部封裝了一個或多個緊密相關的容器，除了Pod之外，K8s還有一個Service的概念，一個Service可以看作一組提供相同服務的Pod的對外訪問接口，將工作內容與容器集分離。Kubernetes 服務代理會自動將服務請求分發到正確的容器集，無論這個容器集會移到集羣中的哪個位置，哪怕被替換掉。 -
Docker：主要用來創建容器
-
Kubelet：主要負責監視指派到它所在Node上的Pod，包括創建、修改、監控、刪除等，也是真正去運行Pod組件的部分
-
Kube-proxy：主要負責爲Pod對象提供代理
-
Fluentd：主要負責日誌收集、存儲與查詢
過程描述：
用戶可以通過 UI 或者 CLI 提交一個 Pod 給 Kubernetes 進行部署，這個 Pod 請求首先會通過 CLI 或者 UI 提交給 Kubernetes API Server，下一步 API Server 會把這個信息寫入到它的存儲系統 etcd，之後 Scheduler 會通過 API Server 的 watch 或者叫做 notification 機制得到這個信息：有一個 Pod 需要被調度。
這個時候 Scheduler 會根據它的內存狀態進行一次調度決策，在完成這次調度之後，它會向 API Server report 說：“這個 Pod 需要被調度到某一個節點上。”
這個時候 API Server 接收到這次操作之後，會把這次的結果再次寫到 etcd 中，然後 API Server 會通知相應的節點進行這次 Pod 真正的執行啓動。相應節點的 kubelet 會得到這個通知，kubelet 就會去調 Container runtime 來真正去啓動配置這個容器和這個容器的運行環境，去調度 Storage Plugin 來去配置存儲，network Plugin 去配置網絡。