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 关闭即可)

2019 容器使用量报告

最近 sysdig 发布了 2019 容器使用报告,内容还比较有趣,特别来介绍一下。 关注公众号「Moelove」回复 docker2019 即可获取完整 PDF 报告。 关键信息 容器运行时 Docker 仍然是占据市场规模最大的容器运行时 (79%),而其他的,类似 rkt,lxc,podman 之类的市场占比微乎其微,甚至没有在报告中出现。 containerd 源自 Docker,现在也占据了一席之地;而对于 cri-o 报告中指出,之后市场份额可能会增加。 在我个人看来,近一年内 Docker 在企业生产环境的使用规模仍然会保持最大。 编排 可以看到 Kubernetes 遥遥领先,加上构建在 Kubernetes 之上的 OpenShift 和 Rancher ,这个霸主地位是非常稳了。 个人看来,近一年内,Kubernetes 的地位是不可能被撼动了,越来越多的企业也都会将技术栈迁移上去或者调研基于 Kubernetes 的云原生解决方案。 metrics Prometheus 已经成为事实标准,加上 Prometheus 作为 CNCF 毕业项目,以及围绕 CNCF 及云原生相关的各类基础软件等,都增加了各类 metrics,以及各类 exporter 越来越多,几乎可以涵盖生产中所需的各类 metrics 的需求了。 报警 这个图也可以从侧面反映出,节点的稳定性是大多数用户所关注的焦点。(无论上层如何调度,底层的稳定性依然很重要) Pods 规模 多数集群属于中小规模的(也说明是个正在发展的阶段) 结论 容器仍然在应用交付上发挥着重要的作用,从去年发布报告(在公众号后台回复 docker2018 获取)以来,容器技术的采用率仍在加速,容器密度翻了一番,并且随着技术的成熟,也有了越来越多的成熟案例。 Prometheus 已经成为了云原生应用指标的标准化方案,容器编排技术 Kubernetes 成为了事实的标准,企业应该在 Kubernetes 上进行投资,以跟上技术潮流的步伐。 可以通过下面二维码订阅我的文章公众号【MoeLove】, 在公众号后台回复 docker2019 可下载完整报告。

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

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Vitess 正式从 CNCF 毕业 CNCF(云原生计算基金会)在美国时间 2019 年 11 月 5 日宣布 Vitess 正式毕业了。 这是 CNCF 中第 8 个正式毕业的项目,最近的几次周报中,基本都会谈到关于 CNCF 项目毕业相关的信息(忙碌的 Q4 啊) Vitess 最初由 YouTube 在 2010 年创建, 主要是用于 MySQL 横向扩展的数据库系统。据说 Vitess 一直为 YouTube 的所有数据库提供服务,国内貌似是京东使用比较多。 补一张 Vitess 的架构图: 最后,再次 恭喜 Vitess 顺利毕业! Helm v2.16.0 正式发布 在之前的 K8S 生态周报| Helm v2 最后一个特性版本发布中,我介绍了 Helm 正式发布了 v2.15.0 作为 v2 版本的最后一个特性版本。 而本次发布的 v2.16.0 也确实没有主要的特性更新,都是一些问题修复和安全更新等;(在这次版本中是 13 个独立 committers 之一 :) )

K8S 生态周报| Helm v2 爆出全版本漏洞

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Jaeger 顺利从 CNCF 毕业 CNCF(云原生计算基金会)在美国时间 2019 年 10 月 31 日宣布 Jaeger 正式毕业了。 这是 CNCF 中第 7 个正式毕业的项目,在上次周报的最后 我才刚提过一些项目提交了毕业申请,也同时以 Jaeger 为时一年的毕业申请申请举了个例子,没想到本周就毕业了。:) Jaeger 最初是由 Uber 受 Dapper 和 OpenZipkin 启发,开源出来的一套分布式追踪系统。它主要可用于微服务架构下的分布式系统的根因分析,性能/延迟优化,服务依赖等方面。截至目前,它在 GitHub 上有 9.4k 的 star ,986 个 fork 以及 115 位贡献者。 它现在的存储后端主要就支持两种 Cassandra 3.4+ 和 Elasticsearch 5.x/6.x ,在这种系统中,随着服务规模的扩大,对后端存储的要求也会很高。另外,它有一套比较现代化的 UI,是基于 react 开发的。 整体来看的话,在使用上基本技术栈就会成为下面这样: 当然实际的架构也可能会因为基础设施而改变,比如说如果已经使用了 SkyWalking 的话,两者倒是也可以结合,大概就会变成下面这样: 不过,对于技术方案的选择,我个人建议是考虑实际需求,以及对各方案进行理性的权衡,否则的话,说不定什么时候就演变成了下面这样:(这个调用链虽然是可以走通的,但此处我是开个玩笑的, 请勿当真) 最后,再次恭喜 Jaeger 顺利毕业! Helm 2 爆出全版本受影响的漏洞 本周 Helm 官方披露出来一个全版本 (Helm 在 2.

K8S 生态周报| Helm v3 最后一个beta版本发布

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Helm v3.0.0-beta.5 发布 这将是最后一个 beta 版本,下一个版本将会是 Helm v3.0.0-rc.1 。现在主要精力都集中在一些 bugfix 上,也会有一些设计方面的事情还需要最终确认。 快速的看一下在此版本中新增的内容: 为了能提供更多子命令,现在 helm get 和 helm show 分别移动到了 helm get all 和 helm show all, 这是一个破坏性变更; 对 helm get values 增加了一个 --output 的选项,现在支持三种格式 table, json, yaml; helm test 新增了一个 --logs 的参数,这是在 Helm 2 中新增的; 对此版本感兴趣的朋友可以参考 ReleaseNote Docker Hub 新增双因素认证功能 最近 Docker Hub 上线了 双因素认证 的功能。这个事情主要有两个方面的考虑: DockerHub 希望能给用户更多的安全性,以及提供更完善的功能,以此来吸引个人用户/开源项目/组织/企业等使用; 这个事情其实也算是 4 月份被攻击事件的后续,在上个月的周报中,我也介绍了 Docker Hub 上线了 Access Token 的功能。而这次上线 2FA 更是进一步提高了其安全性! 关于如何启用 2FA 可直接参考 Docker Hub 的文档 https://docs.

K8S 生态周报| Helm v2 最后一个特性版本发布

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 文末有活动,欢迎参与。 Docker 19.03.4 正式发布 在本周 Docker 发布了 19.03.4 版本,这个版本主要是为了修复上周周报中介绍的 DOCKER-USER iptables 链丢失的问题。 如果要升级 Docker 版本的话,可选择升级到此版本。 Kubernetes 修复全版本影响漏洞 上周周报中的 上游进展 部分,介绍了对 CVE-2019-11253 的修复,限制 YAML/JSON 的解码大小为 3M 。本周相继发布了以下版本,包含了对此漏洞的修复。 v1.13.12 v1.14.8 v1.15.5 v1.16.2 实际受此漏洞影响的版本是: Kubernetes v1.0.0-1.12.x Kubernetes v1.13.0-1.13.11 (修复于 v1.13.12) Kubernetes v1.14.0-1.14.7 (修复于 v1.14.8) Kubernetes v1.15.0-1.15.4 (修复于 v1.15.5) Kubernetes v1.16.0-1.16.1 (修复于 v1.16.2) 建议对集群进行升级。 但是升级前,请务必先阅读完 https://github.com/kubernetes/kubernetes/issues/83253 的内容 在清楚了解不同版本的行为后,再做升级。 对此漏洞感兴趣的朋友,也可参阅社区公告 Prometheus Pushgateway v1.0 正式发布 Prometheus Pushgateway v1.

K8S 生态周报| Docker 19.03.3 DNS 不再区分大小写

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 文末有活动,欢迎参与。 Docker 19.03.3 正式发布 在本周 Docker 发布了 19.03.3 版本,这个版本的变更内容 很重要,我会将主要内容都列出来。(上周周报介绍了 19.03.3-rc1 的一些情况) 已知问题 DOCKER-USER iptables 链丢失;如果你并不需要在 DOCKER-USER 链上定义规则的话,那你也并不会受此问题的影响。 临时解决办法:手动添加丢失的链,操作如下: iptables -N DOCKER-USER iptables -I FORWARD -j DOCKER-USER iptables -A DOCKER-USER -j RETURN 这个问题会在 19.03.4 中进行修复, 很快会进行发布; 实际会把 libnetwork 中有问题的那段代码先去掉。 如果已经升级了此版本的用户,受到此问题影响的话,可以使用上述方式进行临时解决。 安全问题 将 runc 更新到了 v1.0.0-rc8-92-g84373aaa 这其中包含了 runc 中对 CVE-2017-18367 的修复,该漏洞的根本原因在于 libseccomp-golang 中一个错误的逻辑运算 ,有兴趣的朋友可以点开链接看看实际的修复代码,并且也可以发现该代码其实在 2017 年 4 月就已经合并进 libseccomp-golang 的主干中了,但实际上在今年 6 月在 runc 中才真正修复。 这个问题其实反映出来的是当我们在维护项目时,对自己所用的各种依赖需要有所了解和把握,整体来讲,尽可能避免依赖项过旧是个好事儿;并且安全问题非常值得关注。

Docker 核心知识必知必会

自 2013 年起,随着 Docker 的正式面世,容器技术迅速成为了基础技术领域中的热门。而在近两三年中,随着容器编排领域的混战结束,Kubernetes 已经成为了容器编排领域事实上的标准。 有一些人存在误解,认为 Kubernetes 的出现取代了 Docker。但事实上,Docker 与 Kubernetes 是相辅相成的。Kubernetes 使用 Docker 作为容器运行时,用来启动应用;当 Docker 容器规模变大时,自然是需要有容器编排工具进行管理的。引用最近一次的网络研讨会后的文章内容: In fact, Kubernetes is better with Docker. And Docker is better with Kubernetes. 无论在使用 Docker 或是 Kubernetes 亦或者是使用基于这些技术的其他衍生技术时,都有可能会遇到一些意料之外的情况,当问题发生时,我们总是希望可以快速定位问题,并且从根本上解决问题。 一般情况下,上层的问题比较容易解决,但如果问题发生在运行时/Docker 或容器上时,如果没有系统性的知识,很难从根本上解决问题;当然,有些时候通过搜索引擎可以帮我们找到一些问题的解决办法,但如果不将其彻底搞懂,以后遇到类似问题可能还是没法快速解决。 我自 Docker 0.9 版本时开始学习和使用,自己踩过了很多坑,活跃在社区中,也帮别人解决了很多问题。现在我的新专栏《Docker 核心知识必知必会》正式上线了,共 51 节,从 7 个核心维度来 系统性 的讲解 Docker 容器技术的核心特性及原理,实践与源码相结合;部分内容会深入到 Linux 内核源码,以此来建立起从内核到 Docker 容器技术的知识体系。 我希望借由这个课程,将 Docker 容器技术的本质和思想与我在开发和运维 Docker 过程中对其原理和实践经验的总结讲清楚,并将结合着实践和核心特性的原理,加深对 Docker 容器技术的理解。 因此,我把课程划分成了三大模块: Docker 入门: 这个模块分成了三篇内容,通过第一篇,带你了解 Docker 容器技术生态的发展脉络;第二篇,是为刚入门 Docker 的读者准备的,也是为后续章节进行铺垫;第三篇是很多读者或公司都常会困惑的问题,Docker 与 Linux 内核兼容性如何,要上生产环境该选择哪个版本?我会在这一篇中与你分享,让你不再困惑。