K8S 生態週報| Docker v19.03.6-rc2 發佈

「K8S 生態週報」內容主要包含我所接觸到的 K8S 生態相關的每週值得推薦的一些信息。歡迎訂閱知乎專欄「k8s生態」。

Docker v19.03.6-rc2 發佈

自 2019 年 11 月 15 日 Docker v19.03.5 發佈後，Docker Inc. 包括社區都發生了很多的變化。

v19.03.6 將會是 v19.03 系列的下一個 bugfix 版本。在此版本中，有幾個比較值得注意的內容：

• buildkit: 修復了在觸發 ONBUILD 規則以後，未清理掉 ONBUILD 規則的問題。對於依賴 ONBUILD 指令，且使用 buildkit 的用戶而言是個重要修復；
• buildkit: 修復了啓用了 userns 時，可能致使權限錯誤的問題；
• 使用了 libnetwork 的短 ID, 以免遇到 UNIX_PATH_MAX 的錯誤;

說到這個問題，其實也蠻有趣的，可能很多人都遇到過相似的問題。固然我也想在這個 UNIX_PATH_MAX 的問題上稍微多聊一點。

這個問題其實在四五年前我在 Docker 項目中其餘的部分就遇到過，解決起來也簡單就是縮短路徑長度便可。但你可能會好奇，要縮短到什麼程度呢？多長是合理值呢？

其實這個問題要深究的話，背後有蠻多歷史的，這裏我先跳過。我主要說下如何目前的限制是什麼，這個限制能夠在 Linux 的源碼中找到的。

// include/uapi/linux/un.h
#ifndef _LINUX_UN_H
#define _LINUX_UN_H

#include <linux/socket.h>

#define UNIX_PATH_MAX 108

struct sockaddr_un {
	__kernel_sa_family_t sun_family; /* AF_UNIX */
	char sun_path[UNIX_PATH_MAX];	/* pathname */
};

#define SIOCUNIXFILE (SIOCPROTOPRIVATE + 0) /* open a socket file with O_PATH */

#endif /* _LINUX_UN_H */
複製代碼

能夠看到如今頭文件中定義的是 108 。（ 注意我此處使用的是 Linux 5.4 版本的內核 ）

另外，這個頭文件定義在 include/uapi/linux/un.h 這個 uapi 目錄可能有些人會以爲陌生，其實它是在 Linux 3.x 新增的，其中包含的內容基本就是本來散落在各處的頭文件。這也是爲了解決 Linux 中循環引用的問題。

有點跑題了，回到 Docker v19.03.6 版本上，若是你對此版本有所期待，能夠搶先嚐試下當前的 rc 版。若是追求穩定，能夠再稍微等幾天，等正式版本發佈（大概在兩週內）。

此處破例推薦下個人專欄 《Docker 核心知識必知必會》，當前內容已經更新了一半以上，以 Docker 的最新版本爲基礎，對比舊版本及 Docker 上游發展的差別，並對每一個核心知識點進行由淺入深、從實踐到內部原理的講解，其中也包含了一些 Linux 內核相關的知識。感謝訂閱。

containerd v1.3.3 發佈

本週 containerd v1.3.3 發佈，帶來了一些重要的修復和更新：

• runtime v2 方面，將 runc shim 中 platform 的關閉流程移到了 Shutdown 方法中，這樣能夠確保 platform 只關閉一次；
• 修復了一個 containerd v1.3.0+ 版本及以上 exec 時存在的 eventfd 泄漏的 bug ；

另外，本週 containerd 也發佈了 v1.2.12 版本 。

這兩個版本中均包含了一系列重要的安全更新 CVE-2019-19921 、CVE-2019-16884 和 CVE-2020-0601

建議，若是有在使用 containerd 的朋友請儘早更新。這兩個版本更詳細的變動，請參考 containerd v1.2.12 的 ReleaseNote 和 containerd v1.3.3 的 ReleaseNote

CNCF 發佈了 containerd 項目的旅程報告

CNCF 對 containerd 自建立到畢業後項目的活躍度及社區發展等維度進行了調研，並給出了相應的報告。

總體來看，containerd 自打從 Docker 中誕生開始，截至目前項目及社區發展都挺不錯。

對此報告感興趣的朋友能夠參考 CNCF 的報告: CNCF containerd Project Journey Report 。

Docker 將關閉舊的 APT 和 YUM 倉庫

Docker project 於 2013 年在 PyCon 上首次正式亮相，並逐步成長爲社區項目，因此當時就註冊了 dockerproject.org 和 dockerproject.com 的域名，而且後來在這兩個域名之下託管了 APT 和 YUM 倉庫。

後期隨着 Docker Inc. 的成立，爲了更好的專一於 Docker 的產品 （CE 和 EE），因此就註冊了 docker.com 的域名。而且正式將 APT 和 YUM 倉庫託管到了 download.docker.com。

如今幾乎全部人都已經在使用新的 download.docker.com 的倉庫了（若是你尚未使用，請儘快更新）。

重點： Docker Inc 計劃在 2020 年 3 月 31 日中止老舊的 dockerproject.org 和 dockerproject.com 域名下託管的 APT 和 YUM 倉庫了！

請你們儘早按 Docker 官方文檔中的安裝說明 安裝 Docker，並中止使用老舊的倉庫域名。

上游進展

kubectl run 想必你們都不陌生吧，能夠用它來手動建立各類資源。

在 Kubernetes v1.18 中，會將以前已標註過時的各種 generator 都移除掉。 也就是說，自 v1.18 起使用 kubectl run 命令主要就是建立 Pod 了，而不會建立多餘的 deploy 之類的。

至於像 service 加了 --expose 倒也還能夠建立，只不過相似 --service-generator 這類參數就也都標記廢棄了。

v1.18 以前版本的執行結果是這樣：

(MoeLove) ➜  ~ kubectl run redis --image="redis:alpine"
kubectl run --generator=deployment/apps.v1 is DEPRECATED and will be removed in a future version. Use kubectl run --generator=run-pod/v1 or kubectl create instead.
deployment.apps/redis created
(MoeLove) ➜  ~ kubectl get all -l run=redis
NAME                         READY   STATUS    RESTARTS   AGE
pod/redis-8544698fd7-tvz5q   1/1     Running   0          14s

NAME                    READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/redis   1/1     1            1           14s

NAME                               DESIRED   CURRENT   READY   AGE
replicaset.apps/redis-8544698fd7   1         1         1       14s
複製代碼

v1.18 版本：

(MoeLove) ➜  bin ./kubectl run redis-new --image="redis:alpine"
pod/redis-new created
(MoeLove) ➜  bin ./kubectl get all -l run=redis-new
NAME            READY   STATUS    RESTARTS   AGE
pod/redis-new   1/1     Running   0          12s
複製代碼

題外話

仍是那句老話，注意勤洗手，多喝水，注意休息，照顧好家人。

在家宅着也別忘記學習，再次推薦個人專欄 《Docker 核心知識必知必會》

---

能夠經過下面二維碼訂閱個人文章公衆號【MoeLove】，在公衆號後臺回覆 k8s 可加入技術圈交流。點擊閱讀原文有更好的閱讀體驗。