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

微软开源了 Open Service Mesh

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

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

主要特性如下:

  • 支持 Service Mesh Interface (SMI) 的规范,主要包括 Traffic Access ControlTraffic SpecsTraffic 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/unixunix.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】

TheMoeLove