年终盘点Kubernetes生态：大版本“内卷”，安全性值得重视 作者 ｜ 张晋涛 本文是 “2021 年度技术盘点” 系列文章之一，主要介绍Kubernetes生态在2021年的重要进展。 “2021年终技术盘点”是掘金推出的重磅企划，涵盖Serverless、Service Mesh、大前端、数据库、人工智能、低代码、边缘计算等众多技术领域。看过去，向未来，回顾IT技术在2021年的发展情况，盘点IT技术的重大事件，展望IT技术的未来趋势。同时，我们将开启第15期技术主题征文活动，一起来聊聊你眼中的2022年技术趋势吧！ 2021 年已经结束了，我们来对 Kubernetes 及相关生态做个回顾和总结。 Kubernetes 的 2021 从 2021 年的 4 月份开始， Kubernetes 的发版节奏由原先的每 3 个月发布一个版本，修改成了每 4 个月发布一个版本。所以在 2021 年，Kubernetes 一共发布了 3 个大版本。包括 v1.21、v1.22 和 v1.23 。 从整体的功能上而言，主要侧重在以下的几个方面。 资源利用内存管理器（kubelet）在 Kubernetes v1.21 中在 kubelet 组件生态中新增了一个内存管理器，在 Linux 系统中，为需要保证 QoS 的 Pod 在多 NUMA 节点保障内存和大内存页分配。这个特性非常有用，尤其是当数据库类或者使用 DPDK 进行高性能数据包处理的应用要部署到 Kubernetes 中时，内存对其性能影响至关重要。 这里稍微聊点和 NUMA 相关的内容。简单来说就是在多 NUMA 结构下，为了保证效率，所以会按内存和 CPU 的相对距离来按 node 定义是否为 local memory 或者说本地内存，同时由于实际位置不同，所以就可能会产生内存分配不均匀的情况了。比如，我们可以使用 numactl 管理工具查看下当前机器上的情况： [tao@moelove ~]# numactl -Havailable: 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 29node 0 size: 65186 MBnode 0 free: 9769 MBnode 1 cpus: 10 11 12 13 14 15 16 17 18 19 30 31 32 33 34 35 36 37 38 39node 1 size: 65536 MBnode 1 free: 15206 MBnode distances:node 0 1 0: 10 21 1:2110可以看到在我当前的这台机器上就存在着比较明显的内存分配不均的情况。所以当某个进程达到了其 local memory 的上限，那自然就会影响到它的性能。 这次在 kubelet 中增加的内存管理器便可以很好的解决这个问题，可以在启动 kubelet 的时候通过--reserved-memory以及配合--memory-manager-policy等参数来一起设置。例如： --memory-manager-policystatic--reserved-memory0:memory=1Gi,hugepages-1M=2Gi--reserved-memory1:memory=2Gi注意：memory-manager-policy必须设置为 static，如果不设置则默认为 none，即不采取任何行为。 不过这个特性还在较早期的阶段，目前只为GuaranteedQoS 类的 Pod 提供支持。另外，如果正确启用了此特性，则在机器的 /var/lib/kubelet/memory_manager_state 可以看到其详细信息。 最终将会影响到拓扑管理器。 内存资源的QoS之前 Kubernetes 在使用 cgroups v1 ，对于 Pod 的 QoS 其实只适用于 CPU 资源。Kubernetes v1.22 中通过引入 cgroups v2 来提供了一个 alpha 特性，允许对内存资源也提供 QoS。（如果没记错，貌似是腾讯云团队提交的 KEP 吧） ReplicaSet 缩容算法调整当前的缩容算法，主要是优先删除生命周期最短的 Pod，本次修改主要是为了避免某些场景： 比如在缩容的时候，一次性把新扩容的所有的 Pod 给删掉了之类的。所以计划对他们进行对数计算，也可以简单的理解为想要相对随机的对 Pod 进行清理。 这个调整确实能避免掉上述提到的那种场景，不过也可能会带来一些其他的关于服务可用性相关的问题，比如通常情况下运行时间越久的 Pod 可能当前服务的用户数就越多，连接销毁时，可能就会比新 Pod 带来的影响大一些了。（当然，这些也都是可以通过其他的方式来避免的） Node swap 支持此特性现在是 Alpha 阶段。 虽然 swap 并不够快，但是现在有很多场景都是需要用到它的，尤其是一些 Java 和 Node 应用。 在 Kubernetes 的 issue 列表中有一个存在了 5 年左右的讨论，就是针对于能否开启 swap 支持的。当前这个特性一旦开启就是针对于整个 Node 的，并不能精确到某个 Pod 中。 你可以通过如下步骤启用此特性： 在 Node 中启用 swap； 开启 kubelet 的NodeMemorySwap特性； 设置--fail-on-swap=false 可选在 Kubelet 的配置中增加MemorySwap.SwapBehavior=UnlimitedSwap 更多内容可参考：github.com/kubernetes/… HPA v2 API 达到 GAHPA v2 大约是在 5 年前首次提出，经过这 5 年的发展，终于在现在它达到了 GA 级别。 安全性Pod Security Policy 的替代品PodSecurity admission controller是在 Kubernets v1.21 中被废弃的PodSecurity Policies的替代品。 这个 admission controller 可以按 namespace 级别启用PodSecurity Standards，可以有以下三种模式： enforce: 违反策略的 Pod 将被拒绝； audit：违反策略的 Pod 将会添加审计注释，但其他情况下都允许； warn：违反策略的 Pod 将会触发面向用户的警告； 可通过如下配置文件进行控制： apiVersion: apiserver.config.k8s.io/v1kind: AdmissionConfigurationplugins:- name: PodSecurity configuration: defaults: # Defaults applied when a mode label is not set. enforce: default enforce policy level enforce-version: default enforce policy version audit: default audit policy level audit-version: default audit policy version warn: default warn policy level warn-version: default warn policy version exemptions: usernames: [ array of authenticated usernames to exempt ] runtimeClassNames: [ array of runtime class names to exempt ] namespaces: [ array of namespaces to exempt ]可扩展性新增 OpenAPI V3这个特性是 Alpha 级别，可通过OpenApiv3feature gate 进行开启。 增加此特性主要是由于 CRD 目前可通过 OpenApi V3 进行定义，但是 api-server 目前还不支持。当从 OpenApi V3 转换为 V2 时，部分信息将会丢失。 更多详细信息可参考KEP #2896 CRD Validation 表达式语言这是一项 Alpha 级别的特性，默认是不开启的。可通过增加CustomResourceValidationExpressionsfeature gate 来进行开启。单独介绍此 Alpha 级别的特性是因为目前基于 Custom Resource Definitions (CRDs) 的方式对 Kubernetes 进行扩展已经成为主流，但是在 CRD 中目前能添加的校验规则有限，更多的场景都需要通过额外的 Admission 来完成。 此功能使用一种叫做 Common Expression Language (CEL) 的语言进行规则定义，通过x-kubernetes-validation-rules字段进行规则的添加。 例如，某个 CRDs 的内容如下，其中定义了minReplicas小于replicas并且replicas小于maxReplicas。 ...openAPIV3Schema: type: object properties: spec: type: object x-kubernetes-validation-rules: - rule: "self.minReplicas = self.replicas" message: "replicas should be greater than or equal to minReplicas." - rule: "self.replicas = self.maxReplicas" message: "replicas should be smaller than or equal to maxReplicas." properties: ... minReplicas: type: integer replicas: type: integer maxReplicas: type: integer required: - minReplicas - replicas - maxReplicas那么，当有如下的自定义资源创建时，Kubernetes 将会拒绝其请求。 apiVersion: "stable.example.com/v1"kind: CustomDeploymentmetadata: name: my-new-deploy-objectspec: minReplicas: 0 replicas: 20 maxReplicas: 10并且返回如下错误： The CustomDeployment "my-new-deploy-object" is invalid:* spec: Invalid value: map[string]interface {}{"maxReplicas":10, "minReplicas":0, "replicas":20}: replicas should be smaller than or equal to maxReplicas.这样相比原来我们通过 Admission 的方式来进行校验就会方便的多。 易用性增加kubectl alpha events命令增加此命令主要是由于在不修改kubectl get的前提下，查看event有一些限制，所以直接增加kubectl events命令可以更方便的去获取到需要的信息，尤其是 event 是在 Kubernetes 中经常需要查看的一个信息。kubectl get events比较典型的一些问题, 比如排序（虽然可以通过加参数解决）， watch，以及无法按照时间线方式去查看 events 等。 Kubernetes 生态的 2021Service Mesh 在 Kubernetes 生态中，今年最主要的不同是在 Service Mesh 领域迎来了一个新的选手：Cilium Service Mesh。 在之前，Service Mesh 的典型架构是以 Istio 和 Linkerd 等为代表的，基于 Sidecar 的架构模式。在应用程序的 Pod 中自动的注入一个 Sidecar 用于流量的管理等相关能力。 但是 Cilium Service Mesh 提出了 Sidecarless 的模式，通过 eBPF 技术的加持，带来了更加安全，高性能，以及良好的可观测性。 这也将引起了新一轮的变革。 Serverless今年，Severless领域出现了一些新选手，比如国内青云团队开源出来的 OpenFunction 等项目。 2012年，Severless概念正式提出，2014年Serverless开启商业化之路，2021年是Serverless规模化落地的关键一年，几乎所有的科技公司都有各种方式、形式的Serverless应用落地。 2022 展望2022 年，Kubernetes的技术趋势可能将围绕安全性和eBPF展开。 安全性随着云原生的普及，越来越多的公司已经越过了最初的探索阶段，迈入了实际使用或更大规模应用的阶段。 安全性成为了另一个受大家关注的核心。其中包括供应链安全，DevSecOps 以及 Kubernetes 在使用时遇到的各种安全性问题。 在 2022 年，这方面也会得到更多的重视。 eBPFeBPF 技术将会得到更多的普及，不仅是用于可观测性。也会被用于提升 Kubernetes 集群整体的网络性能，还有包括像 Cilium Service Mesh 等这样的架构层上的变革。 这些都会提升 eBPF 技术在云原生时代的重要性。 作者介绍 张晋涛，API7.AI 云原生技术专家，Apache APISIX committer, Kubernetes ingress-nginx reviewer，containerd/Docker/Helm/Kubernetes/KIND 等众多开源项目 contributor， 『K8S 生态周报』的维护者，微软 MVP 。对 Docker 和 Kubernetes 等容器化技术有大量实践和深入源码的研究，业内多个知名大会讲师，PyCon China 核心组织者之一，写有 《Kubernetes 上手实践》和 《Docker 核心知识必知必会》等专栏。公众号：MoeLove 相关阅读： 年终盘点Serverless：工业、学术、社区遍地开花，国内厂商迅速卡位