GITBOOK-222: No subject

cit965 · Jan 9, 2025 · c23a816 · c23a816
1 parent bae03ba
commit c23a816
Show file tree

Hide file tree

Showing 105 changed files with 1,487 additions and 54 deletions.
diff --git a/.gitbook/assets/2c04672d520a7703b42d0acc0ae2c74.png b/.gitbook/assets/2c04672d520a7703b42d0acc0ae2c74.png
diff --git a/.gitbook/assets/aac3d96077168f8b28857ec2f713624.jpg b/.gitbook/assets/aac3d96077168f8b28857ec2f713624.jpg
diff --git a/.gitbook/assets/d09eacd15ca9df1262faf8b13fc7963.jpg b/.gitbook/assets/d09eacd15ca9df1262faf8b13fc7963.jpg
diff --git a/.gitbook/assets/image (10).png b/.gitbook/assets/image (10).png
diff --git a/.gitbook/assets/image (11).png b/.gitbook/assets/image (11).png
diff --git a/.gitbook/assets/image (12).png b/.gitbook/assets/image (12).png
diff --git a/.gitbook/assets/image (13).png b/.gitbook/assets/image (13).png
diff --git a/.gitbook/assets/image (14).png b/.gitbook/assets/image (14).png
diff --git a/.gitbook/assets/image (15).png b/.gitbook/assets/image (15).png
diff --git a/.gitbook/assets/image (16).png b/.gitbook/assets/image (16).png
diff --git a/.gitbook/assets/image (17).png b/.gitbook/assets/image (17).png
diff --git a/.gitbook/assets/image (18).png b/.gitbook/assets/image (18).png
diff --git a/.gitbook/assets/image (19).png b/.gitbook/assets/image (19).png
diff --git a/.gitbook/assets/image (20).png b/.gitbook/assets/image (20).png
diff --git a/.gitbook/assets/image (21).png b/.gitbook/assets/image (21).png
diff --git a/.gitbook/assets/image (22).png b/.gitbook/assets/image (22).png
diff --git a/.gitbook/assets/image (23).png b/.gitbook/assets/image (23).png
diff --git a/.gitbook/assets/image (24).png b/.gitbook/assets/image (24).png
diff --git a/.gitbook/assets/image (25).png b/.gitbook/assets/image (25).png
diff --git a/.gitbook/assets/image (26).png b/.gitbook/assets/image (26).png
diff --git a/.gitbook/assets/image (27).png b/.gitbook/assets/image (27).png
diff --git a/.gitbook/assets/image (28).png b/.gitbook/assets/image (28).png
diff --git a/.gitbook/assets/image (29).png b/.gitbook/assets/image (29).png
diff --git a/.gitbook/assets/image (30).png b/.gitbook/assets/image (30).png
diff --git a/.gitbook/assets/image (31).png b/.gitbook/assets/image (31).png
diff --git a/.gitbook/assets/image (32).png b/.gitbook/assets/image (32).png
diff --git a/.gitbook/assets/image (33).png b/.gitbook/assets/image (33).png
diff --git a/.gitbook/assets/image (34).png b/.gitbook/assets/image (34).png
diff --git a/.gitbook/assets/image (35).png b/.gitbook/assets/image (35).png
diff --git a/.gitbook/assets/image (36).png b/.gitbook/assets/image (36).png
diff --git a/.gitbook/assets/image (37).png b/.gitbook/assets/image (37).png
diff --git a/.gitbook/assets/image (38).png b/.gitbook/assets/image (38).png
diff --git a/.gitbook/assets/image (39).png b/.gitbook/assets/image (39).png
diff --git a/.gitbook/assets/image (40).png b/.gitbook/assets/image (40).png
diff --git a/.gitbook/assets/image (41).png b/.gitbook/assets/image (41).png
diff --git a/.gitbook/assets/image (42).png b/.gitbook/assets/image (42).png
diff --git a/.gitbook/assets/image (43).png b/.gitbook/assets/image (43).png
diff --git a/.gitbook/assets/image (44).png b/.gitbook/assets/image (44).png
diff --git a/.gitbook/assets/image (45).png b/.gitbook/assets/image (45).png
diff --git a/.gitbook/assets/image (46).png b/.gitbook/assets/image (46).png
diff --git a/.gitbook/assets/image (47).png b/.gitbook/assets/image (47).png
diff --git a/.gitbook/assets/image (48).png b/.gitbook/assets/image (48).png
diff --git a/.gitbook/assets/image (49).png b/.gitbook/assets/image (49).png
diff --git a/.gitbook/assets/image (50).png b/.gitbook/assets/image (50).png
diff --git a/.gitbook/assets/image (51).png b/.gitbook/assets/image (51).png
diff --git a/.gitbook/assets/image (52).png b/.gitbook/assets/image (52).png
diff --git a/.gitbook/assets/image (53).png b/.gitbook/assets/image (53).png
diff --git a/.gitbook/assets/image (54).png b/.gitbook/assets/image (54).png
diff --git a/.gitbook/assets/image (55).png b/.gitbook/assets/image (55).png
diff --git a/.gitbook/assets/image (56).png b/.gitbook/assets/image (56).png
diff --git a/.gitbook/assets/image (57).png b/.gitbook/assets/image (57).png
diff --git a/.gitbook/assets/image (58).png b/.gitbook/assets/image (58).png
diff --git a/.gitbook/assets/image (59).png b/.gitbook/assets/image (59).png
diff --git a/.gitbook/assets/image (6).png b/.gitbook/assets/image (6).png
diff --git a/.gitbook/assets/image (60).png b/.gitbook/assets/image (60).png
diff --git a/.gitbook/assets/image (61).png b/.gitbook/assets/image (61).png
diff --git a/.gitbook/assets/image (62).png b/.gitbook/assets/image (62).png
diff --git a/.gitbook/assets/image (63).png b/.gitbook/assets/image (63).png
diff --git a/.gitbook/assets/image (64).png b/.gitbook/assets/image (64).png
diff --git a/.gitbook/assets/image (65).png b/.gitbook/assets/image (65).png
diff --git a/.gitbook/assets/image (66).png b/.gitbook/assets/image (66).png
diff --git a/.gitbook/assets/image (67).png b/.gitbook/assets/image (67).png
diff --git a/.gitbook/assets/image (68).png b/.gitbook/assets/image (68).png
diff --git a/.gitbook/assets/image (69).png b/.gitbook/assets/image (69).png
diff --git a/.gitbook/assets/image (7).png b/.gitbook/assets/image (7).png
diff --git a/.gitbook/assets/image (70).png b/.gitbook/assets/image (70).png
diff --git a/.gitbook/assets/image (71).png b/.gitbook/assets/image (71).png
diff --git a/.gitbook/assets/image (72).png b/.gitbook/assets/image (72).png
diff --git a/.gitbook/assets/image (73).png b/.gitbook/assets/image (73).png
diff --git a/.gitbook/assets/image (74).png b/.gitbook/assets/image (74).png
diff --git a/.gitbook/assets/image (75).png b/.gitbook/assets/image (75).png
diff --git a/.gitbook/assets/image (8).png b/.gitbook/assets/image (8).png
diff --git a/.gitbook/assets/image (9).png b/.gitbook/assets/image (9).png
diff --git a/SUMMARY.md b/SUMMARY.md
@@ -18,12 +18,12 @@
   * [06-DeltaFIFO](k8s-yuan-ma-ren-cai-fu-hua-xun-lian-ying/client-go/06-deltafifo.md)
   * [07-workqueue](k8s-yuan-ma-ren-cai-fu-hua-xun-lian-ying/client-go/07-workqueue.md)
   * [08-sharedProcessor](k8s-yuan-ma-ren-cai-fu-hua-xun-lian-ying/client-go/08-sharedprocessor.md)
-* [第二章 ：scheduler 源码](k8s-yuan-ma-ren-cai-fu-hua-xun-lian-ying/ren-zheng-shou-quan/schedule/README.md)
-  * [01-初识 Scheduler](k8s-yuan-ma-ren-cai-fu-hua-xun-lian-ying/ren-zheng-shou-quan/schedule/01-chu-shi-scheduler.md)
-  * [02-Schedule Framework](k8s-yuan-ma-ren-cai-fu-hua-xun-lian-ying/ren-zheng-shou-quan/schedule/02-schedule-framework.md)
-  * [03-Schedule 源码讲解](k8s-yuan-ma-ren-cai-fu-hua-xun-lian-ying/ren-zheng-shou-quan/schedule/03schedule-yuan-ma-jiang-jie.md)
-  * [04-Scheduler 二次开发](k8s-yuan-ma-ren-cai-fu-hua-xun-lian-ying/ren-zheng-shou-quan/schedule/04scheduler-er-ci-kai-fa.md)
-  * [05-nodeSelector,nodeAffinity](k8s-yuan-ma-ren-cai-fu-hua-xun-lian-ying/ren-zheng-shou-quan/schedule/05-nodeselector-nodeaffinity.md)
+* [第二章 ：scheduler 源码](k8s-yuan-ma-ren-cai-fu-hua-xun-lian-ying/schedule/README.md)
+  * [01-初识 Scheduler](k8s-yuan-ma-ren-cai-fu-hua-xun-lian-ying/schedule/01-chu-shi-scheduler.md)
+  * [02-Schedule Framework](k8s-yuan-ma-ren-cai-fu-hua-xun-lian-ying/schedule/02-schedule-framework.md)
+  * [03-Schedule 源码讲解](k8s-yuan-ma-ren-cai-fu-hua-xun-lian-ying/schedule/03schedule-yuan-ma-jiang-jie.md)
+  * [04-Scheduler 二次开发](k8s-yuan-ma-ren-cai-fu-hua-xun-lian-ying/schedule/04scheduler-er-ci-kai-fa.md)
+  * [05-nodeSelector,nodeAffinity](k8s-yuan-ma-ren-cai-fu-hua-xun-lian-ying/schedule/05-nodeselector-nodeaffinity.md)
 * [第三章： operator开发](k8s-yuan-ma-ren-cai-fu-hua-xun-lian-ying/operator/README.md)
   * [02-operator 二次开发背景](k8s-yuan-ma-ren-cai-fu-hua-xun-lian-ying/operator/02operator-er-ci-kai-fa-bei-jing.md)
   * [01-controller-runtime](k8s-yuan-ma-ren-cai-fu-hua-xun-lian-ying/operator/01-controller-runtime.md)

diff --git a/k8s-yuan-ma-ren-cai-fu-hua-xun-lian-ying/client-go/03-xie-yi-ge-kong-zhi-qi.md b/k8s-yuan-ma-ren-cai-fu-hua-xun-lian-ying/client-go/03-xie-yi-ge-kong-zhi-qi.md
@@ -4,7 +4,7 @@
 
 informer 设计之初是为了更好的写 controller，本章我们来手写一个 controller，下图是官方推荐的编程模式：
 
-<figure><img src="../../.gitbook/assets/image (2) (1) (1) (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../.gitbook/assets/image (32).png" alt=""><figcaption></figcaption></figure>
 
 * 控制器包含三部分： informer ，workqueue，control loop
 * informer 负责同步远端集群资源到本地缓存Indexer

diff --git a/k8s-yuan-ma-ren-cai-fu-hua-xun-lian-ying/client-go/05-indexer.md b/k8s-yuan-ma-ren-cai-fu-hua-xun-lian-ying/client-go/05-indexer.md
@@ -307,7 +307,7 @@ Indices: {
 }
 ```
 
-<figure><img src="../../.gitbook/assets/image (3) (1) (1).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../.gitbook/assets/image (30).png" alt=""><figcaption></figcaption></figure>
 
 了解了底层数据接口，我们再回过头来看看其暴露给外部的方法：
 

diff --git a/k8s-yuan-ma-ren-cai-fu-hua-xun-lian-ying/client-go/06-deltafifo.md b/k8s-yuan-ma-ren-cai-fu-hua-xun-lian-ying/client-go/06-deltafifo.md
@@ -1,6 +1,6 @@
 # 06-DeltaFIFO
 
-<figure><img src="../../.gitbook/assets/image (4) (1) (1).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../.gitbook/assets/image (34).png" alt=""><figcaption></figcaption></figure>
 
 DeltaFIFO本质上是一个先进先出的队列，有数据的生产者和消费者，其中生产者是Reflector调用的Add方法，消费者是Controller调用的Pop方法。下面分析DeltaFIFO的核心功能：
 
@@ -105,7 +105,7 @@ DeltaFIFO与其他队列最大的不同之处是，它会保留所有关于资
 
 queue字段存储资源对象的key，该key通过KeyOf函数计算得到。items字段通过map数据结构的方式存储，value存储的是对象的Deltas数组。DeltaFIFO存储结构如图所示。
 
-<figure><img src="../../.gitbook/assets/image (3) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../.gitbook/assets/image (33).png" alt=""><figcaption></figcaption></figure>
 
 ### 生产者
 

diff --git a/k8s-yuan-ma-ren-cai-fu-hua-xun-lian-ying/client-go/07-workqueue.md b/k8s-yuan-ma-ren-cai-fu-hua-xun-lian-ying/client-go/07-workqueue.md
@@ -1,6 +1,6 @@
 # 07-workqueue
 
-<figure><img src="../../.gitbook/assets/image (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../.gitbook/assets/image (27).png" alt=""><figcaption></figcaption></figure>
 
 今天我们来详细研究下 workqueue 相关代码。client-go 的 util/workqueue 包里主要有三个队列，分别是普通队列，延时队列，限速队列，后一个队列以前一个队列的实现为基础，层层添加新功能，我们按照 Queue、DelayingQueue、RateLimitingQueue 的顺序层层拨开来看限速队列是如何实现的。
 
@@ -419,7 +419,7 @@ func (r *TypedBucketRateLimiter[T]) Forget(item T) {
 
 ```
 
-<figure><img src="../../.gitbook/assets/image (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../.gitbook/assets/image (28).png" alt=""><figcaption></figcaption></figure>
 
 令牌桶算法内部实现了一个存放token（令牌）的“桶”，初始时“桶”是空的，token会以固定速率往“桶”里填充，直到将其填满为止，多余的token会被丢弃。每个元素都会从令牌桶得到一个token，只有得到token的元素才允许通过（accept），而没有得到token的元素处于等待状态。令牌桶算法通过控制发放token来达到限速目的。
 
@@ -474,7 +474,7 @@ func (r *TypedItemExponentialFailureRateLimiter[T]) Forget(item T) {
 
 排队指数算法将相同元素的排队数作为指数，排队数增大，速率限制呈指数级增长，但其最大值不会超过maxDelay。
 
-<figure><img src="../../.gitbook/assets/image (2) (1) (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../.gitbook/assets/image (29).png" alt=""><figcaption></figcaption></figure>
 
 ### 3.`TypedItemFastSlowRateLimiter` 和上面的指数级限速器很像，都是用于错误尝试的，但是二者的限速策略不同，`ItemFastSlowRateLimiter` 是尝试次数超过阈值后用长延迟，否则用短延迟，具体的实现如下所示：
 

diff --git a/k8s-yuan-ma-ren-cai-fu-hua-xun-lian-ying/client-go/08-sharedprocessor.md b/k8s-yuan-ma-ren-cai-fu-hua-xun-lian-ying/client-go/08-sharedprocessor.md
@@ -12,7 +12,7 @@
 
 下面 `sharedIndexInformer` 简化的实现原理架构图.
 
-<figure><img src="../../.gitbook/assets/image (5) (1) (1).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../.gitbook/assets/image (35).png" alt=""><figcaption></figcaption></figure>
 
 那 sharedIndexInformer 如何去通知多个 控制器呢？ 这里就用到了 shareProcessor
 

diff --git a/...n-cai-fu-hua-xun-lian-ying/controller-manager/4.1-controllermanager-jie-shao.md b/...n-cai-fu-hua-xun-lian-ying/controller-manager/4.1-controllermanager-jie-shao.md
@@ -10,7 +10,7 @@ description: controller
 
 比如当某个Pod出现故障时，Deployment Controller会及时发现故障并执行自动化修复流程，确保集群里的Pod始终处于预期的工作状态。
 
-<figure><img src="../../.gitbook/assets/image (1) (1) (1) (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../.gitbook/assets/image (22).png" alt=""><figcaption></figcaption></figure>
 
 ## 工作原理
 

diff --git a/...i-fu-hua-xun-lian-ying/controller-manager/4.12-statefulset-controller-fen-xi.md b/...i-fu-hua-xun-lian-ying/controller-manager/4.12-statefulset-controller-fen-xi.md
@@ -90,7 +90,7 @@ StatefulSet controller 是 kube-controller-manager 众多控制器中的一个
 
 StatefulSet controller 的大致组成和处理流程如下图，当事件发生时，控制器会watch到然后将对应的StatefulSet 对象放入到 queue 中，然后调用`syncStatefulSet`方法协调。
 
-<figure><img src="../../.gitbook/assets/image (2) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../.gitbook/assets/image (19).png" alt=""><figcaption></figcaption></figure>
 
 ### **pod 的命名规则、pod 创建与删除**
 
@@ -746,5 +746,5 @@ func (ssc *defaultStatefulSetControl) updateStatefulSet(
 }
 </code></pre>
 
-<figure><img src="../../.gitbook/assets/image (1) (1) (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../.gitbook/assets/image (20).png" alt=""><figcaption></figcaption></figure>
 
diff --git a/...ua-xun-lian-ying/controller-manager/4.13-daemonset-controller-yuan-ma-fen-xi.md b/...ua-xun-lian-ying/controller-manager/4.13-daemonset-controller-yuan-ma-fen-xi.md
@@ -84,7 +84,7 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
 
 daemonset controller的大致组成和处理流程如下图，daemonset controller对daemonset、pod、node、ControllerRevision对象注册了event handler，当有事件时，会watch到然后将对应的daemonset对象放入到queue中，然后`syncDaemonset`方法为daemonset controller调谐daemonset对象的核心处理逻辑所在，从queue中取出daemonset对象，做调谐处理。
 
-<figure><img src="../../.gitbook/assets/image (25).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../.gitbook/assets/image (55).png" alt=""><figcaption></figcaption></figure>
 
 ## 源码分析
 

diff --git a/k8s-yuan-ma-ren-cai-fu-hua-xun-lian-ying/controller-manager/4.16-k8s-gc.md b/k8s-yuan-ma-ren-cai-fu-hua-xun-lian-ying/controller-manager/4.16-k8s-gc.md
@@ -62,7 +62,7 @@ spec:
 * ReplicaSet 作为 Owner 的同时也同样作为 Dependent, 它的 Owner 为 Deployment, Dependent 为 3 个依赖它的 Pod
 * Deployment 作为 Owner, 它的 Dependent 为依赖的 ReplicaSet
 
-<figure><img src="../../.gitbook/assets/image (26).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../.gitbook/assets/image (56).png" alt=""><figcaption></figcaption></figure>
 
 ### 级联删除 （Cascading deletion） <a href="#cascading-deletion" id="cascading-deletion"></a>
 
@@ -123,11 +123,11 @@ kubectl delete deployment nginx-deployment --cascade=orphan
 
 本文着重从源代码的角度分析一下 GarbageCollector 的实现原理，GarbageCollector 功能对应的源代码位于 Kubernetes 项目的 `pkg/controller/garbagecollector/` 目录，本文以 Kubernetes `v1.30.0` 版本源代码进行分析。
 
-<figure><img src="../../.gitbook/assets/image (27).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../.gitbook/assets/image (57).png" alt=""><figcaption></figcaption></figure>
 
 ### GarbageCollector 架构图 <a href="#garbagecollector" id="garbagecollector"></a>
 
-<figure><img src="../../.gitbook/assets/image (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../.gitbook/assets/image (17).png" alt=""><figcaption></figcaption></figure>
 
 <pre class="language-go"><code class="lang-go"><strong>// GarbageCollector 对象表示垃圾回收控制器，是实现垃圾回收功能的核心对象。
 </strong><strong>// 通过 reflector 监视受管API对象的更改，将结果汇集到单线程的dependencyGraphBuilder中
@@ -161,7 +161,7 @@ B对应一个node，owner列表里有A，dependent列表里有C；
 C对应一个node，owner列表里有B，无dependent。  
 ```
 
-<figure><img src="../../.gitbook/assets/image (1) (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../.gitbook/assets/image (18).png" alt=""><figcaption></figcaption></figure>
 
 #### **2个处理器**
 

diff --git a/...ren-cai-fu-hua-xun-lian-ying/controller-manager/4.3-deployment-controller-01.md b/...ren-cai-fu-hua-xun-lian-ying/controller-manager/4.3-deployment-controller-01.md
@@ -131,7 +131,7 @@ kubectl rollout undo deployment &#x3C;deployment-name> --to-revision=&#x3C;revis
 
 ## 工作流程
 
-<figure><img src="../../.gitbook/assets/image (2) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../.gitbook/assets/image (21).png" alt=""><figcaption></figcaption></figure>
 
 dc 的 Informer 主要监听三种资源，Deployment，ReplicaSet，Pod。其中 Deployment，ReplicaSet 监听 Add, Update, Delete。 Pod 只监听 Delete 事件。
 

diff --git a/...ren-cai-fu-hua-xun-lian-ying/controller-manager/4.4-deployment-controller-02.md b/...ren-cai-fu-hua-xun-lian-ying/controller-manager/4.4-deployment-controller-02.md
@@ -127,7 +127,7 @@ func (m *ReplicaSetControllerRefManager) ClaimReplicaSets(ctx context.Context, s
 }
 ```
 
-<figure><img src="../../.gitbook/assets/image (20).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../.gitbook/assets/image (50).png" alt=""><figcaption></figcaption></figure>
 
 ### 怎么理解 adopt 和 release
 
@@ -209,7 +209,7 @@ According to the log of the first linked failure, and a local reproduction, the
 根据第一次链接失败的日志和本地复制，RS 不是孤立的，因为部署控制器重新采用了刚刚被垃圾收集器孤立的 RS。
 
 **I propose this fix: 我建议这个修复：**\
-To prevent the race, the deployment controller should get the latest deployment from API server and checks its deletionTimestamp, instead of checking its local cache, before [adopting](https://github.com/kubernetes/kubernetes/blob/master/pkg/controller/controller\_ref\_manager.go#L310) the RS. This can completely prevent re-adoption. Because if the deployment tries to adopt the RS, it means the RS lacks the controllerRef, which means the garbage collector has orphaned the RS, which means the deletionTimestamp must have already been set, so the proposed check will prevent the re-adoption. (but race for new-adoption is still possible)
+To prevent the race, the deployment controller should get the latest deployment from API server and checks its deletionTimestamp, instead of checking its local cache, before [adopting](https://github.com/kubernetes/kubernetes/blob/master/pkg/controller/controller_ref_manager.go#L310) the RS. This can completely prevent re-adoption. Because if the deployment tries to adopt the RS, it means the RS lacks the controllerRef, which means the garbage collector has orphaned the RS, which means the deletionTimestamp must have already been set, so the proposed check will prevent the re-adoption. (but race for new-adoption is still possible)
 
 
 

diff --git a/...ren-cai-fu-hua-xun-lian-ying/controller-manager/4.6-replicaset-controller-01.md b/...ren-cai-fu-hua-xun-lian-ying/controller-manager/4.6-replicaset-controller-01.md
@@ -12,7 +12,7 @@ replicaset controller主要作用是根据replicaset对象所期望的pod数量
 
 replicaset controller的大致组成和处理流程如下图，replicaset controller对pod和replicaset对象注册了event handler，当有事件时，会watch到然后将对应的replicaset对象放入到queue中，然后`syncReplicaSet`方法为replicaset controller调谐replicaset对象的核心处理逻辑所在，从queue中取出replicaset对象，做调谐处理。
 
-<figure><img src="../../.gitbook/assets/image (21).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../.gitbook/assets/image (51).png" alt=""><figcaption></figcaption></figure>
 
 ### 初始化与启动分析 <a href="#replicasetcontroller-de-chu-shi-hua-yu-qi-dong-fen-xi" id="replicasetcontroller-de-chu-shi-hua-yu-qi-dong-fen-xi"></a>
 

diff --git a/...ren-cai-fu-hua-xun-lian-ying/controller-manager/4.7-replicaset-controller-02.md b/...ren-cai-fu-hua-xun-lian-ying/controller-manager/4.7-replicaset-controller-02.md
@@ -1,6 +1,6 @@
 # 4.7 replicaset controller 02
 
-<figure><img src="../../.gitbook/assets/image (22).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../.gitbook/assets/image (52).png" alt=""><figcaption></figcaption></figure>
 
 replicaset controller分析分为3大块进行，分别是：&#x20;
 
@@ -687,4 +687,4 @@ func updateReplicaSetStatus(logger klog.Logger, c appsclient.ReplicaSetInterface
 }
 ```
 
-<figure><img src="../../.gitbook/assets/image (23).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../.gitbook/assets/image (53).png" alt=""><figcaption></figcaption></figure>
diff --git a/...i-fu-hua-xun-lian-ying/di-wu-zhang-apimachinery/5.2-shen-me-shi-apimachinery.md b/...i-fu-hua-xun-lian-ying/di-wu-zhang-apimachinery/5.2-shen-me-shi-apimachinery.md
@@ -55,7 +55,7 @@ K8s 之前，基础设施基本上是各种不同 API、格式和语义的“云
 
 这些 API 是跨公有云/私有云和各家云厂商的，各云厂商会将 Kubernetes 结构和语义 对接到它们各自的原生 API。 因此我们可以说，Kubernetes 提供了一种**管理软件定义基础设施（也就是云）的标准接口**。 或者说，Kubernetes 是一个针对云服务（cloud services）的标准 API 框架。
 
-<figure><img src="../../.gitbook/assets/image (2) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../.gitbook/assets/image (16).png" alt=""><figcaption></figcaption></figure>
 
 ## apimachinery
 

diff --git a/k8s-yuan-ma-ren-cai-fu-hua-xun-lian-ying/operator/01-controller-runtime.md b/k8s-yuan-ma-ren-cai-fu-hua-xun-lian-ying/operator/01-controller-runtime.md
@@ -8,13 +8,13 @@ Operator 是 Kubernetes 用来拓展其 API 的一种开发范式（Pattern）
 
 controller-runtime 这个包的内容不少，为了在一篇文章里能覆盖到，本文仅选取在构建 Operator 过程中起关键作用的包进行介绍，`envtest`、`scheme`、`certwatcher` 等同样重要的包就不在此提及。下面是我读代码时画的意识流思维导图，有的子项目是组成结构，有的子项目是工作角色，比较自由灵活。我选取了 `Cache`,`Source`, `Handler`, `Client`, `Controller` 和 `Manager` 这六个包
 
-<figure><img src="../../.gitbook/assets/image (11).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../.gitbook/assets/image (41).png" alt=""><figcaption></figcaption></figure>
 
 ## WorkFlow
 
 对于控制器而言，资源发生变动的信息均来自于 API Server，从资源发生变动到控制器完成调解需要经过多个模块的处理，大体来说可以用下面的图来表示。
 
-<figure><img src="../../.gitbook/assets/image (12).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../.gitbook/assets/image (42).png" alt=""><figcaption></figcaption></figure>
 
 ## Cache <a href="#cache" id="cache"></a>
-Original file line number
+Diff line change
@@ Expand Up / @@ -307,7 +307,7 @@ Indices: { @@
     }
     ```
-    <figure><img src="../../.gitbook/assets/image (3) (1) (1).png" alt=""><figcaption></figcaption></figure>
+    <figure><img src="../../.gitbook/assets/image (30).png" alt=""><figcaption></figcaption></figure>
     了解了底层数据接口，我们再回过头来看看其暴露给外部的方法：
@@ Expand Down @@