kubernetes 增强特性(kep)是为了解决社区中的疑难问题而创建的一个项目，每一个增强特性都对 kubernetes 的部分功能有较大的影响，需要 kubernetes 项目下的多个组(SIG)协作开发，对应的特性通常要经过 alpha、beta以及 GA 三个版本，所以每个方案的开发周期比较长，大多需要经过 9~10 个月才能完成，某些特性甚至已经讨论多年至今仍未开发完成，像 crd、dry-run、kubectl diff、pid limit 等已经开发完成的功能都是在 kep 中提出来的。本文会介绍几个比较重要的已经在 kep 中孵化的特性。
1、client-go 中对 resource 的操作支持传递 context 参数
该特性的目标：
- （1）支持请求超时以及取消请求的调用；
- （2）支持分布式追踪；
以下是新旧版本中用 client-go list deployment 方式的一个对比：
// 老版本中的使用方式
deploymentList, _ := clientset.AppsV1().Deployments(apiv1.NamespaceDefault).List( metav1.ListOptions{})
// 新版本中的使用方式
deploymentList, err := clientset.AppsV1().Deployments(apiv1.NamespaceDefault).List(context.TODO(), metav1.ListOptions{})
可以看到在新版本中 client-go 对于 resource 的操作(verbs)首个参数需要传入 context，当然，社区考虑到用户升级 client-go 代码库时需要对应大量的代码进行改动，kubernetes 社区会对 client-go 的老版本进行一个快照，快照将存在以下几个包中：
k8s.io/apiextensions-apiserver/pkg/client/{clientset => deprecated}
k8s.io/client-go/{kubernetes => deprecated}
k8s.io/kube-aggregator/pkg/client/clientset_generated/{clientset => deprecated}
k8s.io/metrics/pkg/client/{clientset => deprecated}
此次升级无论对于用户还是 kubernetes 社区中的项目无疑都需要非常大的变动，使用 client-go 新版本的用户可以使用 sed 等工具修改代码中的相关用法。对于 kubernetes 社区内部项目代码，所有调用中会使用 context.TODO() 作为初始值添加到对 resource 操作的首个参数中。
2、从 apiserver 的 watch cache 中进行一致性读取
该特性的目标：
1、解决过期数据问题(https://github.com/kubernetes/kubernetes/issues/59848)；
2、当 watch cache 启用后，提高对 resource get 和 list 操作的可扩展性以及性能问题；
从以上 issue 中可以看到其问题出现的场景为：
- 1、集群中存在多个 master 实例，node-1 与 node-2 首先都连接至 apiserver-1；
- 2、由 controller 管理的 pod-0 最初在 node-1 节点上运行，
T2时刻 pod-0 被删除后调度至 node-2 节点，然后 node-2 节点启动了 pod-0； - 3、pod-0 在 node-2 上启动的同时 node-1 节点因异常导致 kubelet 重新启动，此时 node-1 上的 kubelet 连接到了 apiserver-2 上，但 apiserver-2 此时的 watch cache 正好延迟于
T2时刻(因 apiserver-2 网络或者性能问题导致数据延迟)，apiserver 会将自己的 delay cache 中的 pod list 发送给 node-1，此时 node-1 也会启动一个 pod-0，而 node-1 上面的 pod-0 已经处于运行状态；
kubelet 通过 apiserver list 数据时默认将 resourceVersion 设置为 0，此时返回的数据是 apiserver watch cache 中的，并非直接读取 etcd 而来，而因网络或其他原因此时 etcd 与 apiserver watch cache 中的数据可能不同。也就是说，在使用 list/get 时设置 resourceVersion 为 0 可能会获取到过期的数据，当然以上问题会出现在所有的 controller 中。众所周知，resourceVersion 有三种设置方法，第一种当不设置时会从 etcd 中基于 quorum-read 方式获取，此时数据是最新的，第二是设置为 0 从 apiserver cache 中获取，第三种则是设置为指定的 resourceVersion。
那难道在 kubelet list/get pod 时不设置 resourceVersion 解决不了吗？社区给了一个场景，试想在一个超大集群中，有 5K node 且每个 node 有 30 个 pods，此时集群中有 15 万 pods，在此集群中某个 node 使用 list 请求 apiserver 时，其仅仅需要本机的 30 个 pods，而 apiserver 需要从 etcd 中获取 15 万个 pods 对象并过滤出该 node 所需要的 30 个 pods，这种操作对集群的影响是不可预知的，集群性能骤降或者集群宕机都有可能出现。
解决办法：
通过以上描述可知，根本问题是在 apiserver 与 etcd 之间的数据传输时有一定延迟导致的。而在 etcd 3.4+ 版本中支持了在客户端 watch 时启用 WithProgressNotify 参数，当 WithProgressNotify 参数启用后，etcd 会自动发送 progress events，此时客户端缓存中的数据与 etcd 中的数据是一致的，但 etcd 默认每 10 分钟发送一次，社区计划设置 progress events 的时延为 250ms 进行测试，根据社区的讨论，其会在数据准确性、性能以及可扩展性等方面进一步测试以及讨论该决策是否满足需求。
该功能会在 kubernetes 新版本中以 WatchCacheConsistentReads feature gate 的方式开放用户使用。
参考文档：20191210-consistent-reads-from-cache.md
3、支持使用 cgroup v2
该特性的目标：
- 在 kubernetes 中支持使用 cgroup v2；
Linux 内核已经支持 cgroup v2 特性两年多，cgroup v2 一个大的特性就是可以用非 root 用户操作资源限制（例如：可以使用非 root 权限模式运行 kubernetes 组件），该特性在内核中也已经处于稳定版本，某些发现版(例如 Fedora)中已经默认使用 cgroup v2，所以社区计划在 kubernetes 中支持使用 cgroup v2。这是一个庞大的计划，需要分为多步进行，社区首先会在 kubelet 中支持使用 cgroup v2（该特性已经在进行中 #85218），并保证 cgroup v1 的配置在 cgroup v2 上依然可以使用，然后会对 runtime 进行改造以及进行适配，目前 docker，containerd，runc，cAdvisor 等都已经相继增加了对 cgroupv2 的支持。
而从 cgroup v1 转换到 cgroup v2 也有一些风险存在：
- 1、cgroups v1 中部分特性无法在 cgroup v2 中使用，如
cpuacct.usage_percpu和 cgroup 中的network stats； - 2、cgroups v1 中的一些 controller 在 v2 中也不可用 ，如
device和net_cls,net_prio等，对于这部分不可用的 controller 社区将会使用 eBPF 替换他们；
4、volume 被挂载时支持禁止更改 volume 的所有者以及权限
该特性的目标：
- volume 在 mount 时允许跳过更改其所有者以及权限；
目前，在 pod 中使用 volume 时，将 volume 挂载到容器之前时该 volume 中文件的权限以及所有者将被递归地更改为所提供的 fsGroup 的值，这种更改权限的操作可能需要很长时间才能完成，尤其是在非常大的 volume 中(>=1TB)。更改权限是为了保证所提供的 fsGroup 可以对此 volume 进行读写，但此时 pod 可能会启动超时，部分文件权限更改也可能会导致 pod 中某些应用无法启动。为了解决这一问题，社区将会在 pod 中添加一个名为 .Spec.SecurityContext.FSGroupChangePolicy 的字段，允许用户指定希望 pod 使用的 volume 权限和所有者如何更改。
参考文档：20200120-skip-permission-change.md
5. 支持禁用 ConfigMap/Secret 的自动更新机制
该特性的目标：
- 1、引入一种保护机制来禁止 ConfigMap/Secret 的自动更新；
- 2、提高 kube-apiserver 的性能；
社区为 ConfigMap 和 Secret 增加了一个 Immutable 字段来禁止其自动更新：
Immutable *bool
建议使用 Immutable 的 ConfigMap/Secret 主要有两个原因：
- 一是 pod 使用 ConfigMap/Secret 的模式一般是通过 Volume Mounts 的方式，而 kubelet 会通过 Watch/Poll 的方式去获取 ConfigMap/Secret 更新，同时将最近文件同步到 pod 中，这种方式下 pod 能够快速、无感地获取到 ConfigMap/Secret 更新。但这种更新是一把双刃剑，一次错误的更新可能会导致 pod 内进程异常甚至 pod 不可用，而大多数人都不希望使用这种功能，更多的是使用 Rolling Update 的方式，创建一个新的 ConfigMap/Secret 同时创建新的 pod 去引用新的 ConfigMap/Secret；
- 二个是在大规模集群内，kubelet 过多的 Watch/Poll 大量的 ConfigMap/Secret 会给 kube-apiserver 造成巨大的压力（尽管我们在这个 PR 中为每个 Watch 请求降低了一个 Goruntine 的消耗）。而使用了
Immutable的 ConfigMap/Secret，kubelet 也就不会为其建立 Watch/Poll 请求；
