「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。
大家好，我是张晋涛。
很抱歉，最近一段时间真的太忙了，写文章都断断续续的。主要在使用 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 响应。
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 添加了一个 config validate 的子命令，用于验证配置是否正确，如果有错误或者警告将会直接提示出来。
这使得在使用 kubeadm 的时候，可以先通过此命令检查配置是否存在问题，提前进行修正。
此外还可以配合使用 kubeadm config migrate 命令, 将旧版本的配置升级到新版本。
修复了一个在没有任何 deployment 时，执行 kubectl rollout status deployment 命令没有返回的 bug，
而且执行该命令后，会一直卡住没有反应。
本次修复增加了对应的报错信息。
Bound service account tokens 在 v1.22 版本中已经 GA，并且是分配 service tokens 的当前和更安全的方式。
然而，旧版基于密钥的令牌的自动生成仍然可用，并且生产集群将会存储大量旧版令牌。
KEP 2799 清理了这个问题，结束了旧版令牌的自动生成。
这个 PR 实现了对旧版令牌进行清除，如果启用 LegacyServiceAccountTokenCleanUp feature gate，则可以使用该功能来清除它们。到 v1.30 左右，预计默认情况下将启用此功能。
感谢大家，我们下期再见！
欢迎订阅我的文章公众号【MoeLove】
