Docker和k8s核心概念(理解友好版)
當(dāng)前位置：點(diǎn)晴教程→知識(shí)管理交流
→『 技術(shù)文檔交流 』
背景 這是在HWL負(fù)責(zé)網(wǎng)校云業(yè)務(wù)線測(cè)試時(shí)，給同事分享的基礎(chǔ)概念文檔。 目錄： 一. Docker核心概念 二. Kubernetes是什么及架構(gòu) 三. Kubernetes核心概念 四. Deployment部署Pod操作 一、Docker核心概念
1、為什么是Docker
虛擬機(jī)： 基礎(chǔ)設(shè)施（Infrastructure）。服務(wù)器，或者是云主機(jī)。 主操作系統(tǒng)（Host Operating System）。服務(wù)器上運(yùn)行的操作系統(tǒng) 虛擬機(jī)管理系統(tǒng)（Hypervisor）。利用Hypervisor，可以在主操作系統(tǒng)之上運(yùn)行多個(gè)不同的從操作系統(tǒng)。 從操作系統(tǒng)（Guest Operating System）。假設(shè)你需要運(yùn)行3個(gè)相互隔離的應(yīng)用，則需要使用Hypervisor啟動(dòng)3個(gè)從操作系統(tǒng)，也就是3個(gè)虛擬機(jī)。這些虛擬機(jī)都非常大，也許有700MB，這就意味著它們將占用2.1GB的磁盤空間。更糟糕的是，它們還會(huì)消耗很多CPU和內(nèi)存。 各種依賴。每一個(gè)從操作系統(tǒng)都需要安裝許多依賴。 應(yīng)用。安裝依賴之后，就可以在各個(gè)從操作系統(tǒng)分別運(yùn)行應(yīng)用了，這樣各個(gè)應(yīng)用就是相互隔離的。 Docker： Docker守護(hù)進(jìn)程（Docker Daemon）。Docker守護(hù)進(jìn)程取代了Hypervisor，它是運(yùn)行在操作系統(tǒng)之上的后臺(tái)進(jìn)程，負(fù)責(zé)管理Docker容器。 各種依賴。對(duì)于Docker，應(yīng)用的所有依賴都打包在Docker鏡像中，Docker容器是基于Docker鏡像創(chuàng)建的。 應(yīng)用。應(yīng)用的源代碼與它的依賴都打包在Docker鏡像中，不同的應(yīng)用需要不同的Docker鏡像。不同的應(yīng)用運(yùn)行在不同的Docker容器中，它們是相互隔離的。 對(duì)比虛擬機(jī)與Docker Docker守護(hù)進(jìn)程可以直接與主操作系統(tǒng)進(jìn)行通信，為各個(gè)Docker容器分配資源；它還可以將容器與主操作系統(tǒng)隔離，并將各個(gè)容器互相隔離。虛擬機(jī)啟動(dòng)需要數(shù)分鐘，而Docker容器可以在數(shù)毫秒內(nèi)啟動(dòng)。由于沒(méi)有臃腫的從操作系統(tǒng)，Docker可以節(jié)省大量的磁盤空間以及其他系統(tǒng)資源。
2、Docker 架構(gòu)
Docker使用客戶端 - 服務(wù)器（C/S）架構(gòu)，使用遠(yuǎn)程API管理和創(chuàng)建Docker 容器。Docker 客戶端與Docker 守護(hù)進(jìn)程通信，后者負(fù)責(zé)構(gòu)建、運(yùn)行和分發(fā)Docker容器。 Docker客戶端和守護(hù)進(jìn)程可以在同一系統(tǒng)上運(yùn)行，也可以將Docker客戶端連接到遠(yuǎn)程Docker守護(hù)進(jìn)程。Docker客戶端和守護(hù)進(jìn)程使用REST API，通過(guò)UNIX套接字或網(wǎng)絡(luò)接口進(jìn)行通信。 Client Docker daemon Docker Host Docker Registry Docker Image 鏡像可以用來(lái)創(chuàng)建 Docker 容器，一個(gè)鏡像可以創(chuàng)建很多容器。Docker 提供了一個(gè)很簡(jiǎn)單的機(jī)制來(lái)創(chuàng)建鏡像或者更新現(xiàn)有的鏡像，用戶甚至可以直接從其他人那里下載一個(gè)已經(jīng)做好的鏡像來(lái)直接使用。 Docker Container 可以把容器看做是一個(gè)簡(jiǎn)易版的 Linux 環(huán)境（包括root用戶權(quán)限、進(jìn)程空間、用戶空間和網(wǎng)絡(luò)空間等）和運(yùn)行在其中的應(yīng)用程序。 3、Docker CLI 4、Dockerfile
5、Docker Compose Compose 是用于定義和運(yùn)行多容器 Docker 應(yīng)用程序的工具。通過(guò) Compose，您可以使用 YML 文件來(lái)配置應(yīng)用程序需要的所有服務(wù)。然后，使用一個(gè)命令，就可以從 YML 文件配置中創(chuàng)建并啟動(dòng)所有服務(wù)。
6、Docker Swarm 集群管理 Swarm是Docker 引擎內(nèi)置（原生）的集群管理和編排工具，它將 Docker 主機(jī)池轉(zhuǎn)變?yōu)閱蝹€(gè)虛擬 Docker 主機(jī)。
Docker Swarm 適用于簡(jiǎn)單和快速開(kāi)發(fā)至關(guān)重要的環(huán)境，而 Kubernetes 適合大中型集群運(yùn)行復(fù)雜應(yīng)用程序的環(huán)境。 兩者不是競(jìng)爭(zhēng)對(duì)手，各有利弊，因需選擇。
二、Kubernetes是什么及架構(gòu) 1、k8s是什么 先來(lái)一張Kubernetes官網(wǎng)的截圖，可以看到，官方對(duì)Kubernetes的定義：Kubernetes（k8s）是一個(gè)自動(dòng)化部署、擴(kuò)展和管理容器化應(yīng)用程序的開(kāi)源系統(tǒng)。
Kubernetes 這個(gè)單詞是希臘語(yǔ)，它的中文翻譯是“舵手”或者“飛行員”。在一些常見(jiàn)的資料中也會(huì)看到“ks”這個(gè)詞，也就是“k8s”，它是通過(guò)將8個(gè)字母“ubernete ”替換為“8”而導(dǎo)致的一個(gè)縮寫(xiě)。 Kubernetes 為什么要用“舵手”來(lái)命名呢？
這是一艘載著一堆集裝箱的輪船，輪船在大海上運(yùn)著集裝箱奔波，把集裝箱送到它們?cè)撊サ牡胤健?span id="0o8kqia" class="s10" style="margin: 0px; padding: 0px;">Container 這個(gè)英文單詞也有另外的一個(gè)意思就是“集裝箱”。Kubernetes 也就借著這個(gè)寓意，希望成為運(yùn)送集裝箱的一個(gè)輪船，來(lái)幫助我們管理這些集裝箱，也就是管理這些容器。 這個(gè)就是為什么會(huì)選用 Kubernetes 這個(gè)詞來(lái)代表這個(gè)項(xiàng)目的原因。更具體一點(diǎn)地來(lái)說(shuō)：Kubernetes 是一個(gè)自動(dòng)化的容器編排平臺(tái)，它負(fù)責(zé)應(yīng)用的部署、應(yīng)用的彈性以及應(yīng)用的管理。 2、k8s能做什么
2.1調(diào)度 Kubernetes 可以把用戶提交的容器放到 Kubernetes 管理的集群的某一臺(tái)節(jié)點(diǎn)上去。Kubernetes 的調(diào)度器是執(zhí)行這項(xiàng)能力的組件，它會(huì)觀察正在被調(diào)度的這個(gè)容器的大小、規(guī)格。 比如，容器所需要的CPU以及它所需要的內(nèi)存，然后在集群中找一臺(tái)相對(duì)比較空閑的機(jī)器來(lái)進(jìn)行一次放置的操作。
2.2 自動(dòng)修復(fù) Kubernetes 有節(jié)點(diǎn)健康檢查的功能，它會(huì)監(jiān)測(cè)這個(gè)集群中所有的宿主機(jī)，當(dāng)宿主機(jī)本身出現(xiàn)故障，或者軟件出現(xiàn)故障的時(shí)候，這個(gè)節(jié)點(diǎn)健康檢查會(huì)自動(dòng)對(duì)它進(jìn)行發(fā)現(xiàn)。 接下來(lái) Kubernetes 會(huì)把運(yùn)行在這些失敗節(jié)點(diǎn)上的容器進(jìn)行自動(dòng)遷移，遷移到一個(gè)正在健康運(yùn)行的宿主機(jī)上，來(lái)完成集群內(nèi)容器的自動(dòng)恢復(fù)。
2.3 水平伸縮 Kubernetes有業(yè)務(wù)負(fù)載檢查的能力，它會(huì)監(jiān)測(cè)業(yè)務(wù)上所承擔(dān)的負(fù)載，如果這個(gè)業(yè)務(wù)本身的CPU利用率或內(nèi)存占用過(guò)高，或者響應(yīng)時(shí)間過(guò)長(zhǎng)，它可以對(duì)這個(gè)業(yè)務(wù)進(jìn)行一次擴(kuò)容。 比如，下面的例子中，黃顏色的過(guò)度忙碌，Kubernetes就可以把黃顏色負(fù)載從一份變?yōu)槿?。接下?lái)，它就可以通過(guò)負(fù)載均衡把原來(lái)打到第一個(gè)黃顏色上的負(fù)載平均分到三個(gè)黃顏色的負(fù)載上去，以此來(lái)提高響應(yīng)速度。
3、k8s的架構(gòu) Kubernetes 架構(gòu)是一個(gè)比較典型的二層架構(gòu)和server-client架構(gòu)。Master作為中央管控節(jié)點(diǎn)，與Node建立連接。 所有 UI 的、clients、user側(cè)的組件，只會(huì)和Master進(jìn)行連接，把希望的狀態(tài)或者想執(zhí)行的命令下發(fā)給 Master，Master會(huì)把這些命令或者狀態(tài)下發(fā)給相應(yīng)的節(jié)點(diǎn)，進(jìn)行最終的執(zhí)行。
Kubernetes 的Master包含四個(gè)主要的組件：API Server、Controller、Scheduler以及etcd。
API Server：提供了資源操作的唯一入口，并提供認(rèn)證、授權(quán)、訪問(wèn)控制、API注冊(cè)和發(fā)現(xiàn)等機(jī)制。 Kubernetes 中所有的組件都會(huì)和API Server進(jìn)行連接，組件與組件之間一般不進(jìn)行獨(dú)立的連接，都依賴于API Server進(jìn)行消息的傳送； Controller：控制器，它負(fù)責(zé)維護(hù)集群的狀態(tài)，比如故障檢測(cè)、自動(dòng)擴(kuò)展、滾動(dòng)更新等。上面的2個(gè)例子，第1個(gè)自動(dòng)對(duì)容器進(jìn)行修復(fù)、第2個(gè)自動(dòng)水平擴(kuò)張，都是由Controller 完成的； Scheduler：是調(diào)度器，負(fù)責(zé)資源的調(diào)度，按照預(yù)定的調(diào)度策略將Pod調(diào)度到相應(yīng)的機(jī)器上。例如上面的例子，把用戶提交的pod，依據(jù)它對(duì)CPU、memory請(qǐng)求的大小，找一臺(tái)合適的節(jié)點(diǎn)，進(jìn)行放置； etcd：是一個(gè)分布式的存儲(chǔ)系統(tǒng)，保存了整個(gè)集群的狀態(tài)，比如Pod、Service等對(duì)象信息。API Server 中所需要的原信息都被放置在etcd中，etcd本身是一個(gè)高可用系統(tǒng)，通過(guò)etcd保證整個(gè)Kubernetes的Master組件的高可用性。
Kubernetes 的 Node 是真正運(yùn)行業(yè)務(wù)負(fù)載的，每個(gè)業(yè)務(wù)負(fù)載會(huì)以 Pod 的形式運(yùn)行。一個(gè) Pod 中運(yùn)行的一個(gè)或者多個(gè)容器。 kubelet：Master在Node節(jié)點(diǎn)上的Agent，是真正去運(yùn)行 Pod 的組件，也是Node上最關(guān)鍵的組件，負(fù)責(zé)本Node節(jié)點(diǎn)上Pod的創(chuàng)建、修改、監(jiān)控、刪除等生命周期管理，同時(shí)Kubelet定時(shí)“上報(bào)”本Node的狀態(tài)信息到API Server。 它通過(guò) API Server 接收到所需要 Pod 運(yùn)行的狀態(tài)。然后提交到 Container Runtime 組件中。
Container Runtime：容器運(yùn)行時(shí)。負(fù)責(zé)鏡像管理以及Pod和容器的真正運(yùn)行（CRI），可以理解為類似JVM Storage Plugin 或者 Network Plugin：對(duì)存儲(chǔ)跟網(wǎng)絡(luò)進(jìn)行管理 在 OS 上去創(chuàng)建容器所需要運(yùn)行的環(huán)境，最終把容器或者 Pod 運(yùn)行起來(lái)，也需要對(duì)存儲(chǔ)跟網(wǎng)絡(luò)進(jìn)行管理。Kubernetes 并不會(huì)直接進(jìn)行網(wǎng)絡(luò)存儲(chǔ)的操作，他們會(huì)靠 Storage Plugin 或者Network Plugin 來(lái)進(jìn)行操作。用戶自己或者云廠商都會(huì)去寫(xiě)相應(yīng)的 Storage Plugin 或者 Network Plugin，去完成存儲(chǔ)操作或網(wǎng)絡(luò)操作。 Kube-proxy：負(fù)責(zé)為Service提供cluster內(nèi)部的服務(wù)發(fā)現(xiàn)和負(fù)載均衡，完成 service 組網(wǎng) 在 Kubernetes 自己的環(huán)境中，也會(huì)有 Kubernetes 的 Network，它是為了提供 Service network 來(lái)進(jìn)行搭網(wǎng)組網(wǎng)的。真正完成 service 組網(wǎng)的組件是 Kube-proxy，它是利用了 iptable 的能力來(lái)進(jìn)行組建 Kubernetes 的 Network，就是 cluster network。 組件間的通信
步驟說(shuō)明： 1. 通過(guò) UI 或者 CLI 提交1個(gè) Pod 給 Kubernetes 進(jìn)行部署，這個(gè) Pod 請(qǐng)求首先會(huì)提交給API Server，下一步 API Server 會(huì)把這個(gè)信息寫(xiě)入到存儲(chǔ)系統(tǒng) etcd，之后 Scheduler 會(huì)通過(guò) API Server 的 watch機(jī)制得到這個(gè)信息：有1個(gè)Pod 需要被調(diào)度。 2. Scheduler會(huì)根據(jù)node集群的內(nèi)存狀態(tài)進(jìn)行1次調(diào)度決策，在完成這次調(diào)度之后，它會(huì)向 API Server 報(bào)告：“OK！這個(gè) Pod 需要被調(diào)度到XX節(jié)點(diǎn)上。” API Server 接收后，會(huì)把這次的操作結(jié)果再次寫(xiě)到 etcd 中。 3. API Server 通知相應(yīng)的節(jié)點(diǎn)進(jìn)行這個(gè)Pod真正的執(zhí)行啟動(dòng)。相應(yīng)節(jié)點(diǎn)的 kubelet 會(huì)得到通知，然后kubelet 會(huì)去調(diào) Container runtime 來(lái)真正去啟動(dòng)配置這個(gè)容器和這個(gè)容器的運(yùn)行環(huán)境，去調(diào)度 Storage Plugin 來(lái)去配置存儲(chǔ)，network Plugin 去配置網(wǎng)絡(luò)。
三、Kubernetes核心概念 第一個(gè)概念：Pod Pod 是 Kubernetes 的最小調(diào)度以及資源單元?？梢酝ㄟ^(guò) Kubernetes 的 Pod API 生產(chǎn)一個(gè) Pod，讓 Kubernetes 對(duì)這個(gè) Pod 進(jìn)行調(diào)度，也就是把它放在某一個(gè) Kubernetes 管理的節(jié)點(diǎn)上運(yùn)行起來(lái)。一個(gè) Pod 簡(jiǎn)單來(lái)說(shuō)是對(duì)一組容器的抽象，它里面會(huì)包含一個(gè)或多個(gè)容器。 比如下圖，它包含了兩個(gè)容器，每個(gè)容器可以指定它所需要資源大小 當(dāng)然，在這個(gè) Pod 中也可以包含一些其他所需要的資源：比如說(shuō)我們所看到的 Volume 卷這個(gè)存儲(chǔ)資源。
第二個(gè)概念：Volume 管理 Kubernetes 存儲(chǔ)，用來(lái)聲明在 Pod 中的容器可以訪問(wèn)的文件目錄，一個(gè)卷可以被掛載在 Pod 中一個(gè)或者多個(gè)容器的指定路徑下面。 而 Volume 本身是一個(gè)抽象的概念，一個(gè) Volume 可以去支持多種的后端的存儲(chǔ)。Kubernetes 的 Volume 支持很多存儲(chǔ)插件，可以支持本地的存儲(chǔ)和分布式的存儲(chǔ)，比如像 ceph，GlusterFS；也可以支持云存儲(chǔ)，比如阿里云上的云盤、AWS 上的云盤、Google 上的云盤等等。
第三個(gè)概念：Deployment Deployment 是在Pod上更為上層的一個(gè)抽象，它可以定義一組Pod 的副本數(shù)目、以及Pod的版本。一般用Deployment來(lái)做應(yīng)用的真正的管理，而Pod是組成Deployment最小的單元。 Kubernetes通過(guò) Controller（控制器）維護(hù)Deployment中Pod 的數(shù)目，Controller也會(huì)去幫助Deployment自動(dòng)恢復(fù)失敗的Pod。 比如，可以定義一個(gè)Deployment，這個(gè)Deployment里面需要2個(gè)Pod，當(dāng)1個(gè)Pod失敗的時(shí)候，控制器就會(huì)監(jiān)測(cè)到，再去新生成1個(gè)Pod，把Deployment中的Pod數(shù)目從1個(gè)恢復(fù)到2個(gè)。通過(guò)控制器，也可以完成發(fā)布策略，比如進(jìn)行滾動(dòng)升級(jí)、重新生成的升級(jí)或者進(jìn)行版本回滾。
第四個(gè)概念：Service Service：提供1個(gè)或者多個(gè) Pod 實(shí)例的穩(wěn)定訪問(wèn)地址 比如，一個(gè) Deployment 可能有2個(gè)甚至更多個(gè)完全相同的 Pod。對(duì)于外部的用戶來(lái)講，訪問(wèn)哪個(gè) Pod 都是一樣的，所以希望做一次負(fù)載均衡，在做負(fù)載均衡的同時(shí)，只需要訪問(wèn)某一個(gè)固定的 VIP，也就是 Virtual IP 地址，而不需要得知每一個(gè)具體的 Pod 的 IP 地址。 如果1個(gè) Pod 失敗了，可能會(huì)換成另外一個(gè)新的。提供了多個(gè)具體的 Pod 地址，對(duì)外部用戶來(lái)說(shuō)，要不停地去更新 Pod 地址。當(dāng)這個(gè) Pod 再失敗重啟之后，如果有一個(gè)抽象，把所有 Pod 的訪問(wèn)能力抽象成1個(gè)第三方的 IP 地址，實(shí)現(xiàn)這個(gè)的 Kubernetes 的抽象就叫 Service。 實(shí)現(xiàn) Service 有多種入口方式：
第五個(gè)概念：Namespace Namespace：用來(lái)做一個(gè)集群內(nèi)部的邏輯隔離，包括鑒權(quán)、資源管理等。Kubernetes 的每個(gè)資源，比如Pod、Deployment、Service 都屬于一個(gè) Namespace，同一個(gè) Namespace 中的資源需要命名的唯一性，不同的 Namespace 中的資源可以重名。
K8S的API Kubernetes API 是由 HTTP+JSON 組成的：用戶訪問(wèn)的方式是HTTP，訪問(wèn)API 中 content 的內(nèi)容是JSON格式的。 用Kubectl 命令、Kubernetes UI或者Curl，直接與Kubernetes交互都是使用 HTTP + JSON 的形式。 如下圖，對(duì)于這個(gè)Pod類型的資源，它的HTTP訪問(wèn)的路徑就是 API，apiVesion: V1, 之后是相應(yīng)的Namespaces，以及Pods資源，最終是 Podname，也就是Pod的名字。
當(dāng)提交一個(gè) Pod，或者 get 一個(gè) Pod 的時(shí)候，它的 content 內(nèi)容都是用JSON 或者是YAML表達(dá)的。上圖中YAML的例子，在這個(gè)YAML文件中，對(duì)Pod資源的描述分為幾個(gè)部分。 第一個(gè)部分，一般是 API 的 version。比如在這個(gè)例子中是 V1，它也會(huì)描述我在操作哪個(gè)資源； kind 如果是 pod，在 Metadata 中，就寫(xiě)上這個(gè) Pod 的名字；比如nginx。也會(huì)給pod打一些 label，在 Metadata 中，有時(shí)候也會(huì)去寫(xiě) annotation，也就是對(duì)資源的額外的一些用戶層次的描述。 比較重要的一個(gè)部分叫 Spec，Spec 也就是希望 Pod 達(dá)到的一個(gè)預(yù)期的狀態(tài)。比如pod內(nèi)部需要有哪些 container 被運(yùn)行；這里是一個(gè)name為nginx 的 container，它的 image 是什么？它暴露的 port 是什么？ 當(dāng)從 Kubernetes API 中去獲取這個(gè)資源的時(shí)候，一般在 Spec 下面會(huì)有一個(gè)status字段 ，它表達(dá)了這個(gè)資源當(dāng)前的狀態(tài)；比如一個(gè) Pod 的狀態(tài)可能是正在被調(diào)度、或者是已經(jīng) running、或者是已經(jīng)被 terminates（被執(zhí)行完畢）。 Label是一個(gè)比較有意思的 metadata，可以是一組KeyValue的集合。 如下圖，第一個(gè) pod 中，label 就可能是一個(gè) color 等于 red，即它的顏色是紅顏色。當(dāng)然也可以加其他 label，比如說(shuō) size: big 就是大小，定義為大的，它可以是一組label。 這些 label 是可以被 selector（選擇器）所查詢的。就好比sql 類型的 select 語(yǔ)句。
通過(guò)label，kubernetes 的API層就可以對(duì)這些資源進(jìn)行篩選。 例如，Deployment可能代表一組Pod，是一組Pod 的抽象，一組Pod就是通過(guò)label selector來(lái)表達(dá)的。當(dāng)然Service對(duì)應(yīng)的一組Pod來(lái)對(duì)它們進(jìn)行統(tǒng)一的訪問(wèn)，這個(gè)描述也是通過(guò)label selector來(lái)選取的一組Pod。 四、Depolyment部署pod操作 屏幕。。。 轉(zhuǎn)自https://www.cnblogs.com/ailiailan/p/18522478 該文章在 2024/11/5 8:58:19 編輯過(guò) |
相關(guān)文章
正在查詢... 
|
400 186 1886
