安装redis k8s_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   108struct 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          14sNAME                    READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/redis   1/1     1            1           14sNAME                               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】