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 可加入技术圈交流。点击阅读原文有更好的阅读体验。