K8S 生态周报| 2019-05-13~2019-05-19

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 kind v0.3.0 正式发布 kind (Kubernetes In Docker) 是我很喜欢并且一直持续参与贡献的项目,本周发布了 v0.3.0 版本。关于 Kind 的介绍和基础使用,可以参考我之前写的文章 《使用 Kind 搭建你的本地 Kubernetes 集群》 本次的发布主要侧重于加速集群的启动速度及提高稳定性,优化镜像大小,以及对网络的优化和一些 bugfix 等;其中最主要的内容是将默认的 CRI 从 Docker 换成了 Containerd,以此可以缩小镜像体积,以及加快集群的启动。 v0.3.0 版本中,可以通过配置文件自行部署不同的 CNI,更有利于用户测试实际的集群情况;现在版本中已经将默认的 Kubernetes 版本升级到了最新的 v1.14.2 。 当然,也还有一些正在增加的特性,预计会在 v0.4.0 版本中发布,主要集中于 IPv6 和集群重启的支持(相信很快就可以完成了)。 顺便公布一个数据,Kind 目前的 star 数是 1.8k 还在持续增长中 :) 更多的细节和信息请参考 ReleaseNote Kubernetes v1.14.2 正式发布 这是一个常规的 bugfix 版本,但有个值得关注的点: 升级到了 golang v1.12.5 版本。 你可能要问为什么需要关注 golang 版本的升级?这是因为在此版本中 golang 有一些关于运行时的修改,尤其是其中关于二叉树查找部分的修改等部分的修改,可有效的降低 Kubernetes API server 的延迟。

初试 Helm 3

经过了长时间的开发,Helm 3 终于在今天发布了第一个 alpha 版本。本文将简单介绍 Helm 3 新特性。 移除 Tiller Helm 2 是 C/S 架构,主要分为客户端 helm 和服务端 Tiller; 与之前版本相同,Helm 3 同样在 Release 页面提供了预编译好的二进制文件。差别在于原先的二进制包下载下来你会看到 helm 和 tiller 。而 Helm 3 则只有 helm 的存在了。 Tiller 主要用于在 Kubernetes 集群中管理各种应用发布的版本,在 Helm 3 中移除了 Tiller, 版本相关的数据直接存储在了 Kubernetes 中。 现在我们直接在一个新创建的集群上来使用 Helm。测试集群的创建可以参考我之前的文章 使用 Kind 搭建你的本地 Kubernetes 集群。 与之前版本相同,我们需要先执行 helm init 来进行初始化。但现在的初始化就简单了很多,不再需要给集群中部署 Tiller 了 (MoeLove) ➜ ~ export HELM_HOME=/tmp/helm3 (MoeLove) ➜ ~ helm3 init Creating /tmp/helm3/repository Creating /tmp/helm3/repository/cache Creating /tmp/helm3/plugins Creating /tmp/helm3/starters Creating /tmp/helm3/cache/archive Creating /tmp/helm3/repository/repositories.

K8S 生态周报| 2019-05-06~2019-05-12

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Alpine Linux Docker 镜像漏洞 CVE-2019-5021 本周比较吓人的是 CVE-2019-5021, 根据漏洞报告,自 Alpine Linux 3.3 版本开始的所有 Docker 镜像中,root 用户包含一个空密码,这可能会导致攻击者获得 root 权限,今儿造成攻击。 报告中称:受影响范围是 Alpine Linux Docker 镜像 3.3、3.4、3.5、3.6、3.7、3.8、3.9、edge 等全部版本。 要知道由于 Alpine Linux 镜像体积较小,所以在构建 Docker 镜像时,很多人都会推荐使用 Alpine Linux 作为基础镜像;包括很多 Docker 官方镜像也基本上都提供了基于 Alpine Linux 的镜像,甚至像 Docker 镜像等是只提供了使用 Alpine Linux 作为基础镜像的版本。 当前漏洞已经修复,更多内容请阅读 关于 Alpine Docker 镜像漏洞 CVE-2019-5021 。 istio-operator 发布 0.1.12 版本 banzaicloud/istio-operator 发布 0.1.12 版本,默认已支持 istio 1.1.5 。(虽然截至目前 istio 发布了 1.

关于 Alpine Docker 镜像漏洞 CVE-2019-5021

关于 CVE-2019-5021 带来的一点思考。 本周比较吓人的是 CVE-2019-5021, 根据漏洞报告,自 Alpine Linux 3.3 版本开始的所有 Docker 镜像中,root 用户包含一个空密码,这可能会导致攻击者获得 root 权限,进而造成攻击。 报告中称:受影响范围是 Alpine Linux Docker 镜像 3.3、3.4、3.5、3.6、3.7、3.8、3.9、edge 等全部版本。 要知道由于 Alpine Linux 镜像体积较小,所以在构建 Docker 镜像时,很多人都会推荐使用 Alpine Linux 作为基础镜像;包括很多 Docker 官方镜像也基本上都提供了基于 Alpine Linux 的镜像,甚至像 Docker 镜像等,是只提供了使用 Alpine Linux 作为基础镜像的版本。 报告一出,瞬间这个消息就被传播成了 “Alpine Linux Docker 镜像不安全”/“不要再使用 Alpine Linux 了”。当然 Google 的开发者也顺便推了一次自家的 distroless 镜像。 我们来看一下 CVE-2019-5021 到底是什么以及如何复现吧。 CVE-2019-5021 (MoeLove) ➜ ~ docker run --rm -it alpine:3.9 / # grep root /etc/passwd root❌0:0:root:/root:/bin/ash operator❌11:0:operator:/root:/bin/sh / # grep root /etc/shadow root:::0::::: / # 以上是一个 alpine:3.

K8S 生态周报| 2019-04-28~2019-05-05

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Docker Hub 只读维护 在上周的推送中,有写到 Docker Hub 用户隐私数据泄漏。受此事件影响,5 月 4 日 Docker Hub 进行升级维护,在此期间 Docker Hub 有一段时间处于只读模式,包括自动构建等服务不可用;在最后有小于 15 分钟的完全宕机时间,服务完全不可用。 如果只是看事情表面的话,可能这就是一个由于发现“安全问题”而进行的升级/维护;但如果仔细考虑下,作为云原生服务,升级为何会有宕机的情况,为何会有服务完全不可用的时候? 摘录一段来自本次维护的公告内容: Q: Is this maintenance related to recent Docker Hub data breach? A: While we discovered unauthorized access to a single Hub database storing a subset of non-financial user data last week, which has since been remediated, we are always looking at ways to improve and enhance our security practices to protect our customers and their data.

K8S 生态周报| 2019-04-22~2019-04-28

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Docker Hub 用户隐私数据泄漏 2019 年 4 月 25 日,Docker Hub 团队发现了对存储非财务用户数据子集的单个 Hub 数据库的未授权访问。 在发现异常后官方团队迅速采取行动并保护网站免受攻击。 经过官方团队的调查,目前大概有 190000 帐号的敏感信息(小于总用户数的 5% )包括用户名和哈希后的用户密码,当然也包括 GitHub 及 Bitbucket 等的用于自动构建的 Token 。 当前的主要措施是对可能被泄漏信息的用户发送了邮件通知,对于可能泄漏哈希密码的用户发送了重置密码的邮件,并且 主动 将密码失效,以及自动构建的 Token 也都被失效。( 所以如果你收到了 Docker Hub 团队关于此次事件的直接报告邮件,很大概率是因为你的信息已经被泄漏了 ) 附上官方声明中关于此次事件的处理声明: During a brief period of unauthorized access to a Docker Hub database, sensitive data from approximately 190,000 accounts may have been exposed (less than 5% of Hub users).

K8S 生态周报| 2019-04-15~2019-04-21

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Prometheus v2.9.0 正式发布 Prometheus 是 CNCF 毕业项目,可用于监控系统及服务状态。它整体是使用 Pull 的模式,在周期时间内采集目标的 metrics ,并且提供了 PromQL 的查询语言,以供对监控数据进行查询过滤等操作。并且可以通过配置规则来触发报警等。我首次接触 Prometheus 大概是在 2015 年 0.15.0 版本左右,当时 Prometheus 还处于比较早期的阶段,不过在进入 CNCF 后,Prometheus 基本就成为了 K8S 监控的实施标准了,并且多数软件也都增加了对 Prometheus metrics 的支持。 v2.9.0 的主要更新: 从 2.8 开始引入了的从 WAL 读取进行 remote write 有时候会丢数据的问题已经得到修复; Kubernetes 和 OpenStack 在服务发现时候增加了更多元数据; Consul 现在支持多 tag; 添加了一个 honor_timestamps 的选项; TLS 证书会自动从磁盘加载; 日志也变的更易读; 其他更新请阅读 ReleaseNote Linkerd 2.3 正式发布 Linkerd 是一个 service mesh 旨在提供平台范围的可观察性,可靠性和安全性,而无需用户更改代码。在本月初的周报推送中,推荐了一篇关于 Linkerd v2 从产品中吸取的教育和经验的文章,Linkerd v2 使用 Go 和 Rust 进行了重写,并因此获得了巨大的收益。

K8S 生态周报| 2019.04.08~2019.04.14

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 CRI-O 成为 CNCF 托管项目 CRI-O 是基于 OCI 的 Kubernetes CRI 实现,旨在提供符合 OCI 运行时和 kubelet 之间的集成。简单来说就是完全符合 OCI 标准的 CRI 实现。(比如之前介绍的 runc 便是 OCI 标准的参考实现) 在 2016 年的时候 Kubernetes 就推出了容器运行时接口(CRI),这给了 kubelet 一种使用各种不同容器运行时的能力,现在最常用的当然还是 Docker,当然也有人使用 containerd、runc、CRI-O 等各类运行时。 CRI-O 最初由 Red Hat 和 Google 开发,现在已达到稳定状态,且已有大量的贡献者,本次成为 CNCF 托管项目,也算是给容器运行时提供一个更大的可能。 附一张官方图: 详细信息请阅读 CNCF 官方新闻 Helm 子项目 chart-testing 发布 v2.3.0 版本 chart-testing v2.3.0 版本正式发布,该项目的主要目标是用于 Helm Chart 的测试,使用该项目可更方便的检查 Chart 中是否有错误,以及定位错误位置等。 本次发布主要在于覆盖更多异常情况,详细内容建议阅读 ReleaseNote CoreDNS v1.

恭喜 Fluentd 从 CNCF 毕业

今年新闻不断,多数早期进入 CNCF 的项目都相继宣布毕业。 CNCF(云原生计算基金会)在美国时间 2019 年 4 月 11 日宣布 fluentd 今天正式毕业了。 这是 CNCF 中毕业的第 6 个项目,之前已经毕业的项目为 Kubernetes、Prometheus、Envoy 、CoreDNS 和 containerd 。 fluentd 自 2011 年由 Treasure Data 公司的联合创始人 Sadayuki “Sada” Furuhashi 创建,作为构建统一记录层的开源数据收集器,统一记录层统一收集采集和消费,以便更好的使用和理解数据。在 2016 年 11 月,fluentd 也是第 6 个成为 CNCF 托管项目的。 fluentd 可以从多种数据源采集事件,并将它写入文件, RDBMS, NoSQL, IaaS, SaaS, Hadoop等等各类的目标地址。截至目前,fluentd 在 GitHub 上有 7629 个 star ,895 个 fork,以及 166 位贡献者,超过 4k+ commit 。 做日志相关的小伙伴基本都玩过 ELK ,我们都知道在大规模使用 Logstash 时的痛苦(还记得被 Logstash 配置文件支配的恐惧吗? 2333) 而 fluentd 的事件路由是通过 tag 来做,相比 Logstash 使用管道将所有数据路由到单个流里再通过配置将它发送到对应的目标而言这将大大简化配置的复杂度。(是的,这里是吐槽)

K8S 生态周报| 2019.04.01~2019.04.07

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Kubernetes client-go v11.0.0 正式发布 这是最后一个使用 dep 作为依赖管理的版本,后续版本将转向使用 go modules. Kubernetes 生态中的相关项目大多都已转向或正在转向使用 go modules 了,这也是一个技术风向,理性选择。 Release containerd 1.2.6 正式发布 这是 containerd 1.2 的第 6 个 patch 版本,主要更新: 在默认的 seccomp profile 白名单增加了 io_pgetevents 和 statx 这两个系统调用; 修复了在 1.2.5 中自定义 cgroup path 无法工作的 bug; 更新 CNI 插件到 v0.7.5 以修复 CVE-2019-9946; 更新 runc 版本,修复在无 SELinux 系统下的失败情况; 当然还有一些其他的改进和修复,比如修复了 pod 的 UTS namespace 等,建议阅读 ReleaseNote。 Docker CE 19.