「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Vitess 正式从 CNCF 毕业 CNCF（云原生计算基金会）在美国时间 2019 年 11 月 5 日宣布 Vitess 正式毕业了。 这是 CNCF 中第 8 个正式毕业的项目，最近的几次周报中，基本都会谈到关于 CNCF 项目毕业相关的信息（忙碌的 Q4 啊） Vitess 最初由 YouTube 在 2010 年创建， 主要是用于 MySQL 横向扩展的数据库系统。据说 Vitess 一直为 YouTube 的所有数据库提供服务，国内貌似是京东使用比较多。 补一张 Vitess 的架构图： 最后，再次 恭喜 Vitess 顺利毕业! Helm v2.16.0 正式发布 在之前的 K8S 生态周报| Helm v2 最后一个特性版本发布中，我介绍了 Helm 正式发布了 v2.15.0 作为 v2 版本的最后一个特性版本。 而本次发布的 v2.16.0 也确实没有主要的特性更新，都是一些问题修复和安全更新等；（在这次版本中是 13 个独立 committers 之一 :) ）

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Jaeger 顺利从 CNCF 毕业 CNCF（云原生计算基金会）在美国时间 2019 年 10 月 31 日宣布 Jaeger 正式毕业了。 这是 CNCF 中第 7 个正式毕业的项目，在上次周报的最后 我才刚提过一些项目提交了毕业申请，也同时以 Jaeger 为时一年的毕业申请申请举了个例子，没想到本周就毕业了。:) Jaeger 最初是由 Uber 受 Dapper 和 OpenZipkin 启发，开源出来的一套分布式追踪系统。它主要可用于微服务架构下的分布式系统的根因分析，性能/延迟优化，服务依赖等方面。截至目前，它在 GitHub 上有 9.4k 的 star ，986 个 fork 以及 115 位贡献者。 它现在的存储后端主要就支持两种 Cassandra 3.4+ 和 Elasticsearch 5.x/6.x ，在这种系统中，随着服务规模的扩大，对后端存储的要求也会很高。另外，它有一套比较现代化的 UI，是基于 react 开发的。 整体来看的话，在使用上基本技术栈就会成为下面这样： 当然实际的架构也可能会因为基础设施而改变，比如说如果已经使用了 SkyWalking 的话，两者倒是也可以结合，大概就会变成下面这样： 不过，对于技术方案的选择，我个人建议是考虑实际需求，以及对各方案进行理性的权衡，否则的话，说不定什么时候就演变成了下面这样：（这个调用链虽然是可以走通的，但此处我是开个玩笑的， 请勿当真） 最后，再次恭喜 Jaeger 顺利毕业！ Helm 2 爆出全版本受影响的漏洞 本周 Helm 官方披露出来一个全版本 (Helm 在 2.

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Helm v3.0.0-beta.5 发布 这将是最后一个 beta 版本，下一个版本将会是 Helm v3.0.0-rc.1 。现在主要精力都集中在一些 bugfix 上，也会有一些设计方面的事情还需要最终确认。 快速的看一下在此版本中新增的内容： 为了能提供更多子命令，现在 helm get 和 helm show 分别移动到了 helm get all 和 helm show all， 这是一个破坏性变更; 对 helm get values 增加了一个 --output 的选项，现在支持三种格式 table, json, yaml； helm test 新增了一个 --logs 的参数，这是在 Helm 2 中新增的； 对此版本感兴趣的朋友可以参考 ReleaseNote Docker Hub 新增双因素认证功能 最近 Docker Hub 上线了 双因素认证 的功能。这个事情主要有两个方面的考虑： DockerHub 希望能给用户更多的安全性，以及提供更完善的功能，以此来吸引个人用户/开源项目/组织/企业等使用； 这个事情其实也算是 4 月份被攻击事件的后续，在上个月的周报中，我也介绍了 Docker Hub 上线了 Access Token 的功能。而这次上线 2FA 更是进一步提高了其安全性！ 关于如何启用 2FA 可直接参考 Docker Hub 的文档 https://docs.

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 文末有活动，欢迎参与。 Docker 19.03.4 正式发布 在本周 Docker 发布了 19.03.4 版本，这个版本主要是为了修复上周周报中介绍的 DOCKER-USER iptables 链丢失的问题。 如果要升级 Docker 版本的话，可选择升级到此版本。 Kubernetes 修复全版本影响漏洞 上周周报中的 上游进展 部分，介绍了对 CVE-2019-11253 的修复，限制 YAML/JSON 的解码大小为 3M 。本周相继发布了以下版本，包含了对此漏洞的修复。 v1.13.12 v1.14.8 v1.15.5 v1.16.2 实际受此漏洞影响的版本是： Kubernetes v1.0.0-1.12.x Kubernetes v1.13.0-1.13.11 (修复于 v1.13.12) Kubernetes v1.14.0-1.14.7 (修复于 v1.14.8) Kubernetes v1.15.0-1.15.4 (修复于 v1.15.5) Kubernetes v1.16.0-1.16.1 (修复于 v1.16.2) 建议对集群进行升级。 但是升级前，请务必先阅读完 https://github.com/kubernetes/kubernetes/issues/83253 的内容 在清楚了解不同版本的行为后，再做升级。 对此漏洞感兴趣的朋友，也可参阅社区公告 Prometheus Pushgateway v1.0 正式发布 Prometheus Pushgateway v1.

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 文末有活动，欢迎参与。 Docker 19.03.3 正式发布 在本周 Docker 发布了 19.03.3 版本，这个版本的变更内容 很重要，我会将主要内容都列出来。(上周周报介绍了 19.03.3-rc1 的一些情况) 已知问题 DOCKER-USER iptables 链丢失；如果你并不需要在 DOCKER-USER 链上定义规则的话，那你也并不会受此问题的影响。 临时解决办法：手动添加丢失的链，操作如下： iptables -N DOCKER-USER iptables -I FORWARD -j DOCKER-USER iptables -A DOCKER-USER -j RETURN 这个问题会在 19.03.4 中进行修复, 很快会进行发布； 实际会把 libnetwork 中有问题的那段代码先去掉。 如果已经升级了此版本的用户，受到此问题影响的话，可以使用上述方式进行临时解决。 安全问题 将 runc 更新到了 v1.0.0-rc8-92-g84373aaa 这其中包含了 runc 中对 CVE-2017-18367 的修复，该漏洞的根本原因在于 libseccomp-golang 中一个错误的逻辑运算 ，有兴趣的朋友可以点开链接看看实际的修复代码，并且也可以发现该代码其实在 2017 年 4 月就已经合并进 libseccomp-golang 的主干中了，但实际上在今年 6 月在 runc 中才真正修复。 这个问题其实反映出来的是当我们在维护项目时，对自己所用的各种依赖需要有所了解和把握，整体来讲，尽可能避免依赖项过旧是个好事儿；并且安全问题非常值得关注。

自 2013 年起，随着 Docker 的正式面世，容器技术迅速成为了基础技术领域中的热门。而在近两三年中，随着容器编排领域的混战结束，Kubernetes 已经成为了容器编排领域事实上的标准。 有一些人存在误解，认为 Kubernetes 的出现取代了 Docker。但事实上，Docker 与 Kubernetes 是相辅相成的。Kubernetes 使用 Docker 作为容器运行时，用来启动应用；当 Docker 容器规模变大时，自然是需要有容器编排工具进行管理的。引用最近一次的网络研讨会后的文章内容： In fact, Kubernetes is better with Docker. And Docker is better with Kubernetes. 无论在使用 Docker 或是 Kubernetes 亦或者是使用基于这些技术的其他衍生技术时，都有可能会遇到一些意料之外的情况，当问题发生时，我们总是希望可以快速定位问题，并且从根本上解决问题。 一般情况下，上层的问题比较容易解决，但如果问题发生在运行时/Docker 或容器上时，如果没有系统性的知识，很难从根本上解决问题；当然，有些时候通过搜索引擎可以帮我们找到一些问题的解决办法，但如果不将其彻底搞懂，以后遇到类似问题可能还是没法快速解决。 我自 Docker 0.9 版本时开始学习和使用，自己踩过了很多坑，活跃在社区中，也帮别人解决了很多问题。现在我的新专栏《Docker 核心知识必知必会》正式上线了，共 51 节，从 7 个核心维度来 系统性 的讲解 Docker 容器技术的核心特性及原理，实践与源码相结合；部分内容会深入到 Linux 内核源码，以此来建立起从内核到 Docker 容器技术的知识体系。 我希望借由这个课程，将 Docker 容器技术的本质和思想与我在开发和运维 Docker 过程中对其原理和实践经验的总结讲清楚，并将结合着实践和核心特性的原理，加深对 Docker 容器技术的理解。 因此，我把课程划分成了三大模块： Docker 入门: 这个模块分成了三篇内容，通过第一篇，带你了解 Docker 容器技术生态的发展脉络；第二篇，是为刚入门 Docker 的读者准备的，也是为后续章节进行铺垫；第三篇是很多读者或公司都常会困惑的问题，Docker 与 Linux 内核兼容性如何，要上生产环境该选择哪个版本？我会在这一篇中与你分享，让你不再困惑。

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 runc v1.0.0-rc9 发布 不知不觉，runc v1.0.0-rc9 于近日发布了。早先关注过我文章的朋友们应该看到过我从去年开始每次在 runc 新版本发布时都有专门写一篇文章进行介绍。这次版本的定位主要是修复 CVE-2019-16884 所以我也就不再单独写文章介绍了（另一个原因是现在在假期，还是多抽空陪陪家人） 先对 CVE-2019-16884 做个简单的介绍。这是一个中等级别的漏洞，其主要影响是 runc 源码中的 libcontainer/rootfs_linux.go 在文件挂载至 /proc 时，少做了一些检查，可绕过 AppArmor 的限制，所以可能导致被一些恶意镜像所利用。 主要的修复方式是将原先的 checkMountDestination 函数改写为 checkProcMount，并在其中添加了对源文件类型的判断，只允许 procfs 类型的文件挂载至 /proc 。 此漏洞影响到的范围是 runc 以及一些使用 runc 作为基础组件的容器管理软件。请尽快进行升级。 此版本的地址是：https://github.com/opencontainers/runc/releases/tag/v1.0.0-rc9 Docker v19.03.3-rc1 发布 自从 Docker 修改维护周期后，Docker 对软件的质量要求有了显著提高，每次版本发布前会经历多阶段的测试和回归，确保软件没有什么问题后才会发布正式版。 按现在的进度来看 v19.03.3 应该会在一两周内放出。新版本会将 containerd 升级至最新的 1.2.10 ，并修复了一个在 5.2 版本内核上 overlay2 文件系统挂载时的错误。 关于此版本感兴趣的朋友可以参考 ReleaseNote 上游进展 Kubernetes v1.17 已经进入发布周期，这个版本的发布周期会比较短，现在已经发布了 v1.17.0-alpha 版本，计划是在 12 月 9 日可以最终发布。(想想看，距现在也就两个月的时间，你的集群现在是哪个版本呢？)

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 containerd v1.3.0 正式发布 在上个主版本（v1.2.0）后经过 11 个月，我们终于迎来了 containerd v1.3.0 的发布，当然这个版本也是 containerd 自 CNCF 毕业后的首个主版本。（关于 containerd 毕业的信息可参考我之前的文章） 在三周前 containerd v1.3.0-rc.0 发布时，我也提到过一些，现在我们来整体看一下。 增加了 Windows v2 的 runtime API， 同时移除了 Windows v1 API； 为修复 CVE-2019-16884 更新了 runc 依赖； 可配置的插件目录； 允许插件注册为一个 TCP Server ，通过这种机制其实可以做到很多的事情了； 增加了流式处理的插件，允许在解包的时候处理自定义资源类型（设计上考虑可使用此功能进行加解密相关的逻辑）； 支持跨仓库推送镜像； 新增了 devicemapper 的快照支持，然而需要注意的是 Docker 已经将 devicemapper 的存储驱动标记为了过期，推荐大家使用 Overlay2 的存储驱动； 在 CRI 方面 io.containerd.runtime.v1.linux 仍然是默认的运行时，可选配置为新的 io.containerd.runc.v2，新的版本

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Kubernetes v1.16 正式发布 正如我在上次周报中所说，本周 Kubernetes v1.16 正式发布了。此版本中共包含 31 项功能增强：其中 8 项处于 stable 阶段，8 项处于 beta 阶段，剩下的 15 项处于 alpha 阶段。 如果一直关注本周报系列文章的话，这个版本中比较重要的功能我基本都已经提到过了（这里划个重点）。 CRD 达到 GA ，这是当前社区最为推崇的一种扩展 Kubernetes 的方式，并且自从 1.7 加入后，也被越来越广泛的使用了； 准入控制 webhooks 达到 GA ，准入控制在 Kubernetes 中太过于重要了，自 1.9 该功能加入以来，被广泛用于扩展 Kubernetes 相关功能； 现在 CSI 规范中支持调整卷大小，当前正在迁移至 Beta 阶段； IPv4/IPv6 双栈支持； 为了更好的控制 kube-apiserver 的网络流量，正在尝试给它增加一个代理，详情可点击链接查看； 其余还有一些比较重要的内容： 现在 kubeadm 在 TLS bootstrap 之后，将会删除 bootstrap-kubelet.conf，如果有依赖此文件的小伙伴，请尽快迁移使用 kubelet.conf ，此外也建议先看看 RBAC 相关的内容，了解下切换的意义； beta.

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Istio 1.3.0 正式发布 上周 k8s 生态周报中，我推送了关于 Istio 1.3.0-rc2 发布的消息后，有小伙伴专门私聊我，说想问问 Istio 1.3 到底有什么新特性；以及为何上次没有对 Istio 1.3 的新特性进行介绍。 这里我来做下说明，首先关于为何上次没有对 Istio 1.3 新特性进行介绍。有两个主要原因：1. 上周时，正式版尚未发布；2. 对 1.3 这个版本而言没有太多新特性，此版本主要在于改善用户体验。 对 Istio 而言，今年是个很重要的节点，而且自从 3 月份发布 1.1 版本以来， Istio 的更新频率基本稳定在了 3 个月发布一个版本。1.1 版本专注于企业就绪，在此版本中一方面是提升系统的稳定性，另一方面则是解决企业落地时，可能遇到的一些问题，所以 1.1 中有大量的新特性。而 1.2 版本其实也类似，虽然花费了很多精力在保证质量上，但其中也有不少功能从 Beta 到了 Stable 阶段。 其次是关于 1.3 版本到底有哪些新特性： 出站流量自动确定协议：之前版本中，Istio 要求 Service 需要按照指定的规则进行命名才可以自动确认其协议，而在此版本中则可以自动确认其是 HTTP 或 HTTP/2 流量，如果无法自动确认，则认为其是纯 TCP 流量，如果是通过 Helm 安装的话，可以使用 --set pilot.enableProtocolSniffing=false 关闭此功能； Pod spec 中不再需要定义 containerPort，默认情况下会捕获所有端口，当然你也可以通过 traffic.