K8S 生态周报| Ingress-NGINX v1.8 发布,升级前请先检查

  张晋涛   2023-06-12 16:08   1147 人阅读  0 条评论

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中简要介绍过其中的一些特性,如今它终于发布了正式版!

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

废弃

它的实现也比较简单,调整 /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 中,有三种 pathTypeImplementationSpecificPrefix 和 Exact。下面是对这三种 pathType 的解释以及使用例子。

  1. 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
  1. 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
  1. 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 左右,预计默认情况下将启用此功能。

感谢大家,我们下期再见!



本文地址:https://dockerworld.cn/?id=321
温馨提示:文章内容系作者个人观点,不代表Docker中文社区对观点赞同或支持。
版权声明:本文为转载文章,来源于  张晋涛 ,版权归原作者所有,欢迎分享本文,转载请保留出处!

 发表评论


表情

还没有留言,还不快点抢沙发?