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

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

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 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

加载评论