「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。
rkt 项目正式被 CNCF 归档
8 月 16 日，CNCF 宣布技术委员会已经投票通过将 rkt 项目归档。
这个事情，我在几周前的周报大概介绍过，既然现在已经尘埃落定，不如一起来看看 rkt 的前世今生，毕竟它在容器技术的发展中也曾做出了很多贡献。
rkt 最早是由 CoreOS 公司创建的，而 CoreOS 最早应该也算是 Docker 的用户之一。但是随着 Docker 发展的日趋壮大，CoreOS 就想要脱离 Docker，成立自己的标准。
之后 CoreOS 发布了 AppC 规范（这个规范我也曾仔细研究过），而 CoreOS 主打的旗号是开放，毕竟当时 Docker 一枝独秀，所以也就吸引了不少的伙伴参与。当然 rkt 也就借着这股风，得到了不少人的青睐。
这里且不说 rkt 功能或是规范如何，我们单独来看看那场容器市场份额的争夺战是如何打的。
在那时候，同时进行的另外一场战役是容器编排系统的战役。所以 rkt 也算是做了努力，它选择了与 Kubernetes 的合作（大概算是共同阵营的合作吧），所以在 2016 年 Kubernetes 1.3 版本中，宣布了支持 rkt 作为容器运行时的一个可选想。
但 Docker 的发展（指 Docker 项目），却几乎没有受到影响。为什么呢？ Docker 早已凭借自身的稳定性和易用性占领了大批的用户，即使有用户选择 rkt 大多也只是用于尝试（心疼选择 rkt 放入生产环境中的那批）。而且不得不说，Docker 在用户心中几乎是容器的代名词，是一个默认选项。
所以很自然的 rkt 在此战役中失败，之后 Kubernetes 也抛弃了对 rkt 的支持。 另外，CoreOS 公司的发展可能对造成 rkt 的现状也有很大的关系。
最后，最关键的其实还是因为项目存活率，我们来用数据说话：
关于事情的官方报道是：CNCF Archives the rkt Project
CNI Plugins v0.8.2 发布
是一个 bugfix 的版本，但是要注意的是这个版本中包含了一个错误修复 #366 , 当在节点启动时，同时运行多个 Pod ，cni0 网桥将被多个 goroutine 创建，这就有可能引起一个错误 failed to set bridge addr: could not add IP address to \"cni0\": file exists.
关于此版本的更多细节请查看 ReleaseNote
Istio 1.2.4 发布，大量安全更新
这个版本中有大量的安全更新，建议尽快升级。
我们来看看漏洞的影响，主要是 CVE-2019-14993， CVE-2019-9512，CVE-2019-9513，CVE-2019-9515，CVE-2019-9518 这些漏洞主要是可能被用来做 DoS 攻击。当然原问题是在 Envoy 上 的。
关于此版本的更多内容请参考 ReleaseNote
可以通过下面二维码订阅我的文章公众号【MoeLove】，在公众号后台回复 k8s 可加入技术圈交流。
