“「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」[1]。 ”
大家好，我是张晋涛。
很抱歉，最近一段时间真的太忙了，写文章都断断续续的。主要在使用 Langchain 搭配 GPT-4 开发一些项目。
此外，在 6 月 11 日的 Gopher China 大会上我会做一个 Service Mesh 相关的分享，来参会的小伙伴欢迎来打个招呼。
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 响应。
代码语言：javascript复制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 左右，预计默认情况下将启用此功能。
感谢大家，我们下期再见！
TheMoeLove
参考资料
[1]
k8s生态: https://zhuanlan.zhihu.com/container
