ebs.csi.aws.com 与 kubernetes.io/aws-ebs 对于配置程序有什么区别？

Question

我知道“配置者”的概念，但我不明白 intree ebs 驱动程序的含义。ebs.csi.aws.com 是 aws 维护的 csi 驱动程序，另一个是 k8s 本身维护的吗？这个比那个好吗？

Answer 1

根据官方文档：

\n

\n

在CSI之前，Kubernetes提供了强大的卷插件系统。这些卷插件是 \xe2\x80\x9cin-tree\xe2\x80\x9d ，这意味着它们的代码是核心 Kubernetes 代码的一部分，并随核心 Kubernetes 二进制文件一起提供。然而，向 Kubernetes 添加对新卷插件的支持具有挑战性。想要向 Kubernetes 添加对其存储系统的支持（甚至修复现有卷插件中的错误）的供应商被迫与 Kubernetes 发布流程保持一致。此外，第三方存储代码导致核心 Kubernetes 二进制文件出现可靠性和安全性问题，并且 Kubernetes 维护人员通常很难（在某些情况下不可能）测试和维护这些代码。使用 Kubernetes 中的容器存储接口解决了这些主要问题。

\n

\n

\n

随着更多 CSI 驱动程序的创建并投入生产，我们希望所有 Kubernetes 用户都能从 CSI 模型中获益。但是，我们不想通过破坏现有的通用存储 API 来强制用户进行工作负载/配置更改。前进的方向很明确 - 我们必须用 CSI 替换 \xe2\x80\x9cin-tree 插件\xe2\x80\x9d API 的后端。

\n

\n

所以回答你的问题 - 是的，ebs.csi.aws.com 由 AWS 维护，而树内插件由 Kubernetes 维护，但似乎他们已经停止按照本文实现新功能：

\n

\n

当我意识到树内存储插件已被弃用并且从 Kubernetes 1.20 开始没有对它们进行新的增强时，这个旅程的想法开始升温。当我发现简单地从 gp2 切换到 gp3 卷意味着我必须开始使用 AWS CSI 驱动程序时，我意识到我已经落后于时代了。

\n

\n

回答您的最后一个问题，按照以下说明使用 ebs.csi.aws.com 可能会更好：

\n

\n

现有的树内 EBS 插件仍受支持，但通过使用 CSI\n驱动程序，您可以从 Kubernetes\n上游发布周期和 CSI 驱动程序发布周期之间的解耦中受益。

\n

\n