K8S 生态周报| runc v1.0-rc92 发布

网易有道资深运维开发

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

微软开源了 Open Service Mesh

微软近期开源了一个新的名为 Open Service Mesh[1] 的项目并准备捐赠给 CNCF[2] 。

OSM 主打轻量&可扩展，支持 Service Mesh Interface (SMI) 规范[3] 附带开箱即用的可观察性功能。截至目前，已经发布了v0.2.0 版本。

主要特性如下：

支持 Service Mesh Interface (SMI) 的规范，主要包括 Traffic Access Control， Traffic Specs 和 Traffic Split 。剩下的 Traffic Metrics 正在开发中；
服务间的通信加密使用 mTLS ；
定义和执行服务间的访问控制[4]策略；
通过 Prometheus 和 Grafana 完成器观察性；
可与外部证书管理服务进行集成；
Envoy sidecar [5] 自动注入；

关于 Open Service Mesh 更详细的内容，请参考我上一篇文章 初试 Open Service Mesh（OSM）[6]

runc v1.0-rc92 发布

这个版本在本周发布，主要是因为上个版本 v1.0-rc91 发布之后，我发现了它会导致 Docker 无法使用 --privileged 参数运行一个容器，总是会提示 invalid argument 这个错误。

查看代码后，发现它来自于 Golang 中 golang.org/x/sys/unix 的 unix.Mknod() 这个方法，这其实是一个系统调用。本着求真务实的态度，我去检查了下这个函数的源码， glibc 以及 linux kernel 的源码，一番折腾后，也定位到了问题所在。

发现问题来自于 runc 的某次修改，并联系到了 runc 的维护者 Aleksa Sarai ，他在一次更新中 删除了一段用于检查设备类型的代码，所以才导致了隐藏在 runc 中的 bug 这次被暴露了出来。

而这个 bug 目前只影响到了 Docker ，并未影响 runc 作为容器运行时自身的功能。

随后 Aleksa Sarai 提交代码进行了漏洞修复，我们来看看这段折腾了我好几天的代码：

- switch {
- case mode&unix.S_IFBLK == unix.S_IFBLK:
+ switch mode & unix.S_IFMT {
+ case unix.S_IFBLK:
    devType = configs.BlockDevice
- case mode&unix.S_IFCHR == unix.S_IFCHR:
+ case unix.S_IFCHR:
    devType = configs.CharDevice
- case mode&unix.S_IFIFO == unix.S_IFIFO:
+ case unix.S_IFIFO:
    devType = configs.FifoDevice
default:
    return nil, ErrNotADevice

其实就是一段用来判断系统设备类型的代码，但很遗憾，之前的类型判定一直都是错误的，用来判定设备类型，不能使用类似 mode&unix.S_IFBLK == unix.S_IFBLK 这样的方法，而是需要使用 mode & unix.S_IFMT 作为判定。

这在 Linux 内核的源码中也早有体现 https://github.com/torvalds/linux/blob/bcf876870b95592b52519ed4aafcf9d95999bc9c/include/uapi/linux/stat.h#L21-L27

// include/uapi/linux/stat.h
#define S_ISLNK(m) (((m) & S_IFMT) == S_IFLNK)
#define S_ISREG(m) (((m) & S_IFMT) == S_IFREG)
#define S_ISDIR(m) (((m) & S_IFMT) == S_IFDIR)
#define S_ISCHR(m) (((m) & S_IFMT) == S_IFCHR)
#define S_ISBLK(m) (((m) & S_IFMT) == S_IFBLK)
#define S_ISFIFO(m) (((m) & S_IFMT) == S_IFIFO)
#define S_ISSOCK(m) (((m) & S_IFMT) == S_IFSOCK)

最终，这个修复被合并了，Docker 也可以继续和新版本的 runc 一起工作了。(个人体会就是，有些 bug 隐藏太深，这段代码我之前看过，但太像了，被我给忽略掉了 orz)

containerd v1.4.0-rc.0

这是 containerd 的第 5 个主要版本，此版本中包含了大量的更新，比如对 CGroups v2 的支持，扩展的 SELinux 支持，通过 CRI 提供了 Kubernetes On Windows 的支持，共享远端存储的快照支持等。

此版本中包含的重大 bug 的修复也会移植到当前还受支持的版本中。此外，在这个版本中，也包含了两个不向后兼容的 API 修改，需要注意。

以下是我觉得值得关注的变更：

[#3726](https://github.com/containerd/containerd/pull/3726, 3726) 添加对 CGroups v2 的支持；
[#4384](https://github.com/containerd/containerd/pull/4384, 4384) 标记 io.containerd.runtime.v1.* 和 io.containerd.runc.v1 这两个 runtime 为废弃。 在当前 Docker v19.03.x 版本中，默认的 runtime 调用的 API 就是 io.containerd.runtime.v1.linux , 如果要升级 Docker 或者单独升级 containerd ，需要格外注意;
[#3765](https://github.com/containerd/containerd/pull/3765, 3765) 支持 FUSE 挂载；
[#3972](https://github.com/containerd/containerd/pull/3972, 3972) 修复了镜像并发下载的问题；
[#3925](https://github.com/containerd/containerd/pull/3925, 3925) 为快照添加了 cleanup 的 API；
[#4439](https://github.com/containerd/containerd/pull/4439, 4439) 安装 containerd 的时候，不需要在额外安装 libseccomp，内置了；

以上就是我认为 containerd v1.4.0-rc.0 中值得注意的变更，更多关于此版本的信息，请参考其 ReleaseNote[7]

Docker v19.03.13-beta2 发布

本次版本主要是进行一些 bugfix，目前没什么太值得单独聊的，本期暂且跳过，等正式版本发布时再具体聊。

上游进展

#93570 componentstatus API 被标记废弃。

有时，我们会通过 kubectl get componentstatus 来查看集群组件是否健康。例如：

(MoeLove) ➜  ~ kubectl get componentstatus
NAME                 STATUS    MESSAGE             ERROR
controller-manager   Healthy   ok                  
scheduler            Healthy   ok                  
etcd-0               Healthy   {"health":"true"}

但随着 secure port 相继被启用，这个 API 已经不能很好的正常工作了。所以现在将其标记为废弃，不建议再通过此 API 来获取集群组件的状态信息了。

欢迎订阅我的文章公众号【MoeLove】