K8S 生态周报| Helm 五周岁啦！

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」^[1]。

Helm 五周岁啦！

Helm 于 2015 年，在 Deis 的黑客松中创建（该公司已被微软收购）。在同年的首届 KubeCon 上正式推出现在被称之为 Helm classic 的版本。

2016 年 Helm 团队和 Google，Skippbox，以及 Bitnami 一起创建了 Helm 2 。自此 Helm Chart 工作流就基本定义好了，也就是我们现在在用的样子。

2018 年 6 月，Helm 成为了 CNCF 的孵化项目。在那之后，Helm Hub 也开始托管 Helm Chart 。

最近 Helm 团队做出了一个重大的决定：

Hub 迁移到了 Artifact Hub

Helm Hub 正式迁移到了 Artifact Hub 。

Helm Hub 是构建在 Monocular 项目之上的，根据 Helm 团队的说法，这个项目设计之初仅为处理有限的 Helm repo 。但随着现在 Helm 应用的越来越广泛，Monocular 项目的局限性就暴露了出来。

现在 Helm 团队决定将 Helm Hub 正式迁移到 Artifact Hub 。这个项目可以很好的处理现在的增长问题，并且它不仅可以处理 Helm Chart 也可以处理更多 CNCF 生态中的其他内容。比如 Artifact Hub 中也包含了很多 Falco 规则，可以很方便的一键应用到自己的环境中。

在我使用 GitHub 帐号登录 Artifact Hub 时，总是遇到错误，不过我还没有看具体原因~ 另外，Artifact Hub 项目缺少一些文档之类的信息，但也在逐步完善中。

另外， Artifact Hub 也可能会支持 OCI 兼容的 Helm repo，期待中。

此外，2020 年 4 月 Helm 正式从 CNCF 毕业，现在 Helm 有超过 1500 家公司在使用 Helm 或为 Helm 贡献代码，Helm 组织也管理者大量的 GitHub 仓库。

但在存储 Chart 方面，之前 Helm stable chart 一直托管在 Google 的对象存储中。

在 Helm 五周岁之际，Helm 团队也宣布了一个重要的决定：

Helm stable 和 incubator 的 Chart 仓库，将直接托管在 GitHub 上

并发布了 Helm Chart Releaser^[2] GitHub Action 工具。

感兴趣的朋友欢迎直接在 GitHub 上体验~

Rook 正式从 CNCF 毕业

Rook 为 Kubernetes 提供了云原生的存储解决方案。包括平台，框架，以及对多种存储解决方案的支持，例如：Ceph，minio 等。

它从 2018 年开始被接受成为 CNCF 项目，是第 13 个正式从 CNCF 毕业的项目，也是第一个提供了 block , file 和对象存储的存储类项目。

我也在使用 Rook 来管理 Kubernetes 中的 Ceph 集群，用来提供块存储和对象存储。整体而言是比较方便的，只是版本升级之类的，需要注意下，不需要追的太紧。我在「K8S 生态周报」中，也在持续跟进 Rook 的发展，及每个版本中包含的问题和解决方案之类的，有兴趣的朋友可以看看历史文章。

最后，再次恭喜 Rook 正式毕业！

Rook v1.4.6 发布

此次版本中包含了一些比较重要的更新，我们一起来看看吧：

• #6283 提供了对 IPv6 单栈的支持；

• #6437 对于规模较小的集群，比如但节点的测试集群，则仅启动一个 CSI provisioner， 之前默认是 2；

• #6184 在 LV-backed PVC 上让 OSD 使用 RAW 模式，而非 LVM 模式；

更多关于此版本的变更，请参考其 ReleaseNote

containerd v1.2.14 发布

如果还有在使用 containerd v1.2.x 版本的小伙伴请注意。此版本主要是为了修复 CVE-2020-15157 。该漏洞仅影响 containerd v1.3 之前的版本

相应的，在 Docker v19.03.13 之前，默认使用的均是 containerd v1.2.x 版本。所以如果为了避免受此安全漏洞的影响，也需要对应的升级 Docker 所使用的 containerd 版本，或者直接将 Docker 升级到 v19.03.13 版本。

此漏洞的具体影响是：containerd v1.2.14  之前的版本中，在请求容器镜像的 manifest 时，如果服务端返回 401 响应头，则它会尝试提供登录凭据进行认证。

这种情况下，如果对应的服务端地址是由攻击者控制的，则攻击者就可以获取用户的登录凭证。

解决办法是升级 containerd v1.2.14 或者 containerd v1.3+ 以上的版本。

上游进展

• #95125 kubeadm 废弃了实验性的自托管功能的支持 kubeadm alpha self-hosting 命令将在之后版本进行移除；

• #94712 避免在日志中泄漏 .dockercfg 的内容；

• #78153 新增 kubectl create ingress 命令；

• KEP#1899 增强处理 exec 请求以避免 SSRF 攻击；

题外话

非常抱歉，近期工作很忙，拖更了两篇。感谢大家没有取关~ 后续会继续坚持更新的！

---

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

TheMoeLove

参考资料

[1]

k8s生态: https://zhuanlan.zhihu.com/container

[2]

Helm Chart Releaser: https://github.com/marketplace/actions/helm-chart-releaser