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】

參考資料

[1]

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

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