微服務演進方向
•
面向分散式設計（Distribution）：容器、微服務、API 驅動的開發；
•
面向配置設計（Configuration）：⼀個映象，多個環境配置；
•
面向韌性設計（Resistancy）：故障容忍和自愈；
•
面向彈性設計（Elasticity）：彈性擴充套件和對環境變化（負載）做出響應；
•
面向交付設計（Delivery）：⾃動拉起，縮短交付時間；
•
面向效能設計（Performance）：響應式，併發和資源高效利用；
•
面向自動化設計（Automation）：⾃動化的 DevOps；
•
面向診斷性設計（Diagnosability）：叢集級別的日誌、metric 和追蹤；
•
面向安全性設計（Security）：安全端點、API Gateway、端到端加密；
滿足微服務架構模式要求
•
容器化
•
服務發現
•
可編排
•
動態排程
•
支援標準cicd
•
分散式配置架構
•
宣告式配置
Kubernetes就是為了滿足上述微服務的各種演進和特點誕生的，在K8S的設計哲學裡充滿了對微服務編排的各種模式的定製化支援。
K8S的特性
•
Predictable Demands
￮
資源使⽤
￮
服務配置
￮
流量控制
￮
依賴管理
•
Declarative Deployment
￮
滾動升級
￮
固定方式升級
￮
藍綠升級
￮
金絲雀釋出
•
HealthProbe
￮
健康檢查：health check
￮
存活檢查： lineness probes （HTTP，TCP，EXEC）
￮
可用性檢查：readiness probe
•
Managed Lifecycle
￮
Signal
￮
sigkill
￮
Restart
￮
Prestop hook
￮
Poststart hook
•
Automated Placement
￮
面向最合適的資源進行排程
K8S各個元件的聯動
Pod介紹
將多個容器打通共享隔離機制，每個pod都會包含一個paused的容器用於初始化環境，其他容器繼承該容器的隔離配置
Pod基礎
Pod的本質是多個共享資源的容器的組合。
Pod排程的篩選策略
Pod申請資源的優先順序控制機制與模型
如上圖所示，三種資源分配模型各自具備一定的特點，基於模型的特點可以整合資源混合部署的優先順序控制機制，增強整體叢集資源的利用率
•
BestEffort
•
Bustable
•
Guaranteed
Service
在K8叢集中，客戶端需要訪問的服務就是Service物件。每個Service會對應一個叢集內部有效的虛擬IP，叢集內部透過虛擬IP訪問⼀個服務。
•
label：用於過濾篩選pod，label在k8s內部會
進行索引
，因此檢索效率非常高效，業務模型設計的時候用於過濾檢索的欄位可以用label表示，儘量寫的所有label都是有效檢索欄位。
•
annotations：用於註解一些label不易說清楚的事項，注意annotation不會被索引，因此不要使用annotation用來做篩選欄位。
•
configmap：當開發控制器或者定義容器的時候需要額外的配置，這些配置資訊又無法透過label和annotation來傳遞，此時最好的方案就是用configmap。
流量接入
透過proxy方式
負載均衡器直接接入到service
透過ingress元件暴露介面
ETCD說明
etcd是k8s的分散式儲存中心，etcd叢集管理，raft協議保證一致性。
關於etcd的詳細說明有一個開源電子書：https：//csunny。gitbook。io/etcd/introduce
Controller控制器模型
K8S在etcd基礎之上提供了一個基於事件驅動的程式設計模型，基於該模型可以控制資源的生命週期以及響應事件的變化做出動態調整；
控制原理示意圖
Obeserve——->Analyze——->Act 事件迴圈，k8s提供的控制器程式設計模型提供了可靠的基於資源的擴充套件協議和通用的程式設計模型，在該模型下可以擴充套件更多的通用定製化邏輯。
用shell指令碼模擬控制器模式如下：
K8S Watch的事件型別補充說明一下：
Operator
operator本質上是定製化的控制器，只不過控制器層面額外做了很多封裝操作，這些操作使得我們做定製化資源控制和服務管理時更得心應手。
CRD（CustomResourceDefinition）非常有用，CRD對於我們擴充套件K8S的介面非常有幫助，有CRD我們就可以基於K8S做更多的定製化場景的服務管控。CRD將K8S的能力和特定領域的軟體的能力進行了整合，這個整合使得K8S具備了非常好的擴充套件空間。
一個標準的crd定義舉例：
1。
Name
2。
API歸屬組
3。
確定資源型別，用於識別該資源
4。
名稱的複數形式，用於 URL：/apis/<組>/<版本>/<名稱的複數形式>
5。
作用域，名字空間維度或者叢集維度等
6。
版本
7。
具體支援的版本號
8。
只有一個版本會標記為存檔版本，設定為true表示當前版本需要儲存
9。
每個版本都可以透過served表示啟用與否
10。
openapi的版本schema定義模式
Volume
Volume是Pod中能夠被多個容器訪問的共享目錄，Kubernetes中的Volume與Pod⽣生命週期相同，但與容器的⽣命週期不相關，Kubernetes⽀持多種型別的Volume，並且一個Pod可以同時使用任意多個Volume。
•
EmptyDir：Pod分配時建立，K8S⾃自動分配，當Pod被移除資料被清空。⽤用於臨時空間 等。
•
hostPath： 為Pod上掛載宿主機⽬目錄。⽤用於持久化資料。
￮
gcePersistentDisk、awsElasticBlockStore：掛載公有云盤。
￮
nfs、iscsi、glusterfs、rbd、gitRepo：掛載相應磁碟資源。
K8S宣告式配置標準
•
apiVersion
•
kind
•
metadata
•
spec
示例：
Resource資源
K8S幾乎所有物件都被抽象為了資源（Resource），包括 K8s Core Resources（Pod， Service， Namespace 等）、CRD、APIService 擴充套件的資源型別。同時 K8s 底層將這些資源統一抽象為了 RESTful 的儲存（Storage），一方面服務端按目錄形式（/registry/xxx） 存放在 ETCD 中，另一方面也為客戶端提供了 RESTful API 介面，便於對資源的操作（get/post/put/patch/delete 等）。
K8s Watch API 就是為資源提供的一種持續監聽其變化的機制，當資源有任何變化的時候，都可以實時、順序、可靠的傳遞給客戶端，使得使用者可以針對目標資源進行靈活應用與操作。
容器內和K8S配置聯動方式
容器內程序能獲取到的外部編排的上下文資訊有兩個來源，環境變數和掛載項。
第一為環境變數
環境變數需要在編排期設定
第二為掛載的檔案
掛載檔案以及生成規則也需要在編排期設定，對於配置是否只讀也可以在編排期設定選項
•
示例，比如容器想在執行時瞭解容器編排的一些註解資訊和標籤資訊，基於該註解內容來控制流量策略和業務模型，那麼實現可以如下方式：
K8S叢集編排服務的模式梳理
DaemonSet模式
類似於守護程序一樣，每個節點部署一個pod。
SideCar模式
⽣產環境中經常需要有一些通⽤的配置初始化策略，比如許可權統⼀設定，類似的活⼉交由sidecar 模式的容器器進行管理，這樣的容器可以只處理通用性的需求，比如統⼀將⽇志⽬錄的掛載採集策略進⾏編排，將日誌掛載路路徑規範化，採集統⼀化；所謂的sidecar就是有一個容器器和其他容器進行了某種的共享策略，然後基於共享的內容各自負責各自的事情。
Init Container
服務的啟動依賴其他容器進⾏一些初始化工作，⽐如動態生成配置⽂件，靜態檔案獨立編譯生成
後交由服務容器器使⽤。
Singleton Service
全域性只能有一個Pod例項，有些特定場景的服務只能全域性保證只有一個容器在幹活，其他的同時處理會有資源競爭或者分散式鎖的問題，因此該場景下可以考慮singleton的部署方式。
Stateful Service
有狀態服務比如mysql，其資料層關係到該POD不能跟無狀態圖服務一樣故障後重新尋找資源然後啟動就OK了，有狀態服務需要保證帶狀態的層和服務的捆綁。因此一個服務一旦對某個特定狀態有依賴務必需要重點考慮其部署編排模式。
Ambassador
ambassador模式類似於代理模式，將服務基礎能力透過封裝的方式獨立出去，然後業務邏輯透過容器內去訪問，降低容器接入外部服務的成本。
動態擴縮容
擴容，縮容涉及到的維度不同工作原理與方案就不同，比如叢集維度，pod維度等差異。
K8S內建了很多可以面向動態擴縮容的機制，比如基於metirc指標動態生成擴容計劃
•
POD的動態調整模型
•
叢集的動態調整模型
其他
•
K8S常用的各種命令：https：//kubernetes。io/docs/reference/generated/kubectl/kubectl-commands#create
•
k8s的watchapi整理：
https：//mp。weixin。qq。com/s/swmMoegiNgNHUwc67NN6AA
•
kubebuilder：將多個crd整合到一起開發的專案
￮ https：//github。com/kubernetes-sigs/kubebuilder
•
Metacontroller：提供一個定製化的crd，但是該crd提供了各種能力的通用型擴充套件語義
￮ https：//github。com/metacontroller/metacontroller
•
jsonnet資料模板語言：
https：//github。com/google/jsonnet
•
operatorhub：
https：//operatorhub。io/
•
operator sdk：
https：//github。com/operator-framework/operator-sdk
