前言
Kubernetes的教程一直在編寫，目前已經初步完成了以下內容：
1）基礎理論
2）使用Minikube部署本地Kubernetes集群
3）使用Kubeadm創建集群
接下來還會逐步完善本教程，比如Helm、ELK、Windows Server容器等等。
目錄
Kubernetes主體架構
1.1.主要核心組件
1.1.1. Master組件
1.1.2. 節點（Node）組件
1.1.3. 插件
1.2. 基本概念
1.2.1. 容器組（Pod）
1.2.2. 服務（Service）
1.2.3. 卷（Volume）
1.2.4. 標簽（Labels）和標簽選擇器（Label Selector）
1.2.5. 復制控制器（Replication Controller，RC）
1.2.6. 副本集控制器（Replica Set，RS）
1.2.7. 部署控制器(Deployment)
1.2.8. StatefulSet
1.2.9. 后台支撐服務集（DaemonSet）
1.2.10. 一次性任務（Job）
Kubernetes主體架構
k8s的整體架構如下圖所示：
C:\Users\Lys_Desktop\Documents\Tencent Files\512982554\FileRecv\思維導圖1.png
1.1主要核心組件
1.1.1Master組件
Master為集群控制管理節點，負責整個集群的管理和控制。Master的組件如下所示：
1）kube-apiserver
kube-apiserver用於暴露Kubernetes API，提供了資源操作的唯一入口。任何的資源請求/調用操作都是通過kube-apiserver提供的接口進行。
2）etcd
etcd是Kubernetes的高可用的一致性鍵值存儲系統，也是其提供的默認的存儲系統，用於存儲所有的集群數據，使用時需要為etcd數據提供備份計划。
3）kube-scheduler
kube-scheduler 監視新創建沒有分配到Node的Pod，為Pod選擇一個Node以供其運行。
4）kube-controller-manager
kube-controller-manager運行管理控制器，它們是集群中處理常規任務的后台線程。邏輯上，每個控制器是一個單獨的進程，但為了降低復雜性，它們都被編譯成單個二進制文件，並在單個進程中運行。
這些控制器包括：
- 節點（Node）控制器：負責在節點出現故障時警示和響應。
- 副本（Replication）控制器：負責為系統中的每個副本控制器對象維護正確的pod數量。
- 端點（Endpoints）控制器：填充Endpoints對象（即連接Services＆Pods）。
- Service Account和Token控制器：為新的Namespace創建默認帳戶訪問API 訪問Token。
5）cloud-controller-manager
雲控制器管理器負責與底層雲提供商的平台交互。雲控制器管理器是Kubernetes版本1.6中引入的。
雲控制器管理器僅運行雲提供商特定的（controller loops）控制器循環。可以通過將--cloud-provider flag設置為external啟動kube-controller-manager ，來禁用控制器循環。
cloud-controller-manager 具體功能：
- 節點（Node）控制器：檢查雲端節點，以確保節點在停止響應之后在雲中是否刪除。
- 路由（Route）控制器：用於在底層雲基礎架構中設置路由。
- 服務（Service）控制器：用於創建，更新和刪除雲提供商的負載均衡器。
- 卷（Volume）控制器：用於創建，附加和裝載卷，以及與雲提供商交互以協調卷。
1.1.2 節點（Node）組件
Node是k8s集群中的工作負載節點，用於被Master分配工作負載（容器）。Node的組件有：
1）kubelet
kubelet是節點代理，它會監視已分配給節點的pod，確保容器在pod中運行。
2）kube-proxy
kube-proxy為節點的網絡代理，通過在主機上維護網絡規則並執行連接轉發來實現Kubernetes的服務抽象。
kube-proxy負責請求轉發。kube-proxy允許通過一組后端功能進行TCP和UDP流轉發或循環TCP和UDP轉發。
3）Container Runtime
容器運行時是負責運行容器的軟件。
Kubernetes支持多個容器運行時：Docker， containerd，cri-o， rktlet以及Kubernetes CRI（容器運行時接口）的任何實現。目前最佳組合為Kubernetes+Docker。
1.1.3 插件
插件是實現集群功能的pod和服務，他們擴展了Kubernetes的功能。主要的插件有：
- DNS
Kubernetes的集群DNS擴展插件用於支持k8s集群系統中各服務之間的發現和調用。
- Web UI (Dashboard)
Dashboard（儀表盤）是Kubernetes集群的基於Web的通用UI，它允許用戶管理群集，以及管理集群中運行的應用程序。
- Container Resource Monitoring（容器資源監測）
Container Resource Monitoring工具提供了UI監測容器、Pods、服務以及整個集群中的數據，用於檢查Kubernetes集群中，應用程序的性能。
- Cluster-level Logging（集群級日志記錄）
Cluster-level Logging提供了容器日志存儲，並且提供了搜索/瀏覽界面。
1.2 基本概念
初步了解了Kubernetes的主題架構和核心組件，我們還需要進一步了解一些Kubernetes的基本概念。主要如下所示：
1.2.1 容器組（Pod）
Pod是k8s集群中運行部署應用或服務的最小單元，一個Pod由一個或多個容器組成。在一個Pod中，容器共享網絡和存儲，並且在一個Node上運行。
Kubernetes為每個Pod都分配了唯一的IP地址，稱之為Pod IP，一個Pod里的多個容器共享Pod IP地址。Kubernetes要求底層網絡支持集群內任意兩個Pod之間的TCP/IP直接通信，這通常采用虛擬二層網絡技術來實現，例如Flannel、Open vSwitch等。因此，在Kubernetes里，一個Pod里的容器與另外主機上的Pod容器能夠直接通信。
Pod有兩種類型：普通的Pod和靜態Pod（Static Pod），靜態Pod不存放在etcd存儲里，而是存放在某個具體的Node上的一個具體文件中，並且只在此Node上啟動運行。普通的Pod一旦被創建，就會被存儲到etcd中，隨后會被Kubernetes Master調度到某個具體的Node上並進行綁定（Binding），該Node上的kubelet進程會將其實例化成一組相關的容器並啟動起來。當Pod里的某個容器停止時，Kubernetes會自動檢測到這個問題並且重新啟動這個Pod（重啟Pod里的所有容器）；如果Pod所在的Node宕機，則會將這個Node上的所有Pod重新調度到其他節點上運行。
Pod、容器與Node的關系如下圖：
apiVersion: v1 kind: Pod metadata: name: myapp-pod labels: app: myapp spec: containers: - name: myapp-container image: busybox command: ['sh', '-c', 'echo Hello Kubernetes! && sleep 3600']
1.2.2 服務（Service）
在Kubernetes中，Pod會經歷“生老病死”而無法復活，也就是說，分配給Pod的IP會隨着Pod的銷毀而消失，這就導致一個問題——如果有一組Pod組成一個集群來提供服務，某些Pod提供后端服務API，某些Pod提供前端界面UI，那么該如何保證前端能夠穩定地訪問這些后端服務呢？這就是Service的由來。
Service在Kubernetes中是一個抽象的概念，它定義了一組邏輯上的Pod和一個訪問它們的策略（通常稱之為微服務）。這一組Pod能夠被Service訪問到，通常是通過Label選擇器確定的。
例如，一個圖片處理的后端程序，它運行了3個副本，這些副本是可互換的——前端程序不需要關心它們調用了哪個后端副本。雖然組成這一組的后端程序的Pod實際上可能會發生變化，但是前端無需知道也沒必要知道，也不需要跟蹤后端的狀態。Service的抽象解耦了這種關聯。
apiVersion: v1 kind: Service metadata: name: my-service spec: selector: app: MyApp ports: - protocol: TCP port: 80 targetPort: 9376
1.2.3 卷（Volume）
和Docker不同，Kubernetes的Volume定義在Pod上，被一個Pod里的多個容器掛載到具體的文件目錄下，當容器終止或者重啟時，Volume中的數據也不會丟失。也就是說，在Kubernetes中，Volume是Pod中能夠被多個容器訪問的共享目錄。
目前，Kubernetes支持以下類型的卷：
- awsElasticBlockStore
awsElasticBlockStore可以掛載AWS上的EBS盤到容器，需要Kubernetes運行在AWS的EC2上。
- azureDisk
Azure是微軟提供的公有雲服務，如果使用Azure上面的虛擬機來作為Kubernetes集群使用時，那么可以通過AzureDisk這種類型的卷插件來掛載Azure提供的數據磁盤。
- azureFile
AzureFileVolume用於將Microsoft Azure文件卷（SMB 2.1和3.0）掛載到Pod中。
- cephfs
cephfs Volume可以將已經存在的CephFS Volume掛載到pod中，與emptyDir特點不同，pod被刪除的時，cephfs僅被被卸載，內容保留。cephfs能夠允許我們提前對數據進行處理，而且這些數據可以在Pod之間“切換”。
- cinder
cinder用於將OpenStack Cinder Volume安裝到Pod中。
- configMap
configMap提供了一種將配置數據注入Pod的方法。存儲在ConfigMap對象中的數據可以在configMap類型的卷中引用，然后由在Pod中運行的容器化應用程序使用。
- csi
Container Storage Interface（CSI）為Kubernetes定義了一個標准接口，以將任意存儲系統暴露給其容器工作負載。在Kubernetes集群上部署CSI兼容卷驅動程序后，用戶可以使用csi卷類型來附加，裝載等CSI驅動程序公開的卷。
- downwardAPI
downwardAPI可以將Pod和Container字段公開給正在運行的Container。
- emptyDir
使用emptyDir時，Pod分配給節點時就會首先創建卷，並且只要Pod在該節點上運行，這個卷就會一直存在。當Pod被刪除時，emptyDir中的數據也不復存在。
- fc (fibre channel)
光纖通道區域存儲網絡，需要購買支持FC的磁盤陣列設備、控制器、光纖、光接口以及與設置相匹配的軟件。
- flocker
flocker是一個開源的容器集群數據卷管理器，它提供由各種存儲后端支持的數據卷的管理和編排。
- gcePersistentDisk
gcePersistentDisk可以掛載GCE（Google的雲計算引擎）上的永久磁盤到容器，需要Kubernetes運行在GCE的VM中。與emptyDir不同，Pod刪除時，gcePersistentDisk被刪除，但Persistent Disk的內容任然存在。這就意味着gcePersistentDisk能夠允許我們提前對數據進行處理，而且這些數據可以在Pod之間“切換”。
- glusterfs
glusterfs，允許將Glusterfs（一個開源網絡文件系統）Volume安裝到pod中。不同於emptyDir，Pod被刪除時，Volume只是被卸載，內容被保留。
- hostPath
hostPath允許掛載Node上的文件系統到Pod里面去。如果Pod需要使用Node上的文件，可以使用hostPath。
- iscsi
iscsi允許將iscsi磁盤掛載到pod中，Pod被刪除時，Volume只是被卸載，內容被保留。
- local
Local 是Kubernetes集群中每個節點的本地存儲（如磁盤，分區或目錄），在Kubernetes1.7中kubelet可以支持對kube-reserved和system-reserved指定本地存儲資源。
通過上面的這個新特性可以看出來，Local Storage同HostPath的區別在於對Pod的調度上，使用Local Storage可以由Kubernetes自動的對Pod進行調度，而是用HostPath只能人工手動調度Pod，因為Kubernetes已經知道了每個節點上kube-reserved和system-reserved設置的本地存儲限制。
但是，本地卷仍受基礎節點可用性的限制，並不適用於所有應用程序。如果節點變得不健康，則本地卷也將變得不可訪問，並且使用它的Pod將無法運行。使用本地卷的應用程序必須能夠容忍這種降低的可用性以及潛在的數據丟失，具體取決於底層磁盤的持久性特征。
- nfs
NFS是Network File System的縮寫，即網絡文件系統。Kubernetes中通過簡單地配置就可以掛載NFS到Pod中，而NFS中的數據是可以永久保存的，同時NFS支持同時寫操作。Pod被刪除時，Volume被卸載，內容被保留。這就意味着NFS能夠允許我們提前對數據進行處理，而且這些數據可以在Pod之間相互傳遞。
使用NFS數據卷適用於多讀多寫的持久化存儲，適用於大數據分析、媒體處理、內容管理等場景。
- persistentVolumeClaim
persistentVolumeClaim用來掛載持久化磁盤。PersistentVolumes是用戶在不知道特定雲環境的細節的情況下，實現持久化存儲（如GCE PersistentDisk或iSCSI卷）的一種方式。
- projected
Projected volume將多個Volume源映射到同一個目錄，目前，可以支持以下類型的卷源：secret、downwardAPI、configMap、serviceAccountToken。
所有源都需要與Pod在同一名稱空間中。
- portworxVolume
portworxVolume是一個運行在Kubernetes中的彈性塊存儲層，可以通過Kubernetes動態創建，也可以在Kubernetes Pod中預先配置和引用。它能夠聚合多個服務器之間的容量，可以將服務器變成一個聚合的高可用的計算和存儲節點。
- quobyte
Quobyte是Quobyte公司推出的分布式文件存儲系統，它實現了Container Storage Interface（CSI，容器存儲接口）。
- rbd
RBD允許Rados Block Device格式的磁盤掛載到Pod中，同樣的，當pod被刪除的時候，rbd也僅僅是被卸載，內容保留。
RBD的一個特點是它可以同時由多個消費者以只讀方式安裝，但是不允許同時寫入。這意味着我們可以使用數據集預填充卷，然后根據需要從多個Pod中並行使用。
- scaleIO
ScaleIO是一種基於軟件的存儲平台（虛擬SAN），可以使用現有硬件來創建可擴展的共享塊網絡存儲的集群。ScaleIO卷插件允許部署的pod訪問現有的ScaleIO卷。
- secret
secret volume用於將敏感信息（如密碼）傳遞給pod。我們可以將secrets存儲在Kubernetes API中，使用的時候以文件的形式掛載到pod中，而無需直接連接Kubernetes。secret volume由tmpfs（RAM支持的文件系統）支持，因此它們永遠不會寫入非易失性存儲。
- storageos
StorageOS是一家英國的初創公司，給無狀態容器提供簡單的自動塊存儲、狀態來運行數據庫和其他需要企業級存儲功能。StorageOS在Kubernetes環境中作為Container運行，從而可以從Kubernetes集群中的任何節點訪問本地或附加存儲。可以復制數據以防止節點故障。精簡配置和內容壓縮可以提高利用率並降低成本。
StorageOS的核心是為容器提供塊存儲，可通過文件系統訪問。StorageOS Container需要64位Linux，並且沒有其他依賴項。提供免費的開發人員許可。
- vsphereVolume
vsphereVolume用於將vSphere VMDK Volume掛載到Pod中。卸載卷后，內容將被保留。它同時支持VMFS和VSAN數據存儲。
1.2.4 標簽（Labels）和標簽選擇器（Label Selector）
Labels其實就是附加到對象（例如Pod）上的鍵值對。給某個資源對象定義一個Label，就相當於給它打了一個標簽，隨后就可以通過Label Selector（標簽選擇器）來查詢和篩選擁有某些Label的資源對象，Kubernetes通過這種方式實現了類似SQL的簡單又通用的對象查詢機制。
總的來說，使用Label可以給對象創建多組標簽，Label和Label Selector共同構成了Kubernetes系統中最核心的應用模型，使得被管理對象能夠被精細地分組管理，同時實現了整個集群的高可用性。
1.2.5 復制控制器（Replication Controller，RC）
RC的作用是保障Pod的副本數量在任意時刻都符合某個預期值，不多也不少。如果多了，就殺死幾個，如果少了，就創建幾個。
RC有點類似於進程管理程序，但是它不是監視單個節點上的各個進程，而是監視多個節點上的多個pod，確保Pod的數量符合預期值。
RC的定義由以下內容組成：
當我們定義了一個RC並提交到Kubernetes集群中后，Master節點上的Controller Manager組件就得到通知，定期巡檢系統中當前存活的目標Pod，並確保目標Pod實例的數量剛好等於此RC的期望值。如果有過多的Pod副本在運行，系統就會停掉多余的Pod；如果運行的Pod副本少於期望值，即如果某個Pod掛掉，系統就會自動創建新的Pod以保證數量等於期望值。
通過RC，Kubernetes實現了用戶應用集群的高可用性，並且大大減少了運維人員在傳統IT環境中需要完成的許多手工運維工作（如主機監控腳本、應用監控腳本、故障恢復腳本等）。
常見使用場景：
- 重新規划
比如重新設置Pod數量。
- 縮放
- 滾動更新
RC支持滾動更新，也就是允許我們在更新服務時，逐個的替換Pod。也就是說，滾動更可以保障應用的可用性，確保任何時間都有可用的Pod來提供服務。
- 多個發布版本追蹤
除了在程序更新過程中同時可以運行多個版本的程序外，也可以在更新完成之后的一段時間內或者持續的同時運行多個版本（新舊）。需通過標簽選擇器來完成。
1.2.6 副本集控制器（Replica Set，RS）
ReplicaSet是下一代復制控制器。ReplicaSet和 Replication Controller之間的目前的唯一區別是選擇器的支持——Replica Set支持基於集合的Label selector（Set-based selector），而RC只支持基於等式的Label selector（equality-based selector），所以Replica Set的功能更強大。
Replica Set很少單獨使用，它主要被Deployment（部署）這個更高層的資源對象所使用，從而形成一整套Pod創建、刪除、更新的編排機制。
1.2.7 部署控制器(Deployment)
Deployment（部署控制器）為Pod和Replica Set提供聲明式更新。
我們只需要在Deployment中描述想要的目標狀態是什么，Deployment controller就會幫我們將Pod和Replica Set的實際狀態改變到目標狀態。我們可以定義一個全新的Deployment，也可以創建一個新的替換舊的Deployment。
Deployment相對於RC的最大區別是我們可以隨時知道當前Pod“部署”的進度。一個Pod的創建、調度、綁定節點及在目標Node上啟動對應的容器這一完整過程需要一定的時間，所以我們期待系統啟動N個Pod副本的目標狀態，實際上是一個連續變化的“部署過程”導致的最終狀態。
Deployment的典型使用場景有以下幾個：
- 創建一個Deployment對象來生成對應的Replica Set並完成Pod副本的創建過程。
- 檢查Deployment的狀態來看部署動作是否完成（Pod副本的數量是否達到預期的值）。
- 更新Deployment以創建新的Pod（比如鏡像升級）。
- 如果當前Deployment不穩定，則回滾到一個早先的Deployment版本。
- 暫停Deployment以便於一次性修改多個Pod Template Spec的配置項，之后再恢復Deployment，進行新的發布。
- 擴展Deployment以應對高負載。
- 查看Deployment的狀態，以此作為發布是否成功的指標。
- 清理不再需要的舊版本ReplicaSet。
1.2.8 StatefulSet
StatefulSet用於管理有狀態應用程序，比如Mysql集群、MongoDB集群、ZooKeeper集群等。
StatefulSet主要特性如下：
- StatefulSet里的每個Pod都有穩定、唯一的網絡標識，可以用來發現集群內的其他成員。
- 穩定的持久化存儲，即Pod重新調度后還是能訪問到相同的持久化數據，基於PersistentVolume來實現，刪除Pod時默認不會刪除與StatefulSet相關的存儲卷（為了保證數據的安全）。
- 有序部署，有序擴展，即Pod是有順序的，在部署或者擴展的時候要依據定義的順序依次依次進行（即從0到N-1，在下一個Pod運行之前所有之前的Pod必須都是Running和Ready狀態），基於init containers來實現。
- 有序收縮，有序刪除。
1.2.9 后台支撐服務集（DaemonSet）
DaemonSet保證在每個Node上都運行一個容器副本，常用來部署一些集群的日志、監控或者其他系統管理應用。典型的應用包括：
- 日志收集守護程序，比如fluentd，logstash等。
- 系統監控，比如Prometheus Node Exporter，collectd，New Relic agent，Ganglia gmond等。
- 集群存儲后台進程，比如glusterd，ceph等。
- 系統程序，比如kube-proxy, kube-dns, glusterd, ceph等。
1.2.10 一次性任務（Job）
Job負責批量處理短暫的一次性任務 (short lived one-off tasks)，即僅執行一次的任務，它保證批處理任務的一個或多個Pod成功結束。
Kubernetes支持以下幾種Job：
- 非並行任務。
- 具有固定完成計數要求的並行任務。
- 帶有工作隊列的並行任務。