K8S 生态周报| Istio v1.4.3 发布

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Prometheus v2.15.2 发布 本周 Prometheus 发布了 v2.15.2 版本,其修复了两个 TSDB 相关的问题。 修复对 2.1.0 之前版本构建的 TSDB 块的支持,这个问题直接影响的是那些直接从 2.1.0 版本之前直接升级到 2.15 的用户,根本原因是在 2.1.0 版本加入的一个对 key 排序的特性; 修复了 TSDB 在 Windows 下的压缩问题; 其他变化,感兴趣的朋友可以参看其 ReleaseNote Istio v1.4.3 发布 Istio 发布了 v1.4.3 版本,带来了众多 bugfix 和改进,我们来具体看看: 修复了 Mixer 为 secret 创建大量 watcher 可能导致 Kubernetes api-server OOM 的问题 #19481 ; 修复了注入相关的模板。当 POD 有多个 container 但 container 未暴露端口时,istio-proxy 无法启动的问题。#18594;

K8S 生态周报| 终端下的 K8S 资源树查看器

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 上游进展 Kubernetes v1.17.0 中,如果将 CIDR 设置为低于 /16 位,则 IP 分配器可能会报错。这个问题当前已经在 #86534中修复,将随着 v1.17.1 发布,如果尚未升级至 v1.17.0 的朋友可以稍后; api-server 的 bind-address 最近稍作了调整,如果未指定或者使用 0.0.0.0 或 :: 则会监听本地的所有可用的地址。 项目推荐 kubectl-tree 是一个用于在终端内以树形结构展示 Kubernetes 资源的 Kubectl 插件。(已经登上了 GitHub 的趋势榜) 使用效果如图: 在我的终端下,它不能对齐,不过我还没来得及具体去看原因。 新项目:APISIX-ingress-controller 最近看到一个为 Apache APISIX 实现 Ingress Controller 的项目 APISIX-ingress-controller 同时也看到了一篇文章: 为什么我们重新写了一个 k8s ingress controller 文章的作者解释了为何要重新写一个 Ingress Controller。 在我个人看来,多实现一种 Ingress Controller 对社区而言是好事儿,让大家有了更多的选择,另一方面,这个项目刚起步不久,如果有对实现 APISIX Ingress Controller 感兴趣的朋友可以尽早加入。 ( 抛开此项目不谈,单纯谈写一个简单的自定义 Ingress Controller 其实比较简单,倒也挺有趣的,只不过在处理一些高级特性及处理大量请求时,不同的实现会有些区别。 推荐大家都尝试下

2019 小回顾

这篇文章起笔于上周(年底),不过工作比较忙,一直耽搁到今天(1 月 1 日)才抽出时间,索性就重写了。算是一篇岁岁念,想到什么就写点。 转眼已是 2020 年 1 月 1 日了,惯例做个小回顾。 2019 年发生了太多事情,非常值得好好回顾一下。每年的回顾不仅是对过去一年的总结,也是对新的一年做个计划。 依旧按照我每年的习惯,分别从工作和生活来聊聊。 工作 2019 年我做的事情,主要涉及以下几个方面: Docker 容器化和 Kubernetes API Gateway CI/CD 存储 监控 告警信息收敛 也算是比较典型的云原生工程师的工作内容了,感谢同事们的支持和配合。 2019 年是云原生形势大好的一年,这一年整个行业内都发生了不小的变动,关注我每周推送的「k8s 生态周报」的小伙伴可能已经发现,周报中最多的内容是 K8S 生态中比较核心的软件的版本发布及功能变更或漏洞相关的信息。 为什么这类信息会这么多呢?主要还是因为 2019 年云原生或者说 Kubernetes 的普及越来越广泛,需求增多,场景愈发复杂,相应的像 Docker, Kubernetes, Prometheus 这类基础软件也就需要提供更多的特性支持,或者 bugfix 。所以我在这方面投入的时间也就更多一些。 此外,从 19 年 3 月底,我开始了每周 「k8s 生态周报」 的推送,直到今天共计推送了 41 篇周报,未曾落下,也积累了不少读者,感谢大家关注。 今年在 PyCon China 的角色从讲师变成了出品人,原本计划会有一个主题演讲,但是由于跟我的婚礼时间冲突了,所以未能参加。感谢 PyCon China 的一众小伙伴的谅解和支持。 在国庆假期结束后,我在 GitChat 上发布的专栏《Docker 核心知识必知必会》正式上线了,至今专栏内容已经更新了一半,按照 GitChat 的字数统计现在写了大概是 9w 字左右(这个统计包括了我之前发布的五篇 Chat 文章)。感谢我的小可爱一直督促我,感谢编辑们的辛苦,感谢读者的信任和支持。

K8S 生态周报| Prometheus v2.15.0 正式发布

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Prometheus v2.15.0 正式发布 本周 Prometheus 发布了 v2.15.0 版本,这个版本在 TSDB 方面有诸多改进,以及提升了 PromQL 解析器的性能。 TSDB 方面主要是对内存使用相关的优化。 按照此版本中 对 PromQL 解析器相关变更的 PR,本次解析器性能的提升能达到之前的 7 倍。 同时,此版本中也存在一个 bug,可能会导致并发查询数据时,出现 checksum 不匹配的情况,最直接的影响就是 Grafana 的图表会显示不出来。 所以之后也快速发布了 v2.15.1 版本。建议如果使用 v2.15.0 的朋友可以快速升级至 v2.15.1 以规避此问题。 更多关于此版本的变更,请查看其 ReleaseNote Rancher v2.4.0-alpha1 发布 Rancher 本周发布了 v2.4.0-alpha1 , 此版本中在用户角色方面有两个挺不错的改进。 管理员可以自定义全局范围内的角色,并且可以让用户登录后默认使用该角色。 在使用外部认证方式时,管理员也可以默认设置属于某个组的用户,默认授予的权限。(比较类似于 Grafana 使用 LDAP 认证时,默认给用户设置的权限,但更灵活一些。) 更多关于此版本的信息,可参考其 ReleaseNote 题外话 这是今年 「K8S 生态周报」的最后一篇了,本篇中没有上游进展,上游最近的变更并不频繁,(大概是年底休假的原因) 从 2019 年 3 月份开始,便一直保持着每周更新。新的一年,我也将继续保持更新,与你分享我所接触到的 K8S 生态相关的每周值得推荐的一些信息。

K8S 生态周报| TUF 正式从 CNCF 毕业

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 TUF 正式从 CNCF 毕业 本周 The Update Framework (TUF) 正式从 CNCF 毕业,现在 TUF 的官方 Python 实现有 954 个 star ,142 个 fork 以及 43 位贡献者和 3525 次 commit 记录。 TUF 是从 CNCF 正式毕业的第 9 个项目,没记错的话也是至今为止唯一一个 star 数未上千就正式毕业的项目。不过 TUF 项目本身与其他项目不同,star 数也说明不了项目状态。 可能不少人觉得 TUF 项目的存在感很低,或是没有了解或使用过 TUF 项目,我姑且对它做一点介绍。 TUF 项目大概是十年前启动,并于 2017 年开始托管于 CNCF,它的主要目标正如它的名字一般,提供用于更新的框架,但它更重要的点在于它的安全性设计上。 它充分考虑到了各个环节可能出现的攻击,在提供更新功能的同时,也可以很好的保护现有程序或者是验证待更新版本的安全和可靠性。你可能想问它是如何做到这一点的,其实它主要是提供了一套标准规范,并在各个环节中增加了更多的元数据和相关的检查,包括签名信息,文件 hash ,元数据签名和过期时间等。 至于它的存在感嘛,不知道你是否有使用过 Docker Content Trust(DCT) 相关的功能,简单来说你可以当作就是 docker trust 所涉及到的相关功能,这其中的部分功能是构建在 Docker Notary 之上的,而 Docker Notary 则是使用 TUF 作为其基础安全框架的。(PS:Docker Inc 也已经将 Docker Notary 捐献给了 CNCF)

K8S 生态周报| Kubernetes v1.17 正式发布

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Kubernetes v1.17 正式发布 本周 Kubernetes v1.17 正式发布了,这是 2019 年的第四次发布,当然也是今年最后一次了。Kubernetes v1.17 包含 22 个增强功能,其中 14 个已经 stable ,4 个 beta 以及剩余 4 个 alpha 。 本次版本的主题是 Stability,在发布之时 Kubernetes 官方博客上已经有了一篇 Kubernetes 1.17: Stability 文章介绍,加上每周的周报中也都有上游进展的介绍,我在这里就不赘述了,稍微聊两三个我个人认为比较有用的内容。 rbac.authorization.k8s.io/v1alpha1 和 rbac.authorization.k8s.io/v1beta1 在 v1.17 被标记为废弃,并且在 v1.20 将被废弃; kubectl logs 增加了一个 --prefix 的选项,使用此选项可以在输出日志的时候展示一个前缀,格式是 [pod/name/containerName] 废弃和添加了一大堆 metrics, 感兴趣的朋友可以参考下 ReleaseNote 中 metrics 的部分 其余内容建议参考下完整的 ReleaseNote Harbor v1.10 正式发布 Harbor 目前在 GitHub 有 10.

K8S 生态周报| containerd v1.3.2 发布

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Kind v0.6.1 发布 本周 Kind Kubernetes In Docker 发布了 v0.6.1 版本,这是对 v0.6.0 的一个小 patch 版本,主要变更如下: 修复 containerd 在多 control plane 节点集群下的配置; 修正了 v1alpha4 API 中的 protocol 和 propagation 配置; 重新推送了镜像,v0.6.0 发布的时候忘记把 CNI 的镜像给预加载到 Node 镜像中了。现在的默认镜像是 kindest/node:v1.16.3@sha256:70ce6ce09bee5c34ab14aec2b84d6edb260473a60638b1b095470a3a0f95ebec 另外:Kind 的 Node 镜像在 DockerHub 上的下载量超过了 500K+ ,也说明其正在被广泛使用。(查看了下我自己发布的镜像中,下载量最多的也才只有 50K+)恭喜 Kind ! containerd v1.3.2 发布 这是 containerd 在 v1.3 系列的第二个 patch 版本。 此版本主要的修复内容如下: 修复了一个容器 pid 的问题,会导致 Docker 卡住; 使用已缓存的状态而不是每次都执行 runc state 获取容器状态,相关影响是 Kubernetes 启用 liveness 和 readiness 探针会造成 CPU 飙高以及 Docker 容器使用健康检查也会造成 CPU 飙高; 综合来看,建议更新到此版本。

K8S 生态周报| Rancher v2.3.3 发布

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Rancher v2.3.3 发布 本周 Rancher v2.3.3 发布,正式支持 Kubernetes v1.16,并将 v1.16.3 设置为 Rancher 默认的 Kubernetes 版本。 在此版本中,值得关注的修复如下: 修复了其不支持 kube-proxy 使用 IPVS 模式的问题; 已知问题: Rancher v2.3.3 在开启 SELinux 的 RHEL 7.7 上使用 RHEL Docker 1.13 时,部署集群将导致失败; 更多关于此版本的特性及已知问题,请关注 ReleaseNote 上游进展 api-server 的 --runtime-config 可使用 api/beta=false 参数禁用所有内置的符合 v[0-9]+beta[0-9]+ 版本的 REST API;同时 --feature-gates 可使用 AllBeta=false 禁用所有内置的 beta 特性。#84304 downward API 为 Dualstack 增加了支持,参数名为 status.

K8S 生态周报| containerd v1.3.1 发布

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 containerd v1.3.1 发布 本周 containerd v1.3.1 发布了,我们一起看看其中值得注意的变化: 将 runc 更新至 v1.0.0-rc9 , 其中包含了对 CVE-2019-16884 的修复,关于此漏洞的更多细节也可参考 https://github.com/opencontainers/runc/issues/2128 ; 修复了一个 v1.3.0 在拉取镜像遇到错误时,解包过程中的死锁问题 #3816 ; 定位了一个 containerd 在主机意外重启时,可能无法恢复损坏的镜像的问题,这个问题是比较有意思的,可能遇到这种情况的环境主要是 containerd 数据目录挂载至非根目录所在的盘中(多数环境中,系统盘的空间并不会很大,所以这种安装情况也算比较常见)。发生此问题的根本原因就在于重启后启动的时机不对(我倾向于这样表述,虽然实际的逻辑是 gc 删除了一些元数据,但它本身的行为是正常的)。所以修复的办法也比较简单, 如果你的 containerd 是使用 systemd 进行管理的,那么可以在 service 的配置文件的 After 块中增加 local-fs.target 的配置 local-fs.target 是 systemd 中一个特殊的单元,和 dbus.service 之类的很多单元类似,都属于特殊的那一类。具体来说它是用来集合本地文件系统挂载点的目标单元,听起来可能比较抽象。实际上就是 systemd-fstab-generator 会在所有本地文件系统挂载单元中添加 Before=local-fs.target 这一条,所以呢,当在 local-fs.target 之后执行的,就表示现在机器上的所有本地文件系统均已经正确挂载。(这也是我认为这个问题有意思的地方) 以上就是我认为在此版本中比较值得注意的点了,对此版本有兴趣的朋友可参阅 ReleaseNote Kubernetes v1.17.0-rc.1 发布 虽然本周在举行 KubeCon 但 Kubernetes 的发布进度也没受太多影响,本周顺利发布了 v1.

K8S 生态周报| Helm v3.0.0 正式发布

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Helm v3.0.0 正式发布 本周 Helm v3.0.0 正式发布了。在 Helm v3 发布第一个 alpha 版时,我就写了一篇 《初试 Helm 3》 在那篇文章中,我介绍了一些 Helm 3 的变化及特性。 现在正式版发布了,我们来正式的看看这个版本带来了哪些值得期待的内容。(PS:我不会在本文中介绍其全部特性,只会聊聊我感兴趣的,对全部特性感兴趣的朋友可以参考其官方文档 https://helm.sh/docs/ ) 移除 Tiller 这个特性想必在任何介绍 Helm 3 的文章中都会有提到,当然在我之前的文章中也有提到。在 Helm 2 时,对于启动了 RBAC 的 Kubernetes 集群而言,在生产环境中想要安全的管理 Tiller 的权限是比较麻烦的。 如果使用默认配置(简单来说也就是没啥特别的限制),那么上手很容易,但对于多租户的集群而言,就没那么安全了。 在 Helm 2 时期,为了简单或者说为了安全,我们可以使用 Tillerless 的方式,来避免在集群中安装 Tiller, 同时还可以正常的使用 Helm 的功能。(很早前计划写篇文章介绍一下这个经验来着,结果至今也还没有腾出时间写,现在 Helm 3 发布,也就不用写了,这里大概聊一下) Tillerless 是什么含义呢? 也就是在本地启动一个 Tiller 的服务,让它使用你本地的 KUBECONFIG 的配置文件与集群进行交互,而 Helm 在初始化时,只需要初始化 client 即可, 然后可通过 $HELM_HOST 变量控制连接到本地所启动的 Tiller, 之后便可以正常使用了。(每次部署完成后,将 Tiller 关闭即可)