K8S 生態週報| Kubernetes v1.21 發佈, 帶來新的內存管理器

「K8S 生態週報」內容主要包含我所接觸到的 K8S 生態相關的每週值得推薦的一些信息。歡迎訂閱知乎專欄 「k8s生態」。

Kubernetes v1.21 正式發佈

做爲 2021 年的首個版本， Kubernetes v1.21 們帶來了衆多很棒的特性，共計 51 項特性變動，其中 13 項升級到 Stable， 16 項目升級到 Beta，20 項成爲 alpha，以及 2 項將被廢棄。咱們一塊兒來看看我認爲比較重要的一些內容。

CronJob 升級到 Stable

CronJob 顧名思義就是定時/週期性任務，CronJob 從 Kubernetes v1.4 開始引入，到 v1.8 時進入到 Beta 階段。事實上在 2021 年 2 月份的時候，CronJobV2 controller 已經成爲了它默認的控制器版本，也就是說當你在 Kubernetes v1.21 版本中使用 CronJob 時，若是不想使用 CronJobV2 的控制器，而想要換回原始的控制器時，那你須要顯式的將它禁用掉，好比：

--feature-gates="CronJobControllerV2=false"

但我我的仍是建議使用 CronJobV2 controller ，這個版本用了延遲隊列和 informer 緩存，原始版本的控制器簡陋了些，也會帶來一些問題，好比當鏡像/服務不可用時，會產生無限的 Pod 泄漏的問題。

我在生產用 CronJob 還蠻多的，備份/同步任務等，固然也踩過上面提到的坑，但總體來講，CronJob 是個挺有用的特性。

內存管理器（kubelet）

在 Kubernetes v1.21 中在 kubelet 組件生態中新增了一個 內存管理器 ，在 Linux 系統中，爲須要保證 QoS 的 Pod 在多 NUMA 節點保障內存和大內存頁分配。這個特性很是有用，尤爲是當數據庫類或者使用 DPDK 進行高性能數據包處理的應用要部署到 Kubernetes 中時，內存對其性能影響相當重要。

這裏稍微聊點和 NUMA 相關的內容。簡單來講就是在多 NUMA 結構下，爲了保證效率，因此會按內存和 CPU 的相對距離來按 node 定義是否爲 local memory 或者說本地內存，同時因爲實際位置不一樣，因此就可能會產生內存分配不均勻的狀況了。好比，咱們可使用 numactl 管理工具查看下當前機器上的狀況：

[tao@moelove ~]# numactl -H
available: 2 nodes (0-1)
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 20 21 22 23 24 25 26 27 28 29
node 0 size: 65186 MB
node 0 free: 9769 MB
node 1 cpus: 10 11 12 13 14 15 16 17 18 19 30 31 32 33 34 35 36 37 38 39
node 1 size: 65536 MB
node 1 free: 15206 MB
node distances:
node   0   1 
  0:  10  21 
  1:  21  10

能夠看到在我當前的這臺機器上就存在着比較明顯的內存分配不均的狀況。因此當某個進程達到了其 local memory 的上限，那天然就會影響到它的性能。我最先折騰 NUMA 相關問題是在前些年大量使用 MongoDB 的時候，在這上面也花了些時間，不過這也不影響我對 MongoDB 的喜好~

此次在 kubelet 中增長的內存管理器即可以很好的解決這個問題，能夠在啓動 kubelet 的時候經過 --reserved-memory 以及配合 --memory-manager-policy 等參數來一塊兒設置。例如：

--memory-manager-policy static --reserved-memory 0:memory=1Gi,hugepages-1M=2Gi --reserved-memory 1:memory=2Gi

注意：memory-manager-policy 必須設置爲 static，若是不設置則默認爲 none，即不採起任何行爲。

不過這個特性還在較早期的階段，目前只爲 Guaranteed QoS 類的 Pod 提供支持。另外，若是正確啓用了此特性，則在機器的 /var/lib/kubelet/memory_manager_state 能夠看到其詳細信息。

最終將會影響到拓撲管理器。

ReplicaSet 縮容算法調整

當前的縮容算法，主要是優先刪除生命週期最短的 Pod，本次修改主要是爲了不某些場景：

好比在縮容的時候，一次性把新擴容的全部的 Pod 給刪掉了之類的。因此計劃對他們進行對數計算，也能夠簡單的理解爲想要相對隨機的對 Pod 進行清理。

這個調整確實能避免掉上述提到的那種場景，不過也可能會帶來一些其餘的關於服務可用性相關的問題，好比一般狀況下運行時間越久的 Pod 可能當前服務的用戶數就越多，鏈接銷燬時，可能就會比新 Pod 帶來的影響大一些了。固然，這些也都是能夠經過其餘的方式來避免的，感興趣的小夥伴能夠給我留言，一塊兒討論。

其餘的一些值得關注的變動，我在每週的「K8S 生態週報」中都有介紹過了，這裏就再也不贅述啦，感興趣的小夥伴能夠翻看每期「K8S 生態週報」中 「上游進展」 的部分。關於此版本中的其餘變動，可參考其 ReleaseNote

containerd v1.5.0-rc.0 發佈

本週 containerd 發佈了 v1.5.0-rc.0 版本，這是 containerd 的第六個大版本，帶來了衆多值得關注的變動：

runtime

• #4647 因爲 CRI-API 的更新，能夠在 task update 的 API 中添加 annotations 了；
• #4502 當 terminal 爲 true 時，添加二進制日誌的支持；

Distribution

• #4523 在日誌中記錄 registry 返回的異常狀態碼；
• #4653 改進了在 registry 爲 HTTP 1.1 協議下 pull image 的性能；

CRI

• cri#1552 實驗性的添加了 NRI（Node Resource Interface） 的注入點;
• #4978 容許爲 CRI 的 registry 配置相似 docker 的 /etc/docker/certs.d 目錄，能夠進行更方便的配置；
• #5135 默認開啓 ocicrypt 支持；

更多關於此版本的變動，請查看其 ReleaseNote

Cilium v1.10.0-rc0 發佈

Cilium 我已經屢次介紹過了，感興趣的小夥伴能夠查看我以前的文章《被 Google 選擇的下一代數據面 Cilium 是什麼》。該項目於近期發佈了 v1.10.0-rc0 版本，咱們看看主要的變動：

• #13670 · cilium/cilium 添加了 --datapath-mode=lb-only 選項，以支持僅 LB 模式，這樣就可讓 cilium-agent 做爲一個獨立的 loadbalancer 運行了，不須要鏈接 kube-apiserver 或者 kvstore ；
• #14858 · cilium/cilium 在 wireguard, tun 等無二層設備上添加 NodePort BPF 支持；
• #14207 · cilium/cilium 添加 arm64 支持；

更多關於此版本的變動，請查看其 ReleaseNote

---

歡迎訂閱個人文章公衆號【MoeLove】