K8S 生態週報| Podman 開始廢棄 CNI plugins, 推進自己的網路堆疊

張晉濤發表於2023-01-30
K8SPlugin
「K8S 生態週報」內容主要包含我所接觸到的 K8S 生態相關的每週值得推薦的一些資訊。歡迎訂閱知乎專欄「k8s生態」。

大家好，我是張晉濤。

BuildKit v0.11 釋出

BuildKit 我以前有很多篇文章中都有介紹過了。
它是 Docker 的下一代構建引擎，目前在 Docker Desktop 中已經預設啟用，在 Docker 的下一個版本 v23.0 中也會預設啟用，對 Docker 中構建引擎感興趣的小夥伴可以檢視我之前的 《萬字長文：徹底搞懂容器映象構建 | MoeLove》。

同時它也可以作為獨立的映象構建工具使用，很多人在將 Kubernetes 叢集中的容器執行時從 Docker 替換為 containerd 後，想要尋找新的映象構建工具，我推薦可以嘗試下 BuildKit。

BuildKit 的發展還是很不錯的，目前已經有 6.3K 的 star。本次釋出的 v0.11 中有很多值得關注的內容。

  • 內建的 Dockerfile 前端升級到了 v1.5
  • 可以為構建結果生成 SBOM ，以便看到其相關的依賴；
  • 可以為構建結果設定 OCI annotations 了，並將其匯出為 images;
  • 新的 Build History API 允許監聽構建開始和完成，以及構建過程的事件；
  • 新的 remote cache: Azure Blob Storage 和 S3;
  • 支援了 Nydus 格式；

更多關於此版本的變更可以檢視其 ReleaseNote

OPA v0.48.0 釋出

Open Policy Agent 我在之前的文章 《Open Policy Agent (OPA) 入門實踐 | MoeLove》進行過介紹，感興趣的小夥伴可以看看。

本次釋出的版本中增加了如下值得關注的變更：

改善了 opa eval 命令的錯誤報告

例如有如下規則，因為 0 不能作為除數，所以很明顯這兩個規則都是錯誤的。

package play

this_errors(number) := result {
        result := number / 0
}

this_errors_too(number) := result {
        result := number / 0
}

res1 := this_errors(1)

res2 := this_errors_too(1)

而且在 OPA 中，這其實會得到一個 undefined 的錯誤。

(MoeLove)➜  opa run
> 1/0
> undefined

為了便於除錯，OPA 提供了 --strict-builtin-errors 引數，可以允許使用者得到執行期間的發現的第一個錯誤，然後立即終止。效果如下：

(MoeLove)➜  opa eval --strict-builtin-errors -d multi-error.rego data.play
1 error occurred: multi-error.rego:4: eval_builtin_error: div: divide by zero

但很明顯，只拿到第一個錯誤對於除錯而言往往是不夠的（需要不停的修正錯誤，然後再次除錯，效率很低）。所以在這個版本中新增了 --show-builtin-errors 引數，允許展示所有發現的錯誤。效果如下：

(MoeLove)➜  opa eval --show-builtin-errors -d multi-error.rego data.play -f pretty
2 errors occurred:
multi-error.rego:4: eval_builtin_error: div: divide by zero
multi-error.rego:8: eval_builtin_error: div: divide by zero

其他

  • 新增了 time.format 內建函式；
  • 對於 rule 索引進行了一系列最佳化，索引的查詢時間與規則數量成正比；
  • 在 bundle fetch 的時候可以支援 AWS 的 Signature Version 4A (SigV4A) 方法了，以便於使用 Amazon S3 Multi-Region Access Points (MRAP);

更多關於此版本的變更可以檢視其 ReleaseNote

Podman 開始廢棄 CNI plugins

在 Podman 建立之初，它就使用 CNI 作為它的網路堆疊了，但是 CNI 畢竟不是 Podman 原生的元件，所以會有一些 Podman 中想要有的功能，但是 CNI 中並不打算支援，這實際上就出現了一些分歧。

所以 Podman 在去年的時候建立了自己的 containers/netavark: Container network stack 和 containers/aardvark-dns: Authoritative dns server for A/AAAA container records. Forwards other request to host's /etc/resolv.conf 專案，用來構建 Podman 自己的網路堆疊。

該專案經過一年時間的打磨和使用者的反饋，目前與上游的 CNI 外掛相比，只是在 MACVLAN 的 DHCP 支援上稍有不足，但是後續會補上，另外，該網路堆疊目前主要的一些特性包括：

  • 透過 JSON 配置檔案配置容器網路；
  • 建立和管理網路介面，包括 MACVLAN 網路；
  • 配置防火牆規則，NAT 和埠轉發等能力；
  • 目前支援 iptables 和 firewalld ，未來會支援 nftables ；
  • 支援 rootless 容器；
  • 支援 IPv4 和 IPv6；
  • 可以透過 aardvark-dns 專案完成容器 DNS 解析的能力；

Podman 團隊打算接下來開始廢棄 CNI Plugins 的支援，但這可能會持續很長時間。目前 Podman 自己的網路堆疊是從 Podman 4.x 開始引入的，使用者可以透過 podman info 命令檢視自己在用的網路堆疊，比如：

$ sudo podman info
host:
  arch: amd64
  buildahVersion: 1.29.0-dev
  ...
  memFree: 16088698880
  memTotal: 33380950016
  networkBackend: netavark
  ociRuntime:
    name: crun
    package: crun-1.7.2-3.fc37.x86_64
    ...

在輸出中的 networkBackend: netavark 就表示在用 Podman 自己的網路堆疊了。

其實這件事情也不算是啥大事兒，很多人可能根本沒用過 Podman，但從這個事情中也反映出一些問題，以下是我的一些想法：

Podman 早期屬於儘可能貼近開源社群和一些現成標準，然後基本上是照著 Docker 把所有的功能複製了一遍，所以早期宣傳 Podman 的時候有一句話是：你可以新增一條 alias alias docker='podman' 完成替換。

後來隨著 Podman 有了一些使用者基礎，開始照著 Docker 的生態構造自己的元件了，比如 Podman, Buildah, Skopeo, conmon-rs, crun, Podman Desktop 和 youki。

這些專案基本上是對照著 Docker 生態中的元件來自己實現了一遍，並且納入到了該組織下。它的背後最主要的公司是 Red Hat 。

所以目前在容器領域，基本可以認為存在有兩個陣營，看後續的發展吧。

Argo Rollouts v1.4 釋出

我之前寫了一篇文章 GitOps 應用實踐系列 - Argo CD 的基本介紹 | MoeLove ，Argo CD 是 Argo 生態中的一個專案。

Argo 生態目前主要由四個子專案組成，包括：

  • Argo Workflows -- 第一個 Argo 專案，是 Kubernetes 的原生工作流引擎，支援 DAG 和 step-based 的工作流；
  • Argo Events -- Kubernetes 上的基於事件的依賴管理器，用於觸發 Kubernetes 中的 Argo 工作流和其他操作。
  • Argo CD -- 是 Argo 社群和 Intuit 帶來的開源專案，支援基於 GitOps 的宣告性部署 Kubernetes 資源。
  • Argo Rollouts -- 支援宣告式漸進式交付策略，例如 canary 、blue-green 和更多形式。

Argo Rollouts v1.4 中包含了一些主要的變更：

  • 支援基於 revisions 的快速回滾，這在生產環境中想要快速回滾的時候，非常有用；
  • 提供了 Apache APISIX Ingress 的支援，使用者可以在這個版本中配合 Apache APISIX Ingress 進行漸進式交付；
  • 允許為 canary 釋出的時候設定最小 ReplicaSet 的 Pod 數；

更多關於此版本的更新，請檢視其 ReleaseNote

上游進展

這是 KEP 135 的後續，在 Kubernetes v1.19 中廢棄的 seccomp.security.alpha.kubernetes.io/pod 和 container.seccomp.security.alpha.kubernetes.io 這兩個 annotation ，在這個 PR 中被徹底刪除了。

使用者如果想要使用 seccomp 相關配置，請正確設定 securityContext.seccompProfile 即可。

其他

  • 由 ARMO 建立的 Kubescape 被 CNCF 接受成為了 sandbox 級別的專案，主要是作為 Kubernetes 安全平臺。

歡迎訂閱我的文章公眾號【MoeLove】

TheMoeLove

相關文章