「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。
微软开源了 Open Service Mesh
微软近期开源了一个新的名为 Open Service Mesh 的项目并准备捐赠给 CNCF 。
OSM 主打轻量&可扩展，支持 Service Mesh Interface (SMI) 规范 附带开箱即用的可观察性功能。截至目前，已经发布了v0.2.0 版本。
主要特性如下：
- 支持 Service Mesh Interface (SMI) 的规范，主要包括
Traffic Access Control，Traffic Specs和Traffic Split。剩下的Traffic Metrics正在开发中； - 服务间的通信加密使用 mTLS ；
- 定义和执行服务间的访问控制策略；
- 通过 Prometheus 和 Grafana 完成其观察性；
- 可与外部证书管理服务进行集成；
- Envoy sidecar 自动注入；
关于 Open Service Mesh 更详细的内容，请参考我上一篇文章 初试 Open Service Mesh（OSM）
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 添加对 CGroups v2 的支持；
-
#4384 标记
io.containerd.runtime.v1.*和io.containerd.runc.v1这两个 runtime 为废弃。 在当前 Docker v19.03.x 版本中，默认的 runtime 调用的 API 就是 io.containerd.runtime.v1.linux , 如果要升级 Docker 或者单独升级 containerd ， 需要格外注意; - #3765 支持 FUSE 挂载；
- #3972 修复了镜像并发下载的问题；
-
#3925 为快照添加了
cleanup的 API； -
#4439 安装 containerd 的时候， 不需要在额外安装
libseccomp， 内置了；
以上就是我认为 containerd v1.4.0-rc.0 中值得注意的变更，更多关于此版本的信息，请参考其 ReleaseNote
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】
[
网友评论