K8S 生态周报| Vitess 正式从 CNCF 毕业

「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 生态周报| Helm v2 爆出全版本漏洞

「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 生态周报| Helm v3 最后一个beta版本发布

「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 生态周报| Helm v2 最后一个特性版本发布

「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 生态周报| Docker 19.03.3 DNS 不再区分大小写

「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 中才真正修复。 这个问题其实反映出来的是当我们在维护项目时,对自己所用的各种依赖需要有所了解和把握,整体来讲,尽可能避免依赖项过旧是个好事儿;并且安全问题非常值得关注。

Docker 核心知识必知必会

自 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 生态周报| runc v1.0.0-rc9 发布

「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 生态周报| containerd v1.3 正式发布

「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 生态周报| Kubernetes v1.16 正式发布

「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 生态周报| Istio 1.3 正式发布

「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.