K8S 生态周报| Helm v3.4 发布

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Helm v3.4 正式发布 Helm v3.4 是一个特性更新版本,我们来看看此版本有哪些值得关注的变化: 11 月 13 日, Helm stable 和 incubator 仓库将到达终结日,这些 Chart 的归档将会存储到另外的位置,如果你使用这两个仓库的话,Helm 将会先检查原先的位置,然后进行重定向; #8543 helm lint 将检查名称长度的错误; #8529 helm status 新增 --show-desc 参数,可用来展示描述; #8874 让 helm create 创建的 chart 缩进保持一致; #7970 helm lint 现在也可以检查依赖了; #8438 helm show values 增加 jsonpath 输出的支持; #8613 优化了 service ready 的判断逻辑,改成了判断是否有 ClusterIP; 更多关于此版本的变化,请查看其 ReleaseNote CoreDNS v1.8 正式发布 CoreDNS 今日发布了 v1.8 版本,整体而言变化不是太大,且也做了向后兼容,可能会受影响的是使用 外部 plugin 或者域外流量的用户。

K8S 生态周报| Docker V2 GitHub Action 宣布 GA

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Docker V2 GitHub Action 已 GA Docker Inc. 近期在其官方博客宣布 Docker V2 GitHub Action 已经 GA 。 我在之前的文章《K8S 生态周报| 首个 Docker 官方 Action 发布》 中曾详细介绍过 Docker 提供的V1 GitHub Action 的用法。 此次,V2 版本带来的最大变化是由原先单一的 GitHub Action 转换成了现在的多个模块化,且包含复杂功能的独立 Action。这里我也介绍下其中重点的内容: 独立的 Login Action 本次发布了独立的 Login Action ,之前版本的 Action 是将登录操作同时封装在整个 Action 流程中的。 - name: Login to DockerHub uses: docker/[email protected] with: username: ${{ secrets.DOCKER_USERNAME }} password: ${{ secrets.DOCKER_TOKEN }} 此外,在 Action 执行完成后,会有个 Post Login 的 job ,自动将 Login 动作时创建的用户凭证进行销毁。

K8S 生态周报| Docker v20.10.0-beta1 发布

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Docker 发布 v20.10.0-beta1 版本 Docker 在本周发布了 v20.10.0-beta1 版本,作为 v20.10 版本的首个测试版本,目前可以通过 Docker 官方的 test channel 进行下载,或者直接通过 docker:20.10.0-beta1 和 docker:20.10.0-beta1-dind 等镜像进行体验。 如有遇到问题,欢迎大家反馈~ 这个版本算是姗姗来迟吧,按照原定发布路线的话,v19.03 版本后的下个大版本便是 v20.03 了。不过目前 v19.03 社区也还在积极进行维护,延长了其维护周期,并计划发布 v19.03.14 版本。 Docker v20.10 版本,变化非常的大。提供了 CGroup v2 的支持,增强了 rootless 模式的支持,双栈日志,更灵活的内置 DNS 等,我在这个版本中也花费了很多时间。 详细的变更,我会在 v20.10 正式发布时再进行介绍。欢迎大家进行测试和反馈,目前已经收到了一些反馈的建议。我们会尽快修正并发布下个版本。 Docker Hub 镜像保留策略将延期 两个月前,我在 K8S 生态周报 中曾介绍过 DockerHub 修改了定价的内容,其中包括了一项: 镜像保留策略 的变更, 对于非活跃镜像,默认只保留 6 个月 。这项更新原定是在 11 月 1 日正式实施。 但这项计划公布后,收到了很多来自社区的反馈。本周,Docker Inc. 宣布将对上述提到的镜像保留策略的实施进行延期执行,目前计划是先延期至 2021 年年中。在 2021 年年初会公布新的计划时间表。

K8S 生态周报| Helm 五周岁啦!

「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 生态周报| Helm v3.3.4 发布

「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 生态周报| KIND v0.9 发布带来众多更新

「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 限制,全镜像加速服务

最近 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 生态周报| Istio v1.7.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 v1.16 升级了

「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

被 Google 选择的下一代数据面 Cilium 是什么

背景 在我之前的文章 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 自身内部动态的插入一些控制逻辑,从而满足可观察性和安全性相关的需求。