「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。
大家好，我是张晋涛。
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 -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 的上限，那自然就会影响到它的性能。
这次在 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 可以看到其详细信息。
最终将会影响到拓扑管理器。
内存资源的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 达到 GA
HPA v2 大约是在 5 年前首次提出，经过这 5 年的发展，终于在现在它达到了 GA 级别。
安全性
Pod Security Policy 的替代品
PodSecurity admission controller 是在 Kubernets v1.21 中被废弃的 Pod Security Policies 的替代品。
这个 admission controller 可以按 namespace 级别启用 Pod Security Standards ，可以有以下三种模式：
enforce: 违反策略的 Pod 将被拒绝；
audit：违反策略的 Pod 将会添加审计注释，但其他情况下都允许；
warn：违反策略的 Pod 将会触发面向用户的警告；
可通过如下配置文件进行控制：
apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- 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 级别，可通过 OpenApiv3 feature gate 进行开启。
增加此特性主要是由于 CRD 目前可通过 OpenApi V3 进行定义，但是 api-server 目前还不支持。当从 OpenApi V3 转换为 V2 时，部分信息将会丢失。
更多详细信息可参考 KEP #2896
CRD Validation 表达式语言
这是一项 Alpha 级别的特性，默认是不开启的。可通过增加 CustomResourceValidationExpressions feature 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: CustomDeployment
metadata:
name: my-new-deploy-object
spec:
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 生态的 2021
Service 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 年，这方面也会得到更多的重视。
eBPF
eBPF 技术将会得到更多的普及，不仅是用于可观测性。也会被用于提升 Kubernetes 集群整体的网络性能，还有包括像 Cilium Service Mesh 等这样的架构层上的变革。
这些都会提升 eBPF 技术在云原生时代的重要性。
欢迎订阅我的文章公众号【MoeLove】
