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
上游进展
kubeadm: add the "config validate" subcommand by neolit123 · Pull Request #118013 · kubernetes/kubernetes
kubeadm 添加了一个 config validate
的子命令,用于验证配置是否正确,如果有错误或者警告将会直接提示出来。 这使得在使用 kubeadm 的时候,可以先通过此命令检查配置是否存在问题,提前进行修正。
此外还可以配合使用 kubeadm config migrate
命令, 将旧版本的配置升级到新版本。
add no resources found message to rollout-status command by gxwilkerson33 · Pull Request #117884 · kubernetes/kubernetes
修复了一个在没有任何 deployment 时,执行 kubectl rollout status deployment
命令没有返回的 bug, 而且执行该命令后,会一直卡住没有反应。
本次修复增加了对应的报错信息。
LegacyServiceAccountTokenCleanUp alpha by yt2985 · Pull Request #115554 · kubernetes/kubernetes
Bound service account tokens 在 v1.22 版本中已经 GA,并且是分配 service tokens 的当前和更安全的方式。
然而,旧版基于密钥的令牌的自动生成仍然可用,并且生产集群将会存储大量旧版令牌。
KEP 2799 清理了这个问题,结束了旧版令牌的自动生成。
这个 PR 实现了对旧版令牌进行清除,如果启用 LegacyServiceAccountTokenCleanUp
feature gate,则可以使用该功能来清除它们。到 v1.30
左右,预计默认情况下将启用此功能。
感谢大家,我们下期再见!
温馨提示:文章内容系作者个人观点,不代表Docker中文社区对观点赞同或支持。
版权声明:本文为转载文章,来源于 张晋涛 ,版权归原作者所有,欢迎分享本文,转载请保留出处!
发表评论