作為云原生開發(fā)人員難免會給 kubernetes client-go 打交道，但是有許多坑總是一遍又一遍的被開發(fā)者踩到，下面梳理常見的坑，希望大家注意避免：

informer cache中的數據是只讀的， 任何修改都先deepcopy

informer cache中的數據是只讀的， 任何修改都應該先deepcopy出來，然后提交apiserver, 利用apiserver informer event重新同步回cache中。 如果直接修改cache中的數據，就會出現(xiàn)數據不一致， 程序表現(xiàn)異常， 更嚴重的是， cache中底層實現(xiàn)是一個非線程安全的map, 如果多個groutine 并發(fā)讀寫map的現(xiàn)象, 程序直接fatal, 且不可recover。

更新資源需要RetryOnConflict

kubernetes 中的資源并發(fā)更新模型是樂觀鎖的機制， 每個資源都有一個單調遞增的resourceVersion。 當客戶端發(fā)送一個修改操作時，會攜帶resoruceVersion， apiserver收到請求進行修改之前會判斷該version 是否小于最新的resourceVersion，如果小于就意味著這個資源已經被其他人修改，返回409 錯誤碼，并提示需要沖突重試。 客戶端收到該錯誤后需要進行重試， 目前kubernetes已經封裝好對應的庫， retry.RetryOnConflict。具體使用案例可以參見； Golang retry.RetryOnConflict函數代碼示例

client-go 中訪問apiserver 默認QPS 為5

kubernetes client-go 會默認進行客戶端限流， 訪問apiserver的默認并發(fā)為5。 對于一些并發(fā)比較大的服務來說，顯然是不可接受的， 經常會出現(xiàn)一個服務上線時表現(xiàn)正常， 但是突然某一天出現(xiàn)超時，反應變慢。這時候就需要考慮是不是因為訪問apiserver被限流了。

創(chuàng)建client時傳遞的 rest.Config可以進行配置客戶端并發(fā)度。客戶端限流底層實現(xiàn)是一個令牌桶， 通過兩個參數來調節(jié): 1). QPS: 表示每秒加入桶的token數量，用于控制并發(fā) 2). Burst：表示桶的大小，控制允許的激增請求量。 其中Burst需要設置的比QPS 大，Client-go不會校驗該參數。 具體的數值根據服務負載和apiserver的負載進行權衡。

當發(fā)生客戶端限流時，其實klog是會打印throttling字樣，注意觀察日志定位改問題。

Informer中cache 可以自定義索引

informer 底層是默認是根據namespace/name為key存儲在map里的， 雖然Infomer中內嵌的Lister提供了List(selector labels.Selector) 方法， 但是該方法只是list所有元素之后再進行過濾， 如果元素較多會導致處理時間較長。

可以通過構建索引來優(yōu)化訪問速度：

1). 添加索引： 需要傳入一個生成索引key的函數

2). 使用索引：

這樣我們就可以根據某個label value構建索引，快速地從Informer cache中獲取結果。

List 資源時指定resourceVersion=0將從apiserver cache中獲取

當前我們集群里有大量的資源，如果有l(wèi)ist請求， 可以顯式指定metav1.ListOptions{ResourceVersion: 0} ， 這樣可以請求直接從apiserver的cache中返回， 不會穿透到etcd中。 不僅可以保護etcd，而且能夠更快返回。k8s informer在啟動的時候resourceVersion即為0。

Informer ResyncPeriod

我們在編寫controller的時候，會注冊informer event handler, 在產生event的時候進行一些reconcile操作，這是基于事件觸發(fā)。 除了事件觸發(fā)外，健壯的程序也需要基于時間的定期觸發(fā)，定期全量reconcile, 防止丟失某些event, 或者其他錯誤，相當于一種定期補償。

在創(chuàng)建informer的時候可以指定resyncPeriod, 該參數就是用于控制informer多久全量resync一次，resync時會將informer cache中的所有資源調用OnUpdateEventHandler， 不會請求apiserver。此時傳遞進來的參數 oldObjectResourceVersion==newObj.ResourceVersion， 使用者可以根據resourceVersion來判斷是真正的update event還是由于resync觸發(fā)的update event。

kubernetes 中controlle-manager中的cnotroller默認是： 12h~24h的一個隨機數。

controller workqueue

在編寫controller時， 一種約定俗稱的規(guī)范是在Informer的event handler中將需要處理的resource 加入一個workqueue中， 而不是直接在event handler中處理，這樣做的好處很多:

1. 隊列最重要的作用是防止同一個資源被多個groutine同時處理，防止沖突
2. 隊列提供了很多高級的功能， 例如 rate limit, delay retry等功能
3. 隊列具體削峰填谷的作用， 在變更較為頻繁時， event較多， 利用隊列可以將同一個資源的多次event 緩沖合并成一次reconcile。 而且可以創(chuàng)建多個消費者處理。

盡量使用shardInformer

每種資源類型都有獨立的informer, 但是建議還是使用shardInformer, shardInformer的多個使用方底層復用一個informer, 可以節(jié)省很多資源，例如可以降低apiserver壓力： 對apiserver的連接數， apiserver 資源序列化開銷， 客戶端的cache內存占用開銷。

ContentType 設置為 PB

可以設置如下：

1 conf := &rest.Config{
2         Host:        "https://9.134.163.198:6443",
3         QPS:         10000,
4         Burst:       100000,
5         ContentConfig: rest.ContentConfig{
6             ContentType: "application/vnd.kubernetes.protobuf",
7         },
8 }

這樣可以極大的加快請求的耗時， 尤其是用Informer list 很多資源的時候， PB相對于json 更快的壓縮速度， 和更大的壓縮比。當前默認設置為json, 需要手動設置 contentType為 protobuf。 注意CRD 不能設置CotentType=PB ， 因為CRD 沒有實現(xiàn)對應protobuf marshal interface。創(chuàng)建的時候會報錯如下： “object xxxx does not implement the protobuf marshaling interrace and cannot be encoded to a protobuf message"

ClientConfig設置Timeout

顯式設置ClientConfig timeout，目前創(chuàng)建的k8s client 底層用的是http2協(xié)議， 會復用connection， 如果網絡抖動， 會導致connection hang死， 需要等很久底層操作系統(tǒng)將鏈接重置之后應用層才能恢復，如果是http1協(xié)議的話， 因為每個請求都是發(fā)送一個新的出去， 如果網絡問題會直接返回失敗。 為了避免底層過長的超時時間，我們可以手動設置一個短一點的超時時間。

SharedInformer WaitForCacheSync 返回并不代表 eventHandler 執(zhí)行完畢

我們使用informer的典型的一個順序是 1).注冊各種 eventHandler 2). 啟動sharedInformer 3). 等待Informer 同步完成

往往我們認為 informer 同步完成對應的eventHander 也被調用成功， 但實際上并不是如此。ShardInformer 中的WaitForCacheSync 返回只是代表對應的事件已經分發(fā)下去了， eventHandler 是異步執(zhí)行的， 并不保證執(zhí)行時間。 sharedInfomer 往往會注冊多個eventHandler , 如果是同步執(zhí)行的話， 某個Handler 處理的特別慢的話會影響其他handler 的及時被調用, 所以每個handler 都是異步執(zhí)行的。對于一些嚴重依賴handler 執(zhí)行的邏輯需要特別小心， 例如我們維護了一個cache, 在每次有event 的時候更新這個cache, 當WaitForCacheSync 返回的時候我們不能直接開始執(zhí)行業(yè)務邏輯，去讀取這個cache, 很可能這個cache 還沒有完全執(zhí)行完畢。但是對于單個informer， WaitForCacheSync 執(zhí)行完畢后，eventHandler 也執(zhí)行完畢了。

并發(fā)更新 CRD 造成全量更新relist

高并發(fā)更新/增加很容易導致apiserver的watchCache的緩存被穿透，從而導致所有連接其上的informer 在rewatch時出現(xiàn)“too old resource version”，從而引發(fā)relist動作，加劇Apiserver的內存劇增。

Informer EventHandler 中Ondelete的時候 需要判斷DeletedFinalStateUnknown

在Informer EventHandler 中OnDelete 被調用的時候， 需要判斷 DeletedFinalStateUnknown 狀態(tài)， 典型的使用場景如下：

DeletedFinalStateUnknown 一般出現(xiàn)在由于網絡中斷等原因導致informer 本地cache 和apiserver 不一致， 等informer relist的時候發(fā)現(xiàn)informer cache中存在這個Object, 但是apiserver 沒有， 就會觸發(fā)一個DeletedFinalStateUnknown。 使用者需要顯式的轉換會原來的對象。

Reference:

Writing Controllers