聊聊 Kube-Apiserver 內(nèi)存優(yōu)化進階
原理
內(nèi)存優(yōu)化是一個經(jīng)典問題，在看具體 K8S 做了哪些工作之前，可以先抽象一些這個過程，思考一下如果是我們的話，會如何來優(yōu)化。這個過程可以簡單抽象為外部并發(fā)請求從服務(wù)端獲取數(shù)據(jù)，如何在不影響吞吐的前提下降低服務(wù)端內(nèi)存消耗？一般有幾種方式：
- 緩存序列化的結(jié)果
- 優(yōu)化序列化過程內(nèi)存分配
數(shù)據(jù)壓縮在這個場景可能不適用，壓縮確實可以降低網(wǎng)絡(luò)傳輸帶寬，從而提升請求響應(yīng)速度，但對服務(wù)端內(nèi)存的優(yōu)化沒有太大的作用。kube-apiserver 已經(jīng)支持基于 gzip 的數(shù)據(jù)壓縮，只需要設(shè)置 Accept-Encoding 為 gzip 即可，詳情可以參考官網(wǎng)[1]介紹。
當(dāng)然緩存序列化的結(jié)果適用于客戶端請求較多的場景，尤其是服務(wù)端需要同時把數(shù)據(jù)發(fā)送給多個客戶時，緩存序列化的結(jié)果收益會比較明顯，因為只需要一次序列化的過程即可，只要完成一次序列化，后續(xù)給其他客戶端直接發(fā)送數(shù)據(jù)時直接使用之前的結(jié)果即可，省去了不必要的 CPU 和內(nèi)存的開銷。當(dāng)然緩存序列化的結(jié)果這個操作本身來說也是會占用一些內(nèi)存的，如果客戶端數(shù)量較少，那么這個操作可能收益不大甚至可能帶來額外的內(nèi)存消耗。kube-apiserver watch 請求就與這個場景非常吻合。
下文會就 kube-apiserver 中是如何就這兩點進行的優(yōu)化做一個介紹。
實現(xiàn)
下文列出的時間線中的各種問題和優(yōu)化可能而且有很大可能只是眾多問題和優(yōu)化中的一部分。
緩存序列化結(jié)果
時間線
- 早在 2019 年的時候，社區(qū)有人反饋了一個問題[2]：在一個包含 5000 個節(jié)點的集群中，創(chuàng)建一個大型的 Endpoints 對象（5000 個 Pod，大小接近 1MB），kube-apiserver 可能會在 5 秒內(nèi)完全過載；
- 接著社區(qū)定位了這個問題，并提出了 KEP 1152 less object serializations[3]，通過避免為不同的 watcher 重復(fù)多次序列化相同的對象，降低 kube-apiserver 的負載和內(nèi)存分配次數(shù)，此功能在 v1.17 中發(fā)布，在 5000 節(jié)點的測試結(jié)果，內(nèi)存分配優(yōu)化 ~15%，CPU 優(yōu)化 ~5%，但這個優(yōu)化僅對 Http 協(xié)議生效，對 WebSocket 不生效；
- 3 年后，也就是 2023 年，通過 Refactor apiserver endpoint transformers to more natively use Encoders #119801[4] 對序列化邏輯進行重構(gòu)，統(tǒng)一使用 Encoder 接口進行序列化操作，早在 2019 年就已經(jīng)創(chuàng)建對應(yīng)的 issue 83898[5]。本次重構(gòu)同時還解決了 2 提到的針對 WebSocket 不生效的問題，于 1.29 中發(fā)布；
所以如果你不是在以 WebSocket 形式（默認使用 Http Transfer-Encoding: chunked）使用 watch，那么升級到 1.17 之后理論上就可以了。
原理
圖片
新增了 CacheableObject 接口，同時在所有 Encoder 中支持對 CacheableObject 的支持，如下
// Identifier represents an identifier.
// Identitier of two different objects should be equal if and only if for every
// input the output they produce is exactly the same.
type Identifier string
type Encoder interface {
...
// Identifier returns an identifier of the encoder.
// Identifiers of two different encoders should be equal if and only if for every input
// object it will be encoded to the same representation by both of them.
Identifier() Identifier
}
// CacheableObject allows an object to cache its different serializations
// to avoid performing the same serialization multiple times.
type CacheableObject interface {
// CacheEncode writes an object to a stream. The <encode> function will
// be used in case of cache miss. The <encode> function takes ownership
// of the object.
// If CacheableObject is a wrapper, then deep-copy of the wrapped object
// should be passed to <encode> function.
// CacheEncode assumes that for two different calls with the same <id>,
// <encode> function will also be the same.
CacheEncode(id Identifier, encode func(Object, io.Writer) error, w io.Writer) error
// GetObject returns a deep-copy of an object to be encoded - the caller of
// GetObject() is the owner of returned object. The reason for making a copy
// is to avoid bugs, where caller modifies the object and forgets to copy it,
// thus modifying the object for everyone.
// The object returned by GetObject should be the same as the one that is supposed
// to be passed to <encode> function in CacheEncode method.
// If CacheableObject is a wrapper, the copy of wrapped object should be returned.
GetObject() Object
}
func (e *Encoder) Encode(obj Object, stream io.Writer) error {
if co, ok := obj.(CacheableObject); ok {
return co.CacheEncode(s.Identifier(), s.doEncode, stream)
}
return s.doEncode(obj, stream)
}
func (e *Encoder) doEncode(obj Object, stream io.Writer) error {
// Existing encoder logic.
}
// serializationResult captures a result of serialization.
type serializationResult struct {
// once should be used to ensure serialization is computed once.
once sync.Once
// raw is serialized object.
raw []byte
// err is error from serialization.
err error
}
// metaRuntimeInterface implements runtime.Object and
// metav1.Object interfaces.
type metaRuntimeInterface interface {
runtime.Object
metav1.Object
}
// cachingObject is an object that is able to cache its serializations
// so that each of those is computed exactly once.
//
// cachingObject implements the metav1.Object interface (accessors for
// all metadata fields). However, setters for all fields except from
// SelfLink (which is set lately in the path) are ignored.
type cachingObject struct {
lock sync.RWMutex
// Object for which serializations are cached.
object metaRuntimeInterface
// serializations is a cache containing object`s serializations.
// The value stored in atomic.Value is of type serializationsCache.
// The atomic.Value type is used to allow fast-path.
serializations atomic.Value
}cachingObject 實現(xiàn)了 CacheableObject 接口，其 object 為關(guān)注的事件對象（例如 Pod），serializations 用來保存序列化之后的結(jié)果，Identifier 是一個標識，代表序列化的類型，因為存在 json、yaml、protobuf 三種序列化方式。
cachingObject 的生成在上圖 Cacher dispatchEvent 消費自身 incoming chan 數(shù)據(jù)，將 event 發(fā)給所有相關(guān)的 cacheWatchers 的時候，會將事件對象轉(zhuǎn)化為 cachingObject 發(fā)給 cacheWatcher 的 input chan。最終的 Encode 操作是在 serveWatch 方法中將最終的對象進行序列化時調(diào)用的，會先判斷是否已經(jīng)存在序列化的結(jié)果，存在則直接復(fù)用，避免重復(fù)的序列化。
注意：
上圖 wrap into cachingObject if len(watchers) >= 3 已成為過去式，新的代碼邏輯中已經(jīng)去掉了后面的判斷，不管 watchers 數(shù)量，統(tǒng)一都進行 cachingObject 的封裝；
并沒有對 Init Event（watchcache 中的全量數(shù)據(jù)） 進行 cachingObject 的封裝，只有發(fā)給 Cacher incoming chan 的數(shù)據(jù)會轉(zhuǎn)化為 cachingObject。也就是說這個優(yōu)化對 Get/List 請求完全無效，因為他們是直接從 watchcache 返回數(shù)據(jù)的，針對 Watch 請求，也將會有部分數(shù)據(jù)在返回時沒有復(fù)用已有序列化結(jié)果，因為仍然可能會有部分 Init Event 數(shù)據(jù)是從 watchcache 獲取并返回的，這是一個很神奇的地方，cacheWatcher 的 input chan 的 event 對象的 object 有可能是正常的資源對象，例如 Pod，也有可能是 CacheableObject 對象，而真正的資源對象則保存在 CacheableObject 的 object 中；
為什么不把 Init Event 也覆蓋了，KEP 1152 中給的說法是先實現(xiàn) Cache incoming chan 的覆蓋，收益就已經(jīng)比較可觀了，解決了之前發(fā)現(xiàn)的問題。如果需要進一步優(yōu)化的話，再來重新評估把 Init Event 也覆蓋的可能。而在 Refactor streaming watch encoder to enable caching #120300[6] 的評論中也有相關(guān)討論
圖片
同時在 KEP 3157 watch-list[7] 中也提到了這個待優(yōu)化項。
優(yōu)化內(nèi)存分配
時間線
- reduce the number of allocations in the WatchServer during objects serialisation #108186[8]，主要針對 protobuf 進行優(yōu)化，對于 json 和 yaml 序列化無效，2022 年隨著 v1.24 發(fā)布，protobuf 一般是內(nèi)部組件使用，而外部組件訪問 k8s 時一般都是使用 json 或者 yaml 序列化；
- Do not copy bytes for cached serializations #118362[9]，自定義 SpliceBuffer，避免對 cachingObject 的序列化結(jié)果進行深拷貝，2023 年隨著 v1.28 發(fā)布；
- Refactor streaming watch encoder to enable caching #120300，這個修復(fù)是在已有的緩存資源對象的序列化結(jié)果的基礎(chǔ)上，把 Event 的序列化結(jié)果也做緩存，因為最終返回給客戶端的是 Event 而不是資源對象；
原理
針對 2，巧妙地定義了 SpliceBuffer 通過淺拷貝的方式有效的優(yōu)化了內(nèi)存分配，避免 embeddedEncodeFn 對已經(jīng)序列化后的結(jié)果 []byte 的深拷貝；
// A spliceBuffer implements Splice and io.Writer interfaces.
type spliceBuffer struct {
raw []byte
buf *bytes.Buffer
}
// Splice implements the Splice interface.
func (sb *spliceBuffer) Splice(raw []byte) {
sb.raw = raw
}Benchmark 效果顯著
go test -benchmem -run=^$ -bench ^BenchmarkWrite k8s.io/apimachinery/pkg/runtime -v -count 1
goos: linux
goarch: amd64
pkg: k8s.io/apimachinery/pkg/runtime
cpu: AMD EPYC 7B12
BenchmarkWriteSplice
BenchmarkWriteSplice-48 151164015 7.929 ns/op 0 B/op 0 allocs/op
BenchmarkWriteBuffer
BenchmarkWriteBuffer-48 3476392 357.8 ns/op 1024 B/op 1 allocs/op
PASS
ok k8s.io/apimachinery/pkg/runtime 3.619s針對 3，嚴格來說這個 pr 不是用來優(yōu)化內(nèi)存分配的，而是來解決 issue 110146[10] 的提到的 json 序列化時 json.compact 導(dǎo)致的 CPU 使用率過高的問題，隨著 v1.29 發(fā)布。問題產(chǎn)生的原因是雖然上面提到了通過 cachingObject 來緩存資源對象的序列化結(jié)果，但最終發(fā)回到客戶端的是 Event 對象，還是需要做一次 Event 的序列化操作，而 json.compact 會在每次 Marshal 后被調(diào)用，這是 golang 自帶的 json 序列化的實現(xiàn)，可以參考 golang json 源碼[11]。這個修復(fù)是在緩存資源對象的序列化結(jié)果的基礎(chǔ)上，把 Event 的序列化結(jié)果也做緩存，用來規(guī)避 json.compact 帶來的影響。
這個 PR 涉及到的改動較大，筆者目前對其實現(xiàn)仍然存在一些疑問，已經(jīng)提了 issue 122153[12] 咨詢社區(qū)，等搞清楚后可以再專門安排一篇來講講這個實現(xiàn)，這塊涉及到了 watch handler 的整個序列化邏輯，Encoder 的嵌套非常深，連 google 大神在 review 代碼時都有如下感嘆
圖片
圖片
筆者在看這塊代碼時被接口的來回跳轉(zhuǎn)搞暈了，寫了個 unit test 來一步步調(diào)試才搞清楚這些 Encoder，真的是層層嵌套，梳理如下，可以感受下這五層嵌套
watchEncoder
—> watchEmbeddedEncoder
—> encoderWithAllocator
—> codec
—> json.Serializer
他們都實現(xiàn)了 Encoder 接口...
類似 cachingObject 序列化，對 Event 進行序列化同樣需要額外的內(nèi)存空間，但可以避免對每個 Event 進行多次序列化帶來的內(nèi)存消耗和 CPU 消耗，所以也起到了內(nèi)存優(yōu)化的作用。
效果
通過 WatchList 以及上述的種種優(yōu)化，社區(qū)給出了優(yōu)化效果
優(yōu)化前
圖片
優(yōu)化后
圖片
最后
Kube-apiserver 內(nèi)存優(yōu)化系系列包含前面的鋪墊，到此也 6 篇了，如果把這其中涉及到的知識都搞懂了，對 kube-apiserver 的理解一定可以上一個臺階，后續(xù)也會持續(xù)關(guān)注這塊的內(nèi)容，不定時補充~
序列化，聽上去簡單，調(diào)個方法的事情，但用好了也不容易，往往這種地方最能體現(xiàn)能力，尋常見功力，細微見真章，看看大牛寫的代碼，領(lǐng)會其中的設(shè)計和思想，總結(jié)轉(zhuǎn)化吸收為我所用。
k8s 使用起來容易，用好了不容易，搞明白背后是怎么回事難。項目經(jīng)過 10 來年的迭代，無論代碼量還是復(fù)雜度上面都已經(jīng)比較恐怖了，而且還在不斷地迭代更新，但路雖遠，行則將至，事雖難，做雖然不一定成吧，不做一定成不了。
Talk is cheap, Show me the code and PPT
最后，歡迎加筆者微信 YlikakuY，一起交流前沿技術(shù)，行業(yè)動態(tài)~
參考資料
[1]
kubernetes-api: https://kubernetes.io/zh-cn/docs/concepts/overview/kubernetes-api/
[2]issue#75294: https://github.com/kubernetes/kubernetes/issues/75294
[3]kep#1152-less-object-serializations: https://github.com/kubernetes/enhancements/tree/master/keps/sig-api-machinery/1152-less-object-serializations
[4]pr#119801: https://github.com/kubernetes/kubernetes/pull/119801
[5]issue#83898: https://github.com/kubernetes/kubernetes/issues/83898
[6]pr#120300: https://github.com/kubernetes/kubernetes/pull/120300
[7]kep#3157 watch-list: https://github.com/kubernetes/enhancements/blob/master/keps/sig-api-machinery/3157-watch-list/README.md
[8]pr#108186: https://github.com/kubernetes/kubernetes/pull/108186
[9]pr#118362: https://github.com/kubernetes/kubernetes/pull/118362/
[10]issue#11014: https://github.com/kubernetes/kubernetes/issues/110146
[11]golang#json: https://github.com/golang/go/blob/d8762b2f4532cc2e5ec539670b88bbc469a13938/src/encoding/json/encode.go#L498
[12]issue#122153: https://github.com/kubernetes/kubernetes/issues/122153
