## 關於我們

更多關於雲原生的案例和知識，可關注同名【騰訊雲原生】公眾號~

#### 福利：

①公眾號後臺回覆【手冊】，可獲得《騰訊雲原生路線圖手冊》&《騰訊雲原生最佳實踐》~

②公眾號後臺回覆【系列】，可獲得《15個系列100+篇超實用雲原生原創乾貨合集》，包含Kubernetes 降本增效、K8s 效能最佳化實踐、最佳實踐等系列。

③公眾號後臺回覆【白皮書】，可獲得《騰訊雲容器安全白皮書》&《降本之源-雲原生成本管理白皮書v1.0》

④公眾號後臺回覆【光速入門】，可獲得騰訊雲專家5萬字精華教程，光速入門Prometheus和Grafana。

## 作者
王成，騰訊雲研發工程師，Kubernetes member，從事資料庫產品容器化、資源管控等工作，關注 Kubernetes、Go、雲原生領域。

#### 目錄

1.概述

2.從 HTTP 說起

2.1 Content-Length
    
   2.2 Chunked Transfer Encoding
    
   2.3 HTTP/2
 
3.APIServer 啟動

4.ETCD 資源封裝

5.客戶端 Watch 實現

6.服務端 Watch 實現

7.小結

## 概述
進入 K8s 的世界，會發現幾乎所有物件都被抽象為了資源(Resource)，包括 K8s Core Resources(Pod, Service, Namespace 等)、CRD、APIService 擴充套件的資源型別。同時 K8s 底層將這些資源統一抽象為了 RESTful 的儲存(Storage)，一方面服務端按目錄形式(/registry/xxx) 存放在 ETCD 中，另一方面也為客戶端提供了 RESTful API 介面，便於對資源的操作(get/post/put/patch/delete 等)。

K8s Watch API 就是為資源提供的一種持續監聽其變化的機制，當資源有任何變化的時候，都可以實時、順序、可靠的傳遞給客戶端，使得使用者可以針對目標資源進行靈活應用與操作。

那 K8s Watch 機制是怎麼實現的呢？底層具體依賴了哪些技術？

本文將從 HTTP 協議、APIServer 啟動、ETCD Watch 封裝、服務端 Watch 實現、客戶端 Watch 實現等方面，對 K8s Watch 實現機制進行了解析。

流程概覽如下：

![](https://qcloudimg.tencent-cloud.cn/raw/bf5d8a517093f65234f242ec3ff28406.png)

> 本文及後續相關文章都基於 K8s v1.23

## 從 HTTP 說起
### Content-Length
如下圖所示，HTTP 傳送請求 Request 或服務端 Response，會在 HTTP header 中攜帶 Content-Length，以表明此次傳輸的總資料長度。如果 Content-Length 長度與實際傳輸長度不一致，則會發生異常(大於實際值會超時, 小於實際值會截斷並可能導致後續的資料解析混亂)。

```
curl baidu.com -v

> GET / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: baidu.com
> Accept: */*

< HTTP/1.1 200 OK
< Date: Thu, 17 Mar 2022 04:15:25 GMT
< Server: Apache
< Last-Modified: Tue, 12 Jan 2010 13:48:00 GMT
< ETag: "51-47cf7e6ee8400"
< Accept-Ranges: bytes
< Content-Length: 81
< Cache-Control: max-age=86400
< Expires: Fri, 18 Mar 2022 04:15:25 GMT
< Connection: Keep-Alive
< Content-Type: text/html

```

如果服務端提前不知道要傳輸資料的總長度，怎麼辦？

### Chunked Transfer Encoding
HTTP 從 1.1 開始增加了分塊傳輸編碼（Chunked Transfer Encoding），將資料分解成一系列資料塊，並以一個或多個塊傳送，這樣伺服器可以傳送資料而不需要預先知道傳送內容的總大小。資料塊長度以十六進位制的形式表示，後面緊跟著 \r\n，之後是分塊資料本身，後面也是 \r\n，終止塊則是一個長度為 0 的分塊。

```
> GET /test HTTP/1.1
> Host: baidu.com
> Accept-Encoding: gzip

< HTTP/1.1 200 OK
< Server: Apache
< Date: Sun, 03 May 2015 17:25:23 GMT
< Content-Type: text/html
< Transfer-Encoding: chunked
< Connection: keep-alive
< Content-Encoding: gzip

4\r\n        (bytes to send)
Wiki\r\n     (data)
6\r\n        (bytes to send)
pedia \r\n   (data)
E\r\n        (bytes to send)
in \r\n
\r\n
chunks.\r\n  (data)
0\r\n        (final byte - 0)
\r\n         (end message)
```

為了實現以流（Streaming）的方式 Watch 服務端資源變更，HTTP1.1 Server 端會在 Header 裡告訴 Client 要變更 Transfer-Encoding 為 chunked，之後進行分塊傳輸，直到 Server 端傳送了大小為 0 的資料。

### HTTP/2

HTTP/2 並沒有使用 Chunked Transfer Encoding 進行流式傳輸，而是引入了以 Frame(幀) 為單位來進行傳輸，其資料完全改變了原來的編解碼方式，整個方式類似很多 RPC協議。Frame 由二進位制編碼，幀頭固定位置的位元組描述 Body 長度，就可以讀取 Body 體，直到 Flags 遇到 END_STREAM。這種方式天然支援服務端在 Stream 上傳送資料，不需要通知客戶端做什麼改變。

```
+-----------------------------------------------+
|                 Body Length (24)                   | ----Frame Header
+---------------+---------------+---------------+
|   Type (8)    |   Flags (8)   |
+-+-------------+---------------+-------------------+
|R|                 Stream Identifier (31)          |
+=+=================================================+
|                   Frame Payload (0...)        ...    ----Frame Data
+---------------------------------------------------+
```
K8s 為了充分利用 HTTP/2 在 Server-Push、Multiplexing 上的高效能 Stream 特性，在實現 RESTful Watch 時，提供了 HTTP1.1/HTTP2 的協議協商(ALPN, Application-Layer Protocol Negotiation) 機制，在服務端優先選中 HTTP2，協商過程如下：
```
curl  https://{kube-apiserver}/api/v1/watch/namespaces/default/pods/mysql-0 -v

* ALPN, offering h2
* ALPN, offering http/1.1
* SSL verify...
* ALPN, server accepted to use h2
* Using HTTP2, server supports multiplexing
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7f2b921a6a90)
> GET /api/v1/watch/namespaces/default/pods/mysql-0 HTTP/2
> Host: 9.165.12.1
> user-agent: curl/7.79.1
> accept: */*
> authorization: Bearer xxx
> 
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* Connection state changed (MAX_CONCURRENT_STREAMS == 250)!

< HTTP/2 200 
< cache-control: no-cache, private
< content-type: application/json
< date: Thu, 17 Mar 2022 04:46:36 GMT

{"type":"ADDED","object":{"kind":"Pod","apiVersion":"v1","metadata":xxx}}
```

## APIServer 啟動
APIServer 啟動採用 Cobra 命令列，解析相關 flags 引數，經過 Complete(填充預設值)->Validate(校驗) 邏輯後，透過 Run 啟動服務。啟動入口如下：
```go
// kubernetes/cmd/kube-apiserver/app/server.go
// NewAPIServerCommand creates a *cobra.Command object with default parameters
func NewAPIServerCommand() *cobra.Command {
   s := options.NewServerRunOptions()
   cmd := &cobra.Command{
      Use: "kube-apiserver",
      ...
      RunE: func(cmd *cobra.Command, args []string) error {
         ...
         // set default options
         completedOptions, err := Complete(s)
         if err != nil {
            return err
         }

// validate options
         if errs := completedOptions.Validate(); len(errs) != 0 {
            return utilerrors.NewAggregate(errs)
         }

return Run(completedOptions, genericapiserver.SetupSignalHandler())
      },
   }
   ...

return cmd
}
```
在 Run 函式中，按序分別初始化 APIServer 鏈(APIExtensionsServer、KubeAPIServer、AggregatorServer)，分別服務於 CRD(使用者自定義資源)、K8s API(內建資源)、API Service(API 擴充套件資源) 對應的資源請求。相關程式碼如下：
```go
// kubernetes/cmd/kube-apiserver/app/server.go
// 建立 APIServer 鏈(APIExtensionsServer、KubeAPIServer、AggregatorServer)，分別服務 CRD、K8s API、API Service
func CreateServerChain(completedOptions completedServerRunOptions, stopCh  K8s APIServer 為了安全考慮，只支援客戶端 HTTPS 請求，不支援 HTTP。

## ETCD 資源封裝
ETCD 實現 Watch 機制，經歷了從 ETCD2 到 ETCD3 實現方式的轉變。ETCD2 透過長輪詢 Long-Polling 的方式監聽資源事件的變更；ETCD3 則透過基於 HTTP2 的 gRPC 實現 Watch stream，效能得到了很大的提升。

> Polling(輪詢)：由於 http1.x 沒有服務端 push 的機制，為了 Watch 服務端的資料變化，最簡單的辦法當然是客戶端去 pull：客戶端每隔定長時間去服務端拉資料同步，無論服務端有沒有資料變化。但是必然存在通知不及時和大量無效的輪詢的問題。
> 
> Long-Polling(長輪詢)：就是在這個 Polling 的基礎上的最佳化，當客戶端發起 Long-Polling 時，如果服務端沒有相關資料，會 hold 住請求，直到服務端有資料要發或者超時才會返回。

在上一步配置 APIServerConfig 時，封裝了底層儲存用的 ETCD。以 kubeAPIServerConfig 為例，說明 K8s 內建資源是如何封裝 ETCD 底層儲存的。

首先，透過 buildGenericConfig 例項化 RESTOptionsGetter，用於封裝 RESTStorage。之後透過 InstallLegacyAPI -> NewLegacyRESTStorage 例項化 K8s 內建資源的 RESTStorage，包括 podStorage、nsStorage、pvStorage、serviceStorage 等，用於 APIServer 在處理客戶端資源請求時，呼叫的後端資源儲存。

InstallLegacyAPI 原始碼如下：
```go
// kubernetes/pkg/controlplane/instance.go
// 註冊 K8s 的內建資源，並封裝到對應的 RESTStorage(如 podStorage/pvStorage)
func (m *Instance) InstallLegacyAPI(c *completedConfig, restOptionsGetter generic.RESTOptionsGetter) error {
   ...
   legacyRESTStorage, apiGroupInfo, err := legacyRESTStorageProvider.NewLegacyRESTStorage(c.ExtraConfig.APIResourceConfigSource, restOptionsGetter)
   if err != nil {
      return fmt.Errorf("error building core storage: %v", err)
   }
   if len(apiGroupInfo.VersionedResourcesStorageMap) == 0 { // if all core storage is disabled, return.
      return nil
   }

controllerName := "bootstrap-controller"
   coreClient := corev1client.NewForConfigOrDie(c.GenericConfig.LoopbackClientConfig)
   bootstrapController, err := c.NewBootstrapController(legacyRESTStorage, coreClient, coreClient, coreClient, coreClient.RESTClient())
   if err != nil {
      return fmt.Errorf("error creating bootstrap controller: %v", err)
   }
   m.GenericAPIServer.AddPostStartHookOrDie(controllerName, bootstrapController.PostStartHook)
   m.GenericAPIServer.AddPreShutdownHookOrDie(controllerName, bootstrapController.PreShutdownHook)

...
   return nil
}
```
在例項化 ETCD 底層儲存中，透過開關 EnableWatchCache 來控制是否啟用 Watch 快取。如果啟用了，則會先走 StorageWithCacher 邏輯，然後才走 UndecoratedStorage 真正呼叫底層 ETCD3 儲存。

> K8s 當前只支援 ETCD3，不再支援 ETCD2。K8s 充分信任 ETCD3 的 Watch 機制，保證資源狀態與 ETCD 底層儲存的一致性。

整個呼叫過程如下：

![](https://qcloudimg.tencent-cloud.cn/raw/e2acfc5b5b987bc02f4241a0242cc490.png)

> K8s 各類資源(CRD/Core/Aggregator) 都統一以 RESTful 風格暴露 HTTP 請求介面，並支援多種型別的編解碼格式，如 json/yaml/protobuf。

## 客戶端 Watch 實現
經過上面的步驟，APIServer 服務端已準備好 K8s 各類資源的 RESTStorage(底層封裝了 ETCD3)，此時客戶端可透過 RESTful HTTP 介面向 APIServer 發出資源請求，包括 GET/POST/PATCH/WATCH/DELETE 等操作。

> 客戶端 Watch 包括：
> (1). kubectl get xxx -w，獲取某類資源、並持續監聽資源變化；
> (2). client-go 中 Reflector ListAndWatch APIServer 各類資源；

我們以 kubectl get pod -w 為例，說明客戶端是如何實現資源的 Watch 操作。

首先，kubectl 也是透過 Cobra 命令列解析引數(--watch，或 --watch-only)，然後呼叫 Run 呼叫 cli-runtime 包下面的 Watch 介面，之後透過 RESTClient.Watch 向 APIServer 發起 Watch 請求，獲得一個流式 watch.Interface，然後不斷從其中 ResultChan 獲取 watch.Event。之後，根據客戶端傳送的編解碼型別(json/yaml/protobuf)，從 stream 中按幀(Frame) 讀取並解碼(Decode) 資料，輸出顯示到命令列終端。

客戶端透過 RESTClient 發起 Watch 請求，程式碼如下：
```go
// kubernetes/staging/src/k8s.io/cli-runtime/pkg/resource/helper.go
func (m *Helper) Watch(namespace, apiVersion string, options *metav1.ListOptions) (watch.Interface, error) {
   options.Watch = true
   return m.RESTClient.Get().
      NamespaceIfScoped(namespace, m.NamespaceScoped).
      Resource(m.Resource).
      VersionedParams(options, metav1.ParameterCodec).
      Watch(context.TODO())
}
```

客戶端 Watch 實現過程小結如下：

![](https://qcloudimg.tencent-cloud.cn/raw/9e780af7d9b601e2849735afe583908d.png)

## 服務端 Watch 實現
服務端 APIServer 啟動後，一直在持續監聽著各類資源的變更事件。在接收到某類資源的 Watch 請求後，呼叫 RESTStorage 的 Watch 介面，透過開關 EnableWatchCache 來控制是否啟用 Watch 快取，最終透過 etcd3.Watch 封裝實現了 ETCD 底層的 Event 變更事件。

> RESTStorage 就是在 APIServer 啟動時候，提前註冊、封裝的 ETCD 資源儲存。

etcd3.watcher 透過兩個 channel(incomingEventChan、resultChan，預設容量都為 100) 實現 ETCD 底層事件到 watch.Event 的轉換，然後透過 serveWatch 流式監聽返回的 watch.Interface，不斷從 resultChan 中取出變更事件。之後，根據客戶端傳送的編解碼型別(json/yaml/protobuf)，編碼(Encode) 資料，按幀(Frame) 組裝後傳送到 stream 中給客戶端。

服務端透過 serveWatch 流式監聽返回的 watch.Interface，程式碼如下：
```go
// kubernetes/staging/src/k8s.io/apiserver/pkg/endpoints/handlers/get.go
func ListResource(r rest.Lister, rw rest.Watcher, scope *RequestScope, forceWatch bool, minRequestTimeout time.Duration) http.HandlerFunc {
   return func(w http.ResponseWriter, req *http.Request) {
      ...

if opts.Watch || forceWatch {
         ...
         watcher, err := rw.Watch(ctx, &opts)
         if err != nil {
            scope.err(err, w, req)
            return
         }
         requestInfo, _ := request.RequestInfoFrom(ctx)
         metrics.RecordLongRunning(req, requestInfo, metrics.APIServerComponent, func() {
            serveWatch(watcher, scope, outputMediaType, req, w, timeout)
         })
         return
      }
      ...
   }
}
```

> K8s 在 v1.11 之後將 WATCH/WATCHLIST 型別的 action.Verb 廢棄了，統一都交由 LIST -> restfulListResource 處理。

服務端 Watch 實現過程小結如下：

![](https://qcloudimg.tencent-cloud.cn/raw/ce59b10334b6189519f30e7bb181939b.png)

> APIServer 除了支援 HTTP2，也支援 WebSocket 通訊。當客戶端請求包含了 Upgrade: websocket，Connection: Upgrade 時，則服務端會透過 WebSocket 與客戶端進行資料傳輸。

值得注意的是，底層 ETCD 事件透過 transform 函式轉換為 watch.Event，包括以下幾種型別(Type)：

![](https://qcloudimg.tencent-cloud.cn/raw/ba8280fab679e3fe364c7056fe6a83bc.png)

## 小結
本文透過分析 K8s 中 APIServer 啟動、ETCD watch 封裝、服務端 Watch 實現、客戶端 Watch 實現等核心流程，對 K8s Watch 實現機制進行了解析。透過原始碼、圖文方式說明了相關流程邏輯，以期更好的理解 K8s Watch 實現細節。

K8s 底層完全信任 ETCD(ListAndWatch)，將各類資源統一抽象為了 RESTful 的儲存(Storage)，透過 Watch 機制獲取各類資源的變更事件，然後透過 Informer 機制分發給下游監聽的 ResourceEventHandler，最終由 Controller 實現資源的業務邏輯處理。隨著 ETCD3 在 HTTP/2 基礎上不斷最佳化完善，K8s 將提供更高效、更穩定的編排能力。

### 參考資料
1. [HTTP/2 Wikipedia](https://en.wikipedia.org/wiki/HTTP/2 "HTTP/2 Wikipedia")
2. [Chunked Transfer Encoding](https://en.wikipedia.org/wiki/Chunked_transfer_encoding "Chunked Transfer Encoding")
3. [Kubernetes 原始碼](https://github.com/kubernetes/kubernetes "Kubernetes 原始碼")
4. [ETCD watch-api](https://etcd.io/docs/v3.2/learning/api/#watch-api "ETCD watch-api")
5. [K8s API Concepts](https://kubernetes.io/docs/reference/using-api/api-concepts/ "K8s API Concepts")
6. [Server Push 與 Client Poll](https://ninokop.github.io/2018/07/25/watch-push-or-pull/ "Server Push 與 Client Poll")

K8s 如何提供更高效穩定的編排能力？K8s Watch 實現機制淺析

相關文章