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