文章目錄

• 01 資源對(duì)象概述
• 02 集群類
• • 2.1 Master
  • 2.2 Node
  • 2.3 命名空間
• 03 應(yīng)用類
• • 3.1 service和pod
  • 3.2 label與標(biāo)簽選擇器
  • 3.3 Pod和Deployment
  • 3.4 Service和ClusterIp
  • 3.5 Service外網(wǎng)訪問
  • 3.6 有狀態(tài)的應(yīng)用集群
  • 3.7 批處理應(yīng)用
  • 3.8 應(yīng)用的配置
  • • 3.8.1 ConfigMap
    • 3.8.2 Secret
  • 3.9 應(yīng)用的運(yùn)維
  • • 3.9.1 HPA橫向擴(kuò)容
    • 3.9.2 VPA垂直擴(kuò)容
• 04 存儲(chǔ)類
• • 4.1 Volume（存儲(chǔ)卷）
  • • 4.1.1 emptyDir（臨時(shí)目錄）
    • 4.1.2 hostPath（宿主機(jī)目錄）
    • 4.1.3 公有云Volume
    • 4.1.4 其它類型的Volume
    • 4.1.5 動(dòng)態(tài)存儲(chǔ)
• 05 安全類
• • 5.1 Service Account
  • 5.2 Role
  • 5.2 Role Binding
  • 5.3 NetworkPolicy（網(wǎng)絡(luò)策略）

01 資源對(duì)象概述

Kubernetes 中的基本概念和術(shù)語大多是圍繞 資源對(duì)象（Resource Object）來說 的，而資源對(duì)象在總體上可分為以下兩類：

某種資源的對(duì)象。例如節(jié)點(diǎn)Node、Pod、服務(wù)Service、存儲(chǔ)卷 Volume。

與資源對(duì)象相關(guān)的事物與動(dòng)作。例如標(biāo)簽Label、注解Annotation、命名空間Namespace、部署Deployment、HPA、PVC。

資源對(duì)象一般包括幾個(gè)通用屬性：版本、類別（Kind）、名稱、標(biāo)簽、注解，如下所述。

• 版本信息：包括了此對(duì)象所屬的資源組，一些資源對(duì)象的屬性會(huì)隨著版本的升級(jí)而變化，在定義資源對(duì)象時(shí)要特別注意這一點(diǎn)。
• 類別屬性：用于定義資源對(duì)象的類型。
• 資源對(duì)象的名稱（Name）、標(biāo)簽、注解這三個(gè)屬性屬于資源對(duì)象的元數(shù)據(jù)（metadata)，資源對(duì)象的名稱要唯一。資源對(duì)象的標(biāo)簽是很重要的數(shù)據(jù)，也是 Kubernetes 的一大設(shè)計(jì)特性，比如通過標(biāo)簽來表明資源對(duì)象的特征、類別，以及通過標(biāo)簽篩選不同的資源對(duì)象并實(shí)現(xiàn)對(duì)象之間的關(guān)聯(lián)、控制或協(xié)作功能。
• 注解：可被理解為一種特殊的標(biāo)簽，不過更多地是與程序掛鉤，通常用于實(shí)現(xiàn)資源對(duì)象屬性的自定義擴(kuò)展。

我們可以采用 YAML 或 JSON 格式聲明（定義或創(chuàng)建）一個(gè) Kubernetes 資源對(duì)象，每個(gè)資源對(duì)象都有自己的特定結(jié)構(gòu)定義（可以理解為數(shù)據(jù)庫中一個(gè)特定的表），并且統(tǒng)一保存在 etcd 這種非關(guān)系型數(shù)據(jù)庫中，以實(shí)現(xiàn)最快的讀寫速度。此外，所有資源對(duì)象都可以通過 Kubernetes 提供的kubectl工具（或者 API 編程調(diào)用）執(zhí)行增、刪、改、查等操作。

這里按照功能或用途對(duì)眾多資源對(duì)象其進(jìn)行分類，將其分為集群類、應(yīng)用類、存儲(chǔ)類及安全類這四大類，下面來講解。

02 集群類

集群（Cluster）表示一個(gè)由 Master 和 Node 組成的 Kubernetes 集群。

2.1 Master

Master指的是集群的控制節(jié)點(diǎn)。在每個(gè) Kubernetes 集群中都需要有一個(gè)或一組被稱為 Master 的節(jié)點(diǎn)，來負(fù)責(zé)整個(gè)集群的管理和控制。Master 通常占據(jù)一個(gè)獨(dú)立的服務(wù)器（在高可用部署中建議至少使用 3 臺(tái)服務(wù)器），是整個(gè)集群的“大腦”，如果它發(fā)生宕機(jī)或者不可用，那么對(duì)集群內(nèi)容器應(yīng)用的管理都將無法實(shí)施。

在 Master上運(yùn)行著以下關(guān)鍵進(jìn)程:

• Kubernetes API Server (kube-apiserver）：提供 HTTP RESTful API 接口的主要服務(wù)，是 Kubernetes 里對(duì)所有資源進(jìn)行增、刪、改、查等操作的唯一入口，也是集群控制的入口進(jìn)程。
• Kubernetes Controller Manager：Kubernetes 里所有資源對(duì)象的自動(dòng)化控制中心，可以將其理解為資源對(duì)象的“大總管”。
• Kubernetes Scheduler：負(fù)責(zé)資源調(diào)度（Pod 調(diào)度）的進(jìn)程，相當(dāng)于公交公司的調(diào)度室。
• 在 Master上通常還需要部署etcd服務(wù)。

2.2 Node

Kubernetes集群中除 Master 外的其他服務(wù)器被稱為 Node。Node 可以是一臺(tái)物理主機(jī)，也可以是一臺(tái)虛擬機(jī)。Node 是Kubernetes集群中的工作負(fù)載節(jié)點(diǎn)，每個(gè) Node 都會(huì)被 Master 分配一些工作負(fù)載（Docker 容器），當(dāng)某個(gè)Node宕機(jī)時(shí)，其上的工作負(fù)載會(huì)被 Master 自動(dòng)轉(zhuǎn)移到其他 Node 上。

在每個(gè) Node 上都運(yùn)行著以下關(guān)鍵進(jìn)程：

• kubelet：負(fù)責(zé) Pod 對(duì)應(yīng)容器的創(chuàng)建、啟停等任務(wù)，同時(shí)與 Master 密切協(xié)作，實(shí)現(xiàn)集群管理的基本功能。
• kube-proxy：實(shí)現(xiàn) Kubernetes Service 的通信與負(fù)載均衡機(jī)制的服務(wù)。
• 容器運(yùn)行時(shí)（如 Docker） : 負(fù)責(zé)本機(jī)的容器創(chuàng)建和管理。

我們可以運(yùn)行以下命令查看在集群中有多少個(gè) Node:

查詢node詳情：

2.3 命名空間

在集群類里還有一個(gè)重要的基礎(chǔ)概念一一命名空間，它在很多情況下用于實(shí)現(xiàn)多租戶的資源隔離，典型的一種思路就是給每個(gè)租戶都分配一個(gè)命名空間。每個(gè)命名空間都是相互獨(dú)立的存在，屬于不同命名空間的資源對(duì)象從邏輯上相互隔離。

在每個(gè) Kubernetes 集群安裝完成且正常運(yùn)行之后，Master 會(huì)自動(dòng)創(chuàng)建兩個(gè)命名空間。

• 默認(rèn)級(jí)（default）：用戶創(chuàng)建的資源對(duì)象如果沒有指定命名空間，則被默認(rèn)存放在default命名空間中；
• 系統(tǒng)級(jí)（kube-system）：系統(tǒng)相關(guān)的資源對(duì)象如網(wǎng)絡(luò)組件、DNS 組件、監(jiān)控類組件等，都被安裝在 kube-system 命名空間中。

我們可以通過命名空間將集群內(nèi)部的資源對(duì)象“分配”到不同的命名空間中，形成邏輯上分組的不同項(xiàng)目、小組或用戶組，便于不同的分組在共享使用整個(gè)集群的資源的同時(shí)能被分別管理。當(dāng)給每個(gè)租戶都創(chuàng)建一個(gè)命名空間來實(shí)現(xiàn)多租戶的資源隔離時(shí)，還能結(jié)合 Kubernetes 的資源配額管理，限定不同租戶能占用的資源，例如 CPU 使用量、內(nèi)存使用量等。

命名空間的定義很簡(jiǎn)單，如下所示的 YAML 文件定義了名為development的命名空間：

查看（注意加上-namespace或-n）:

03 應(yīng)用類

3.1 service和pod

Node、Pod與容器間的關(guān)系圖如下：

Pod及周邊對(duì)象：

應(yīng)用類相關(guān)的資源對(duì)象主要是圍繞 Service（服務(wù)）和 Pod 這兩個(gè)核心對(duì)象展開的。

• Service ：一般指的是無狀態(tài)服務(wù)，通常由多個(gè)程序副本提供服務(wù)，在特殊情況下也可以是有狀態(tài)的單實(shí)例服務(wù)，比如 MySQL 這種數(shù)據(jù)存儲(chǔ)類的服務(wù)。
• Pod：有一個(gè)特殊的被稱為“根容器”的 Pause 容器，Pause 容器對(duì)應(yīng)的鏡像屬于 Kubernetes 平臺(tái)的一部分，還包含一個(gè)或多個(gè)緊密相關(guān)的用戶業(yè)務(wù)容器。

3.2 label與標(biāo)簽選擇器

給某個(gè)資源對(duì)象定義一個(gè) label，就相當(dāng)于給它打了一個(gè)標(biāo)簽，隨后可以通過 Label Selector（標(biāo)簽選擇器）查詢和篩選擁有某些 Label 的資源對(duì)象，Kubernetes 通過這種方式實(shí)現(xiàn)了類似 SQL 的簡(jiǎn)單又通用的對(duì)象查詢機(jī)制。

寫法舉例：

舉例圖：

3.3 Pod和Deployment

Pod、Deployment和Service的關(guān)系：

前面提到，大部分 Service 都是無狀態(tài)的服務(wù)，可以由多個(gè)Pod副本實(shí)例提供服務(wù)。通常情況下，每個(gè) Service 對(duì)應(yīng)的Pod服務(wù)實(shí)例數(shù)量都是固定的，如果一個(gè)一個(gè)地手工創(chuàng)建 Pod 實(shí)例，就太麻煩了，最好是用模板的思路，即提供一個(gè) Pod 模板（Template），然后由程序根據(jù)我們指定的模板自動(dòng)創(chuàng)建指定數(shù)量的 Pod 實(shí)例。這就是Deployment這個(gè)資源對(duì)象所要完成的事情了，舉例：

3.4 Service和ClusterIp

Kubernetes 內(nèi)部在每個(gè) Node 上都運(yùn)行了一套全局的虛擬負(fù)載均衡器，自動(dòng)注入并自動(dòng)實(shí)時(shí)更新集群中所有 Service 的路由表，通過 iptables或者 IPVS 機(jī)制，把對(duì) Service 的請(qǐng)求轉(zhuǎn)發(fā)到其后端對(duì)應(yīng)的某個(gè) Pod 實(shí)例上，并在內(nèi)部實(shí)現(xiàn)服務(wù)的負(fù)載均衡與會(huì)話保持機(jī)制。

不僅如此，Kubernetes 還采用了一種很巧妙又影響深遠(yuǎn)的設(shè)計(jì)一 ClusterIP 地址。

Service 一旦被創(chuàng)建，Kubernetes 就會(huì)自動(dòng)為它分配一個(gè)全局唯一的虛擬 IP 地址，即ClusterIP 地址，而且在Service的整個(gè)生命周期內(nèi)，其 ClusterIP 地址不會(huì)發(fā)生改變，這樣一來，每個(gè)服務(wù)就變成了具備唯一 IP 地址的通信節(jié)點(diǎn)，遠(yuǎn)程服務(wù)之間的通信問題就變成了基礎(chǔ)的 TCP 網(wǎng)絡(luò)通信問題。

3.5 Service外網(wǎng)訪問

我們需要先弄明白 Kubernetes 的三種 IP，分別如下：

• Node IP: 是 Kubernetes集群中每個(gè)節(jié)點(diǎn)的物理網(wǎng)卡的 IP 地址，是一個(gè)真實(shí)存在的物理網(wǎng)絡(luò)，所有屬于這個(gè)網(wǎng)絡(luò)的服務(wù)器都能通過這個(gè)網(wǎng)絡(luò)直接通信。
• Pod IP: 每個(gè) Pod 的 IP 地址，在使用 Docker 作為容器支持引擎的情況下，它是 Docker Engine 根據(jù) dockero 網(wǎng)橋的 IP 地址段進(jìn)行分配的，通常是一個(gè)虛擬二層網(wǎng)絡(luò)，通過Pod IP所在的虛擬二層網(wǎng)絡(luò)進(jìn)行通信的，真實(shí)的TCP/IP 流量是通過Node IP 所在的物理網(wǎng)卡流出。
• Service IP: Service 的 ClusterIP 地址屬于集群內(nèi)的地址，無法在集群外直接使用這個(gè)地址。為了解決這個(gè)問題，Kubernetes 首先引入了 NodePort。
  

對(duì)于每個(gè) Service，我們通常需要配置一個(gè)對(duì)應(yīng)的負(fù)載均衡器實(shí)例來轉(zhuǎn)發(fā)流量到后端的 Node 上，這的確增加了工作量及出錯(cuò)的概率，如下圖：

NodePort 的確功能強(qiáng)大且通用性強(qiáng)，但也存在一個(gè)問題，即每個(gè) Service 都需要在 Node 上獨(dú)占一個(gè)端口，而端口又是有限的物理資源，那能不能讓多個(gè) Service 共用一個(gè)對(duì)外端口呢，這就是后來增加的 Ingress資源對(duì)象所要解決的問題。

Ingress其實(shí)只能將多個(gè) HTTP (HTTPS）的 Service“聚合”，通過虛擬域名或者 URL Path 的特征進(jìn)行路由轉(zhuǎn)發(fā)功能，考慮到常見的微服務(wù)都采用了 HTTP REST 協(xié)議，所以 Ingress 這種聚合多個(gè) Service 并將其暴露到外網(wǎng)的做法還是很有效的。

在一定程度上，我們可以把 Ingress 的實(shí)現(xiàn)機(jī)制理解為基于 Nginx 的支持虛擬主機(jī)的 HTTP 代理。下面是一個(gè) Ingress 的實(shí)例：

3.6 有狀態(tài)的應(yīng)用集群

我們知道，Deployment 對(duì)象是用來實(shí)現(xiàn)無狀態(tài)服務(wù)的多副本自動(dòng)控制功能的，那么有狀態(tài)的服務(wù)，比如: ZooKeeper：集群、MySQL 高可用集群（3 節(jié)點(diǎn)集群）、Kafka 集群等是怎么實(shí)現(xiàn)自動(dòng)部署和管理的呢？

這個(gè)問題就復(fù)雜多了，這些一開始是依賴 StatefulSet 解決的，但后來發(fā)現(xiàn)對(duì)于一些復(fù)雜的有狀態(tài)的集群應(yīng)用來說，StatefulSet 還是不夠通用和強(qiáng)大，所以后面又出現(xiàn)了 Kubernetes Operator。

平臺(tái)開發(fā)者借助 Operator 框架提供的 API，可以更方便地開發(fā)一個(gè)類似 StatefulSet 的控制器。在這個(gè)控制器里，開發(fā)者通過編碼方式實(shí)現(xiàn)對(duì)目標(biāo)集群的自定義操控，包括集群部署、故障發(fā)現(xiàn)及集群調(diào)整等方面都可以實(shí)現(xiàn)有針對(duì)性的操控，從而實(shí)現(xiàn)更好的自動(dòng)部署和智能運(yùn)維功能。

從發(fā)展趨勢(shì)來看，未來主流的有狀態(tài)集群基本都會(huì)以 Operator 方式部署到 Kubernetes集群中。

3.7 批處理應(yīng)用

除了無狀態(tài)服務(wù)、有狀態(tài)集群、常見的第三種應(yīng)用，還有批處理應(yīng)用。批處理應(yīng)用的特點(diǎn)是一個(gè)或多個(gè)進(jìn)程處理一組數(shù)據(jù)（圖像、文件、視頻等），在這組數(shù)據(jù)都處理完成后，批處理任務(wù)自動(dòng)結(jié)束。為了支持這類應(yīng)用，Kubernetes 引入了新的資源對(duì)象一一 Job，下面是一個(gè)計(jì)算圓周率的經(jīng)典例子：

Jobs 控制器提供了兩個(gè)控制并發(fā)數(shù)的參數(shù)：completions 和 parallelism, completions 表示需要運(yùn)行任務(wù)數(shù)的總數(shù)，parallelism 表示并發(fā)運(yùn)行的個(gè)數(shù)。后來kubernetes增加了cronjob可以周期性的執(zhí)行某個(gè)任務(wù)。

3.8 應(yīng)用的配置

通過前面的學(xué)習(xí)，我們初步理解了三種應(yīng)用建模的資源對(duì)象，總結(jié)如下。

• 無狀態(tài)服務(wù)的建模：Deployment
• 有狀態(tài)集群的建模：StatefulSet
• 批處理應(yīng)用的建模：Job

在進(jìn)行應(yīng)用建模時(shí)，應(yīng)該如何解決應(yīng)用需要在不同的環(huán)境中修改配置的問題呢？這就涉及 ConfigMap 和 Secret 兩個(gè)對(duì)象。

3.8.1 ConfigMap

用戶將配置文件的內(nèi)容保存到 ConfigMap 中，文件名可作為 key, value 就是整個(gè)文件的內(nèi)容，多個(gè)配置文件都可被放入同一個(gè) ConfigMap。

在建模用戶應(yīng)用時(shí)，在 Pod 里將 ConfigMap。定義為特殊的 Volume 進(jìn)行掛載。在 Pod 被調(diào)度到某個(gè)具體 Node 上時(shí)，ConfigMap 里的配置文件會(huì)被自動(dòng)還原到本地目錄下，然后映射到 Pod 里指定的配置目錄下，這樣用戶的程序就可以無感知地讀取配置了。

在 ConfigMap 的內(nèi)容發(fā)生修改后，Kubernetes 會(huì)自動(dòng)重新獲取 ConfigMap 的內(nèi)容，并在目標(biāo)節(jié)點(diǎn)上更新對(duì)應(yīng)的文件。

3.8.2 Secret

Secrett也用于解決應(yīng)用配置的問題，不過它解決的是對(duì)敏感信息的配置問題，比如數(shù)據(jù)庫的用戶名和密碼、應(yīng)用的數(shù)字證書、Tokn、SSH 密鑰及其他需要保密的敏感配置。對(duì)于這類敏感信息，我們可以創(chuàng)建一個(gè) Secret 對(duì)象，然后被 Pod 引用。Secret 中的數(shù)據(jù)要求以 BASE64 編碼格式存放。注意，BASE64 編碼并不是加密的，在 Kubernetes1.7 版本以后，Secret 中的數(shù)據(jù)才可以以加密的形式進(jìn)行保存，更加安全。

3.9 應(yīng)用的運(yùn)維

3.9.1 HPA橫向擴(kuò)容

首先就是 HPA (Horizontal Pod Autoscaler），我們可以將 HPA 理解為 Pod 橫向自動(dòng)擴(kuò)容，即自動(dòng)控制 Pod 數(shù)量的增加或減少。通過追蹤分析指定 Deployment 控制的所有目標(biāo)Pod的負(fù)載變化情況，來確定是否需要有針對(duì)性地調(diào)整目標(biāo) Pod 的副本數(shù)量，這是 HPA 的實(shí)現(xiàn)原理。

例如：Kubernetes 內(nèi)置了基于Pod的 CPU利用率進(jìn)行自動(dòng)擴(kuò)縮容的機(jī)制，應(yīng)用開發(fā)者也可以自定義度量指標(biāo)如每秒請(qǐng)求數(shù)，來實(shí)現(xiàn)自定義的 HPA 功能。下面是一個(gè) HPA 定義的例子：

根據(jù)上面的定義，我們可以知道這個(gè) HPA 控制的目標(biāo)對(duì)象是一個(gè)名為 php-apache 的 Deployment里的 Pod 副本，當(dāng)這些 Pod 副本的 CPU 利用率的值超過 90% 時(shí)，會(huì)觸發(fā)自動(dòng)動(dòng)態(tài)擴(kuò)容。

3.9.2 VPA垂直擴(kuò)容

VPA (Vertical Pod Autoscaler） 即垂直 Pod 自動(dòng)擴(kuò)縮容，它根據(jù)容器資源使用率自動(dòng)推測(cè)并設(shè)置 Pod 合理的CPU和內(nèi)存的需求指標(biāo)，從而更加精確地調(diào)度 Pod，實(shí)現(xiàn)整體上節(jié)省集群資源的目標(biāo)，因?yàn)闊o須人為操作，因此也進(jìn)一步提升了運(yùn)維自動(dòng)化的水平。

04 存儲(chǔ)類

存儲(chǔ)類的資源對(duì)象主要包括: Volume、Persistent Volume、PVC 和 StorageClass。

4.1 Volume（存儲(chǔ)卷）

Volume 是 Pod 中能夠被多個(gè)容器訪問的共享目錄。

首先Kubernetes 中的 Volume 被定義在 Pod上，被一個(gè) Pod 里的多個(gè)容器掛載到具體的文件目錄下；其次，Kubernetes 中的 Volume 與 Pod 的生命周期相同，但與容器的生命周期不相關(guān)，當(dāng)容器終止或者重啟時(shí)，Volume 中的數(shù)據(jù)也不會(huì)丟失；最后，Kubernetes支持多種類型的 Volume，例如 GlusterFS、Ceph 等分布式文件系統(tǒng)。

Volume 的使用：在大多數(shù)情況下，我們先在 Pod 上聲明一個(gè) Volume，然后在容器里引用該 Volume并將其掛載（Mount）到容器里的某個(gè)目錄下。

舉例來說，若我們要給之前的 Tomcat Pod增加一個(gè)名為 datavol的Volume，并將其掛載到容器的/mydata-data 目錄下，則只對(duì)Pod 的定義文件做如下修正即可（代碼中的粗體部分）：

Kubernetes提供了非常豐富的Volume類型供容器使用，例如：臨時(shí)目錄、宿主機(jī)目錄、共享存儲(chǔ)等，下面對(duì)其中一些常見的類型進(jìn)行說明。

4.1.1 emptyDir（臨時(shí)目錄）

一個(gè) emptyDir 是在 Pod 分配到 Node 時(shí)創(chuàng)建的。從它的名稱就可以看出，它的初始內(nèi)容為空，并且無須指定宿主機(jī)上對(duì)應(yīng)的目錄文件，因?yàn)檫@是 Kubernetes 自動(dòng)分配的一個(gè)目錄，當(dāng) Pod 從 Node 上移除時(shí)，emptyDir 中的數(shù)據(jù)也被永久移除。

emptyDir 的一些用途如下。

• 臨時(shí)空間，例如用于某些應(yīng)用程序運(yùn)行時(shí)所需的臨時(shí)目錄，且無須永久保留。
• 長時(shí)間任務(wù)執(zhí)行過程中使用的臨時(shí)目錄。
• 一個(gè)容器需要從另一個(gè)容器中獲取數(shù)據(jù)的目錄（多容器共享目錄）。在默認(rèn)情況下，emptyDir 使用的是節(jié)點(diǎn)的存儲(chǔ)介質(zhì)，例如磁盤或者網(wǎng)絡(luò)存儲(chǔ)。

還可以使用 emptyDir. Nedium 屬性，把這個(gè)屬性設(shè)置為“Memory”，就可以使用更快的基于內(nèi)存的后端存儲(chǔ)了。需要注意的是，這種情況下的 emptyDir 使用的內(nèi)存會(huì)被計(jì)入容器的內(nèi)存消耗，將受到資源限制和配額機(jī)制的管理。

4.1.2 hostPath（宿主機(jī)目錄）

HostPath 為在 Pod 上掛載宿主機(jī)上的文件或目錄，通常可以用于以下幾方面：

• 在容器應(yīng)用程序生成的日志文件需要永久保存時(shí)，可以使用宿主機(jī)的高速文件系統(tǒng)對(duì)其進(jìn)行存儲(chǔ)。
• 需要訪問宿主機(jī)上 Docker 引擎內(nèi)部數(shù)據(jù)結(jié)構(gòu)的容器應(yīng)用時(shí)，可以通過定hostPath為宿主機(jī)/var/Iib/docker目錄，使容器內(nèi)部的應(yīng)用可以直接訪問 Docker 的文件系統(tǒng)。

在使用這種類型的 Volume時(shí)，需要注意以下幾點(diǎn)。

• 在不同的 Node 上具有相同配置的 Pod，可能會(huì)因?yàn)樗拗鳈C(jī)上的目錄和文件不同，而導(dǎo)致對(duì) Volume上目錄和文件的訪問結(jié)果不一致。
• 如果使用了資源配額管理，則 Kubernetes 無法將 hostPath 在宿主機(jī)上使用的資源納入管理。

在下面的例子中使用了宿主機(jī)的/data目錄定義了一個(gè)hostPath 類型的 Volume:

4.1.3 公有云Volume

公有云提供的 Volume 類型包括谷歌公有云提供的 GCEPersistentDisk、亞馬遜公有云提供的 AWS Elastic Block Store (EBS Volume）等。當(dāng)我們的Kubernetes集群運(yùn)行在公有云上或者使用公有云廠家提供的 Kubernetes 集群時(shí)，就可以使用這類 Volume。

4.1.4 其它類型的Volume

• Iscsi：將 SCSI 存儲(chǔ)設(shè)備上的目錄掛載到 Pod 中。
• nfs：將 NFS Server上的目錄掛載到 Pod 中。
• glusterfs：將開源 GlusterFS 網(wǎng)絡(luò)文件系統(tǒng)的目錄掛載到 Pod 中。
• rbd：將 Ceph 塊設(shè)備共享存儲(chǔ)（Rados Block Device）掛載到Pod中。
• gitRepo：通過掛載一個(gè)空目錄，并從 Git 庫克隆（clone）一個(gè) git repository 以供 Pod 使用。
• configmap：將配置數(shù)據(jù)掛載為容器內(nèi)的文件。
• secret：將 Secret數(shù)據(jù)掛載為容器內(nèi)的文件。

4.1.5 動(dòng)態(tài)存儲(chǔ)

Volume屬于靜態(tài)管理的存儲(chǔ)，即我們需要事先定義每個(gè) Volume，然后將其掛載到 Pod 中去用，這種方式存在很多弊端，典型的弊端如下。

• 配置參數(shù)煩瑣，存在大量手工操作，違背了 Kubernetes 自動(dòng)化的追求目標(biāo)。
• 預(yù)定義的靜態(tài) Volume 可能不符合目標(biāo)應(yīng)用的需求，比如容量問題、性能問題。

所以 Kubernetes 后面就發(fā)展了存儲(chǔ)動(dòng)態(tài)化的新機(jī)制，來實(shí)現(xiàn)存儲(chǔ)的自動(dòng)化管理。相關(guān)的核心對(duì)象（概念）有三個(gè)：Persistent Volume（簡(jiǎn)稱 PV）、StorageClass、PVC。

• PV： 表示由系統(tǒng)動(dòng)態(tài)創(chuàng)建（dynamically provisioned）的一個(gè)存儲(chǔ)卷，可以被理解成 Kubernetes集群中某個(gè)網(wǎng)絡(luò)存儲(chǔ)對(duì)應(yīng)的一塊存儲(chǔ)，它與 Volume 類似，但 PV 并不是被定義在 Pod 上的，而是獨(dú)立于 Pod 之外定義的。PV 目前支持的類型主要有 gcePersistentDisk、AWSElasticBlockStore、AzureFile、AzureDisk、FC (Fibre Channel）、NFS、iSCSI、RBD (Rados Block Device）、CephFS、Cinder、GlusterFS、VsphereVolume、Quobyte Volumes、Mware Photon、Portworx Volumes、ScaleIO Volumes、ostPath、Local 等。
• StorageClass 用來描述和定義某種存儲(chǔ)系統(tǒng)的特征，例如：StorageClass 有幾個(gè)關(guān)鍵屬性：provisioner、parameters 和 reclaimPolicy，系統(tǒng)在動(dòng)態(tài)創(chuàng)建 PV 時(shí)會(huì)用到這幾個(gè)參數(shù)。簡(jiǎn)單地說，provisioner 代表了創(chuàng)建 PV 的第三方存儲(chǔ)插件，parameters 是創(chuàng)建 PV 時(shí)的必要參數(shù)，reclaimPolicy則表明了 PV 回收策略，回收策略包括刪除或則保留。
• PVC ：StorageClass名稱會(huì)在 PVC (PV Claim）中出現(xiàn)，下面就是一個(gè)典型的 PVC 定義：PVC 正如其名，表示應(yīng)用希望申請(qǐng)的 PV 規(guī)格，其中重要的屬性包括 accessModes（存儲(chǔ)訪問模式）、storageClassName（用哪種 StorageClass 來實(shí)現(xiàn)動(dòng)態(tài)創(chuàng)建）及 resources（存儲(chǔ)的具體規(guī)格）

有了以 StorageClass 與 PVC 為基礎(chǔ)的動(dòng)態(tài) PV 管理機(jī)制，我們就很容易管理和使用 Volume 了，只要在 Pod 里引用 PVC 即可達(dá)到目的，如下面的例子所示：

05 安全類

安全始終是 Kubernetes 發(fā)展過程中的一個(gè)關(guān)鍵領(lǐng)域。

從本質(zhì)上來說 ，Kubernetes 可被看作一個(gè)多用戶共享資源的資源管理系統(tǒng)，這里的資源主要是各種Kubernetes里的各類資源對(duì)象，比如 Pod、Service、Deployment 等。只有通過認(rèn)證的用戶才能通過 Kubernetes 的 API Server 查詢、創(chuàng)建及維護(hù)相應(yīng)的資源對(duì)象，理解這一點(diǎn)很關(guān)鍵。

5.1 Service Account

在默認(rèn)情況下，Kubernetes在每個(gè)命名空間中都會(huì)創(chuàng)建一個(gè)默認(rèn)的名稱為 default 的 Service Account，因此 Service Account 是不能全局使用的，只能被它所在命名空間中的 Pod 使用。通過以下命令可以查看集群中的所有 Service Account：

Service Account 是通過 Secret 來保存對(duì)應(yīng)的用戶（應(yīng)用）身份憑證的，這些憑證信息有 CA 根證書數(shù)據(jù)（ca.crt）和簽名后的Token信息（Token）。

在 Token 信息中就包括了對(duì)應(yīng)的Service Account的名稱，因此 API Server 通過接收到的Token信息就能確定 Service Account 的身份。在默認(rèn)情況下，用戶創(chuàng)建一個(gè) Pod 時(shí)，Pod 會(huì)綁定對(duì)應(yīng)命名空間中的 default 這個(gè) Service Account 作為其“公民身份證”。

當(dāng) Pod 里的容器被創(chuàng)建時(shí)，Kubernetes 會(huì)把對(duì)應(yīng)的Secret對(duì)象中的身份信息（ca.crt、Token 等）持久化保存到容器里固定位置的本地文件中，因此當(dāng)容器里的用戶進(jìn)程通過 Kubernetes 提供的客戶端 API 去訪問 API Server 時(shí)，這些API會(huì)自動(dòng)讀取這些身份信息文件，并將其附加到 HTTPS 請(qǐng)求中傳遞給API Server以完成身份認(rèn)證邏輯。在身份認(rèn)證通過以后，就涉及“訪問授權(quán)”的問題，這就是 RBAC 要解決的問題了。

5.2 Role

首先我們要學(xué)習(xí)的是 Role 這個(gè)資源對(duì)象，包括 Role 與 ClusterRole兩種類型的角色。角色定義了一組特定權(quán)限的規(guī)則，比如可以操作某類資源對(duì)象。局限于某個(gè)命名空間的角色由Role對(duì)象定義，作用于整個(gè) Kubernetes 集群范圍內(nèi)的角色則通過 Cluster Role 對(duì)象定義。

下面是 Role 的一個(gè)例子，表示在命名空間 default 中定義一個(gè)Role對(duì)象，用于授予對(duì) Pod 資源的讀訪問權(quán)限，綁定到該 Role 的用戶則具有對(duì) Pod 資源的 get、watch 和list權(quán)限：

5.2 Role Binding

接下來就是如何將 Role 與具體用戶綁定（用戶授權(quán)）的問題了。我們可以通過 RoleBinding 與 ClusterRoleBinding 來解決這個(gè)問題。下面是一個(gè)具體的例子，在命名空間 default 中將“pod-reader”角色授予用戶“Caden”，結(jié)合對(duì)應(yīng)的 Role 的定義，表明這一授權(quán)將允許用戶“Caden”從命名空間 default 中讀取 pod:

在 RoleBinding 中使用 subjects（目標(biāo)主體）來表示要授權(quán)的對(duì)象，這是因?yàn)槲覀兛梢允跈?quán)三類目標(biāo)賬號(hào)：Group（用戶組）、User（某個(gè)具體用戶）和 Service Account (Pod 應(yīng)用所使用的賬號(hào)）。

5.3 NetworkPolicy（網(wǎng)絡(luò)策略）

在安全領(lǐng)域，除了以上針對(duì) API Server 訪問安全相關(guān)的資源對(duì)象，還有一種特殊的資源對(duì)象一一 NetworkPolicy（網(wǎng)絡(luò)策略），它是網(wǎng)絡(luò)安全相關(guān)的資源對(duì)象，用于解決用戶應(yīng)用之間的網(wǎng)絡(luò)隔離和授權(quán)問題。

NetworkPolicy 是一種關(guān)于 Pod 間相互通信，以及 Pod 與其他網(wǎng)絡(luò)端點(diǎn)間相互通信的安全規(guī)則設(shè)定。

NetworkPolicy資源使用標(biāo)簽選擇 Pod，并定義選定 Pod 所允許的通信規(guī)則。在默認(rèn)情況下，Pod 間及Pod與其他網(wǎng)絡(luò)端點(diǎn)間的訪問是沒有限制的，這假設(shè)了 Kubernetes集群被一個(gè)廠商（公司/租戶）獨(dú)占，其中部署的應(yīng)用都是相互可信的，無須相互防范。但是，如果存在多個(gè)廠商共同使用一個(gè)Kubernetes集群的情況，則特別是在公有云環(huán)境中，不同廠商的應(yīng)用要相互隔離以增加安全性，這就可以通過 NetworkPolicy 來實(shí)現(xiàn)了。

總結(jié)

以上是生活随笔為你收集整理的k8s教程（基础篇）-基本概念和术语的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。