Kubernetes 是什么

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

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

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

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

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

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

[Success]

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

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

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

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

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

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

Kubernetes 集群的組成

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

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

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

Pod

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

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

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

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

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

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

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

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

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

一個(gè) 主節(jié)點(diǎn)中包含以下訪問：

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

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

組件

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

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

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

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

Master 節(jié)點(diǎn)

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

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

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

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

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

kube-apiserver

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

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

[Info] kubectl

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

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+ 樹實(shí)現(xiàn)的，etcd 是非常重要的組件，需要及時(shí)備份數(shù)據(jù)。

kube-scheduler

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

kube-controller-manager

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

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

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

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

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

• 端點(diǎn)控制器（Endpoints Controller）

  填充端點(diǎn)(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í)有所幫助，也希望大家多多支持腳本之家。

最新評論