「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Helm 五周岁啦！ Helm 于 2015 年，在 Deis 的黑客松中创建（该公司已被微软收购）。在同年的首届 KubeCon 上正式推出现在被称之为 Helm classic 的版本。 2016 年 Helm 团队和 Google，Skippbox，以及 Bitnami 一起创建了 Helm 2 。自此 Helm Chart 工作流就基本定义好了，也就是我们现在在用的样子。 2018 年 6 月，Helm 成为了 CNCF 的孵化项目。在那之后，Helm Hub 也开始托管 Helm Chart 。 最近 Helm 团队做出了一个重大的决定： Hub 迁移到了 Artifact Hub Helm Hub 正式迁移到了 Artifact Hub 。 Helm Hub 是构建在 Monocular 项目之上的，根据 Helm 团队的说法，这个项目设计之初仅为处理有限的 Helm repo 。 但随着现在 Helm 应用的越来越广泛，Monocular 项目的局限性就暴露了出来。

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Helm v3.3.4 发布 本周 Helm v3.3.4 发布了, 这个版本是一个 bugfix 版本, 修复了自 Helm v3.3.2 中引入的一些问题。 #8779 确保 warning 信息输出到 stderr 而不是 stdout ； #8791 修复了自 #8779 中引入的，在 windows 上 build 的异常。主要是在 PR CI 中没有测试 Windows 平台； #8777 修复了自 v3.3.2 中带来的 break change 。在 v3.3.1 及之前版本中，helm repo add 是一个幂等操作，但自 v3.3.2 中为了修复安全问题，引入了一个 break change ，如果要添加同名的 repo ，需要增加 --force-update 参数才可以。这导致了很多自动化工具的失败，所以在 v3.3.4 版本中对此进行了修复。即：如果添加的 repo 完全相同，则此操作还是幂等的，如果 repo 仅是 name 相同，但是 url 或者 repo 的信息不同，则需要增加 --force-update 参数才可以。 Docker v19.

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 KIND v0.9 正式发布 KIND 是我很喜欢也一直在参与贡献的 Kubernetes SIG 子项目，本周 KIND 发布了 v0.9 版本，距离上次 v0.8 版本已过去了 4 个多月，在此期间，我们做了很多的优化和改进。下面我来具体介绍下： 破坏性变更 默认的 Node 镜像版本已经升级为最新的 Kubernetes v1.19.1 版本； v1alpha3 版本的 KIND config 配置文件版本已被废弃，当前最新的版本是 v1alpha4； 执行 kind build node-image 命令时，如果 --type 指定为 bazel ，则仅能与 Kubernetes v1.15+ 版本兼容。如果使用默认的 docker 类型的构建方式，则可以与 v1.13+ 版本兼容； 使用 KIND v0.9.0 版本构建的节点 image，仅支持与 KIND v0.9.0+ 版本一起工作。如果是使用 KIND v0.8+ 版本构建的镜像，也可与 KIND 最新版一起工作，但是少了一些内部优化的特性； 不再支持 Kubernetes v1.13 之前的 Kubernetes 版本了。 多节点集群的话，仅支持 Kubernetes v1.

最近 DockerHub 修改了定价，对于免费帐号会限制 200 pulls/6小时，对于匿名帐号则限制 100 pulls/6小时。 本文我来介绍下如何使用 Cache 来应对此问题。 背景 DockerHub 是全世界最早也是最大的容器镜像仓库，托管着众多操作系统发行版及各类软件的 Docker 镜像。 在推进业务容器化的过程中，不可避免的，我们会需要使用来自 DockerHub 上的容器镜像。 无论是在个人本地环境中使用，还是用于跑测试服务 以下是两种主要的解决方案： 构建一些公共基础镜像，存放在企业的私有镜像仓库中给业务方使用： 这种方案下，如果业务方偶尔需要一些小众的/非基础的镜像，可能只是临时测试使用，那通常情况下是没必要将此类镜像作为基础镜像维护的。 结果可能是： 使用中直接从 DockerHub pull 镜像，网络状况不佳时，就是无尽的等待； 先 pull 镜像，然后 docker tag 重 tag 后， push 到企业的私有镜像仓库中。这种情况下，如果没有较好的镜像管理规则，那么镜像仓库中就会存在各种无意义的镜像，造成存储资源的浪费。 为 docker daemon 配置 Proxy 进行加速： 众多国内镜像加速服务，仅提供 Docker 官方镜像的加速服务，个人/组织下的镜像不提供加速服务； 即使在不同节点上，下载相同的镜像，仍然需要通过网络加速，会产生额外的海外带宽成本； 并且近期 DockerHub 修改了其服务价格, 对于免费用户，进行了如下限制： 未登录用户，每 6 小时只允许 pull 100 次 已登录用户，每 6 小时只允许 pull 200 次 如果我们继续使用上述两种模式的话，由于出口 IP 是相对固定的，所以很容易触发 DockerHub 的配额限制。 此限制将于 11 月 1 日正式全面实施。

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Istio v1.7.1 发布 这是 Istio v1.7 系列的第一个 patch 版本。此次更新有些值得注意的内容： #26625 修复了 istioctl x authz check 使其能更好的兼容 v1beta1 AuthorizationPolicy ； #26617 修复了 headless services endpoint 更新不会触发任何 xds pushes 的问题； ##26938 修复了当使用 IstioCNI 时 remove-from-mesh 未移除 init container 的问题； Rook v1.4.3 发布 这是个 patch 版本，主要修复了一些和 Ceph 有关的问题, 以及引入了一些小功能： 修复： #6232 由于 Ceph-CSI driver 在某些集群中会把垃圾回收清理掉，所以创建 csidriver 对象时不再为它设置 ownerRef 了。主要是因为 csidriver 是集群级别的对象，不应该将 namespace 级别的对象设置为它的 ownerRef； 修改：

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Kubernetes v1.16.15 发布 Kubernetes v1.16.15 是 v1.16 系列的最后一个更新，我在之前的周报中也有介绍过。 是时候考虑将 v1.16 升级至更高版本了！ 以下介绍从 v1.16 升级至 v1.17 需要关注的一些重点。 etcd 就外部依赖而言，最主要的变化是 etcd 从 v3.3.13 升级到了 v3.4.3 。 在升级 etcd 前，我建议你先阅读下 etcd 的升级文档。 我从中说几个重点内容： In the general case, upgrading from etcd 3.3 to 3.4 can be a zero-downtime, rolling upgrade: one by one, stop the etcd v3.3 processes and replace them with etcd v3.4 processes

背景 在我之前的文章 K8S 生态周报| Google 选择 Cilium 作为 GKE 下一代数据面 一文中，我介绍了 Google 宣布使用 Cilium 作为 GKE 的下一代数据面，及其背后的故事。 Google 选择 Cilium 主要是为了增加 GKE 平台的容器安全性和可观测性。那么，Cilium 到底是什么，为什么会有这么强的吸引力呢？ 摘一段官网的介绍： Cilium is open source software for transparently securing the network connectivity between application services deployed using Linux container management platforms like Docker and Kubernetes. Cilium 是一个用于透明保护部署在 Linux 容器管理平台（比如 Docker 和 Kubernetes）上的应用服务之间网络连接的开源软件。 为什么着重强调是 “Linux 容器管理平台” 呢？这就不得不提到 Cilium 的实现了。Cilium 的基础是一种称为 eBPF 的 Linux 内核技术，使用 eBPF 可以在 Linux 自身内部动态的插入一些控制逻辑，从而满足可观察性和安全性相关的需求。

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Kubernetes v1.19 正式发布 本周 Kubernetes v1.19 正式发布，这是今年发布的第二个版本，也是耗时最长的一个版本。 在此版本中有 34 个增强功能，其中 10 个GA，15 个 beta 以及 9 个 alpha。并且从 v1.19 开始，Kubernetes 每个版本的支持周期延长至 1 年。（感谢[ Long Term Support (LTS) working group ]（https://github.com/kubernetes/community/tree/master/wg-lts#readme “LTS WG”）） 关于此版本中重要的变更，可参考我每期周报中 “上游进展” 的部分。或者直接参考 官方博客中 v1.19 的介绍文章 。 这里我来单独介绍一个更具体且实用的特性。 API 弃用规则 Kubernetes 是一个庞大的系统，当讨论它的 API 时，我们不得不提到常用的 4 个术语，即：group（组）, version（版本）, kind（类型）和 resource（资源）。 一个 API group 是一组相关功能的集合，group + version 是确保 API 可随着时间推移，进行版本升级或功能更新的基础。 这里我来介绍下 自 Kubernetes v1.

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Google 选择 Cilium 作为 GKE 网络的数据面 Google 声明将选择 Cilium 作为 GKE 网络的数据面 V2 以便增加其容器安全性和可观测性。 Kubernetes 最强的能力之一便是其开发者优先的网络模型，可以提供简单易用的功能，比如： L3/L4 service 和 L7 ingress 以便将流量引入 Kubernetes 集群，以及多租户的网络隔离等。 但随着越来越多的企业使用 Kubernetes , 用例范围越来越广，围绕多云，安全性，可观察性和可扩展性等方面均提出了新的要求。此外，诸如 service mesh 和 serverless 等技术，均需要来自底层 Kubernetes 的更多自定义。这些新要求最终汇聚到一起得出来的结论便是： 需要一个更具可编程性的数据平面，该平面可执行 Kubernetes 感知的数据包操作，并且还不会损失性能。 Cilium 的出现恰恰满足了这些需求，它基于 eBPF 技术的实现，使 Linux 内核具备了 Kubernetes 的意识。它可以很好的满足现在新的对容器负载的可伸缩性，可观察性以及安全等方面相关的要求。此外， Cilium 所提供的功能也远超了传统 CNI 提供的功能，不仅有传统的 Network Policy， service 和 LB ，还有 Flow & Policy logging 以及内置运维和安全侧的 metrics 等。

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Helm v2 将正式废弃 本周，Helm v2 系列发布了 v2.16.10 版本， 这是 Helm v2 的最后一个 bugfix 版本，此后不会再为 Helm v2 提供错误修复。并且在三个月后，将停止为 Helm v2 提供安全补丁。届时， Helm v2 也就完全废弃，不会再去维护了。 如果有在使用 Helm v2 的小伙伴，请尽快升级至 Helm v3， 社区也提供了 Helm 2to3 的工具，可以帮助迁移。 另外，还有个别厂商绑定 Helm v2 提供应用安装/部署服务的，也建议尽快迁移了。 我统计了下，我发布的文章中，有 25 篇与 Helm 相关。包括 Helm v3 的尝试，Helm v2 的废弃计划，从 Helm v2 迁移到 v3 等内容，感兴趣的小伙伴可以看看历史文章。 DockerHub 修改了定价和 TOS DockerHub 本周对其服务收费以及 TOS（Terms of Service）。我们重点来看看本次的修改对我们会有哪些影响吧。 这里重点来看看对免费用户/（未登录）匿名用户的影响。 流量限制