关于kubernetes:K8S-生态周报-Kubernetes-v125-将添加-user-namespaces-的支持

21次阅读

共计 2932 个字符,预计需要花费 8 分钟才能阅读完成。

「K8S 生态周报」内容次要蕴含我所接触到的 K8S 生态相干的每周值得举荐的一些信息。欢送订阅知乎专栏「k8s 生态」。

大家好,我是张晋涛。

本周同样是繁忙的一周,一个教训分享给大家,优先答复问题而非解释细节。这也就是为什么我常常在文章的结尾都会先阐明下文章次要涵盖的内容,这样有助于节省时间。

我本周闲暇工夫根本都在关注上游的停顿,没空折腾其余的货色。
Kubernetes v1.25.0-rc.0 已于本周公布,失常状况下会在本月公布正式版本。

我来介绍一些本周关注到比拟值得注意的内容:

上游停顿

  • Add support for user namespaces phase 1 (KEP 127) by rata · Pull Request #111090 · kubernetes/kubernetes

这个 PR 实现了 KEP127 的第一阶段,KEP127 旨在为 Pod 增加 user namespaces 的反对。
对 user namespaces 不太熟悉的小伙伴,能够看看我之前的系列文章:《搞懂容器技术的基石:namespace(上)》和《搞懂容器技术的基石:namespace(下)》。

在 Kubernetes 中反对应用 user namespaces 的益处在于,能够在与主机有不同 UID/GID 的 Pod 中运行过程,这样在 Pod 内的特权过程
理论是作为主机中的一般过程运行的。这样,假如 Pod 内的特权过程因为安全漏洞被攻破,对主机的影响也能够降到比拟低。

间接相干的破绽,比方 CVE-2019-5736,我也曾在 2019 年的文章《runc 1.0-rc7 公布之际》专门介绍过,
感兴趣的小伙伴能够到该文章中理解详情。

该实现是在 Pod 的 Spec 中增加了布尔类型的 HostUsers 字段,以决定是否启用主机的 user namespaces,默认是 true。

此外,目前可预感的状况是,如果 Kubernetes 集群应用的 Linux 内核版本在 v5.19 以下的话,那么应用该个性可能会导致 Pod 的启动工夫减少。

期待后续的停顿。

  • cleanup: Remove storageos volume plugins from k8s codebase by Jiawei0227 · Pull Request #111620 · kubernetes/kubernetes
  • cleanup: Remove flocker volume plugins from k8s codebase by Jiawei0227 · Pull Request #111618 · kubernetes/kubernetes
  • cleanup: Remove quobyte volume plugins from k8s codebase by Jiawei0227 · Pull Request #111619 · kubernetes/kubernetes

在上周的「k8s 生态」中我曾介绍过,in-tree 的 GlusterFS plugin 在 PR #111485 中被废除。
上述的这几个 PR 所做的事件根本相似,是一些清理操作。

将 Kubernetes 我的项目中 StorageOSFlockerQuobyte 等 in-tree 的卷插件都删除掉了。

其中 StorageOSQuobyte 如果有在应用,倡议往 CSI plugin 进行迁徙,而 Flocker 则是因为不再保护了,所以并没有任何迁徙打算。

只管 Flocker 不再保护了,不过我感觉还是能够略微介绍下它(算是把本人曾记得的一些事件倒进去,大略当前就能够平安删除了,hahah)

如果是比拟晚期参加到 Docker/Kubernetes 生态的小伙伴,可能还会记得 Flocker 这个工具,
这个工具次要解决的是容器化利用中数据卷治理的问题,这在 2015 年左右算是容器生态圈最次要解决的问题之一。

在那个时候,涌现进去很多 Docker volume plugin,做的事件其实都差不多,但这个我的项目背地的公司 / 团队却比拟有意思。

这家名为 ClusterHQ 的公司,和当初很多的开源商业化公司相似,以开源软件 Flocker 作为其出发点,先后实现了 Docker/Kubernetes/Mosos 等各种平台的集成,
后续推出了其 SaaS 服务 FlockerHub。

团队成员也大多数来自于出名开源我的项目 Twisted,用 Python 的小伙伴应该很少有人不晓得这个我的项目。
很天然的,Flocker 也是用 Python 构建的。

但就是这样一家看起来都还不错的公司,在它的 SaaS 服务推出预览版后的一段时间后,就忽然发表敞开了。

当年很多人猜想,兴许是公司将商业外围放在了 SaaS 上,然而该产品并没有真正流行起来。

其实这类事件在整个容器生态畛域,曾经产生了很多,并且还在继续的产生。
这背地更多的其实是商业化逻辑,只管 Flocker 也曾炽热一时,但在商业公司敞开后,也就间接进行保护了。

当初从 Kubernetes 中将其删除,很可能在是风行我的项目中最初一次看到 Flocker 的名字了。

  • Promote CronJobTimeZone to beta by soltysh · Pull Request #111435 · kubernetes/kubernetes

CronJob TimeZone 的个性达到了 Beta 阶段。不过依据 Kubernetes 最新的个性策略,该个性依然须要手动开启 CronJobTimeZone feature gate。

留神,CronJob 如果不设置 TimeZone 的话,默认应用的是 kube-controller-manager 过程的 TimeZone。
之前有遇到小伙伴在这个问题上节约了一些工夫。

Cloud Native Security Whitepaper version 1.0 有声读物公布

该音频是 2020 年版本的 Cloud Native Security Whitepaper,能够从 soundcloud 听到。

当初 Cloud Native Security Whitepaper v2 的文字版也曾经公布,能够从以下仓库中获取到。

https://github.com/cncf/tag-s…

cri-dockerd 公布 v0.2.5

想必大家还记得之前探讨比拟多的 Kubernetees 移除其 dockershim 组件的事件,我也专门曾写了一篇文章《K8S 弃用 Docker 了?Docker 不能用了?别逗了!》对此事件进行阐明。

现在 Kubernetes 曾经将其 in-tree 的 dockershim 组件彻底移除,而 Mirantis 也正在如履行其之前的承诺,在保护 Mirantis/cri-dockerd 我的项目。

该我的项目曾经逐渐的进入绝对标准的保护期,也正在追随上游进行继续的演进。

比方在 v0.2.5 版本中,将默认的网络插件批改成了 CNI。

如果有小伙伴的 Kubernetes 集群中,依然应用 Docker 作为容器运行时,并且想要对 Kubernetes 集群进行降级的话,能够查看此我的项目。
应用起来并不麻烦。

期待后续的体现。

好了,以上就是本期的内容,我想发动一个投票理解下大家目前在用的 Kubernetes 版本,欢送大家参加,在 v1.25 公布后投票主动敞开,届时再和大家分享数据。

https://wj.qq.com/s2/10618008…


欢送订阅我的文章公众号【MoeLove】

正文完
 0