关于docker:K8S-生态周报-Docker-v20107-发布修复了死锁和容器启动失败的问题

35次阅读

共计 3988 个字符,预计需要花费 10 分钟才能阅读完成。

「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/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 版本,还须要继续的打磨,欢送参加!


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

正文完
 0