库伯奈特在生产中的持久储存

Question

我在实验和学习Rancher/Kubernetes。在一个非常短的eBook中，我读到了这个。

“在Kubernetes集群中，需要有可供应用程序使用的持久存储。由于这个集群中没有启用Kubernetes云提供程序，因此我们将部署nfs- server -provisioner，它将在Kubernetes集群中运行NFS服务器，以便持久存储。

--这不是一种可以生产的解决方案，但有助于说明持久存储结构.“

我在Rancher中配置了nfs-server-provisioner，一切都像预期的那样工作。但这里有个问题。

为了我的“生产”主页，我准备了5倍裸金属服务器，并安装在Kubernates之上的Rancher，我还创建了一个RKE2集群

• etcd
• 控制平面节点
• worker Node 1
• worker Node 2

F 211

我不使用AWS，Azure或任何云解决方案。

什么是我的堆栈的“生产准备解决方案”。为什么"nfs-server-provisioner“不是”生产就绪解决方案“呢？

Answer 1

在没有看到全文的情况下，这只是猜测，但基于这个引用，仅使用nfs-server-provider并不能提供“真实”和可靠的持久性。

NFS -服务器提供商在集群中启动NFS服务器，这意味着它的数据也在kubernetes的存储系统中。这里没有真正的持久性:相反，基于NFS的持久卷的持久性、可用性和安全性取决于nfs-服务器提供者存储数据的方式。如果供应商以不高可用的方式存储NFS数据，则肯定会失去生产准备--例如，在每个节点上的本地主机路径上。如果nfs-server-provider正在使用可靠的存储类，那么为什么不减少开销，直接对所有持久卷使用该存储类呢？这可能就是你引用的文字所指的。

我还想指出(至少在旁边)，当NFS服务器驻留在同一个集群中时，使用NFS作为存储类可能意味着自找麻烦。如果节点上的NFS -服务器提供程序由于某种原因而失败(甚至是一个微不足道的原因，比如无法获取映像)，您将失去对基于NFS的持久卷的访问，将所有依赖NFS卷的荚发送到崩溃循环上。然而，对于Longhorn、OpenEBS和其他集群存储类也是如此。

做好生产准备，需要您至少将NFS -服务器-提供者本身配置为使用生产级存储后端，或者使用高度可用的外部NFS。

还请注意，对于生产级别，至少应该有两个控制平面和三个etcd节点，而不是一个和一个(不要使用偶数的etcd节点！)。一个节点可以运行多个节点，所以使用您的设备，我可能会选择两个节点，运行控制平面和etcd的两个节点，两个“纯”的工作节点和一个节点同时运行这三个节点。最后一种并不是推荐的，但在homelab环境下，当使用pod副本进行测试时，会给您提供更多的工作人员。