k8s的認知與學習

關於 K8s 的基本概念咱們將會圍繞以下七點展開：

• Docker 的管理痛點
• 什麼是 K8s？
• 雲架構 & 雲原生
• K8s 架構原理
• K8s 核心組件
• K8s 的服務註冊與發現
• 關鍵問題

Docker 的管理痛點

若是想要將 Docker 應用於龐大的業務實現，是存在困難的編排、管理和調度問題。

因而，咱們迫切須要一套管理系統，對 Docker 及容器進行更高級更靈活的管理。

Kubernetes 應運而生！Kubernetes，名詞源於希臘語，意爲「舵手」或「飛行員」。

Google 在 2014 年開源了 Kubernetes 項目，創建在 Google 在大規模運行生產工做負載方面擁有十幾年的經驗的基礎上，結合了社區中最好的想法和實踐。

K8s 是 Kubernetes 的縮寫，用 8 替代了 「ubernete」，下文咱們將使用簡稱。

什麼是 K8s ？

K8s 是一個可移植的、可擴展的開源平臺，用於管理容器化的工做負載和服務，可促進聲明式配置和自動化。

K8s 擁有一個龐大且快速增加的生態系統。K8s 的服務、支持和工具普遍可用。

經過 K8s 咱們能夠：

• 快速部署應用
• 快速擴展應用
• 無縫對接新的應用功能
• 節省資源，優化硬件資源的使用

K8s 有以下特色：

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

雲架構 & 雲原生

①雲和 K8s 是什麼關係

雲就是使用容器構建的一套服務集羣網絡，雲由不少的大量容器構成。K8s 就是用來管理雲中的容器。

②常見幾類雲架構

常見幾類雲架構如上圖所示：

• On-Premises（本地部署）。
• IaaS（基礎設施即服務）：用戶：租用（購買|分配權限）雲主機，用戶不須要考慮網絡，DNS，硬件環境方面的問題；運營商：提供網絡，存儲，DNS，這樣服務就叫作基礎設施服務。
• PaaS（平臺即服務-中間件）：MySQL/ES/MQ/...
• SaaS（軟件即服務-瀏覽器頁面）：釘釘，財務管理。
• Serverless：無服務，不須要服務器。站在用戶的角度考慮問題，用戶只須要使用雲服務器便可，在雲服務器所在的基礎環境，軟件環境都不須要用戶關心。

若是以爲很差理解，推薦閱讀這篇文章：如何通俗解釋 IaaS、PaaS、SaaS 的區別：

https://www.zhihu.com/question/21641778/answer/62523535

能夠預見：將來服務開發都是 Serverless，企業都構建了本身的私有云環境，或者是使用公有云環境。③雲原生

爲了讓應用程序（項目，服務軟件）都運行在雲上的解決方案，這樣的方案叫作雲原生。

雲原生有以下特色：

• 容器化，全部服務都必須部署在容器中
• 微服務，Web 服務架構式服務架構
• CI/CD
• DevOps

K8s 架構原理

①K8s 架構

k8s架構解釋：

歸納來講 K8s 架構就是一個 Master 對應一羣 Node 節點。下面咱們來逐一介紹 K8s 架構圖中的 Master 和 Node。

Master 節點結構以下：

• apiserver 即 K8s 網關，全部的指令請求都必需要通過 apiserver。
• Scheduler調度器，使用調度算法，把請求資源調度到某一個 Node 節點。
• Controller 控制器，維護 K8s 資源對象。
• etcd: 存儲資源對象。

Node 節點結構以下：

• Kubelet 在每個 Node 節點都存在一份，在 Node 節點上的資源操做指令由 Kubelet 來執行。
• Kube-proxy 代理服務，處理服務間負載均衡。
• Pod 是 K8s 管理的基本單元（最小單元），Pod 內部是容器，K8s 不直接管理容器，而是管理 Pod。
• Docker 運行容器的基礎環境，容器引擎。
• Fluentd 日誌收集服務。

在介紹完 K8s 架構後，咱們又引入了不少技術名詞。不要着急，先有總體概念，再各個擊破。請耐心閱讀下文，相信你必定會有不同的收穫。

K8s 核心組件

①K8s 組件

K8s 是用來管理容器，可是不直接操做容器，最小操做單元是 Pod （間接管理容器）：

• 一個 Master 有一羣 Node 節點與之對應。
• Master 節點不存儲容器，只負責調度、網管、控制器、資源對象存儲。
• 容器的存儲在 Node 節點，容器是存儲在 Pod 內部的）。
• Pod 內部能夠有一個容器，或者多個容器。
• Kubelet 負責本地 Pod 的維護。
• Kube-proxy 負責負載均衡，在多個 Pod 之間來作負載均衡。

②Pod 是什麼？解釋以下：

• Pod 也是一個容器，這個容器中裝的是 Docker 建立的容器，Pod 用來封裝容器的一個容器，Pod 是一個虛擬化分組。
• Pod 至關於獨立主機，能夠封裝一個或者多個容器。
• Pod 有本身的 IP 地址、主機名，至關於一臺獨立沙箱環境。

**③Pod 到底用來幹什麼？

一般狀況下，在服務部署時候，使用 Pod 來管理一組相關的服務。一個 Pod 中要麼部署一個服務，要麼部署一組有關係的服務。一組相關的服務是指：在鏈式調用的調用連路上的服務。

**④Web 服務集羣如何實現？

**實現服務集羣：只須要複製多方 Pod 的副本便可，這也是 K8s 管理的先進之處，K8s 若是繼續擴容，只須要控制 Pod 的數量便可，縮容道理相似。

**⑤Pod 底層網絡，數據存儲是如何進行的？

具體以下：

• Pod 內部容器建立以前，必須先建立 Pause 容器。
• 服務容器之間訪問 localhost ，至關於訪問本地服務同樣，性能很是高。

⑥ReplicaSet 副本控制器

• 控制 Pod 副本「服務集羣」的數量，永遠與預期設定的數量保持一致便可。
• 當有 Pod 服務宕機時候，副本控制器將會立馬從新建立一個新的 Pod，永遠保證副本爲設置數量。

副本控制器：標籤選擇器-選擇維護一組相關的服務（它本身的服務）

• ReplicationController 副本控制器：單選。
• ReplicaSet 副本控制器：單選，複合選擇。

selector：
    app = web
    Release = stable

在新版的 K8s 中，建議使用 ReplicaSet 做爲副本控制器，ReplicationController 再也不使用了。

⑦Deployment 部署對象

Deployment 部署對象以下：

• 服務部署結構模型
• 滾動更新

ReplicaSet 副本控制器控制 Pod 副本的數量。可是，項目的需求在不斷迭代、不斷的更新，項目版本將會不停的的發版。版本的變化，如何作到服務更新？
部署模型：

• ReplicaSet 不支持滾動更新，Deployment 對象支持滾動更新，一般和 ReplicaSet 一塊兒使用。
• Deployment 管理 ReplicaSet，RS 從新創建新的 RS，建立新的 Pod。

⑧MySQL 使用容器化部署，存在什麼樣的問題？

問題以下：

• 容器是生命週期的，一旦宕機，數據丟失
• Pod 部署，Pod 有生命週期，數據丟失

Deployment與StatefulSet(有狀態與無狀態部署策略)

對於 K8s 來講，不能使用 Deployment 部署有狀態服務。一般狀況下，Deployment 被用來部署無狀態服務，那麼對於有狀態服務的部署，使用 StatefulSet 進行有狀態服務的部署。

什麼是有狀態服務？

• 有實時的數據須要存儲。
• 有狀態服務集羣中，把某一個服務抽離出去，一段時間後再加入機器網絡，若是集羣網絡沒法使用。

什麼是無狀態服務？

• 沒有實時的數據須要存儲。
• 無狀態服務集羣中，把某一個服務抽離出去，一段時間後再加入機器網絡，對集羣服務沒有任何影響。

⑨StatefulSet

爲了解決有狀態服務使用容器化部署的一個問題：

• 部署模型
• 有狀態服務

StatefulSet 保證 Pod 從新創建後，Hostname 不會發生變化，Pod 就能夠經過 Hostname 來關聯數據。

K8s 的服務註冊與發現

①Pod 的結構是怎樣的？

結構以下：

• Pod 至關於一個容器，Pod 有獨立 IP 地址，也有本身的 Hostname，利用 Namespace 進行資源隔離，獨立沙箱環境。
• Pod 內部封裝的是容器，能夠封裝一個，或者多個容器（一般是一組相關的容器）。

②Pod 網絡具體以下：

• Pod 有本身獨立的 IP 地址。
• Pod 內部容器之間訪問採用 Localhost 訪問。
• Pod 內部容器訪問是 Localhost，Pod 之間的通訊屬於遠程訪問(集羣內部服務可見)。

**③Pod 是如何對外提供服務訪問的？

Pod 是虛擬的資源對象（進程），沒有對應實體（物理機，物理網卡）與之對應，沒法直接對外提供服務訪問。
那麼該如何解決這個問題呢？
Pod 若是想要對外提供服務，必須綁定物理機端口。也就是說在物理機上開啓端口，讓這個端口和 Pod 的端口進行映射，這樣就能夠經過物理機進行數據包的轉發。歸納來講：先經過物理機 IP+Port 進行訪問，再進行數據包轉發。--【NodePort】

④一組相關的 Pod 副本，如何實現訪問負載均衡？

咱們先明確一個概念，Pod 是一個進程，是有生命週期的。宕機、版本更新，都會建立新的 Pod。這時候 IP 地址會發生變化，Hostname 會發生變化，使用 Nginx 作負載均衡就不太合適了。因此咱們須要依賴 Service 的能力。

⑤Service 如何實現負載均衡？

簡單來講，Service 資源對象包括以下三部分：

• Pod IP：Pod 的 IP 地址。
• Node IP：物理機 IP 地址。
• Cluster IP：虛擬 IP ，是由 K8s 抽象出的 Service 對象，這個 Service 對象就是一個 VIP 的資源對象。

⑥Service VIP 更深刻原理探討

具體以下：

• Service 和 Pod 都是一個進程，Service 也不能對外網提供服務。
• Service 和 Pod 之間能夠直接進行通訊，它們的通訊屬於局域網通訊。
• 把請求交給 Service 後，Service 使用 iptable，ipvs 作數據包的分發。

⑦Service 對象是如何和 Pod 進行關聯的？

具體以下：

• 不一樣的業務有不一樣的 Service。
• Service 和 Pod 經過標籤選擇器進行關聯。

selector：
    app=x 選擇一組訂單的服務 pod ，建立一個 service；
    經過 endpoints 存放一組 pod ip；

Service 經過標籤選擇器選擇一組相關的副本，而後建立一個 Service。

⑧Pod 宕機、發佈新的版本的時候，Service 如何發現 Pod 已經發生了變化？

每一個 Pod 中都有 Kube-Proxy，監聽全部Pod。若是發現 Pod 有變化，就動態更新（etcd 中存儲）對應的 IP 映射關係。

關鍵問題

①企業使用 K8s 主要用來作什麼？

有以下三個方面：

• 自動化運維平臺，創業型公司，中小型企業，使用 K8s 構建一套自動化運維平臺，自動維護服務數量，保持服務永遠和預期的數據保持一致性，讓服務能夠永遠提供服務。這樣最直接的好處就是降本增效。
• 充分利用服務器資源，互聯網企業，有不少服務器資源「物理機」，爲了充分利用服務器資源，使用 K8s 構建私有云環境，項目運行在雲。這在大型互聯網公司尤其重要。
• 服務的無縫遷移，項目開發中，產品需求不停的迭代，更新產品。這就意味着項目不停的發佈新的版本，而 K8s 能夠實現項目從開發到生產無縫遷移。

②K8s 服務的負載均衡是如何實現的？

• Pod 中的容器極可能由於各類緣由發生故障而死掉。Deployment 等 Controller 會經過動態建立和銷燬Pod來保證應用總體的健壯性。
• 換句話說，Pod是脆弱的，但應用是健壯的。每一個 Pod 都有本身的 IP 地址。當 Controller 用新 Pod 替代發生故障的 Pod 時，新 Pod 會分配到新的 IP 地址。這樣就產生了一個問題：若是一組 Pod 對外提供服務（好比 HTTP），它們的 IP 頗有可能發生變化，那麼客戶端如何找到並訪問這個服務呢？
• K8s 給出的解決方案是 Service。Kubernetes Service 從邏輯上表明瞭一組 Pod，具體是哪些 Pod 則是由 Label 來挑選。Service 有本身 IP，並且這個 IP 是不變的。客戶端只須要訪問 Service 的 IP，K8s 則負責創建和維護 Service 與 Pod 的映射關係。不管後端 Pod 如何變化，對客戶端不會有任何影響，由於 Service 沒有變。

③無狀態服務通常使用什麼方式進行部署？

Deployment 爲 Pod 和 ReplicaSet 提供了一個 聲明式定義方法，一般被用來部署無狀態服務。Deployment 的主要做用：定義 Deployment 來建立 Pod 和 ReplicaSet 滾動升級和回滾應用擴容和索容暫停和繼續。Deployment不只僅能夠滾動更新，並且能夠進行回滾，若是發現升級到 V2 版本後，服務不可用，能夠迅速回滾到 V1 版本。