Kubernetes 是什么

在 2008 年，LXC（Linux containers） 發(fā)布第一個版本，這是最初的容器版本；2013 年，Docker 推出了第一個版本；而 Google 則在 2014 年推出了 LMCTFY。

為了解決大集群(Cluster)中容器部署、伸縮和管理的各種問題，出現(xiàn)了 Kubernetes、Docker Swarm 等軟件，稱為容器編排引擎。

容器的產(chǎn)生解決了很多開發(fā)、部署痛點，但隨著云原生、微服務(wù)的興起，純 Docker 出現(xiàn)了一些管理難題。我們先思考一下，運行一個 Docker 容器，只需要使用 docker run ... 命令即可，這是相當(dāng)簡單(relatibely simple)的方法。

但是，要實現(xiàn)以下場景，則是困難的：

• 跨多臺主機的容器相互連接(connecting containers across multiple hosts)
• 拓展容器(scaling containers)
• 在不停機的情況下配置應(yīng)用(deploying applications without downtime)
• 在多個方面進行服務(wù)發(fā)現(xiàn)(service discovery among several aspects)

Kubernetes 是 Google 基于十多年的生產(chǎn)環(huán)境運維經(jīng)驗，開發(fā)出的一個生產(chǎn)級別的容器編排系統(tǒng)。在 Kunernetes 文檔中，這樣描述 Kubernetes：

[Success]

"an open-source system for automating deployment, scaling, and management of containerized applications".

“一個自動化部署、可拓展和管理容器應(yīng)用的開源系統(tǒng)”

Google 的基礎(chǔ)設(shè)施在虛擬機(Virtual machines)技術(shù)普及之前就已經(jīng)達到了很大的規(guī)模，高效地使用集群和管理分布式應(yīng)用成為 Google 挑戰(zhàn)的核心，而容器技術(shù)提供了一種高效打包集群的解決方案。

多年來，Google 一直使用 Borg 來管理集群中的容器，積累了大量的集群管理經(jīng)驗和運維軟件開發(fā)能力，Google 參考 Borg ，開發(fā)出了 Kubernetes，即 Borg 是 Kubernetes 的前身。（但是 Google 目前還是主要使用 Borg）。

Kubernetes 從一開始就通過一組基元(primitives)、強大的和可拓展的 API 應(yīng)對這些挑戰(zhàn)，添加新對象和控制器地能力可以很容易地地址各種各樣的產(chǎn)品需求(production needs)。

編排管理是通過一系列的監(jiān)控循環(huán)控制或操作的；每個控制器都向詢問對象狀態(tài)，然后修改它，直至達到條件為止。容器編排是管理容器的最主要的技術(shù)。Dockers 也有其官方開發(fā)的 swarm 這個編排工具，但是在 2017 年的容器編排大戰(zhàn)中，swarm 敗于 Kubernetes。

Kubernetes 集群的組成

在 Kubernets 中，運行應(yīng)用程序的環(huán)境處于虛擬化當(dāng)中，因此我們一般不談?wù)撚布?/p>

我們談起 Kubernetes 和應(yīng)用部署時，往往會涉及到容器、節(jié)點、Pods 等概念，它們共同工作來管理容器化(containerized)應(yīng)用的部署和執(zhí)行，但是各種各樣的術(shù)語，令人眼花繚亂。為了更好地摸清 Kubernetes，下面我們將列舉這些有邊界的對象。

在 Kubernetes 中，不同的對象其管理的范圍、作用范圍不同，它們的邊界大小也不同。接下來的內(nèi)容，按將從小到大的粒度介紹這些組成成分。

Pod

Pod 是 Kubernetes 中管理和調(diào)度的最小工作單位，Pod 中可以包含多個容器。這些容器會共享 Pod 中的網(wǎng)絡(luò)等資源。當(dāng)部署 Pod 時，會把一組關(guān)聯(lián)性較強的容器部署到同一個節(jié)點上。

而節(jié)點則是指一臺服務(wù)器、虛擬機等，運行著一個完整的操作系統(tǒng)，提供了 CPU、內(nèi)存等計算資源，一個節(jié)點可以部署多個 Pod。

而一個集群(Cluster)之中，運行著 N 臺服務(wù)器，即 N 個節(jié)點。這些節(jié)點有兩種，一種是 master 節(jié)點，一種是 worker 節(jié)點。master 節(jié)點運行著 Kubernetes 系統(tǒng)組件，而 worker 節(jié)點負(fù)責(zé)運行用戶的程序。所有節(jié)點都歸 master 管，我們通過命令、API 的方式管理 Kubernetes 集群時，是通過發(fā)送命令或請求到 master 節(jié)點上的系統(tǒng)組件，然后控制整個集群。

另外，kubernetes 中有命名空間(namespace)的概念，這跟Linux-namespace 類似，在一個集群中使用命名空間將不同的 Pod 隔離開來。但是 Kubernetes 中，不同 namespace 的 Pod 是可以相互訪問的，它們不是完全隔離的。

Kubernetes 結(jié)構(gòu)

用圖來表示體系結(jié)構(gòu)，是闡述 Kubernetes 最快的方式，下面是一張稱為 Kubernetes Architecture graphic 。

上圖是簡單的 kubernetes 結(jié)構(gòu)，左側(cè)虛線方框中，是 master 節(jié)點，運行著各種各樣的組件，master 節(jié)點負(fù)責(zé)控制整個集群，當(dāng)然在很大的集群中也可以有多個 master 節(jié)點；而右側(cè)是三個工作節(jié)點，負(fù)責(zé)運行我們的容器應(yīng)用。這種結(jié)構(gòu)一般稱為 master-slave 結(jié)構(gòu)，因為某些原因，在 Kubernetes 中后來改稱為 master-minions。工作節(jié)點掛了沒關(guān)系，master 節(jié)點會將故障節(jié)點上的業(yè)務(wù)自動在另一個節(jié)點上部署。

工作節(jié)點比較簡單，在工作節(jié)點中，我們看到有 kubelet 和 kube-proxy 兩個組件，kubelet 和 kube-proxy 都是跟 主節(jié)點的 kube-apiserver 進行通信的。kube-proxy 全稱是 Kubenetes Service Proxy，負(fù)責(zé)組件之間的負(fù)載均衡網(wǎng)絡(luò)流量。

在上圖中， 主節(jié)點由多個組件構(gòu)成，結(jié)構(gòu)比較復(fù)雜， 主節(jié)點中記錄了整個集群的工作數(shù)據(jù)，負(fù)責(zé)控制整個集群的運行。工作節(jié)點掛了沒關(guān)系，但是 主節(jié)點掛了，整個集群就掛了。因此， 有條件的情況下，也應(yīng)該 設(shè)置多個 主節(jié)點。

一個 主節(jié)點中包含以下訪問：

• 一個 API 服務(wù)(kube-apiserver)
• 一個調(diào)度器(kube-scheduler)
• 各種各樣的控制器(上圖有兩個控制器)
• 一個存儲系統(tǒng)(這個組件稱為etcd)，存儲集群的狀態(tài)、容器的設(shè)置、網(wǎng)絡(luò)配置等數(shù)據(jù)。

這張圖片中還有很多東西，這里暫時不作講解，我們在后面的章節(jié)再去學(xué)習(xí)那些 Kubernetes 中的術(shù)語和關(guān)鍵字。

組件

一個 kubernetes 集群是由一組被稱為節(jié)點的機器或虛擬機組成，節(jié)點有 master、worker 兩種類型。一個集群中至少有一個 master 節(jié)點，在沒有 worker 節(jié)點的情況下， Pod 也可以部署到 master 節(jié)點上。如果集群中的節(jié)點數(shù)量非常多，則可考慮擴展 master 節(jié)點，使用多個 master 節(jié)點控制集群。

在上一小節(jié)中，我們看到 主節(jié)點中包含了比較多的組件，工作節(jié)點也包含了一些組件，這些組件可以分為兩種，分別是 Control Plane Components(控制平面組件)、Node Components(節(jié)點組件)。

Control Plane Components 用于對集群做出全局決策，部署在 master 節(jié)點上；

Node Components 在 worker 節(jié)點中運行，為 Pod 提供 Kubernetes 環(huán)境。

Master 節(jié)點

Master 是由一組稱為控制平面組件組成的，如果你已經(jīng)根據(jù)第二章中，通過 minikube 或 kubeadm 部署了 kubernetes，那么我們可以打開 /etc/kubernetes/manifests/ 目錄，這里存放了 k8s 默認(rèn)的控制平面組件的 YAML 文件。

.
├── etcd.yaml
├── kube-apiserver.yaml
├── kube-controller-manager.yaml
└── kube-scheduler.yaml

對于集群來說， 這四個組件都是是必不可少的。

在結(jié)構(gòu)圖中，還有一個 cloud-controller 組件，主要由云平臺服務(wù)商提供，屬于第三方組件，這里不再討論。下面我們來了解 master 中的組件。

master 節(jié)點中各個組件(控制平面組件)需要使用到的端口：

普通節(jié)點中各個組件需要使用到的端口：

kube-apiserver

kube-apiserver 是 k8s 主要進程之一，apiserver 組件公開了 Kubernetes API (HTTP API)，apiserver 是 Kubernetes 控制面的前端，我們可以用 Go、C# 等編程語言寫代碼，遠程調(diào)用 Kubernetes，控制集群的運行。apiserver 暴露的 endiont 端口是 6443。

為了控制集群的運行，Kubernetes 官方提供了一個名為 kubectl 的二進制命令行工具，正是 apiserver 提供了接口服務(wù)，kubectl 解析用戶輸入的指令后，向 apiserver 發(fā)起 HTTP 請求，再將結(jié)果反饋給用戶。

[Info] kubectl

kubectl 是 Kubernetes 自帶的一個非常強大的控制集群的工具，通過命令行操作去管理整個集群。

Kubernetes 有很多可視化面板，例如 Dashboard，其背后也是調(diào)用 apiserver 的 API，相當(dāng)于前端調(diào)后端。

總之，我們使用的各種管理集群的工具，其后端都是 apiserver，通過 apiserver，我們還可以定制各種各樣的管理集群的工具，例如網(wǎng)格管理工具 istio。騰訊云、阿里云等云平臺都提供了在線的 kubernetes 服務(wù)，還有控制臺可視化操作，也是利用了 apiserver。

etcd

etcd 是兼具一致性和高可用性的鍵值數(shù)據(jù)庫，作為保存 Kubernetes 所有集群數(shù)據(jù)的后臺數(shù)據(jù)庫。apiserver 的所有操作結(jié)果都會存儲到 etcd 數(shù)據(jù)庫中，etcd 主要存儲 k8s 的狀態(tài)、網(wǎng)絡(luò)配置以及其它持久化數(shù)據(jù)，etcd 是使用 B+ 樹實現(xiàn)的，etcd 是非常重要的組件，需要及時備份數(shù)據(jù)。

kube-scheduler

scheduler 負(fù)責(zé)監(jiān)視新創(chuàng)建的 pod，并把 pod 分配到節(jié)點上。當(dāng)要運行容器時，發(fā)送的請求會被調(diào)度器轉(zhuǎn)發(fā)到 API；調(diào)度器還可以尋找一個合適的節(jié)點運行這個容器。

kube-controller-manager

kube-controller-manager 中包含了多個控制器，它們都被編譯到一個二進制文件中，但是啟動后會產(chǎn)生不同的進程。這些控制器有：

• 節(jié)點控制器（Node Controller）

  負(fù)責(zé)在節(jié)點出現(xiàn)故障時進行通知和響應(yīng)

• 任務(wù)控制器（Job controller）

  監(jiān)測代表一次性任務(wù)的 Job 對象，然后創(chuàng)建 Pods 來運行這些任務(wù)直至完成

• 端點控制器（Endpoints Controller）

  填充端點(Endpoints)對象(即加入 Service 與 Pod)

• 服務(wù)帳戶和令牌控制器（Service Account & Token Controllers）

  為新的命名空間創(chuàng)建默認(rèn)帳戶和 API 訪問令牌

控制器控制的 Pod、Job、Endpoints、Service 等，都是后面要深入學(xué)習(xí)的。

到此這篇關(guān)于Kubernetes(K8S)基礎(chǔ)知識的文章就介紹到這了。希望對大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。