上游进展

deprecate GlusterFS plugin from available in-tree drivers. by humblec · Pull Request #111485 · kubernetes/kubernetes

在这个 PR 中废弃了 in-tree 的 GlusterFS 的 plugin，这其实是最早的 dynamic provisioner ，自 Kubernetes v1.4 版本开始引入。

在后来 CSI 驱动出现的时候，社区中也立刻出现了对应的驱动实现 https://github.com/gluster/gluster-csi-driver/ ，只不过该项目并没有积极的进行维护。现在还有另一个比较推荐的替代方案，可以考虑使用 https://github.com/kadalu/kadalu/ 此项目最新的版本为 v0.8.15 。

经过社区之前的讨论，还是决定在 v1.25 版本开始将 in-tree 的 GlusterFS plugin 标记为废弃，并在后续的版本中进行移除。

如果有正在使用此插件的小伙伴，我建议可以尽早的评估 kadalu 的可行性 & 迁移成本。

此外，这个修改属于完全删除 in-tree 卷插件的一部分，无论你在使用哪种 in-tree 的卷插件，建议尽早迁移至使用 CSI 驱动的模式。

Add shell completion for new --subresource flag by marckhouzam · Pull Request #109070 · kubernetes/kubernetes

在 Kubernetes v1.24 中，给 kubectl 增加了 subresource 的支持（指 status 和 scale），这样就可以很方便的直接对 subresource 进行操作了，而不需要每次都 -o yaml 之类的直接进行查看，或者通过 curl 之类的调用 API 来完成其他操作。使用了此特性后，可以有如下效果：

# v1.24+
tao@moelove:~$ kubectl get  -n apisix  --subresource status deploy apisix-ingress-controller 
NAME                        AGE
apisix-ingress-controller   2d23h

tao@moelove:~$ kubectl get  -n apisix  --subresource scale deploy apisix-ingress-controller  -ojson
{
    "apiVersion": "autoscaling/v1",
    "kind": "Scale",
    "metadata": {
        "creationTimestamp": "2022-08-04T18:57:45Z",
        "name": "apisix-ingress-controller",
        "namespace": "apisix",
        "resourceVersion": "1656",
        "uid": "7c191a14-ee55-4254-80ba-7c91b4c833bd"
    },
    "spec": {
        "replicas": 1
    },
    "status": {
        "replicas": 1,
        "selector": "app.kubernetes.io/instance=apisix,app.kubernetes.io/name=ingress-controller"
    }
}

但是在此之前版本使用该参数的话，会直接提示错误：

# v1.23
tao@moelove:~$ kubectl-v1.23 get  -n apisix  --subresource status deploy apisix-ingress-controller 
Error: unknown flag: --subresource
See 'kubectl get --help' for usage.

此处我提到的这个在 v1.25 中的 PR 实际上是为了给 --subresource 提供一个命令补全的能力（虽然如上文提到的，目前就两种资源），还是比较方便的。

PodSecurityPolicy 已经被删除，请迁移至 PodSecurity Admission Controller

持续关注「k8s生态」的小伙伴应该还记得，我从去年 Kubernetes v1.21 时候就介绍过，PodSecurityPolicy （PSP）被废弃，将通过内置 PodSecurity Admission 来进行替代。并且在后续的文章中也曾对 PodSecurity Admission 进行了介绍。

此外我之前写过《理清 Kubernetes 中的准入控制（Admission Controller)》和《云原生策略引擎 Kyverno》等文章，介绍一些 Kubernetes 中的 Admission 机制和通用的策略引擎，使用它们也可以作为 PodSecurityPolicy 的替代。

目前在 v1.25 中，PodSecurityPolicy 已经被删除，如果你之前有在使用 PodSecurityPolicy，并且打算将 Kubernetes 集群升级到 v1.25 的话，请先进行迁移。

只要你的 Kubernetes 集群版本先升级到 v1.22 以上，并且开启 PodSecurity 特性，那么就可以按照 Migrate from PodSecurityPolicy to the Built-In PodSecurity Admission Controller | Kubernetes 进行迁移了。

或者使用通用的引擎，比如 Kyverno 或者 OPA/Gatekeeper 等进行替代。

cgroup v2 支持达到 GA

在 2019 年 GitChat 对我的访谈中让我聊 2020 年的技术趋势，我当时的主要观点摘录如下：

"

作为云原生技术的基石，Kubernetes 在 2020 年的热度将会持续上升。而各个公司的集群规模，以及对容器技术的推进都将会持续加大。在经历了初步容器化后，更多的公司将面临的问题是稳定性和性能优化问题。与此同时，service mesh，serverless 等技术也都会逐步得到普遍应用。从底层次技术的角度来看，cgroups v2 将逐步普及，进而取代 cgroups v1，但这个过程可能需要两三年左右。整体而言，稳定性和性能优化将会是未来的主旋律。 "

如今，3 年时间已经过去，Kubernetes v1.25 中对 cgroup v2 的支持已经达到 GA ，和我之前的判断是一样的。

我之前也写了一篇《一篇搞懂容器技术的基石：cgroup》，可能该考虑写篇新的 cgroup v2 了（笑

Nutanix Objects 违反了 MinIO 开源许可的后续

在我上上篇周报中，曾介绍过 Nutanix Objects 违反 MinIO 开源许可事件的背景，如今该事件可能是因为发酵了，所以 Nutanix 给出了正式的回应，承认他们的违规行为。

这里简单说一下为什么 Nutanix 坚持不说他们使用了 MinIO 呢？这是由于对于海外的 Gartner 魔力象限和 GigaOm Radar 之类的行业顶级评估报告而言，如果他们使用了 MinIO 那么就不再是一个独立的软件，在进行评估的时候，会把它们排除在外。当然，应该还会有一些其他商业上的原因。

另一方面，Nutanix 的客户如果根据此事件要求 Nutanix 的赔偿，需要检查下与 Nutanix 的赔偿条款是否有覆盖的这个部分。

从 2019 年至今，这算是一个耗时相对较久的侵权事件了。这也可以反映出开源软件协议/许可被侵权，其实是一个相对不那么容易维权的事情。维权成本比较高。

如果不是 MinIO 背后还有个商业公司会盯着这个事情，也许这事情就不了了之了。