kubernetes 中的增强特性(Kubernetes Enhancement Proposal)

kubernetes 增强特性(kep)是为了解决社区中的疑难问题而创建的一个项目,每一个增强特性都对 kubernetes 的部分功能有较大的影响,需要 kubernetes 项目下的多个组(SIG)协作开发,对应的特性通常要经过 alphabeta以及 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 操作的首个参数中。

参考:20200123-client-go-ctx.md

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 中也不可用 ,如 devicenet_cls, net_prio 等,对于这部分不可用的 controller 社区将会使用 eBPF 替换他们;

参考文档:20191118-cgroups-v2.md

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 请求;

官方文档:20191117-immutable-secrets-configmaps.md

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 142,461评论 1 300
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 61,089评论 1 256
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 94,078评论 0 212
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 40,938评论 0 175
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 48,698评论 1 255
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 38,733评论 1 175
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 30,340评论 2 268
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 29,138评论 0 165
  • 想象着我的养父在大火中拼命挣扎,窒息,最后皮肤化为焦炭。我心中就已经是抑制不住地欢快,这就叫做以其人之道,还治其人...
    爱写小说的胖达阅读 28,949评论 6 229
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 32,493评论 0 213
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 29,269评论 2 214
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 30,591评论 1 229
  • 白月光回国,霸总把我这个替身辞退。还一脸阴沉的警告我。[不要出现在思思面前, 不然我有一百种方法让你生不如死。]我...
    爱写小说的胖达阅读 24,216评论 0 31
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 27,107评论 2 213
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 31,485评论 3 204
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 25,615评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,006评论 0 167
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 33,496评论 2 230
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 33,572评论 2 230

推荐阅读更多精彩内容