成為一名k8s專家需要掌握哪些知識
- 在完整的閱讀了k8s原始碼，梳理了160多篇文件之後我進行如下的總結：
- 當然主要目的是羅列一些關鍵點：具體細節受限篇幅不會貼出來
教程地址
k8s知識圖譜
01 容器底層知識
01 到底什麼是容器：簡單說就是受限制的程式，底層相關的兩個技術是linux的namespace和cgrop
- namespace 的分類和sandbox容器的關係，哪些ns是共享的，涉及到容器的隔離不徹底問題
- cgroup v1 和v2 的區別，cpu/mem限制的原理，cpu綁核如何操作
02 容器映象：映象不是docker的專利
- OCI（Open Container Initiative）規範是事實上的容器標準，已經被大部分容器實現以及容器編排系統所採用。
- 任何實現了OCI規範的工具都可以打映象
規範要求映象內容包括以下 幾個 部分：
3個必須的
- Image Manifest ：提供了映象的配置和檔案系統層定位資訊，可以看作是映象的目錄，檔案格式為 json 。
- Image Layer Filesystem Changeset ：序列化之後的檔案系統和檔案系統變更，它們可按順序一層層應用為一個容器的 rootfs，因此通常也被稱為一個 layer（與下文提到的映象層同義），檔案格式可以是 tar ，gzip 等存檔或壓縮格式。
- Image Configuration ：包含了映象在執行時所使用的執行引數以及有序的 rootfs 變更資訊，檔案型別為 json。
1個可選的
- image-index : 影像索引是一種更高階別的清單，它指向特定的影像清單，非常適合一個或多個平臺
03 容器聯合檔案系統：overlayfs 的理解
容器run起來時對應的3個層：
- image layer (只讀)，映象的層
- init layer 容器在啟動時寫入的一些配置檔案，發生在 container layer之前
- container layer 新增的可寫層
copy on write技術
- 好處是減少映象體積，提升啟動速度，
- 缺點就是寫入的速度慢，所以在 container layer 中不適合進行大量的檔案讀寫，應該使用Volume
04 容器執行時 CRI主要包括兩個 gRPC 服務，ImageService 和 RuntimeService
grpc服務分析
- ImageService 服務主要是拉取映象、檢視和刪除映象等操作
- RuntimeService 則是用來管理 Pod 和容器的生命週期，以及與容器互動的呼叫（exec/attach/port-forward）等操作
- Exec等互動服務也可以單獨出來做一個StreamService
low/high level容器執行時
- 如runc、lxc、containerd、docker、libcontainerd 他們有什麼區別
- docker 的元件被拆分成什麼樣子了，它們都負責幹什麼
02 k8s計算
01 內建資源的常規操作
- deployment、statefulset、daemonset、job
- 擴/縮容：慢啟動slowBatchStart建立pod的實現和目的
- 更新策略：滾動更新 vs 暴露重建
- 刪除策略：級聯刪除 vs 保留 pod
02 k8s-pod中幾種容器的關係
- sandbox都幹了什麼
- init容器的目的和應用場景
- app容器的啟動過程：internal hook和給使用者暴露的lifecycle hook
- 三種探針的作用
- 總結就是pod的生命週期，幾種容器的啟動順序，幾個hook的作用，最後還有探針
03 拓撲管理器 kubelet多種資源管理器獨立分配資源缺乏統一的視角
- 多種資源管理器在給pod分配裝置時，都是獨立工作的，不會有一個全域性觀念，這可能會造成資源分配不合理的問題
- Topology Manager就是提供全域性的視角，為了儘量將資源分配在同一個numa節點下，提升效能
04 pod的三種QOS 和cpu記憶體資源的關係
- 不同qos oom_score_adj值的設定
- qos和 資源共享池的關係，涉及到後面的cpu/mem manager的numa設定
05 kubelet呼叫CRI的流程和docker-shim這個奇葩的存在
- k8s如何麻痺docker的
- OCI標準的制定
03 k8s儲存
- 01 常見volume型別
- 02 configMap和secret的熱載入原理
03 動靜態pv和 StorageClass動態生成PV
- PV和PVC之間的相互作用遵循這個生命週期 ：供應-->繫結-->使用--> 釋放--> 迴圈
- 隨著PV數量的增加，管理員需要不停的定義PV的數量，衍生了通過StorageClass動態生成PV
- StorageClass通過PVC中宣告儲存的容量，會呼叫底層的提供商生成PV。
- 04 kubelet volume-manager掛載volume的過程
05 CSI外掛
- 動態 Provisioner機制
04 k8s網路
01 Kubernetes需要解決4種通訊模式：
- 容器和容器之間的通訊
- Pod和Pod之間的通訊
- Pod和Service之間的通訊
- Internet和Service之間的通訊
- 02 svc 4種負載均衡模式：其實說白了就是流量由誰來轉發
- 03 svc的服務發現 ：dns 和環境變數
03 iptables是如何轉發svc的流量的：
- 幾條KUBE-XXX的鏈的資料流轉
04 svc的cluster-ip 能被ping通嗎：
- 需要分情況，比如iptables reject了icmp的報文
- 05 cni外掛：calico和Flannel 的區別
06 ingress機制：原理可以簡化為nginx+服務發現+熱更新
- traefik 原始碼解讀
- 07 無頭服務的真正生產用途
05 k8s的外掛機制
01 准入控制器 ：可以注入sidecar或者做vpa擴容
- 資料請求流程是什麼樣的？
- 02 CRI 、CSI、CNI 就是k8s給第三方實現者提供的 計算儲存網路外掛機制
03 apiserver的聚合外掛，方便擴充套件API：典型應用metrics.k8s.io和custom.metrics.k8s.io
- 原始碼理解的如何？
04 kubelet 的 device-plugins裝置外掛機制，方便如nvidia GPU裝置的接入 ：grpc註冊device和grpc server提供 device的管理
- grpc哪裡怎麼註冊和管理
05 嚴格說來crd+controller的 operator模式也算
- reconcile調諧怎樣寫
06 k8s的控制平面原始碼理解
- 01 建立pod的流程在控制平面元件間的流轉
02 informer機制的作用
- 訊息中介軟體？ 降低etcd的壓力
- 03 leaderelection選主機制
04 kubelet中的syncLoop大迴圈
- 5類事件迴圈 7個chan
05 各個控制器的syncXXX流程
- 讀寫都混在一起的sync流程
06 kubelet中的各個資源manager
- statusManger怎樣同步狀態的
- containerManger 怎樣限制 ephemeral storage
- EvictionManager原始碼中怎樣工作的
07 apiserver
- 認證
- 鑑權：rbac 原始碼
- 准入： mutate vs validate ，當然還有webhook
- 限速
- event broadcast 機制
07 k8s編排
01 基於cpu的hpa ：快起慢縮
- 怎樣做到快起快縮
- 02 基於mem的hpa ：怎麼和metrics-server互動的，涉及到apiserver的聚合外掛
03 基於prometheus-operator的 vpa
- custom.metrics.k8s.io apigroup 的流程
- 其中為什麼需要准入控制器的接入
- vertical-pod-autoscaler原始碼閱讀之Recommender、updater、admission-controller原始碼解讀
04 metrics-server的原始碼理解和 kubelet top的原理
- 底層的資料來自哪裡
- 怎樣儲存的
- cpu rate如何算出的
08 k8s crd開發
- 01 為什麼要crd ：封裝基礎物件來完成對分散式/有狀態服務的快速部署
- 02 crd開發過程： 定義 CRD和實現 controller reconcile的 具體邏輯，其餘交給程式碼生成工具
09 k8s 的監控
01 metrics ，那沒的說肯定就是prometheus，那麼prometheus on k8s那麼方案也太多了
- 儲存怎麼選
- kube-prometheus 中的原理和提示又是什麼
- 02 logging
- 03 event