本文主要是介绍K8S 生态周报| Kubernetes v1.21 发布, 带来新的内存管理器，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
“「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」[1]。
”
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】
参考资料
[1]
k8s生态: https://zhuanlan.zhihu.com/container
这篇关于K8S 生态周报| Kubernetes v1.21 发布, 带来新的内存管理器的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
