关于kubernetes:K8S-生态周报-Kubernetes-v125-将-GlusterFS-卷插件废弃

1次阅读

共计 3311 个字符，预计需要花费 9 分钟才能阅读完成。

「K8S 生态周报」内容次要蕴含我所接触到的 K8S 生态相干的每周值得举荐的一些信息。欢送订阅知乎专栏「k8s 生态」。

大家好，我是张晋涛。

本周事件比拟多，闲暇工夫根本都在关注上游的停顿，没折腾其余的货色。
Kubernetes v1.25 失常状况下会在本月公布正式版本。

我来介绍一些本周关注到比拟值得注意的内容：

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/gl…，只不过该我的项目并没有踊跃的进行保护。
当初还有另一个比拟举荐的代替计划，能够思考应用 https://github.com/kadalu/kad… 此我的项目最新的版本为 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 给出了正式的回应，抵赖他们的违规行为。

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

另一方面，Nutanix 的客户如果依据此事件要求 Nutanix 的抵偿，须要查看下与 Nutanix 的抵偿条款是否有笼罩的这个局部。

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

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

好了，以上就是本期的内容，我想发动一个投票理解下大家目前在用的 Kubernetes 版本，欢送大家参加，在 v1.25 公布后投票主动敞开，届时再和大家分享数据。

https://wj.qq.com/s2/10618008…

欢送订阅我的文章公众号【MoeLove】

正文完