K8S 生态周报| 2019-07-21~2019-07-28

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。

Docker CE v19.03 正式发布

7 月 22 日，正式发布了 Docker CE v19.03 版本，按照 Docker CE 版本的生命周期，此次的 v19.03 可以说是千呼万唤始出来，原本按语义应该是在 3 月，不过之前的发布计划中开始是设定在了 5 月份，而一转眼现在已经到 7 月底了。 先跳过这次发布时间延期的问题，我们来看看此版本中最值得注意的一些变化。

首先来看看被废弃的部分：

• 废弃 aufs 存储驱动，在此版本之前 devicemapper 和 overlay 也都已经被废弃;
• 当 docker daemon 运行时，如果没有指定存储驱动，则会自动选择一个，v19.03 中增加了自动选择时跳过已被废弃的存储驱动的逻辑；
• 废弃 image manifest v2 schema1 以支持 v2 schema2 ，这里的废弃涉及到的内容很多，尤其是涉及到了 image registry 的部分, 所以后续还有很长的路要走。还记得之前推送过 Docker Hub 今年 6 月份停止 v1 API 进行 Pull 操作的事情吗？早年 2015 年 11 月的时候，它就已经禁止了 v1 API 的 Push 操作。从这点上也能看到 Docker 在功能弃用上其实为用户考虑了很多，并且也给了足够长的时间来让用户进行迁移。

其次，我们看看功能增强的部分：

• 对 NVIDIA GPU 设备的支持，在 docker CLI 的 docker run 命令中添加了 --gpus 参数，用于为容器添加 GPU 设备。事实上，大家需要注意的是，这里严格的表述应该是它目前是对 NVIDIA GPU的支持而不是很多国内媒体报道的，对 GPU 的支持（毕竟做 GPU 的有很多家），而且现在对 NVIDIA 的支持，也都是硬编码在代码中的，之后还有很长的路要走。至于很多人可能想问，它添加这个支持后，是否还需要安装驱动，安装 CUDA 是否需要安装 nvidia-docker2 之类的， 我在这部分逻辑刚合并后就在机器上实验过了， 代码中硬编码了对 nvidia-container-cli 的依赖，现在修改成了对 vidia-container-runtime-hook 的依赖， 所以，像驱动啊 nvidia-container-cli 之类的东西还是需要装的，只不过用户使用上和原先用法不一样了罢了。（这里非常希望大家能自行尝试下）
• API 更新至了 v1.40；
• 对 /_ping 接口添加了对 HEAD 请求的支持，返回结果中会包含当前 docker daemon 的 API 和版本，系统类型等信息；
• 构建系统有了很多的改进，这里不再一一细述，感兴趣的朋友可以看我写的文章 「Docker 镜像构建原理及源码分析」 这篇文章中使用的源码版本是 v19.03.0-rc2 内容很新；
• 支持 Rootless 模式，事实上这个功能在去年就已经在逐步推进了，但即使是现在，我也尚不推荐将此功能应用于生产环境。（国内有很多媒体对此大肆宣扬来着，说以后可以不用 root 权限了如何如何 - - 我只想说你们有没有真的用过 Rootless 模式，或者有没有在生产实践中验证过） 这个功能确实是有了，但尚不完善，也尚并不能达到替代当前 docker 全部能力的时候，包括它的网络能力，它的存储能力等目前都还有很多路要走；
• 对 docker network 支持了 dangling 状态的筛选支持。

以上便是 v19.03 中我个人认为最值得注意的内容。当然，现在我还要额外多说一点（划重点）：

使用此版本，我们可以在一台机器上同时管理多个 Docker Engine 这是我用了很长时间的功能，特别有用，与大家分享一下具体使用方法：

(MoeLove) ➜  ~ docker context create build-context --description "build context" --docker "host=tcp://172.17.0.3:2375"
build-context                                           
Successfully created context "build-context"
(MoeLove) ➜  ~ docker context ls                 
NAME                DESCRIPTION                               DOCKER ENDPOINT               KUBERNETES ENDPOINT                  ORCHESTRATOR          
build-context       build context                             tcp://172.17.0.3:2375
default *           Current DOCKER_HOST based configuration   unix:///var/run/docker.sock   https://10.234.9.30:8443 (default)   swarm

使用该 context

(MoeLove) ➜  ~ docker context  use build-context 
build-context                                           
Current context is now "build-context"

这样，我们便可以直接在本机管理远程的一台机器上的 Docker Engine 了，当然它也可以支持用 ssh 连接远程主机的模式。

好了，关于此版本的介绍就到这里，对此版本中构建系统有想深入的了解的还是同样建议阅读 「Docker 镜像构建原理及源码分析」 关于此版本中更多的更新内容请参考 ReleaseNote

Helm v3.0.0-alpha.2 发布

这个版本中主要是对 Helm 3 内部的架构进行了优化，所以外部看到的功能特性变化并不是很大。 如果对 Helm 3 还不了解的朋友，推荐阅读 初试 Helm 3 。

更多关于此版本的信息请参考 ReleaseNote

Kubernetes 上游开发进展

按照预期，特性冻结的 deadline 是 7 月 30 日，过段时间，下一个版本就将会正式发布了。

最近合并的 PR 中最值得注意的我个人认为应该是 #59416 将 Ephemeral Containers 添加到 Kubernetes 核心 API 这个 PR 应该归属于 Ephemeral Containers 相关 KEP 的一部分。

其主要目的在于提供一种机制，方便进行容器的在线调试或者监测。可以理解为启动一个与待调试容器具备相同网络和 Namespace 的容器，以此来进行调试。现在我们一般做这个事情一般是手动完成或者借助一些其他工具，但其实不够”优雅”，随着这个 KEP 的完善，希望能弥补这部分的空缺。

可以通过下面二维码订阅我的文章公众号【MoeLove】