目錄

1. K8S概述

1.1 K8S是什么

1.2 作用

1.3 由來

1.4 含義

1.5 相關(guān)網(wǎng)站

2. 為什么要用K8S

3. K8S解決的問題

4. K8S的特性

5. Kubernetes集群架構(gòu)與組件

6. 核心組件

6.1 Master組件

6.1.1 Kube-apiserver

6.1.2 Kube-controller-manager

6.1.3 kube-scheduler

6.1.4 配置存儲(chǔ)中心

6.2 Node組件

6.2.1 Kubelet

6.2.2 Kube-Proxy

6.2.3 docker或rocket

7. Kubernetes核心概念

7.1 Pod

7.2 Pod控制器

7.3 Label

7.4 Label選擇器（Label selector）

7.5 Service

7.6 Ingress

7.7 Name

7.8 Namespace

8. kubernetes的工作流程

---

1. K8S概述

1.1 K8S是什么

K8S的全稱為Kubernetes（K12345678S

1.2 作用

用于自動(dòng)部署、擴(kuò)展和管理“容器化（containerized）應(yīng)用程序”的開源系統(tǒng)。可以理解成K8S是負(fù)責(zé)自動(dòng)化運(yùn)維管理多個(gè)容器化程序（比如Docker）的集群，是一個(gè)生態(tài)極其豐富的容器編排框架工具。

1.3 由來

K8S由google的Borg系統(tǒng)（博格系統(tǒng)，google內(nèi)部使用的大規(guī)模容器編排工具）作為延用，后經(jīng)GO語言延用Borg的思路重寫并捐獻(xiàn)給 CNCF基金會(huì) 開源。

1.4 含義

詞根源于希臘語的舵手、飛行員

1.5 相關(guān)網(wǎng)站

官網(wǎng): https://kubernetes.io GitHub： GitHub - kubernetes/kubernetes: Production-Grade Container Scheduling and Management

2. 為什么要用K8S

試想下傳統(tǒng)的后端部署辦法：把程序包（包括可執(zhí)行二進(jìn)制文件、配置文件等）放到服務(wù)器上，接著運(yùn)行啟動(dòng)腳本把程序跑起來，同時(shí)啟動(dòng)守護(hù)腳本定期檢查程序運(yùn)行狀態(tài)、必要的話重新拉起程序。 設(shè)想一下，如果服務(wù)的請(qǐng)求量上來，已部署的服務(wù)響應(yīng)不過來怎么辦？傳統(tǒng)的做法往往是，如果請(qǐng)求量、內(nèi)存、CPU超過閾值做了告警，運(yùn)維人員馬上再加幾臺(tái)服務(wù)器，部署好服務(wù)之后，接入負(fù)載均衡來分擔(dān)已有服務(wù)的壓力。 這樣問題就出現(xiàn)了：從監(jiān)控告警到部署服務(wù)，中間需要人力介入！那么，有沒有案發(fā)自動(dòng)完成服務(wù)的部署、更新、卸載和擴(kuò)容、縮容呢？ 而這就是K8S要做的事情：自動(dòng)化運(yùn)維管理容器化（Docker）程序。 K8S的目標(biāo)是讓部署容器化應(yīng)用簡單高效。

3. K8S解決的問題

K8S解決了裸跑Docker的若干痛點(diǎn)：

● 單機(jī)使用，無法有效集群

● 隨著容器數(shù)量的上升，管理成本攀升

● 沒有有效的容災(zāi)、自愈機(jī)制

● 沒有預(yù)設(shè)編排模板，無法實(shí)現(xiàn)快速、大規(guī)模容器調(diào)度

● 沒有統(tǒng)一的配置管理中心工具

● 沒有容器生命周期的管理工具

● 沒有圖形化運(yùn)維管理工具

K8S提供了容器編排，資源調(diào)度，彈性伸縮，部署管理，服務(wù)發(fā)現(xiàn)等一系列功能。

4. K8S的特性

● 彈性伸縮 使用命令、UI或者基于CPU使用情況自動(dòng)快速擴(kuò)容和縮容應(yīng)用程序?qū)嵗?#xff0c;保證應(yīng)用業(yè)務(wù)高峰并發(fā)時(shí)的高可用性；業(yè)務(wù)低峰時(shí)回收資源，以最小成本運(yùn)行服務(wù)。

● 自我修復(fù) 在節(jié)點(diǎn)故障時(shí)重新啟動(dòng)失敗的容器，替換和重新部署，保證預(yù)期的副本數(shù)量；殺死健康檢查失敗的容器，并且在未準(zhǔn)備好之前不會(huì)處理客戶端請(qǐng)求，確保線上服務(wù)不中斷

● 自動(dòng)發(fā)布（默認(rèn)滾動(dòng)發(fā)布模式）和回滾 K8S采用滾動(dòng)更新策略更新應(yīng)用，一次更新一個(gè)Pod，而不是同時(shí)刪除所有Pod，如果更新過程中出現(xiàn)問題，將回滾更改，確保升級(jí)不影響業(yè)務(wù)。

● 集中化配置管理和密鑰管理 管理機(jī)密數(shù)據(jù)和應(yīng)用程序配置，而不需要把敏感數(shù)據(jù)暴露在鏡像里，提高敏感數(shù)據(jù)安全性。并可以將一些常用的配置存儲(chǔ)在K8S中，方便應(yīng)用程序使用。

● 存儲(chǔ)編排，支持外掛存儲(chǔ)并對(duì)外掛存儲(chǔ)資源進(jìn)行編排 掛載外部存儲(chǔ)系統(tǒng)，無論是來自本地存儲(chǔ)，公有云（如AWS），還是網(wǎng)絡(luò)存儲(chǔ)（如NFS、GlusterFS、Ceph）都作為集群資源的一部分使用，極大提高存儲(chǔ)使用靈活性。

● 任務(wù)批處理運(yùn)行 提供一次性任務(wù)，定時(shí)任務(wù)；滿足批量數(shù)據(jù)處理和分析的場景

5. Kubernetes集群架構(gòu)與組件

K8S是屬于主從設(shè)備模型（Master-Slave架構(gòu)），即有Master節(jié)點(diǎn)負(fù)責(zé)集群的調(diào)度、管理和運(yùn)維，Slave節(jié)點(diǎn)是集群中的運(yùn)算工作負(fù)載節(jié)點(diǎn)。 在K8S中，主節(jié)點(diǎn)一般被稱為Master節(jié)點(diǎn)，而從節(jié)點(diǎn)則被稱為Worker Node節(jié)點(diǎn)，每個(gè)Node都會(huì)被Master所在節(jié)點(diǎn)宕機(jī)或不可用，那么所有的控制命令都將失效。除了Master，在K8S集群中的其他機(jī)器被稱為Worker Node節(jié)點(diǎn)，當(dāng)某個(gè)Node宕機(jī)時(shí)，其上的工作負(fù)載會(huì)被Master自動(dòng)轉(zhuǎn)移到其他節(jié)點(diǎn)上去。

6. 核心組件

6.1 Master組件

6.1.1 Kube-apiserver

用于暴露kubernetes API，任何資源請(qǐng)求或調(diào)用操作都是通過kube-apiserver提供的接口進(jìn)行。以HTTP Restful API提供接口服務(wù)，所有對(duì)象資源的增刪改查和監(jiān)聽操作都交給API Server處理后再提交給Etcd存儲(chǔ)。 可以理解成API Server是K8S的請(qǐng)求入口服務(wù)。API Server負(fù)責(zé)接收K8S所有請(qǐng)求（來自UI界面或者CLI命令行工具），然后根據(jù)用戶的具體請(qǐng)求，去通知其他組件干活。可以說API Server是K8S集群架構(gòu)的大腦。

6.1.2 Kube-controller-manager

運(yùn)行管理控制，是K8S集群中處理常規(guī)任務(wù)的后臺(tái)線程，是K8S集群里所有資源對(duì)象的自動(dòng)化控制中心。 在K8S集群中，一個(gè)資源對(duì)應(yīng)一個(gè)控制器，而Controller manager就是負(fù)責(zé)管理這些控制器的。 由一系列控制器組成，通過API Server監(jiān)控整個(gè)集群的狀態(tài)，并確保集群處于預(yù)期的工作狀態(tài)，比如當(dāng)某個(gè)Node意外宕機(jī)時(shí)，Controller Manager會(huì)及時(shí)發(fā)現(xiàn)并執(zhí)行自動(dòng)化修復(fù)流程，確保集群始終處于預(yù)期的工作狀態(tài)。

控制器	說明
Node Controller（節(jié)點(diǎn)控制器）	負(fù)責(zé)在節(jié)點(diǎn)出現(xiàn)故障時(shí)發(fā)現(xiàn)和響應(yīng)
Replication Controller（副本控制器）	負(fù)責(zé)保證集群中一個(gè)RC（資源對(duì)象Replication Controller）所關(guān)聯(lián)的Pod副本數(shù)始終保持預(yù)設(shè)值?？梢岳斫獬纱_保集群中有且僅有N個(gè)Pod實(shí)例，N是RC中定義的Pod副本數(shù)量
Endpoints Controller（端點(diǎn)控制器）	填充端點(diǎn)對(duì)象（即連接Services和Pods），負(fù)責(zé)監(jiān)聽Service和對(duì)應(yīng)的Pod副本的變化?？梢岳斫舛它c(diǎn)是一個(gè)服務(wù)暴露出來的訪問點(diǎn)，如果需要訪問一個(gè)服務(wù)暴露出來的訪問點(diǎn)，如果需要訪問一個(gè)服務(wù)，則必須知道它的endpoint
Service Account & Token Controllers（服務(wù)賬戶和令牌控制器）	為新的命名空間創(chuàng)建默認(rèn)賬戶和API訪問令牌
ResourceQuota Controller（資源配額控制器）	確保指定的資源對(duì)象在任何時(shí)候都不會(huì)超量占用系統(tǒng)物理資源
Namespace Controller（命名空間控制器）	管理namespace的聲明周期
Service Controller（服務(wù)控制器）	屬于K8S集群與外部的云平臺(tái)之間的一個(gè)接口控制器

6.1.3 kube-scheduler

是負(fù)責(zé)資源調(diào)度的進(jìn)程，根據(jù)調(diào)度算法為新創(chuàng)建的Pod選擇一份合適的Node節(jié)點(diǎn)。 可以理解成K8S所有Node節(jié)點(diǎn)的調(diào)度器。當(dāng)用于要部署服務(wù)時(shí)，Scheduler會(huì)根據(jù)調(diào)度算法選擇最合適的Node節(jié)點(diǎn)來部署Pod。

● 預(yù)算策略（predicate）

● 優(yōu)選策略（priorities） API Server接收到請(qǐng)求創(chuàng)建一批Pod，API Server會(huì)讓Controller-manager按照所預(yù)設(shè)的模板去創(chuàng)建Pod，Controller-manager會(huì)通過API Server去找Scheduler為新創(chuàng)建的Pod選擇最適合的Node節(jié)點(diǎn)。比如運(yùn)行這個(gè)Pod需要2C4G的資源，Schedular會(huì)通過預(yù)算策略在所有Node節(jié)點(diǎn)中挑選最優(yōu)的。Node節(jié)點(diǎn)中還剩多少資源是通過匯報(bào)給API Server存儲(chǔ)在etcd里，API Server會(huì)調(diào)用一個(gè)方法找到etcd里所有Node節(jié)點(diǎn)的剩余資源，再對(duì)比Pod所需要的資源，在所有Node節(jié)點(diǎn)中查找哪些Node節(jié)點(diǎn)符合要求。如果都符合，預(yù)算策略就交給優(yōu)選策略處理，優(yōu)選策略再通過CPU的負(fù)載、內(nèi)存的剩余量等因素選擇最合適的Node節(jié)點(diǎn)，并把Pod調(diào)度到這個(gè)Node節(jié)點(diǎn)上運(yùn)行。

6.1.4 配置存儲(chǔ)中心

● etcd K8S的存儲(chǔ)服務(wù)。etcd分布式鍵值存儲(chǔ)系統(tǒng)，存儲(chǔ)了K8S的關(guān)鍵配置和用戶配置，K8S中僅API Server才具備讀寫權(quán)限，其他組件必須通過API Server的接口才能讀寫數(shù)據(jù)。

6.2 Node組件

6.2.1 Kubelet

Node節(jié)點(diǎn)的監(jiān)視器，以及與Master節(jié)點(diǎn)的通訊器。Kubelet是Master節(jié)點(diǎn)安插在Node節(jié)點(diǎn)上的“眼線”，它會(huì)定時(shí)向API Server匯報(bào)自己Node節(jié)點(diǎn)上運(yùn)行的服務(wù)的狀態(tài)，并接受來自Master節(jié)點(diǎn)的指示采取調(diào)整措施。 從Master節(jié)點(diǎn)獲取自己節(jié)點(diǎn)上Pod的期望狀態(tài)（比如運(yùn)行什么容器、運(yùn)行的副本數(shù)量、網(wǎng)絡(luò)或者存儲(chǔ)如何配置等），直接跟容器引擎交互實(shí)現(xiàn)容器的生命周期管理，如果自己節(jié)點(diǎn)上Pod的狀態(tài)與期望狀態(tài)不一致，則調(diào)用對(duì)應(yīng)的容器平臺(tái)接口（即docker的接口）達(dá)到這個(gè)狀態(tài)。 管理鏡像和容器的清理工作，保證節(jié)點(diǎn)上鏡像不會(huì)占滿磁盤空間，退出的容器不會(huì)占用太多資源。 PS：Kubelet真是個(gè)苦逼老父親，又當(dāng)?shù)之?dāng)媽，一把屎一把尿把這些容器拉扯大，還要給它們養(yǎng)老送終。。。。

6.2.2 Kube-Proxy

在每個(gè)Node節(jié)點(diǎn)上實(shí)現(xiàn)Pod網(wǎng)絡(luò)代理，是Kuberbetes Service資源的載體，負(fù)責(zé)維護(hù)網(wǎng)絡(luò)規(guī)劃和四層負(fù)載均衡工作。負(fù)責(zé)寫入規(guī)則至iptables、ipvs實(shí)現(xiàn)服務(wù)映射訪問的。 Kube-Proxy本身不是直接給Pod提供網(wǎng)絡(luò)，Pod的網(wǎng)絡(luò)是由Kubelet提供的，Kube-Proxy實(shí)際上維護(hù)的是虛擬的Pod集群網(wǎng)絡(luò)。 Kube-apiserver通過監(jiān)控Kube-Proxy進(jìn)行對(duì)Kubernets Service的更新和端點(diǎn)的維護(hù)。 在K8S集群中微服務(wù)的負(fù)載均衡是由Kube-Proxy是K8S集群內(nèi)部的負(fù)載均衡器。它是一個(gè)分布式代理服務(wù)器，在K8S的每個(gè)節(jié)點(diǎn)上都會(huì)運(yùn)行一個(gè)Kube-proxy。

6.2.3 docker或rocket

容器引擎，運(yùn)行容器，負(fù)責(zé)本機(jī)的容器創(chuàng)建和管理工作。

7. Kubernetes核心概念

Kubernetes包含多種類型的資源對(duì)象：Pod、Lable、Service、Replication Controller等。 所有的資源對(duì)象都可以通過Kubernetes提供的Kubectl工具進(jìn)行增刪改查等操作，并將其保存在etcd中持久化存儲(chǔ)。Kubernetes其實(shí)是一個(gè)高度自動(dòng)化的資源控制系統(tǒng)，通過跟蹤對(duì)比etcd存儲(chǔ)里的資源期望狀態(tài)與當(dāng)前環(huán)境中的實(shí)際資源狀態(tài)的差異，來實(shí)現(xiàn)自動(dòng)控制和自動(dòng)糾錯(cuò)等高級(jí)功能。

7.1 Pod

Pod是Kuberntes創(chuàng)建或部署的最小/最簡單的基本單位，一個(gè)Pod代表集群上正在運(yùn)行的一個(gè)進(jìn)程。 可以把Pod理解成豌豆莢，而同一Pod內(nèi)的每個(gè)容器是一個(gè)個(gè)豌豆。 一個(gè)Pod由一個(gè)或多個(gè)容器組成，Pod中容器共享網(wǎng)絡(luò)、存儲(chǔ)和計(jì)算資源，在同一臺(tái)Docker主機(jī)上運(yùn)行。 一個(gè)Pod里可以運(yùn)行多個(gè)容器，又叫邊車（SideCara）模式。而在生產(chǎn)環(huán)境中一般都是單個(gè)容器或者具有強(qiáng)關(guān)聯(lián)互補(bǔ)的多個(gè)容器組成一個(gè)Pod。 同一個(gè)Pod之間的容器可以通過localhost互相訪問，并且可以掛在Pod內(nèi)的所有的數(shù)據(jù)卷；但是不同的Pod之間的容器不能用localhost訪問，，也不能掛載其他Pod的數(shù)據(jù)卷。

7.2 Pod控制器

Pod控制器是Pod啟動(dòng)的一種模板，用來保證在K8S里啟動(dòng)的Pod應(yīng)始終按照用戶的預(yù)期運(yùn)行（副本數(shù)、生命周期、健康狀態(tài)檢查等）。 K8S內(nèi)提供了眾多的Pod控制器，常用的有以下幾種：

● Deployment：無狀態(tài)應(yīng)用部署。Deployment的作用就是管理和控制Pod和ReplicaSet，管控它們運(yùn)行在用戶期望的狀態(tài)中。

● Replicaset：確保預(yù)期的Pod副本數(shù)量。ReplicaSet的作用就是管理和控制Pod，管控他們好好干活。但是，ReplicaSet受控于Deployment。

可以理解成Deployment就是總包工頭，主要負(fù)責(zé)監(jiān)督底下的工人Pod干活，確保每時(shí)每刻有用戶要求數(shù)量的Pod在工作。如果一旦發(fā)現(xiàn)某個(gè)工人Pod不行了，就趕緊新拉一個(gè)Pod過來替換它。而ReplicaSet就是總包工頭手下的小包工頭。

從K8S使用者角度來看，用戶會(huì)直接操作Deployment部署服務(wù)，而當(dāng)Deployment被部署的時(shí)候，K8S會(huì)自動(dòng)生成要求的ReplicaSet和Pod。用戶只需要關(guān)心Deployment而不操心ReplicaSet。 資源對(duì)象Replication Controller是ReplicaSet的前身，官方推薦用Deployment取代Replication Controller來部署服務(wù)。

● Daemonset：確保所有節(jié)點(diǎn)運(yùn)行同一類Pod，保證每個(gè)節(jié)點(diǎn)上都有一個(gè)此類Pod運(yùn)行，通常用于實(shí)現(xiàn)系統(tǒng)級(jí)后臺(tái)任務(wù)。

● Statefulset：有狀態(tài)應(yīng)用部署

● Job：一次性任務(wù)。根據(jù)用戶的設(shè)置，Job管理的Pod把任務(wù)成功完成就自動(dòng)退出了。

● Cronjob：周期性計(jì)劃性任務(wù)

7.3 Label

標(biāo)簽，是K8S特色的管理方式，便于分類管理資源對(duì)象。

Label可以附加到各種資源對(duì)象上，例如Node、Pod、Service、RC等，用于關(guān)聯(lián)對(duì)象、查詢和帥選。 一個(gè)Label是一個(gè)key-value的鍵值對(duì)，其中key與value由用戶自己制定。

一個(gè)資源對(duì)象可以定義任意數(shù)量的Label，同一個(gè)Label也可以被添加到任意數(shù)量的資源對(duì)象中，也可以在對(duì)象創(chuàng)建后動(dòng)態(tài)添加或者刪除。

可以通過給指定的資源對(duì)象捆綁一個(gè)或多個(gè)不同的Label，來實(shí)現(xiàn)多維度的資源分組管理功能。 與Label類似的，還有Annotation（注釋）。

區(qū)別在于有效的標(biāo)簽值必須為63個(gè)字符或更少，并且必須為空或以字母數(shù)字字符（[a-z0-9A-Z]）開頭和結(jié)尾，中間可以包含橫杠（-）、下劃線（_）、點(diǎn)（.）和字母或數(shù)字。注釋值則沒有字符長度限制。

7.4 Label選擇器（Label selector）

給某個(gè)資源對(duì)象定義一個(gè)Label，就相當(dāng)于給它打了一個(gè)標(biāo)簽；隨后可以通過標(biāo)簽選擇器（Label selector）查詢和篩選擁有某些Label的資源對(duì)象。 標(biāo)簽選擇器目前有兩種：基于等值關(guān)系（等于、不等于）和基于集合關(guān)系（屬于、不屬于、存在）。

7.5 Service

在K8S的集群里，雖然每個(gè)Pod會(huì)被分配一個(gè)單獨(dú)的IP地址，但由于Pod是有生命周期的（它們可以被創(chuàng)建，而且銷毀之后不會(huì)再啟動(dòng)），隨時(shí)可能會(huì)因?yàn)闃I(yè)務(wù)的變更，導(dǎo)致這個(gè)IP地址也會(huì)隨著Pod的銷毀而消失。 Service就是用來解決這個(gè)問題的核心概念。

K8S中的Service并不是我們常說的“服務(wù)”的含義，而更像是網(wǎng)關(guān)層，可以看做一組提供相同服務(wù)的Pod的對(duì)外訪問機(jī)接口、流量均衡器。

Service作用于哪些Pod是通過標(biāo)簽選擇器來定義的。

在K8S集群中，Service可以看做一組提供相同服務(wù)的Pod的對(duì)外訪問接口?？蛻舳诵枰L問的服務(wù)就是Service對(duì)象。每個(gè)Service都有一個(gè)固定的虛擬IP（這個(gè)IP也被稱為Cluster IP），自動(dòng)并且動(dòng)態(tài)地綁定后端的Pod，所有的網(wǎng)絡(luò)請(qǐng)求直接訪問Service的虛擬IP，Service會(huì)自動(dòng)向后端做轉(zhuǎn)發(fā)。

Service除了提供穩(wěn)定的對(duì)外訪問方式之外，還能起到負(fù)載均衡（Load Balance）的功能，自動(dòng)把請(qǐng)求流量分不到后端所有的服務(wù)上，Service可以做到對(duì)客戶透明地進(jìn)行水平擴(kuò)展（scale）。 而實(shí)現(xiàn)service這一功能的關(guān)鍵，就是kube-proxy。kube-proxy運(yùn)行在每個(gè)節(jié)點(diǎn)上，監(jiān)聽API Server中服務(wù)對(duì)象的變化，可通過以下三種流量調(diào)度模式：userspace（廢棄）、iptables（瀕臨廢棄）、ipvs（推薦，性能最好）來實(shí)現(xiàn)網(wǎng)絡(luò)的轉(zhuǎn)發(fā)。

Service是K8S服務(wù)的核心，屏蔽了服務(wù)細(xì)節(jié)，統(tǒng)一對(duì)外暴露服務(wù)接口，真正做到了“微服務(wù)”。比如我們的一個(gè)服務(wù)A，部署了3個(gè)副本，也就是3個(gè)Pod；對(duì)于用戶來說，只需要關(guān)注一個(gè)Service的入口就可以，而不需要操心究竟也應(yīng)該請(qǐng)求哪一個(gè)Pod。

優(yōu)勢非常明顯：一方面外部用戶不需要感知因?yàn)镻od上服務(wù)的意外崩潰、K8S重新拉起Pod而造成的IP變更，外部用戶也不需要感知因升級(jí)、變更服務(wù)帶來的Pod替換而造成的IP變化。

7.6 Ingress

Service主要負(fù)責(zé)K8S集群內(nèi)部的網(wǎng)絡(luò)拓?fù)?#xff0c;那么集群外部怎么訪問集群內(nèi)部呢？這個(gè)時(shí)候就需要Ingress了。Ingress是整個(gè)K8S集群的接入層，負(fù)責(zé)集群內(nèi)外通訊。

Ingress是K8S集群里工作在OSI網(wǎng)絡(luò)參考模型下，第7層的應(yīng)用，對(duì)外暴露的接口，典型的訪問方式是http/https。

Service只能進(jìn)行第四層的流量調(diào)度，表現(xiàn)形式是ip+port。Ingress則可以調(diào)度不同業(yè)務(wù)域、不同URL訪問路徑的業(yè)務(wù)流量。

比如：客戶端請(qǐng)求http://www.test.com:port --> Ingress --> Service --> Pod

7.7 Name

由于K8S內(nèi)部，使用“資源”來定義每一種邏輯概念（功能），所以每種“資源”，都應(yīng)該有自己的“名稱”。 “資源”有api版本（apiversion）、類別（kind）、元數(shù)據(jù)（metadata）、定義清單（spec）、狀態(tài)（status）等配置信息。

“名稱”通常定義在“資源”的“元數(shù)據(jù)”信息里。在同一個(gè)namespace空間中必須是唯一的。

7.8 Namespace

隨著項(xiàng)目增多、人員增加、集群規(guī)模的擴(kuò)大，需要一種能夠邏輯上隔離K8S內(nèi)各種“資源”的方法，這就是Namespace。

Namespace是為了把一個(gè)K8S集群劃分為若干個(gè)資源不可共享的虛擬集群組而誕生的。

不同Namespace內(nèi)的“資源”名稱可以相同，相同Namespace內(nèi)的各種“資源”，“名稱”不能相同。 合理的使用K8S的Namespace，可以使得集群管理員能夠更好的對(duì)交付到K8S里的服務(wù)進(jìn)行分類管理和瀏覽。 K8S里默認(rèn)存在的Namespace有：default、kube-system、kube-public等。

查詢K8S里特定“資源”要帶上相應(yīng)的Namespace。

8. kubernetes的工作流程

k8s有兩種模塊，master 模塊和worker-node 模塊。

master 節(jié)點(diǎn)包括apiserver、scheduler、controller-manager以及ETCD（可獨(dú)立部署）；node節(jié)點(diǎn)包括 kubelet、kube-proxy、容器引擎（docker/rocket等） 用戶通過客戶端發(fā)送請(qǐng)求給集群的唯一入口 API Server API

Server 先將用戶的請(qǐng)求信息寫入到 etcd存儲(chǔ)中。再去找Controller manager 創(chuàng)建對(duì)應(yīng)的pod Controller Manager通過API Server 去讀取etcd 里的用戶請(qǐng)求信息，根據(jù)請(qǐng)求去創(chuàng)建預(yù)設(shè)的模板（如什么鏡像，多少實(shí)例，健康檢查等），將模板寫入到etcd中，在根據(jù)模板創(chuàng)建pod Controller Manager 通過 API Server 去找到Scheduler調(diào)度pod，為新創(chuàng)建的Pod選擇node節(jié)點(diǎn) Scheduler 通過API Server 再etcd 存儲(chǔ)中讀取node節(jié)點(diǎn)的資源信息（信息由kubele發(fā)送到master的），通過預(yù)算策略和優(yōu)選策略，從node節(jié)點(diǎn)中挑選最優(yōu)的，并把pod調(diào)度到這個(gè)節(jié)點(diǎn)運(yùn)行。 預(yù)算策略：將所有node節(jié)點(diǎn)的剩余資源和pod所需的資源對(duì)比，找出符合pod資源需求的node節(jié)點(diǎn) 優(yōu)選策略：預(yù)算策略篩選后的node節(jié)點(diǎn)被交給優(yōu)選策略。通過cpu負(fù)載，內(nèi)存剩余等因素，找出最合適的node節(jié)點(diǎn)。把pod調(diào)度到這個(gè)節(jié)點(diǎn)運(yùn)行 Scheduler 確定了調(diào)度的節(jié)點(diǎn)后，通過API Server 去找到對(duì)應(yīng)node節(jié)點(diǎn)上的kublet，由kublet 調(diào)動(dòng)容器引擎創(chuàng)建pod kublet 不僅和容器引擎交互，實(shí)現(xiàn)容器的生命周期管理。還監(jiān)控node節(jié)點(diǎn)上的資源信息，pod狀態(tài)。將這些匯報(bào)給API Server 存儲(chǔ)到etcd中。 kube-proxy創(chuàng)建網(wǎng)絡(luò)規(guī)則，制定轉(zhuǎn)發(fā)規(guī)則。創(chuàng)建service作為負(fù)載均衡的訪問入口（cluster-ip、nodeport等)，把用戶的請(qǐng)求通過負(fù)載均衡轉(zhuǎn)發(fā)到關(guān)聯(lián)的pod上，從而發(fā)布pod里的業(yè)務(wù)