【K8S】K8S 基礎概念學習
容器編排與作業(yè)管理
Deployment
多副本，水平擴展
滾動更新
創(chuàng)建一個多復本應用首選的方式就是 Deplyment，Deployment 內部使用 ReplicaSet 實現(xiàn)。
Deployment 實際上是一個兩層控制器：
它通過 ReplicaSet 的個數(shù)來描述應用的版本；
它通過 ReplicaSet 的屬性，比如 replicas的值，來保證 Pod 的副本數(shù)量。
Deployment 控制 ReplicaSet ?版本，ReplicaSet 控制 Pod 副本數(shù)量。
ReplicaSet
StatefulSet
核心功能：通過某種方式記錄 Pod 的拓撲狀態(tài)或者存儲狀態(tài)，然后在 Pod 被重新創(chuàng)建時，能夠為新 Pod 恢復這些狀態(tài)。這里的狀態(tài)包括拓撲狀態(tài)和存儲狀態(tài)。
穩(wěn)定、唯一的網(wǎng)絡標識符
穩(wěn)定、持久的存儲
有序的部署、刪除和擴縮容
有序的滾動更新
如何實現(xiàn)：
StatefuleSet 的控制器直接管理 Pod.
拓撲狀態(tài)：StatefulSet 為每個 Pod 維護了一個粘性 ID 編號，無論怎么調度，每個 Pod 都有一個永遠不變的 ID.
存儲狀態(tài)：為每個 Pod 分配并創(chuàng)建一個同樣編號的 PVC。（這樣，Kubernetes 就可以通過 Persistent Volume 機制為這個 PVC 綁定上對應的 PV，從而保證了每一個 Pod 都擁有一個獨立的 Volume。）
所以即使 Pod 被刪，當被重新創(chuàng)建出來的時候，kubernets 會為它找到同樣編號的 PVC, 掛載 PVC 對應的 Volume.
通過?Headless Service?為每個有編號的 Pod, 生成帶有同樣編號的 DNS 記錄。（只要 StatefulSet 能夠保證這些 Pod 名字里的編號不變，那么 Service 里類似于 web-0.nginx.default.svc.cluster.local 這樣的 DNS 記錄也就不會變）
StatefulSet 這個控制器的主要作用之一，就是使用 Pod 模板創(chuàng)建 Pod 的時候，對它們進行編號，并且按照編號順序逐一完成創(chuàng)建工作。
而當 StatefulSet 的“控制循環(huán)”發(fā)現(xiàn) Pod 的“實際狀態(tài)”與“期望狀態(tài)”不一致，需要新建或者刪除 Pod 進行“調諧”的時候，它會嚴格按照這些 Pod 編號的順序，逐一完成這些操作。
與此同時，通過 Headless Service 的方式，StatefulSet 為每個 Pod 創(chuàng)建了一個固定并且穩(wěn)定的 DNS 記錄，來作為它的訪問入口。
實際上，在部署“有狀態(tài)應用”的時候，應用的每個實例擁有唯一并且穩(wěn)定的“網(wǎng)絡標識”，是一個非常重要的假設。
StatefulSet 其實是一種特殊的 Deployment，只不過這個“Deployment”的每個 Pod 實例的名字里，都攜帶了一個唯一并且固定的編號。這個編號的順序，固定了 Pod 的拓撲關系；這個編號對應的 DNS 記錄，固定了 Pod 的訪問方式；這個編號對應的 PV，綁定了 Pod 與持久化存儲的關系。所以，當 Pod 被刪除重建時，這些“狀態(tài)”都會保持不變。
Headless Service
Persisted Volume Claim (PVC) 對象
Persisted Volume 對象
聲明式 API 與 Kubernets 編程范式
在 Kubernetes 項目中，一個 API 對象在 Etcd 里的完整資源路徑，是由：Group（API 組）、Version（API 版本）和 Resource（API 資源類型）三個部分組成的。
Operator: 聰明的微創(chuàng)新
Operator 的工作原理：
實際上是利用了 Kubernetes 的自定義 API 資源（CRD），來描述我們想要部署的“有狀態(tài)應用”；
然后在自定義控制器里，根據(jù)自定義 API 對象的變化，來完成具體的部署和運維工作。
Controller Manager
控制器模型
控制循環(huán) control loop
基于 etcd watch 的實現(xiàn)方式：
kube-proxy :
容器網(wǎng)絡：Service 是如何被發(fā)現(xiàn)的？
Service 是由 kube-proxy 組件，加上 iptables 來共同實現(xiàn)的
訪問 Service VIP 的 IP 包經(jīng)過上述 iptables 處理之后，就已經(jīng)變成了訪問具體某一個后端 Pod 的 IP 包了。不難理解，這些 Endpoints 對應的 iptables 規(guī)則，正是 kube-proxy 通過監(jiān)聽 Pod 的變化事件，在宿主機上生成并維護的。
Informar 和 緩存機制 - ListAndWatch 機制
所謂 Informer，其實就是一個帶有本地緩存和索引機制的、可以注冊 EventHandler 的 client。
client-go 與 controller runtime 是什么關系？
kubernetes 提供了 client-go 以便使用 go 語言進行二次開發(fā)。
K8s 系統(tǒng)使用 client-go 作為 Go語言的官方編程式交互客戶端庫, 提供對 K8s API Server 服務的交互訪問
k8s 其他組件都是通過 cleint-go informer 機制與 K8s 的 ? API-Server 進行通信的
controller-runtime 是社區(qū)封裝的一個控制器處理框架。
controller runtime 和 kubebuilder 是什么關系？
kubebuilder 基于 controller runtime 做了一些封裝，目的是快速生成 operator 代碼。
kustomize 是什么東西
