Kubernetes

介紹

Kubernetes是一個全新的基於容器技術的分散式架構領先方案, 它是Google在2014年6月開源的一個容器叢集管理系統，使用Go語言開發，Kubernetes也叫K8S。K8S是Google內部一個叫Borg的容器叢集管理系統衍生出來的，Borg已經在Google大規模生產執行十年之久。K8S主要用於自動化部署、擴充套件和管理容器應用，提供了資源排程、部署管理、服務發現、擴容縮容、監控等一整套功能。2015年7月，Kubernetes v1.0正式釋出，截止到2017年9月29日最新穩定版本是v1.8。Kubernetes目標是讓部署容器化應用簡單高效。

Kubernetes最初源於谷歌內部的Borg，提供了面向應用的容器叢集部署和管理系統。Kubernetes 的目標旨在消除編排物理/虛擬計算，網路和儲存基礎設施的負擔，並使應用程式運營商和開發人員完全將重點放在以容器為中心的原語上進行自助運營。Kubernetes 也提供穩定、相容的基礎（平臺），用於構建定製化的workflows 和更高階的自動化任務。

Kubernetes 具備完善的叢集管理能力，包括多層次的安全防護和准入機制、多租戶應用支撐能力、透明的服務註冊和服務發現機制、內建負載均衡器、故障發現和自我修復能力、服務滾動升級和線上擴容、可擴充套件的資源自動排程機制、多粒度的資源配額管理能力。Kubernetes 還提供完善的管理工具，涵蓋開發、部署測試、運維監控等各個環節。

Kubernetes優勢

• 容器編排

• 輕量級

• 開源

• 彈性伸縮

• 負載均衡

特性

1、自我修復

在節點故障時重新啟動失敗的容器，替換和重新部署，保證預期的副本數量；殺死健康檢查失敗的容器，並且在未準備好之前不會處理客戶端請求，確保線上服務不中斷。

2、彈性伸縮

使用命令、UI或者基於CPU使用情況自動快速擴容和縮容應用程式例項，保證應用業務高峰併發時的高可用性；業務低峰時回收資源，以最小成本執行服務。

3、自動部署和回滾

K8S採用滾動更新策略更新應用，一次更新一個Pod，而不是同時刪除所有Pod，如果更新過程中出現問題，將回滾更改，確保升級不受影響業務。

4、服務發現和負載均衡

K8S為多個容器提供一個統一訪問入口（內部IP地址和一個DNS名稱），並且負載均衡關聯的所有容器，使得使用者無需考慮容器IP問題。

5、機密和配置管理

管理機密資料和應用程式配置，而不需要把敏感資料暴露在映象裡，提高敏感資料安全性。並可以將一些常用的配置儲存在K8S中，方便應用程式使用。

6、儲存編排

掛載外部儲存系統，無論是來自本地儲存，公有云（如AWS），還是網路儲存（如NFS、GlusterFS、Ceph）都作為叢集資源的一部分使用，極大提高儲存使用靈活性。  批處理 提供一次性任務，定時任務；滿足批量資料處理和分析的場景。

7、自動裝箱 建構於容器之上，基於資源依賴及其他約東自動完成容器部署且不影響其可用性，並通過排程機制混合關鍵型應用和非關鍵型應用的工作負載於同一節點以提升資源利用率。

8、水平擴充套件 支援通過簡單命令或 UI 手動水平擴充套件，以及基於 CPU 等資源負載率的自動水平擴充套件機制。

9、服務發現和負載均衡 Kubernetes 通過其附加元件之一的 KubeDNS (或 CoreDNS )為系統內建了服務發現功能，它會為每個 Service 配置 DNS 名稱，並允許叢集內的客戶端直接使用此名稱發出訪問請求，而 Service 則通過 iptables 或 ipvs 內建了負載均衡機制。

10、自動釋出和回滾 Kubernetes 支援“灰度”更新應用程式或其配置資訊，它會監控更新過程中應用程式的健康狀態，以確保它不會在同一時刻殺掉所有例項，而此過程中一旦有故障發生，就會立即自動執行回滾操作。

11、金鑰和配置管理 Kubernetes 的 ConfigMap 實現了配置資料與 Docker 映象解耦，需要時，僅對配置做出變更而無須重新構建 Docker 映象，這為應用開發部署帶來了很大的靈活性。 此外，對於應用所依賴的一些敏感資料，如使用者名稱和密碼、令牌、金鑰等資訊， Kubernetes 專門提供了 Secret 物件為其解耦，既便利了應用的快速開發和交付，又提供了一定程度上的安全保障。

12、儲存編排 Kubernetes 支援 Pod 物件按需自動掛載不同型別的儲存系統，這包括節點本地儲存、公有云服務商的雲端儲存(如 AWS 和 GCP 等)，以及網路儲存系統(例如， NFS 、 ISCSI、GlusterFS 、 Ceph 、 Cinder 和 Flocker 等)。

13、批量處理執行 除了服務型應用， Kubernetes 還支援批處理作業及 CI (持續整合)，如果需要，一樣可以實現容器故障後恢復。

術語

官方把 kubernetes 術語分為 12 個分類： 系統結構、社群、核心物件、擴充套件、基礎、網路、操作、安全、儲存、工具、使用者型別、工作負載

由於 k8s 的術語實在太多了，想要全部記住作為新學者還是有點壓力，所以我們課程中只講解一些常用的術語。想要了解更多 kubernetes 術語，請參照官方術語表。 地址：https://kubernetes.io/docs/reference/glossary/?fundamental=true

Pods

在Kubernetes中，最小的管理元素不是一個個獨立的容器，而是Pod,Pod是最小的，管理，建立，計劃的最小單元。

Labels

標籤其實就一對 key/value ，被關聯到物件上，比如Pod；標籤的使用我們傾向於能夠標示物件的特殊特點，並且對使用者而言是有意義的（就是一眼就看出了這個Pod是資料庫），但是標籤對核心系統是沒有直接意義的。標籤可以用來劃分特定組的物件（比如，所有女的），標籤可以在建立一個物件的時候直接給與，也可以在後期隨時修改，每一個物件可以擁有多個標籤，但是，key值必須是唯一的

"labels": {
    "key1" : "value1",
    "key2" : "value2"
 }

Node

• Node是Kubernetes叢集架構中執行Pod的服務節點（亦叫agent或minion）。
• Node是Kubernetes叢集操作的單元，用來承載被分配Pod的執行，是Pod執行的宿主機。
• node可以是任何形式的計算裝置，只要此裝置上能夠有傳統意義上的CPU、記憶體、儲存空間,並且能裝上k8s的集- - 群代理程式，它都可以作為整個k8s叢集一個成員
• 只要能裝上kunelet就能成為一個節點
• Node是Pod真正執行的主機，可以物理機，也可以是虛擬機器。為了管理Pod，每個Node節點上至少要執行container runtime（比如docker或者rkt）、kubelet和kube-proxy服務。

pod

• 運行於Node節點上，若干相關容器的組合。
• K8s的最小排程邏輯單元
• pod可以理解為是容器的外殼,它為容器做了一層抽象的封裝
• Pod是Kurbernetes進行建立、排程和管理的最小單位，它提供了比容器更高層次的抽象，使得部署和管理更加靈活。
• 一個Pod可以包含一個容器或者多個相關容器。同一個pod中的不同容器可以共享儲存卷
• 一個pod上無論是有一個容器還是有多個容器，一旦將此pod排程到某node上執行時，這一個pod內的所有容器只能執行在同一個node上

可能還是不是挺明白，我舉個例子：經常有人把pod比作豌豆莢，容器就是豌豆莢裡的豌豆，那麼豌豆有可能是一個，也有可能是多個，為什麼不直接使用容器呢，而是用pod來封裝一個或多個容器呢

我這裡舉個例子，如果有一套lnmp架構的系統，一般不會執行在一個容器中，而是在多個容器中，但是這樣他們之間的相互連線就變得十分困難，而pod提供了共享網路和儲存，所以他們可以通過localhost進行內部的通訊，雖然網路和儲存是共享的，但是cpu和記憶體就不是，也是就說我們可以單獨對pod中的容器做資源使用的限制

標籤

• 標籤是附加到容器，複製控制器和服務的鍵值，標籤也是k8s特色的管理方式，便於分類管理資源物件

• 一個Label是 一個key=value的鍵值對，其中key與value由使用者自己指定。

  • key：只能使用 字母 數字 _ - . (只能以字母數字開頭，不能超過63給字元)
  • value： 可以為空 只能使用 字母 數字開頭

• 一個標籤可以對應多個資源，一個資源也可以有多個標籤，它們是多對多的關係。

• 一個資源擁有多個標籤，可以實現不同維度的管理。

• 可以使用標籤選擇器來指定能使用哪些標籤。

標籤選擇器

• 標籤選擇器是Kubernetes中的核心分組原語。使用者使用它們來選擇一組物件。
• 標籤選擇器就是一種根據標籤來過濾符合條件的資源物件的機制
• 用來控制pod

分別的作用

pod=排程和管理的最小單位，邏輯單元

node=是工作的，執行容器，執行Pod的服務節點的

標籤=無非就是給他打個標籤，便於分類管理資源

標籤選擇器=控制pod，根據標籤來過濾符合條件的物件進行刪除，停止

架構

​ Kubernetes 架構是一個比較典型的二層架構和 server-client 架構。Master 作為中央的管控節點，會去與 Node 進行一個連線。

​ 所有 UI 的、clients、這些 user 側的元件，只會和 Master 進行連線，把希望的狀態或者想執行的命令下發給 Master，Master 會把這些命令或者狀態下發給相應的節點，進行最終的執行。

master

​ Kubernetes 的 Master 包含四個主要的元件：API Server、Controller、Scheduler 以及 etcd。

• API Server：是用來處理 API 操作的，Kubernetes 中所有的元件都會和 API Server 進行連線，元件與元件之間一般不進行獨立的連線，都依賴於 API Server 進行訊息的傳送；

• Controller：控制器，它用來完成對叢集狀態的一些管理。

• Scheduler：排程器，完成排程的操作。例如，一個使用者提交了 Container，排程器依據它對 CPU、對 memory 請求大小，找一臺合適的節點，進行放置；

• etcd：是一個分散式的一個儲存系統，API Server 中所需要的這些原資訊都被放置在 etcd 中，etcd 本身是一個高可用系統，通過 etcd 保證整個 Kubernetes 的 Master 元件的高可用性。

Node

​ Kubernetes 的 Node 是真正執行業務負載的，每個業務負載會以 Pod 的形式執行。一個 Pod 中執行的一個或者多個容器，真正去執行這些 Pod 的元件的是叫做 kubelet，也就是 Node 上最為關鍵的元件，它通過 API Server 接收到所需要 Pod 執行的狀態，然後提交到下面畫的這個 Container Runtime 元件中。

在 OS 上去建立容器所需要執行的環境，最終把容器或者 Pod 執行起來，也需要對儲存跟網路進行管理。Kubernetes 並不會直接進行網路儲存的操作，他們會靠 Storage Plugin 或者是網路的 Plugin 來進行操作。使用者自己或者雲廠商都會去寫相應的 Storage Plugin 或者 Network Plugin，去完成儲存操作或網路操作。

​ 在 Kubernetes 自己的環境中，也會有 Kubernetes 的 Network，它是為了提供 Service network 來進行搭網組網的。真正完成 service 組網的元件的是 Kube-proxy，它是利用了 iptable 的能力來進行組建 Kubernetes 的 Network，就是 cluster network，以上就是 Node 上面的四個元件。

​ Kubernetes 的 Node 並不會直接和使用者進行互動，它的互動只會通過 Master。而使用者是通過 Master 向節點下發這些資訊的。Kubernetes 每個 Node 上，都會執行我們剛才提到的這幾個元件。

互動流程

使用者可以通過 UI 或者 CLI 提交一個 Pod 給 Kubernetes 進行部署，這個 Pod 請求首先會通過 CLI 或者 UI 提交給 Kubernetes API Server，下一步 API Server 會把這個資訊寫入到它的儲存系統 etcd，之後 Scheduler 會通過 API Server 的 watch 或者叫做 notification 機制得到這個資訊：有一個 Pod 需要被排程。

​ 然後 Scheduler 會根據它的記憶體狀態進行一次排程決策，在完成這次排程之後，它會向告訴API Server 這個 Pod 需要被排程到某一個節點上。

​ 接著 API Server 接收到這次操作之後，會把這次的結果再次寫到 etcd 中，然後 API Server 會通知相應的節點進行這次 Pod 真正的執行啟動。相應節點的 kubelet 會得到這個通知，kubelet 就會去調 Container runtime 來真正去啟動配置這個容器和這個容器的執行環境，去排程 Storage Plugin 來去配置儲存，network Plugin 去配置網路。