「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Rancher v2.3.3 发布 本周 Rancher v2.3.3 发布，正式支持 Kubernetes v1.16，并将 v1.16.3 设置为 Rancher 默认的 Kubernetes 版本。 在此版本中，值得关注的修复如下： 修复了其不支持 kube-proxy 使用 IPVS 模式的问题; 已知问题： Rancher v2.3.3 在开启 SELinux 的 RHEL 7.7 上使用 RHEL Docker 1.13 时，部署集群将导致失败； 更多关于此版本的特性及已知问题，请关注 ReleaseNote 上游进展 api-server 的 --runtime-config 可使用 api/beta=false 参数禁用所有内置的符合 v[0-9]+beta[0-9]+ 版本的 REST API；同时 --feature-gates 可使用 AllBeta=false 禁用所有内置的 beta 特性。#84304 downward API 为 Dualstack 增加了支持，参数名为 status.

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 containerd v1.3.1 发布 本周 containerd v1.3.1 发布了，我们一起看看其中值得注意的变化： 将 runc 更新至 v1.0.0-rc9 ， 其中包含了对 CVE-2019-16884 的修复，关于此漏洞的更多细节也可参考 https://github.com/opencontainers/runc/issues/2128 ； 修复了一个 v1.3.0 在拉取镜像遇到错误时，解包过程中的死锁问题 #3816 ; 定位了一个 containerd 在主机意外重启时，可能无法恢复损坏的镜像的问题，这个问题是比较有意思的，可能遇到这种情况的环境主要是 containerd 数据目录挂载至非根目录所在的盘中（多数环境中，系统盘的空间并不会很大，所以这种安装情况也算比较常见）。发生此问题的根本原因就在于重启后启动的时机不对（我倾向于这样表述，虽然实际的逻辑是 gc 删除了一些元数据，但它本身的行为是正常的）。所以修复的办法也比较简单， 如果你的 containerd 是使用 systemd 进行管理的，那么可以在 service 的配置文件的 After 块中增加 local-fs.target 的配置 local-fs.target 是 systemd 中一个特殊的单元，和 dbus.service 之类的很多单元类似，都属于特殊的那一类。具体来说它是用来集合本地文件系统挂载点的目标单元，听起来可能比较抽象。实际上就是 systemd-fstab-generator 会在所有本地文件系统挂载单元中添加 Before=local-fs.target 这一条，所以呢，当在 local-fs.target 之后执行的，就表示现在机器上的所有本地文件系统均已经正确挂载。(这也是我认为这个问题有意思的地方） 以上就是我认为在此版本中比较值得注意的点了，对此版本有兴趣的朋友可参阅 ReleaseNote Kubernetes v1.17.0-rc.1 发布 虽然本周在举行 KubeCon 但 Kubernetes 的发布进度也没受太多影响，本周顺利发布了 v1.

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Helm v3.0.0 正式发布 本周 Helm v3.0.0 正式发布了。在 Helm v3 发布第一个 alpha 版时，我就写了一篇 《初试 Helm 3》 在那篇文章中，我介绍了一些 Helm 3 的变化及特性。 现在正式版发布了，我们来正式的看看这个版本带来了哪些值得期待的内容。（PS：我不会在本文中介绍其全部特性，只会聊聊我感兴趣的，对全部特性感兴趣的朋友可以参考其官方文档 https://helm.sh/docs/ ） 移除 Tiller 这个特性想必在任何介绍 Helm 3 的文章中都会有提到，当然在我之前的文章中也有提到。在 Helm 2 时，对于启动了 RBAC 的 Kubernetes 集群而言，在生产环境中想要安全的管理 Tiller 的权限是比较麻烦的。 如果使用默认配置（简单来说也就是没啥特别的限制），那么上手很容易，但对于多租户的集群而言，就没那么安全了。 在 Helm 2 时期，为了简单或者说为了安全，我们可以使用 Tillerless 的方式，来避免在集群中安装 Tiller， 同时还可以正常的使用 Helm 的功能。（很早前计划写篇文章介绍一下这个经验来着，结果至今也还没有腾出时间写，现在 Helm 3 发布，也就不用写了，这里大概聊一下） Tillerless 是什么含义呢？ 也就是在本地启动一个 Tiller 的服务，让它使用你本地的 KUBECONFIG 的配置文件与集群进行交互，而 Helm 在初始化时，只需要初始化 client 即可， 然后可通过 $HELM_HOST 变量控制连接到本地所启动的 Tiller， 之后便可以正常使用了。(每次部署完成后，将 Tiller 关闭即可)

最近 sysdig 发布了 2019 容器使用报告，内容还比较有趣，特别来介绍一下。 关注公众号「Moelove」回复 docker2019 即可获取完整 PDF 报告。 关键信息 容器运行时 Docker 仍然是占据市场规模最大的容器运行时 （79%），而其他的，类似 rkt，lxc，podman 之类的市场占比微乎其微，甚至没有在报告中出现。 containerd 源自 Docker，现在也占据了一席之地；而对于 cri-o 报告中指出，之后市场份额可能会增加。 在我个人看来，近一年内 Docker 在企业生产环境的使用规模仍然会保持最大。 编排 可以看到 Kubernetes 遥遥领先，加上构建在 Kubernetes 之上的 OpenShift 和 Rancher ，这个霸主地位是非常稳了。 个人看来，近一年内，Kubernetes 的地位是不可能被撼动了，越来越多的企业也都会将技术栈迁移上去或者调研基于 Kubernetes 的云原生解决方案。 metrics Prometheus 已经成为事实标准，加上 Prometheus 作为 CNCF 毕业项目，以及围绕 CNCF 及云原生相关的各类基础软件等，都增加了各类 metrics，以及各类 exporter 越来越多，几乎可以涵盖生产中所需的各类 metrics 的需求了。 报警 这个图也可以从侧面反映出，节点的稳定性是大多数用户所关注的焦点。(无论上层如何调度，底层的稳定性依然很重要) Pods 规模 多数集群属于中小规模的（也说明是个正在发展的阶段） 结论 容器仍然在应用交付上发挥着重要的作用，从去年发布报告（在公众号后台回复 docker2018 获取）以来，容器技术的采用率仍在加速，容器密度翻了一番，并且随着技术的成熟，也有了越来越多的成熟案例。 Prometheus 已经成为了云原生应用指标的标准化方案，容器编排技术 Kubernetes 成为了事实的标准，企业应该在 Kubernetes 上进行投资，以跟上技术潮流的步伐。 可以通过下面二维码订阅我的文章公众号【MoeLove】， 在公众号后台回复 docker2019 可下载完整报告。

「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 内核兼容性如何，要上生产环境该选择哪个版本？我会在这一篇中与你分享，让你不再困惑。