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

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

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/kuberneteskubectl 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                   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 上次重启/恢复的时间,而不需要去查看日志,方便了很多。

项目推荐

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

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

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

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

apisix-mesh-overview


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

TheMoeLove

你可能感兴趣的:(K8S 生态周报| Docker v20.10.7 发布,修复了死锁和容器启动失败的问题)