摘要：經(jīng)過廣泛的調(diào)查和診斷，我們已經(jīng)確定了處理這些問題的方法。我們發(fā)現(xiàn)在薛定諤平臺上做測試時偶爾會發(fā)生性能抖動，但從下面幾項來看未發(fā)現(xiàn)異常和的日志使用率內(nèi)存和磁盤等負(fù)載信息只能偶爾看到命令執(zhí)行的結(jié)果中包含一些信息。

作者：張文博

Kubernetes（K8s）是一個開源容器編排系統(tǒng)，可自動執(zhí)行應(yīng)用程序部署、擴(kuò)展和管理。它是云原生世界的操作系統(tǒng)。 K8s 或操作系統(tǒng)中的任何缺陷都可能使用戶進(jìn)程存在風(fēng)險。作為 PingCAP EE（效率工程）團(tuán)隊，我們在 K8s 中測試 TiDB Operator（一個創(chuàng)建和管理 TiDB 集群的工具）時，發(fā)現(xiàn)了兩個 Linux 內(nèi)核錯誤。這些錯誤已經(jīng)困擾我們很長一段時間，并沒有在整個 K8s 社區(qū)中徹底修復(fù)。

經(jīng)過廣泛的調(diào)查和診斷，我們已經(jīng)確定了處理這些問題的方法。在這篇文章中，我們將與大家分享這些解決方法。不過，盡管這些方法很有用，但我們認(rèn)為這只是權(quán)宜之策，相信未來會有更優(yōu)雅的解決方案，也期望 K8s 社區(qū)、RHEL 和 CentOS 可以在不久的將來徹底修復(fù)這些問題。

關(guān)鍵詞：SLUB: Unable to allocate memory on node -1

社區(qū)相關(guān) Issue:

https://github.com/kubernetes/kubernetes/issues/61937

https://github.com/opencontainers/runc/issues/1725

https://support.mesosphere.com/s/article/Critical-Issue-KMEM-MSPH-2018-0006

薛定諤平臺是我司開發(fā)的基于 K8s 建立的一套自動化測試框架，提供各種 Chaos 能力，同時也提供自動化的 Bench 測試，各類異常監(jiān)控、告警以及自動輸出測試報告等功能。我們發(fā)現(xiàn) TiKV 在薛定諤平臺上做 OLTP 測試時偶爾會發(fā)生 I/O 性能抖動，但從下面幾項來看未發(fā)現(xiàn)異常：

TiKV 和 RocksDB 的日志

CPU 使用率

內(nèi)存和磁盤等負(fù)載信息

只能偶爾看到 dmesg 命令執(zhí)行的結(jié)果中包含一些 “SLUB: Unable to allocate memory on node -1” 信息。

我們使用 perf-tools 中的 funcslower trace 來執(zhí)行較慢的內(nèi)核函數(shù)并調(diào)整內(nèi)核參數(shù) hung_task_timeout_secs 閾值，抓取到了一些 TiKV 執(zhí)行寫操作時的內(nèi)核路徑信息：

從上圖的信息中可以看到 I/O 抖動和文件系統(tǒng)執(zhí)行 writepage 有關(guān)。同時捕獲到性能抖動的前后，在 node 內(nèi)存資源充足的情況下，dmesg 返回的結(jié)果也會出現(xiàn)大量 “SLUB: Unable to allocate memory on node -1” 的信息。

從 hung_task 輸出的 call stack 信息結(jié)合內(nèi)核代碼發(fā)現(xiàn)，內(nèi)核在執(zhí)行 bvec_alloc 函數(shù)分配 bio_vec 對象時，會先嘗試通過 kmem_cache_alloc 進(jìn)行分配，kmem_cache_alloc 失敗后，再進(jìn)行 fallback 嘗試從 mempool 中進(jìn)行分配，而在 mempool 內(nèi)部會先嘗試執(zhí)行 pool->alloc 回調(diào)進(jìn)行分配，pool->alloc 分配失敗后，內(nèi)核會將進(jìn)程設(shè)置為不可中斷狀態(tài)并放入等待隊列中進(jìn)行等待，當(dāng)其他進(jìn)程向 mempool 歸還內(nèi)存或定時器超時（5s） 后，進(jìn)程調(diào)度器會喚醒該進(jìn)程進(jìn)行重試 ，這個等待時間和我們業(yè)務(wù)監(jiān)控的抖動延遲相符。

但是我們在創(chuàng)建 Docker 容器時，并沒有設(shè)置 kmem limit，為什么還會有 kmem 不足的問題呢？為了確定 kmem limit 是否被設(shè)置，我們進(jìn)入 cgroup memory controller 對容器的 kmem 信息進(jìn)行查看，發(fā)現(xiàn) kmem 的統(tǒng)計信息被開啟了, 但 limit 值設(shè)置的非常大。

我們已知 kmem accounting 在 RHEL 3.10 版本內(nèi)核上是不穩(wěn)定的，因此懷疑 SLUB 分配失敗是由內(nèi)核 bug 引起的，搜索 kernel patch 信息我們發(fā)現(xiàn)確實是內(nèi)核 bug, 在社區(qū)高版本內(nèi)核中已修復(fù)：

slub: make dead caches discard free slabs immediately

同時還有一個 namespace 泄漏問題也和 kmem accounting 有關(guān)：

mm: memcontrol: fix cgroup creation failure after many small jobs

那么是誰開啟了 kmem accounting 功能呢？我們使用 bcc 中的 opensnoop 工具對 kmem 配置文件進(jìn)行監(jiān)控，捕獲到修改者 runc 。從 K8s 代碼上可以確認(rèn)是 K8s 依賴的 runc 項目默認(rèn)開啟了 kmem accounting。

通過上述分析，我們要么升級到高版本內(nèi)核，要么在啟動容器的時候禁用 kmem accounting 功能，目前 runc 已提供條件編譯選項，可以通過 Build Tags 來禁用 kmem accounting，關(guān)閉后我們測試發(fā)現(xiàn)抖動情況消失了，namespace 泄漏問題和 SLUB 分配失敗的問題也消失了。

我們需要在 kubelet 和 docker 上都將 kmem account 功能關(guān)閉。

kubelet 需要重新編譯，不同的版本有不同的方式。

如果 kubelet 版本是 v1.14 及以上，則可以通過在編譯 kubelet 的時候加上 Build Tags 來關(guān)閉 kmem account：

$ git clone --branch v1.14.1 --single-branch --depth 1 [https://github.com/kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) 
$ cd kubernetes

$ KUBE_GIT_VERSION=v1.14.1 ./build/run.sh make kubelet GOFLAGS="-tags=nokmem"

但如果 kubelet 版本是 v1.13 及以下，則無法通過在編譯 kubelet 的時候加 Build Tags 來關(guān)閉，需要重新編譯 kubelet，步驟如下。

首先下載 Kubernetes 代碼：

$ git clone --branch v1.12.8 --single-branch --depth 1 https://github.com/kubernetes/kubernetes
$ cd kubernetes

然后手動將開啟 kmem account 功能的 兩個函數(shù) 替換成 下面這樣：

func EnableKernelMemoryAccounting(path string) error {
    return nil
}

func setKernelMemory(path string, kernelMemoryLimit int64) error {
    return nil
}

之后重新編譯 kubelet：

$ KUBE_GIT_VERSION=v1.12.8 ./build/run.sh make kubelet

編譯好的 kubelet 在 ./_output/dockerized/bin/$GOOS/$GOARCH/kubelet 中。

同時需要升級 docker-ce 到 18.09.1 以上，此版本 docker 已經(jīng)將 runc 的 kmem account 功能關(guān)閉。

最后需要重啟機(jī)器。

驗證方法是查看新創(chuàng)建的 pod 的所有 container 已關(guān)閉 kmem，如果為下面結(jié)果則已關(guān)閉：

$ cat /sys/fs/cgroup/memory/kubepods/burstable/pod//memory.kmem.slabinfo
cat: memory.kmem.slabinfo: Input/output error

關(guān)鍵詞：kernel:unregister_netdevice: waiting for eth0 to become free. Usage count = 1

社區(qū)相關(guān) Issue:

https://github.com/kubernetes/kubernetes/issues/64743

https://github.com/projectcalico/calico/issues/1109

https://github.com/moby/moby/issues/5618

我們的薛定諤分布式測試集群運(yùn)行一段時間后，經(jīng)常會持續(xù)出現(xiàn)“kernel:unregister_netdevice: waiting for eth0 to become free. Usage count = 1” 問題，并會導(dǎo)致多個進(jìn)程進(jìn)入不可中斷狀態(tài)，只能通過重啟服務(wù)器來解決。

通過使用 crash 工具對 vmcore 進(jìn)行分析，我們發(fā)現(xiàn)內(nèi)核線程阻塞在 netdev_wait_allrefs 函數(shù)，無限循環(huán)等待 dev->refcnt 降為 0。由于 pod 已經(jīng)釋放了，因此懷疑是引用計數(shù)泄漏問題。我們查找 K8s issue 后發(fā)現(xiàn)問題出在內(nèi)核上，但這個問題沒有簡單的穩(wěn)定可靠復(fù)現(xiàn)方法，且在社區(qū)高版本內(nèi)核上依然會出現(xiàn)這個問題。

為避免每次出現(xiàn)問題都需要重啟服務(wù)器，我們開發(fā)一個內(nèi)核模塊，當(dāng)發(fā)現(xiàn) net_device 引用計數(shù)已泄漏時，將引用計數(shù)清 0 后移除此內(nèi)核模塊（避免誤刪除其他非引用計數(shù)泄漏的網(wǎng)卡）。為了避免每次手動清理，我們寫了一個監(jiān)控腳本，周期性自動執(zhí)行這個操作。但此方案仍然存在缺陷：

引用計數(shù)的泄漏和監(jiān)控發(fā)現(xiàn)之間存在一定的延遲，在這段延遲中 K8s 系統(tǒng)可能會出現(xiàn)其他問題；

在內(nèi)核模塊中很難判斷是否是引用計數(shù)泄漏，netdev_wait_allrefs 會通過 Notification Chains 向所有的消息訂閱者不斷重試發(fā)布 NETDEV_UNREGISTER 和 NETDEV_UNREGISTER_FINAL 消息，而經(jīng)過 trace 發(fā)現(xiàn)消息的訂閱者多達(dá) 22 個，而去弄清這 22 個訂閱者注冊的每個回調(diào)函數(shù)的處理邏輯來判斷是否有辦法避免誤判也不是一件簡單的事。

在我們準(zhǔn)備深入到每個訂閱者注冊的回調(diào)函數(shù)邏輯的同時，我們也在持續(xù)關(guān)注 kernel patch 和 RHEL 的進(jìn)展，發(fā)現(xiàn) RHEL 的 solutions:3659011 有了一個更新，提到 upstream 提交的一個 patch:

route: set the deleted fnhe fnhe_daddr to 0 in ip_del_fnhe to fix a race

在嘗試以 hotfix 的方式為內(nèi)核打上此補(bǔ)丁后，我們持續(xù)測試了 1 周，問題沒有再復(fù)現(xiàn)。我們向 RHEL 反饋測試信息，得知他們已經(jīng)開始對此 patch 進(jìn)行 backport。

推薦內(nèi)核版本 Centos 7.6 kernel-3.10.0-957 及以上。

安裝 kpatch 及 kpatch-build 依賴：

UNAME=$(uname -r)
sudo yum install gcc kernel-devel-${UNAME%.*} elfutils elfutils-devel
sudo yum install pesign yum-utils zlib-devel 
  binutils-devel newt-devel python-devel perl-ExtUtils-Embed 
  audit-libs audit-libs-devel numactl-devel pciutils-devel bison

# enable CentOS 7 debug repo
sudo yum-config-manager --enable debug

sudo yum-builddep kernel-${UNAME%.*}
sudo debuginfo-install kernel-${UNAME%.*}

# optional, but highly recommended - enable EPEL 7
sudo yum install ccache
ccache --max-size=5G

安裝 kpatch 及 kpatch-build：

git clone https://github.com/dynup/kpatch && cd kpatch
make 
sudo make install
systemctl enable kpatch

下載并構(gòu)建熱補(bǔ)丁內(nèi)核模塊：

curl -SOL  https://raw.githubusercontent.com/pingcap/kdt/master/kpatchs/route.patch
kpatch-build -t vmlinux route.patch （編譯生成內(nèi)核模塊）
mkdir -p /var/lib/kpatch/${UNAME} 
cp -a livepatch-route.ko /var/lib/kpatch/${UNAME}
systemctl restart kpatch (Loads the kernel module)
kpatch list (Checks the loaded module)

雖然我們修復(fù)了這些內(nèi)核錯誤，但是未來應(yīng)該會有更好的解決方案。對于 Bug＃1，我們希望 K8s 社區(qū)可以為 kubelet 提供一個參數(shù)，以允許用戶禁用或啟用 kmem account 功能。對于 Bug＃2，最佳解決方案是由 RHEL 和 CentOS 修復(fù)內(nèi)核錯誤，希望 TiDB 用戶將 CentOS 升級到新版后，不必再擔(dān)心這個問題。