fix typing

Author: Zhang Jun

client-go/1.store-indexer-lister-cache.md

@@ -179,7 +179,7 @@ type DeploymentLister interface {
 
 `ThreadSafeStore` 本身没有实现 `Indexer` 和 `Store` 接口，但包含同名方法。
 
-后文会介绍，`struct cache` 类型内部使用 `ThreadSafeStore` 实现了 `Indexer` 和 `Store` 接口。
+后文会介绍，`struct cache` 类型内部使用 `ThreadSafeStore` 实现了 `Indexer` 和 `Store` 接口。
 
 ``` go
 // 来源于 k8s.io/client-go/tools/cache/thread_safe_store.go
@@ -292,15 +292,15 @@ func (c *threadSafeMap) updateIndices(oldObj interface{}, newObj interface{}, ke
 }
 ```
 
-`Delete()` 方法先后从索引缓存和对象缓存中删除对象。`deleteFromIndices()` 方法遍历 `c.indexers` 中的索引函数，为对象计算索引值列表，然后再从索引缓存和对象缓存中删除该对象：
+`Delete()` 方法先后从索引缓存和对象缓存中删除对象。`deleteFromIndices()` 方法遍历 `c.indexers` 中的索引函数，为对象计算索引值列表，然后再从索引缓存和对象缓存中删除该对象：
 
 ``` go
 // 来源于 k8s.io/client-go/tools/cache/thread_safe_store.go
 func (c *threadSafeMap) Delete(key string) {
 	c.lock.Lock()
 	defer c.lock.Unlock()
 	if obj, exists := c.items[key]; exists {
-		// 从索引缓存中删除对象
+		// 从索引缓存中删除对象
 		c.deleteFromIndices(obj, key)
 		// 从对象缓存中删除对象
 		delete(c.items, key)
@@ -362,7 +362,7 @@ func (c *threadSafeMap) Replace(items map[string]interface{}, resourceVersion st
 
 ## KeyFunc 和实现 Store/Indexer 接口的 cache
 
-在介绍 `struct cache` 类型之前，我们先介绍为对象生成唯一标识 Key 的函数类型 `KeyFunc`：
+在介绍 `struct cache` 类型之前，我们先介绍为对象生成唯一标识 Key 的函数类型 `KeyFunc`：
 
 ``` go
 // 来源于 k8s.io/client-go/tools/cache/store.go
@@ -429,7 +429,7 @@ func NewStore(keyFunc KeyFunc) Store {
 
 在分析 `ThreadSafeStore` 接口时提到过，它的方法如 `Add/Update/Delete/Get()` 都**需要传入**对象的 Key。
 
-而 `cache` 则封装了 `ThreadSafeStore` 和 `KeyFunc`，后者为添加到 `cacheStorage` 的对象生成 Key：
+而 `cache` 则封装了 `ThreadSafeStore` 和 `KeyFunc`，后者为添加到 `cacheStorage` 的对象生成 Key：
 
 ``` go
 // 来源于 k8s.io/client-go/tools/cache/store.go

client-go/2.queue-fifo-delta_fifo.md

@@ -26,15 +26,15 @@ type Queue interface {
 }
 ```
 
-导出函数 `Pop()` 从传入的 Queue 弹出一个对象。
+导出函数 `Pop()` 从传入的 Queue 弹出一个对象。
 
 ## FIFO 实现了 Queue/Store 接口
 
-FIFO 类型(struct 类型，非接口)实现了 Queue/Store 接口，对象被 Pop 的顺序与加入的顺序一致，所以是先入先出(FIFO)。
+FIFO 类型(struct 类型，非接口)实现了 Queue/Store 接口，对象被 Pop 的顺序与加入的顺序一致，所以是先入先出(FIFO)。
 
-但是位于 FIFO 中的某个对象在没有被 Pop 前，如果有多次对它的 `Add/Update()` 操作，FIFO 只会缓存它的最新值，而且该对象只会被 Pop 一次。
+但是位于 FIFO 中的某个对象在没有被 Pop 前，如果有多次对它的 `Add/Update()` 操作，FIFO 只会缓存它的最新值，而且该对象只会被 Pop 一次。
 
-例如 FIFO 中对象 A 的值为 a1，在被 Pop 前，两次更新值分别为  a2, a3，则 Pop 只会返回最新值 a3。
+例如 FIFO 中对象 A 的值为 a1，在被 Pop 前，两次更新值分别为  a2, a3，则 Pop 只会返回最新值 a3。
 
 所以，FIFO 只会缓存对象的**一个值，而且是最新值**。
 
@@ -152,15 +152,15 @@ func (f *FIFO) Delete(obj interface{}) error {
 }
 ```
 
-由于**没有**从 Pop 队列(f.queue) 中移除该对象，如果先 Add/Update 对象，在 Pop 前又 Delete 该对象，则弹出队列中还有该对象的 Key 记录，Pop 遇到这种情况时**会跳过**，继续 Pop 下一个对象。所以 FIFO **不会缓存和 Pop 删除的对象**。
+由于**没有**从 Pop 队列(f.queue) 中移除该对象，如果先 Add/Update 对象，在 Pop 前又 Delete 该对象，则弹出队列中还有该对象的 Key 记录，Pop 遇到这种情况时**会跳过**，继续 Pop 下一个对象。所以 FIFO **不会缓存和 Pop 删除的对象**。
 
 ### `Pop()` 方法
 
 返回弹出队列(f.queue) 中的对象，如果 f.queue 为空，则一直阻塞。
 
-Pop 先从弹出队列(f.queue)移除对象，然后从对象缓存(f.items)中删除对象，接着调用 process 函数，如果该函数执行失败，则应该返回 `ErrRequeue` 类型的错误，这时该对象会被**重新加回** FIFO，后续可以再次被弹出处理。
+Pop 先从弹出队列(f.queue)移除对象，然后从对象缓存(f.items)中删除对象，接着调用 process 函数，如果该函数执行失败，则应该返回 `ErrRequeue` 类型的错误，这时该对象会被**重新加回** FIFO，后续可以再次被弹出处理。
 
-`Pop()` 是在对 FIFO 加锁的情况下调用传入的 process 函数，所以可以在多个 goroutine 中**并发调用** `Pop()` 方法。
+`Pop()` 是在对 FIFO 加锁的情况下调用传入的 process 函数，所以可以在多个 goroutine 中**并发调用** `Pop()` 方法。
 
 ``` go
 // 来源于 k8s.io/client-go/tools/cache/fifo.go
@@ -314,7 +314,7 @@ func NewDeltaFIFO(keyFunc KeyFunc, knownObjects KeyListerGetter) *DeltaFIFO {
 
 ### DeltaFIFO 的生产者和消费者
 
-后续文章会介绍，创建各种 `Informer`（如 `Informer、IndexInformer、SharedInformer、SharedIndexInformer`）时，初始化函数会依次创建 `knownObjects` 缓存、`DeltaFIO` 和 [`controller`](4.controller-informer.md)。`controller` 再将 `DeltaFIFO` 传给 [Reflector](3.reflector.md)，**Reflector 的 `ListAndWatch()` 方法是 DeltaFIFO 的生产者**：
+后续文章会介绍，创建各种 `Informer`（如 `Informer、IndexInformer、SharedInformer、SharedIndexInformer`）时，初始化函数会依次创建 `knownObjects` 缓存、`DeltaFIO` 和 [`controller`](4.controller-informer.md)。`controller` 再将 `DeltaFIFO` 传给 [Reflector](3.reflector.md)，**Reflector 的 `ListAndWatch()` 方法是 DeltaFIFO 的生产者**：
 
 1. List etcd 中(通过 kube-apiserver，下同)特定类型的所有对象，然后调用 DeltaFIFO 的 `Replace()` 方法，将他们同步到 DeltaFIFO；
 2. 根据配置的 Resync 时间，**周期调用** DeltaFIFO 的 `Resync()` 方法（见后文），将 knownObjects 中的对象更新到 DeltaFIFO 中；
@@ -364,7 +364,7 @@ func (f *DeltaFIFO) Add(obj interface{}) error {
 }
 ```
 
-`Update()` 方法和 `Add()` 方法类似，差别在于产生的是 `Updated` Delta 类型事件；
+`Update()` 方法和 `Add()` 方法类似，差别在于产生的是 `Updated` Delta 类型事件；
 
 ### queueActionLocked() 方法
 
@@ -406,7 +406,7 @@ func (f *DeltaFIFO) queueActionLocked(actionType DeltaType, obj interface{}) err
 
 如果 `f.knownObjects` 对象缓存和事件队列 `f.items` 中均没有待删除的对象，则**直接返回**，否则为对象生成 `Deleted` Delta 事件(非`DeletedFinalStateUnknown` 类型)。
 
-不同于 FIFO 的 Deleta() 方法会将对象从缓存中删除，DeltaFIFO 的 Delete() 方法**不将对象从事件缓存 f.items 和弹出队列 f.queue 删除**。而是由 DeltaFIFO 的消费者 `controller` 根据弹出的 Deltas 对象，将对象从对象缓存 f.knownObjects 中删除。
+不同于 FIFO 的 Deleta() 方法会将对象从缓存中删除，DeltaFIFO 的 Delete() 方法**不将对象从事件缓存 f.items 和弹出队列 f.queue 删除**。而是由 DeltaFIFO 的消费者 `controller` 根据弹出的 Deltas 对象，将对象从对象缓存 f.knownObjects 中删除。
 
 ### Get/GetByKey/List/ListKeys() 方法
 

client-go/3.reflector.md

@@ -1,5 +1,16 @@
 # kubernetes 事件反射器
 
+``` go
+func (r *Reflector) Run(stopCh <-chan struct{}) {
+	klog.V(3).Infof("Starting reflector %v (%s) from %s", r.expectedType, r.resyncPeriod, r.name)
+	wait.Until(func() {
+		if err := r.ListAndWatch(stopCh); err != nil {
+			utilruntime.HandleError(err)
+		}
+	}, r.period, stopCh)
+}
+```
+
 ``` go
 func (r *Reflector) ListAndWatch(stopCh <-chan struct{}) error {
     ...
@@ -38,6 +49,13 @@ func (r *Reflector) ListAndWatch(stopCh <-chan struct{}) error {
 
     for {
         ...
+        // Watch 会在 timeoutSeconds 后超时，这时 r.watchHandler() 出错，ListAndWatch() 方法出错返回
+        // 这时 Reflecter 会等待 r.period 事件后重新执行 ListAndWatch() 方法；
+        timeoutSeconds := int64(minWatchTimeout.Seconds() * (rand.Float64() + 1.0))
+		options = metav1.ListOptions{
+			ResourceVersion: resourceVersion,
+			TimeoutSeconds: &timeoutSeconds,
+		}
         w, err := r.listerWatcher.Watch(options)
         ...
         if err := r.watchHandler(w, &resourceVersion, resyncerrc, stopCh); err != nil {