Docker v24.0 正式发布

Docker v23.0.0 在今年 2 月份发布，我也写了一篇 K8S 生态周报| Docker v23.0.0 正式发布，带来众多新特性 | MoeLove 来详细进行了介绍。

事实上 Docker 在 v23.0.0 之前的一个大版本是 v20.10 发布于 2020 年的 12 月份，看起来沉寂了两年多的时间，不过却也是一直在发 patch 版本，上个大版本的 patch 版本也更新到了 v20.10.25。Docker v20.10.25 也将是 v20.10 系列的最后一个版本，不会再继续更新。

作为一个真正被用户采用的开源项目，在初期会不断的满足用户需求，并且也不断的有贡献者参与进来，迭代速度相对较快。但是当大多数需求已经被满足，成为一个基础设施的时候，大多数用户会更加关注于上层的项目，比如 Kubernetes，而逐步放弃对该项目的投入。

目前 Docker Inc. 一直在积极发展，整体在变好，所以 Docker 社区上的投入也在逐步增加。

我在之前的文章 K8S 生态周报| Docker v24.0.0-beta.1 发布 | MoeLove中简要介绍过其中的一些特性，如今它终于发布了正式版！

以下补充一些其他值得关注的内容：

废弃

--oom-score-adjust 配置项被弃用，这个配置项原本是用来调整 dockerd 的 oom_score_adj 配置的，可用于避免 dockerd 在系统出现 OOM 的时候早于容器被 OOM kill，相关的内容可以在我两年前写的这篇文章中看到：K8S 生态周报| Docker v20.10.6 发布，修正了 K8S 中 dind 的异常行为 | MoeLove

它的实现也比较简单，调整 /proc/self/oom_score_adj 即可。

func setupOOMScoreAdj(score int) error {
 if score == 0 {
  return nil
 }
 f, err := os.OpenFile("/proc/self/oom_score_adj", os.O_WRONLY, 0)
 if err != nil {
  return err
 }
 defer f.Close()
 stringScore := strconv.Itoa(score)
 _, err = f.WriteString(stringScore)
 if os.IsPermission(err) {
  if !userns.RunningInUserNS() {
   logrus.Debugf("Permission denied writing %q to /proc/self/oom_score_adj", stringScore)
  }
  return nil
 }

 return err
}

docker info 不再展示 Registry 字段了。

不知道是否有人去尝试过，如果访问这个地址其实会得到 404 响应。

tao@moelove:~$ docker info |grep Registry
 Registry: https://index.docker.io/v1/

index.docker.io 是第一个 DockerHub 的域名，也是它得第一个名称，它实际被命名为 "Docker Index"（因此是 index.docker.io）。该注册表使用了注册表规范的 v1 版本，其中包括 search。

后来 Docker Index 变成了 DockerHub，并且注册表 v2 API 成为 OCI Distribution Spec 的基础。

DockerHub 注册表迁移到另一个域名（registry-1.docker.io），但是 v2 规范（按设计）不提供搜索接口，因此这些接口仍然使用 v1 API（可在 https://index.docker.io/v1/search/ 上访问）。

在某个时候，Docker Engine 和 Docker CLI 代码中实现了逻辑来映射域名到其新位置（例如，对于 docker.io/xxxx image 引用到 registry-1.docker .io 的映射以及从 index.docker.io 进行身份验证的映射）；

相同的逻辑也进入所有容器生态（containerd、cri-o、kubernetes），这意味着随着 Docker Engine 已经有超过3000万月度安装量，要更改这些内容而不破坏现有安装变得非常具有挑战性。

所以这些内容后来也就一直没有变化了，但是这对于用户而言，有可能会产生一些误解，干脆就不再展示了。

Kubernetes Ingress-NGINX v1.8 发布

我们在近期已经发布了 Kubernetes Ingress-NGINX 项目的 v1.8 版本。

这个版本中有一个非常重要的变更需要注意 ⚠️

请所有 Kubernetes Ingress-NGINX 的用户及管理员在升级至新版本前先进行检查。

为了规避我们遇到的一些 CVE 漏洞，所以我们在 ingress-nginx controller 中新增了一个配置项，用户可以选择开启该配置项，以便对 Ingress 资源进行严格校验。

Ingress 资源中的 pathType 用于描述如何匹配请求路径。在 Kubernetes Ingress 中，有三种 pathType：ImplementationSpecific，Prefix 和 Exact。下面是对这三种 pathType 的解释以及使用例子。

ImplementationSpecific（实现特定）: 这是默认的 pathType，它允许 Ingress 控制器自定义路径匹配的规则。实际的匹配规则取决于 Ingress 控制器的实现。例如，Kubernetes Ingress-NGINX 将 ImplementationSpecific 视为 Prefix 类型。

apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-ingress spec: rules:
- host: my-host.example.com http: paths:
  - path: /app pathType: ImplementationSpecific backend: service: name: my-service port: number: 80

由于 ImplementationSpecific 的实际行为取决于 Ingress 控制器的实现，以 nginx-ingress-controller 为例，它将 ImplementationSpecific 视为 Prefix 类型。因此，以下请求路径将正确路由到 my-service：

/app
/app/
/app/something

以下请求路径将不会被正确路由：

/application
/anotherapp

Prefix：前缀匹配

apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-ingress spec: rules:
- host: my-host.example.com http: paths:
  - path: /api pathType: Prefix backend: service: name: api-service port: number: 80

对于 Prefix 类型，以下请求路径将正确路由到 api-service：

/api
/api/
/api/some-resource
/api/users/123

以下请求路径将不会被正确路由：

/apis
/application
/anotherapi

Exact：精确匹配

apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-ingress spec: rules:
- host: my-host.example.com http: paths:
  - path: /exact pathType: Exact backend: service: name: exact-service port: number: 80

对于 Exact 类型，只有一个请求路径将正确路由到 exact-service：

/exact

以下请求路径将不会被正确路由：

/exact/
/exact/something
/exactly

这些例子说明了每种 pathType 的路径匹配行为及正确和错误的路由。在实际应用中，可以根据具体需求选择合适的 pathType。

此外，正如前面提到的，不同的 ingress-controller 的实现并不完全一样。

比如 Apache APISIX Ingress controller 默认将 ImplementationSpecific 视为 Exact 类型。这与数据面的 Apache APISIX 也是有关系的。在处理 Prefix 类型的 pathType 时，创建了两个 uri 来进行兼容。

该版本中的其他变化影响并不是很大，有兴趣的小伙伴可以看看 ReleaseNote