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.

K8S 生态周报| 2019.03.25~2019.03.31

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Kubernetes 1.14 正式发布 1.14 的主要更新: 对 Windows Node 和 container 的支持达到生产级别,支持 Windows Server 2019; 本地持久化数据卷正式可用,这可以方便使用本地 SSD 之类的存储,但注意这个特性容错性较差; Pod 优先级和抢占机制正式可用,(建议慎重使用); Pod Ready++ (Pod Readiness Gates) 达到稳定,可以更好的判断 Pod 及其需要的资源是否均已就绪; 当然还有很多的改进和很多被废弃的功能特性等,建议阅读 ReleaseNote。 Minikube 1.0.0 正式发布 Minikube 是一个用于本地搭建 Kubernetes 环境的工具,使用方法可参考 使用 Minikube 搭建本地 Kubernetes 环境。 1.0.0 的主要更新: 默认 Kubernetes 版本更新至 1.14.0; 新增 --image-repository 参数,方便国内用户使用镜像解决网络问题; 其他特性请阅读 ReleaseNote runc 1.0-rc7 发布 注意,低版本内核(尤其是 3.x)的系统,请不要升级至此版本 这个版本主要为解决之前的漏洞及修正一些规范等,版本说明请参考 runc 1.

runc 1.0-rc7 发布之际

在 18 年 11 月底时,我写了一篇文章 《runc 1.0-rc6 发布之际》 。如果你还不了解 runc 是什么,以及如何使用它,请参考我那篇文章。本文中,不再对其概念和用法等进行说明。 在 runc 1.0-rc6 发布之时,给版本的别名为 “For Real This Time”,当时我们原定计划是发布 1.0 的,但是作为基础依赖软件,我们认为当时的版本还有几个问题: 不够规范; 发布周期不明确; 为了给相关的 runtime 足够的时间进行修正/升级,以及规范版本生命周期等,最终决定了发布 runc 1.0-rc6。 为何有 runc 1.0-rc7 存在 前面已经基本介绍了相关背景,并且也基本明确了 rc6 就是在 1.0 正式发布之前的最后一个版本,那 rc7 为什么会出现呢? CVE-2019-5736 我们首先要介绍今年 runc 的一个提权漏洞 CVE-2019-5736 。 2019 年 2 月 11 日在oss-security 邮件组正式批露该漏洞,攻击者可以利用恶意容器覆盖主机上的 runc 文件,从而达到攻击的目的;(具体的攻击方式此处略过),注意不要轻易使用来源不可信的镜像创建容器便可有效避免被攻击的可能。 简单补充下可能被攻击的方式: 运行恶意的 Docker 镜像 在主机上执行 docker exec 进入容器内 关于容器安全或者容器的运行机制,其实涉及的点很多,我在去年的一次线上分享 《基于 GitLab 的 CI 实践》 有提到过 Linux Security Modules(LSM)等相关的内容,对容器安全感兴趣的朋友可以对 LSM 多了解下。

使用 Kind 搭建你的本地 Kubernetes 集群

Kind 是我很喜欢也一直在参与的项目,我计划将 Kind 相关的文章写成一个系列。(flag++) 这是第一篇。 Kind 介绍 Kind 是 Kubernetes In Docker 的缩写,顾名思义是使用 Docker 容器作为 Node 并将 Kubernetes 部署至其中的一个工具。官方文档中也把 Kind 作为一种本地集群搭建的工具进行推荐。 安装 二进制安装 Kind 使用 Golang 进行开发,在仓库的 Release 页面,已经上传了构建好的二进制,支持多种操作系统,可直接按需下载进行使用。 e.g. # 下载最新的 0.2.0 版本 wget -O /usr/local/bin/kind https://github.com/kubernetes-sigs/kind/releases/download/0.2.0/kind-linux-amd64 && chmod +x /usr/local/bin/kind 通过源码安装 如果你本地已经配置好了 Golang 的开发环境,那你可以直接通过源码进行安装。 e.g. go get -u sigs.k8s.io/kind 运行完上述命令后,会将 kind 的可执行文件放到 $(go env GOPATH)/bin 文件夹内,你可能需要将此目录加入到 $PATH 中。 或者也可以先 clone 源代码再通过 go build 进行构建。

K8S 生态周报| 2019.03.18~2019.03.24

我将从本篇开始维护「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。 Docker 6 岁啦 Docker 从 2013 年首次亮相,至今已 6 年之久,而 Docker 也已一度成为容器技术的代名词,很庆幸能投身 Docker 相关的领域。官方博客 Kind (Kubernetes In Docker) 发布 0.2.0 版本 Kind 是一个利用容器技术快速部署本地 Kubernetes 的工具,主要是用于对 Kubernetes 1.11+ 版本的测试。现在发布的 0.2.0 版本支持最新 Kubernetes v1.13.4 及 Docker 18.06.3 且通过了 CNCF 的一致性认证。 Rancher 发布 K8S 最佳安全实践文章 Rancher 在 CNCF 最近发布的 9 个 Kubernetes 最佳安全实践的基础上发布了一篇更安全的最佳实践,这两篇文章都值得一看。 可以通过下面二维码订阅我的文章公众号【MoeLove】

恭喜 containerd 毕业

今年的第一篇文章更新,带来一个重大的消息。 CNCF(云原生计算基金会)在美国时间 2019 年 2 月 28 日宣布 containerd 今天正式毕业了。 这是 CNCF 中毕业的第 5 个项目,之前已经毕业的项目为 Kubernetes、Prometheus、Envoy 和 CoreDNS 。 containerd 2014 年从 Docker 孵化出来,最初是作为 Docker 引擎的底层管理器;在 2017 年 3 月被 CNCF 接受后,containerd 几乎成为了行业容器运行引擎的标准,它专注于简单,健壮和可移植性,任何人都可以使用它来构建自己的容器引擎/平台。 “When Docker contributed containerd to the community, our goal was to share a robust and extensible runtime that millions of users and tens of thousands of organizations have already standardized on as part of Docker Engine,” said Michael Crosby, containerd maintainer and Docker engineer.