K8S 生态周报 | Docker v20.10.7 发布，修复死锁和容器启动失败的问题-低调大师

K8S 生态周报 | Docker v20.10.7 发布，修复死锁和容器启动失败的问题

2021-06-27 634

“
「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」^[1]。
”

大家好，我是张晋涛。抱歉拖更了，这次为大家带来了近一段时间内值得关注的 K8S 生态的信息。其中，Docker 和上游进展的部分是需要重点关注的。

Docker v20.10.7 正式发布

Docker 在近期也发布了 v20.10.7 版本，这个版本中主要都是侧重在稳定性和安全性上，我们一起来看看具体有哪些值得关注的内容吧！

CLI

CLI 方面主要是移除掉了一直以来存在的 WARNING: No kernel memory limit support 这个 Warning 信息，同时在 cgroup v2 下也不会再显示 WARNING: No oom kill disable support 的 Warning 信息了。

为什么呢？因为 oom kill disable 在 cgroup v2 下不可用。如果你在 cgroup v2 下使用了 --oom-kill-disable 选项就会看到如下提示：

➜  ~ docker info |grep Cgroup                 
 Cgroup Driver: systemd
 Cgroup Version: 2
➜  ~ docker run --rm -it --oom-kill-disable -m 6m alpine sh
WARNING: Your kernel does not support OomKillDisable. OomKillDisable discarded.

这里如果要介绍 cgroup v2 那内容就太多了，我在 2019 年接受访谈聊容器技术趋势的时候就做了如下预测：

“
从底层次技术的角度来看，cgroup v2 将逐步普及，进而取代 cgroup v1，但这个过程可能需要两三年左右。

整体而言，稳定性和性能优化将会是未来的主旋律。
”

现在已经过去了一年多的时间，完全符合我当时的预测。现在包括 runc、containerd、Docker、Kubernetes 等组件已经全部都支持了 cgroup v2 ，包括 Fedora 等操作系统也已将 cgroup v2 设置成了系统默认选项。各公司也都逐步在往 cgroup v2 上进行了迁移。

Networking

在此版本中，主要解决了两个网络相关的问题。

修复了一个可能导致 Docker DNS 无法解析的 deadlock 问题，此问题主要是在使用 Swarm 集群时才会遇到，其他直接使用 Docker 或者将 Docker 作为 Kubernetes 容器运行时的用户不受影响。
由于在 Docker v20.10.6 版本中处理了针对有 IPv6 网络机器上容器端口映射 API 的问题，详情请参考我之前的 K8S 生态周报 - Docker v20.10.6 发布一文的内容。但是这里没有正确的处理当内核带有 ipv6.disable=1 选项启动时的问题，这会导致当服务器启动时候，如果设置了 ipv6.disable=1 参数且进行了端口映射，则容器无法正常启动。

解决办法有 3 种：

取消 ipv6.disable=1 选项的设置（但通常这么设置了应该是有特定原因的）；
升级到 Docker v20.10.7 版本；
在进行端口映射的时候，手动指定其绑定的 IPv4 地址，例如 docker run -d -p 0.0.0.0:6379:6379 ghcr.io/moelove/redis:alpine ；

其他

默认使用 containerd v1.4.6 和 runc v1.0.0-rc95 以便于解决 CVE-2021-30465 漏洞；

docker scan 更新到了 v0.8 ；

➜  ~ docker scan --version  
Version:    v0.8.0
Git commit: 35651ca
Provider:   Snyk (1.563.0 (standalone))

这个版本我是推荐大家进行更新的，尤其是如果你受到了文中提到的 v20.10.6 版本相关问题影响的话，那更加值得升级了。

Docker Desktop 3.4.0 发布

这个版本对大多数用户而言，需要关注的点主要有两个：

Docker Inc. 积极听取社区用户的反馈，跳过更新的功能，不再是付费用户专有了，可以放心选择升级/跳过升级，这个事情的背景可以参考我前两期的 K8S 生态周报 ;
这个版本中对相关组件都进行了升级，包括 Docker Engine 升级到了 v20.10.7 ，Kubernetes 升级到了 v1.21.1 等；

Rook v1.6.5 发布

这是一个 patch release ，变动不大，但这个版本中有个值得关注的内容：

现在可以通过 Helm chart 来配置 CephCluster 这个 CR 了；

你可以使用类似下面的命令来进行配置：

helm repo add rook-master https://charts.rook.io/master
helm install --create-namespace --namespace rook-ceph rook-ceph-cluster \
    --set operatorNamespace=rook-ceph rook-master/rook-ceph-cluster -f values-override.yaml

这种方式相比之前每次都要写个 YAML 要方便多了，另外值得注意的一点是当前的 Helm chart 是实验性的，预计在 v1.7 中达到 stable 。

Thanos v0.21 发布

Thanos 是一个完整的 Prometheus HA 和持久化存储的方案。我在之前的文章中已经介绍过多次（搜了下从 2019 年 Thanos 成为 CNCF sandbox 项目开始就已经在持续介绍它了）

此次更新最主要的特性只有一个：

为 Thanos API 增加了 TLS 和 basic auth 认证。

这其实也是众多监控项目的一个发展趋势，还记得我之前写的文章《为 Prometheus Node Exporter 加上认证》吗？早期解决了有没有及普及度的问题后，就会逐步将注意力往安全性上放了。

Kubernetes Ingress-NGINX v0.47 发布

这个版本的发布主要是为了解决两个问题：

修复 NGINX v1.20 的 CVE 漏洞，将其更新到了 v1.20.1 版本；
为后续版本做准备。在后续版本中，我们计划逐步放弃对旧的 Kubernetes 版本的支持；

兼容说明如下：

Kubernetes 版本	Ingress-NGINX 版本	支持说明
1.22	TBD	进行中
1.21	v0.47.0	仅支持 CVE 和 crash 修正
1.20	v0.47.0	仅支持 CVE 和 crash 修正
1.19	v0.47.0	在 v1.22 发布后 6 个月废弃

另外值得一提的是，这个版本是我和另外两个维护者一起发布的。我们三个人耗费了将近 2 个小时才完成了此次版本的发布，跨时区协作其实蛮累的。

上游进展

#102489 · kubernetes/kubernetes 在新发布的几个 patch release 中，包含了一项 regression，会导致 kubelet crash，建议大家不要升级！最新的修正版本本周将会发布。

#100142 · kubernetes/kubernetes 在 kubectl get pods 的输出中添加了 LAST RESTART 列，例如：

$ kubectl get pods -A
NAMESPACE                NAME                                    READY   STATUS    RESTARTS   LAST RESTART   AGE
kube-system              coredns-74ff55c5b-6qp7j                 1/1     Running   7          23h            7d3h
kube-system              coredns-74ff55c5b-z79st                 1/1     Running   7          23h            7d3h
kube-system              etcd-jjacobelli-lt                      1/1     Running   6          23h            7d3h
kube-system              kube-apiserver-jjacobelli-lt            1/1     Running   0          <none>         57s
kube-system              kube-controller-manager-jjacobelli-lt   0/1     Running   8          61s            7d3h
kube-system              kube-flannel-ds-c8d66                   1/1     Running   7          8h             7d3h
kube-system              kube-proxy-r9nrx                        1/1     Running   6          23h            7d3h
kube-system              kube-scheduler-jjacobelli-lt            0/1     Running   8          62s            7d3h

这样做的好处在于，用户可以很快的发现 Pod 上次重启/恢复的时间，而不需要去查看日志，方便了很多。

#102529 · kubernetes/kubernetes CronJobControllerV2 达到 GA ！我在《K8S 生态周报| Kubernetes v1.21 发布, 带来新的内存管理器》中曾介绍过它，感兴趣的小伙伴可以看看；
一个有趣的提案 KEP 2775 , 这个提案主要目的是为了保护集群资源，以及免受关联删除的影响，提出希望增加交互式删除或者延迟删除的功能，有兴趣的小伙伴可以去这个 KEP 下留言，讨论；
GKE Dataplane V2 已于日前 GA ，请参考我之前的两篇文章了解其背景《K8S 生态周报| Google 选择 Cilium 作为 GKE 下一代数据面》和《被 Google 选择的下一代数据面 Cilium 是什么》。目前它 GA 也标志着 Cilium 的又一大发展！
Grafana v8.0 正式发布了，在这个版本中增加了 AlertManger 的数据源，在告警方面的一大进步。

项目推荐

apisix-mesh-agent - 将 Apache APISIX 用于数据面，与 Istio 等控制面结合使用的 service mesh 项目。利益相关：我是 api7 团队的一员

推荐此项目主要原因如下：

Envoy 项目的上手学习成本较大。Apache APISIX 相比之下更易上手和进行扩展；
Apache APISIX 的性能相较 Envoy 来说是极大的优势；

如果你正在使用 Istio 但苦于 Envoy 的上手/二次开发难度大，那么我推荐你可以去了解下此项目。不过此项目当前只发布了 v0.6 版本，还需要持续的打磨，欢迎参与！

apisix-mesh-overview

欢迎订阅我的文章公众号【MoeLove】

参考资料

[1]

k8s生态: https://zhuanlan.zhihu.com/container

本文分享自微信公众号 - MoeLove（TheMoeLove）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。

微信关注我们

原文链接：https://my.oschina.net/jiayou9020/blog/5078630

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

WhyNotWin11：开源的 Windows 11 升级检测工具

Windows 11 已于近日正式宣布。与此同时，微软提供了一款名为"PC Health Check"的检测工具，以帮助用户确认电脑是否满足升级要求。然而这款工具的使用体验并没另大多数用户感到满意，例如电脑不满足升级要求，但却不告知具体是哪里不符合条件，或者提供相关指导，有时候甚至会出现运行错误。为此，开发者自己编写了一个代替 PC Health Check 的工具——"WhyNotWin11"，并将其托管至 GitHub 以进行开源。虽然称它为工具，但本质其实还是一个脚本，如果要从源代码进行构建，需要在AutoIt 中进行操作。顾名思义，"WhyNotWin11" 除了可以检测电脑是否满足升级到 Windows 11 的要求外，还能提供未满足升级条件的具体原因。WhyNotWin11 的大致运行过程是，它根据微软列出的所有相关标准来检查电脑的升级条件，而且它还会与微软在标准方面的变化保持同步更新。例如下图中的 TPM 1.2 条件已经被微软移除，因此该工具也不再打算对此进行检测。 WhyNotWin11 下载地址：https://github.com/rcmaehl/WhyNo...

2021-06-27

669

Pike 4.1.0版本正式发布，支持更多的种类的持久化存储，如：redis、mongodb等。主要的特性如下：提供WEB的管理配置界面，简单易上手支持br与gzip两种压缩方式，根据客户端自动选择。对于可缓存与不可缓存请求使用不同的压缩配置，更佳的时间与空间的平衡仅基于Cache-Control生成缓存有效期，接口缓存完全由接口开发者决定，准确而高效(开发比运维更清楚接口是否可缓存，可缓存时长) 配置支持文件与etcd两种形式存储，无中断的配置实时更新支持H2C的转发，提升与后端服务的调用性能（如果是内网转发，不需要启用）与upstream的调用支持gzip，brotli，lz4，snappy以及zstd压缩，可根据与upstream的网络线路选择合适的压缩方式支持upstream检测失败时回调告警，可及时获取异常upstream信息支持自定义日志，可配置按日期与大小分割日志并压缩 LUR与持久化存储（可选）配合使用，可根据内存使用选择更小的LRU缓存并增加持久化存储的方式持久化存储支持以下形式：badger(文件)、redis以及mongodb

2021-06-27

681

资源下载

更多资源

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源，继承了IntelliJ IDEA强大的JS部分的功能。