「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Node Exporter v1.0.0 正式发布 Prometheus 是最早由 SoundCloud 开源的监控告警解决方案。并已经成长为继 Kubernetes 之后，第二个从 CNCF 毕业的项目。伴随着云原生理念的普及和 Kubernetes 等技术的发展， Prometheus 在监控领域也有了长足的发展。 其主要组件包括 Prometheus，Alertmanager，Node Exporter，Blackbox Exporter 和 Pushgateway 等。 Promethues 采取 Pull 的模式，所采集的 metrics 需要由对应的 Exporter 暴露出来。我们最常用的用于收集系统 metrics 的组件便是 Node Exporter 了。 本周，Node Exporter 终于迎来了 v1.0.0 版本，标志着它更加稳定，更加通用。 我在本周专门写了一篇文章来介绍它这个版本中我最关注的特性： 为 Prometheus Node Exporter 加上认证, 我们可以让监控变得更加安全。 当然这个版本中也包含了众多变更和 bugfix， 这里暂且跳过，有兴趣的小伙伴可直接参阅其 ReleaseNote Docker v19.03.10 发布 Docker 在本周发布了 v19.03.10 版本，距离上个版本 v19.03.9 仅过了两周的时间，如果在使用 Docker v19.03.x 版本的小伙伴，我个人还是建议你更新到此版本。

这篇文章主要是为了庆祝 Node Exporter 终于迎来了 v1.0.0 版本。 Prometheus 是最早由 SoundCloud 开源的监控告警解决方案。并已经成长为继 Kubernetes 之后，第二个从 CNCF 毕业的项目。伴随着云原生理念的普及和 Kubernetes 等技术的发展， Prometheus 在监控领域也有了长足的发展。 其主要组件包括 Prometheus，Alertmanager，Node Exporter，Blackbox Exporter 和 Pushgateway 等。 本文主要是为了庆祝 Node Exporter 终于迎来了 v1.0.0 版本， 所以重点主要放在一直被人诟病的安全性相关上，具体而言就是利用 TLS 和 Basic Auth 提升其安全性。 背景 Node Exporter 是 Prometheus 官方发布的，用于采集节点的系统信息，比如 CPU，内存，磁盘和网络等信息。 通常情况下，如果我们在使用 Prometheus 作为监控方案，那 Node Exporter 基本都会用到的。 在 Promethues 的监控体系中，社区中一直存在的一个观点是，Metrics 不包含过于私密的信息。所以你可以看到，大多数的 /metrics 接口都是直接暴露出来的，没什么特别的安全措施。 但随着 Prometheus 在生产中的大量应用，安全问题变得更加重要。 大家最先想到的解决办法就是，为 Prometheus 与监控目标之间的连接启用 TLS。 但由于各类 exporter 并不原生支持 TLS 连接，所以通常情况下我们会选择配合反向代理来完成。

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Docker v19.03.9 发布 Docker 在本周发布了 v19.03.9 版本，如果有在使用 Docker v19.03.x 版本的小伙伴，我个人强烈建议你更新到此版本。 在之前的「K8S 生态周报」中，我曾介绍过，自 Docker v19.03.7 开始，其 Backing Filesystem 的检查逻辑存在问题。 这会导致在执行 docker info 的时候，得到如下输出： (MoeLove) ➜ ~ docker info --format '{{ index .DriverStatus 0 }}' [Backing Filesystem ] 另外，由于不能正确识别 Backing Filesystem 也会导致设置 storage quota 时报错。这个问题我早已在上游进行了修复，原计划是在 v19.03.8 中发布，不过由于 v19.03.8 是为安全修复版本发布的， 所以延迟到本次 v19.03.9 中了。 除了上面提到的这个 bug 以外，本次版本中还有些重要的修复： #40780 修正了 BuildKit 中并发构建多个镜像时，可能引发的 panic； #2471 修正了 Docker CLI 使用单个数字作为卷时，可能引发的 panic， 举例而言就是： # 修正前 (MoeLove) ➜ ~ docker run -it --rm -v 1:/1 alpine panic: runtime error: index out of range .

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Helm v3.2.1 版本发布 本周 Helm 发布了 v3.2.1 版本，这是 v3.2 系列的第一个 patch 版本。此次包含一些值得关注的内容： #7959 修复了一个 Helm v3 从 3.0-rc 版一直存在的一个 bug ，详情见 #6899, 但 --reuse-values 这个参数用的人可能不多，实际上影响没那么大； #7653 修改了 helm upgrade 的行为，允许对一个失败的 Release 执行 helm upgrade 进行重新部署，而不需要先删除掉旧的 Release；（方便了很多！） 其实本周 Helm 还发布了 v2.16.7 ，虽然 Helm 2 已经进入了维护期，但不得不说，维护团队还是很靠谱的，一直在持续打 patch 中。 继续建议大家升级至 Helm v3 。 对此版本感兴趣的朋友可查看其完整的 ReleaseNote 。 Rancher v2.4.3 发布 Rancher v2.4 是个大版本，本次发布的 v2.

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 KIND v0.8 正式发布 本周 KIND（Kubernetes In Docker） 正式发布了 v0.8 版本，此次最主要的是为大家带来了 持久化集群，当主机或者 dockerd 重启后，集群可自动恢复。 Breaking Changes 此次默认的集群镜像是 Kubernetes v1.18.2 : kindest/node:v1.18.2@sha256:7b27a6d0f2517ff88ba444025beae41491b016bc6af573ba467b70c5e8e0d85f ; 当使用 KIND v0.8+ 启动集群时，必须使用通过 KIND v0.8+ 构建的 node 镜像，否则无法按预期工作； 新版本中， KIND 创建出来的所有 Node ，都使用自定义的 bridge 网络（默认名称为 kind，可通过环境变量 KIND_EXPERIMENTAL_DOCKER_NETWORK 修改）； 你可以在启动任意容器时，增加 --network=kind，以便让它和 KIND 创建的集群网络互通； 这里需要特别说一下关于持久化集群的特性。在之前版本中，如果你的 dockerd 进行了重启操作，或者是重启了系统，那可能会导致集群 IP 重新分配，进而导致集群状态异常。 在之前版本中，我们建议所有的用户，不要依赖集群持久化。但鉴于有不少用户的反馈，所以我先实现了第一版。 具体做法其实也简单，原先的痛点在于重启后，容器 IP 的重新分配，所以全部以域名的方式进行替代，另外就是借助于 Docker 的 embedded DNS 来完成 LB 层对 master 的代理。

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Helm v3.2.0 正式发布 经过两个多月的时间，Helm v3.2 终于在本周正式发布了！ 这个版本带来了很多值得关注的内容，我们一起来看看吧。 postgres 存储支持 Helm v2 时候，Release 默认是以 configmap 存储的，此外还支持存储为 memory, secret 或 sql 。在 Helm v3 时，社区对此做出了调整，提供了 configmap, secret 和 memory 等三种存储模式，并且默认的存储方式也变成了以 secret 进行存储。所以你可以直接通过 kubectl get secret 看到你部署的 release 。 本次发布的 Helm v3.2 中，对此有了个重大变更！ 本次 v3.2 中，Helm v3 中移植了 Helm v2 版本时，对 sql 存储的支持，即：第四种 postgres, 通过组合 $HELM_DRIVER 和 $HELM_DRIVER_SQL_CONNECTION_STRING 环境变量，便可达到效果。 需要注意的是，这还是个实验中的特性，尚未正式 GA。尝鲜可以，但尽量别放在生产环境中使用。 其他变更 在添加 repo 的时候，增加了 --insecure-skip-tls-verify 参数，可跳过 TLS 检查：

去年中在 Hacker News 上有篇热帖 “Goodbye Docker: Purging is Such Sweet Sorrow” 这篇文章内容其实很常规，无非是自己使用 Docker 的时候遇到了一些问题，最后切换到了 Podman buildah 和 Skopeo 组合的工具集，以作为 Docker 的一种替代方案。 这样的文章在近一年左右应该算是比较常见了，但为何会成为 Hacker News 上的热帖呢？主要有两方面的原因： 1. 还是因为此文的作者是 Ian Miell 他是 Docker in Practice (中译本叫做 《Docker 实践》)的作者，一个 Docker 相关技术书籍的作者将自己的 Docker 给替换掉，会让人比较好奇；2. 替换 Docker 貌似是一种方向，多数人也想要了解这种技术变迁会带来什么优势或者有什么样的坑。 背景介绍完了，我们来开始正文。 容器时代 Docker 在 2013 年 PyCon 上首次亮相，随后开源。由于其简单易用，以及切实解决了因环境不一致导致的问题，迅速获得到一大批粉丝。 接下来的几年中，Docker 改变了软件的交付方式，更多的人为之着迷。随之而来的是 Docker 生态的蓬勃发展。 Docker 在大多数人眼中几乎是容器（container）的代名词，即使是现在我也会常听到有人说“我有几个 docker 跑 xx 服务” 类似这样的话，无疑 Docker 引领了容器的时代。 容器是什么 一直在提容器，我们不如深入点先来探究下容器到底是什么？ 在 Docker 官网上对容器的描述是： “A standardized unit of software” – 软件的标准单元，并没有什么更详细的内容了。多数人对容器的看法也都停留在很浅显的认识：认为容器是轻量级的虚拟机，所以后来也就有一段时间有人推“富容器”技术。

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 containerd v1.3.4 正式发布 本周 containerd v1.3.4 正式发布了，距离上次 v1.3.3 大约 2 个月左右的时间。本次仍然是 v1.3.x 系列的 patch 版本，但本次值得注意的内容并不少，我们一起来看看： containerd/containerd#4007 改善了 docker remote 中镜像主机失败回退的行为。 这个变更是非常有用的，比如当我们想要为某个镜像仓库提供多个可用的镜像源（或者主机）的时候，在 v1.3.4 之前，如果第一个源（或者主机） 返回错误的时候，那默认就会回退，直接请求源站了。这种情况下，相当于我们设置的多个镜像源（或主机）就没什么实际意义了。 经过此次变更后，请求会逐个尝试设置的镜像源，可大大保障拉取的成功率。 containerd/containerd#4104 添加了对 NOTIFY_SOCKET 的支持； containerd/containerd#4150 修正了 FIFO 的清理逻辑； 这个变更是为了修正早先引入的一段对 FIFO 的清理逻辑，再此次修正之前，如果将 stdin/stdout/stderr 等使用 /dev/null 删除，则在任务关闭时，可能会导致清空 /dev 目录，这就非常危险了。 关于此版本的其他变更，可参考其 ReleaseNote Helm v2.16.6 和 v3.2.0-rc.1 发布 这是 Helm v2 的一个 bugfix 版本，修正了一处空指针的错误 #7812 ，如果还有小伙伴未升级使用 Helm v3 ，还是使用 Helm v2 的话，可以考虑升级至此版本。

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Docker 开源 Compose 规范, 助力云原生应用开发 本周 Docker 宣布将 Compose 规范开源，并作为独立组织进行治理。 由于 Compose 可以简单的定义基于多容器的应用程序堆栈的工作方式，并且可以通过一条命令启动应用程序，而不需要手动构建镜像和逐个启动容器，这可以大大节省开发团队的时间。 当前 Compose 已经被数百万开发人员使用，在 GitHub 上有超过 650,000 个 Compose 配置文件。 Docker 也在 GitHub 上创建了一个 awesome-compose 的仓库，其中包含了 Compose 在多种应用场景下的使用示例。 本次开源 Compose 规范，旨在能利用开源社区的力量，并与微软等合作伙伴，共同进行协作创新，为 Compose 规范提供更多活力，并以此帮助建立从桌面到云构建和部署容器应用程序通用开放标准。 另外，Compose 规范计划是捐助给中立的基金会，我个人认为大概率是捐给 CNCF 了（目前没看到正式消息）。扩展后的 Compose 规范必将会大大提升开发者体验。 同时，社区在计划使用 Go 对 docker-compose 工具进行重写（或者是重新实现 Compose 规范），整体而言也是好事儿，值得关注。 详情可查看：http://www.compose-spec.io/ SMI 正式加入 CNCF SMI（Service Mesh Interface）于本周正式加入 CNCF ，成为其 sandbox 级别的项目。 我在去年 5 月份的 K8S 生态周报| 2019-05-20~2019-05-26 中曾介绍过微软宣布推出的 SMI，本质是为了能为服务网格提供通用接口，以便能让 Service Mesh 有更加通用的规范 （就像当初 CNI/CRI 那样子）。

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 NGINX Ingress Controller 1.7.0-rc1 发布 NGINX Ingress Controller 本次发布的 1.7.0-rc1 有一些比较值得注意的更新： #827 为其暴露出的所有 metrics 添加了一个 class 标签。 比如如果原先的 metrics 是 nginx_ingress_controller_ingress_resources_total{type="regular"} 1 那么现在将变成 nginx_ingress_controller_ingress_resources_total{class="nginx",type="regular"} 1 。这个标签的值，可以通过 -ingress-class 进行设置。 #852 在 configmap 中增加了一个 default-server-access-log-off 的配置项，用于配置是否关闭默认 server 的 access log 。 #902 添加了两个新的资源 TransportServer 和 GlobalConfiguration，用来支持 TCP/UDP 和 TLS 的负载均衡。 此版本的变更整体而言是比较多的，其余变更请参考其 ReleaseNote rook v1.2.7 发布 本次 rook 的 v1.2.7 版本，仍然是个 bugfix 版本，其中包含多项改进，这里说两个值得注意的内容：