使用nfs网络路径作为kubernetes持久卷 [英] using nfs network path as a kubernetes persistence volume

问题描述

我已经设置了具有三个节点的kubernetes集群.所有节点都是Linux centos计算机.

I have setup a kubernetes cluster with three nodes. All nodes are Linux centos machines.

我需要持久的卷来存储数据，我正在努力实现这一目标.

I need persistent volume to store data and I am trying to achive this.

我正在关注本教程.但是它仅涵盖一个节点群集. https://kubernetes.io/docs/tutorials/stateful -application/mysql-wordpress-persistent-volume/

I was following this tutorial. But it only covers a one node cluster. https://kubernetes.io/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/

由于我的集群由三个节点组成，因此无法使用本地路径.上一教程对我不起作用.

Since, my cluster consist of three node, I could not use local path. Previous tutorial does not worked for me.

我需要一条网络路径，使用NFS对我来说似乎是一个合理的解决方案. (我想听听其他好方法吗?)

I need a network path and using NFS seems a reasonable solution to me. ( Is there any good alternative I would like to hear.)

使用NFS网络安装包含两个步骤. 首先，在网络路径上创建一个持久卷. 其次，将此网络路径定义为持久卷并使用它.

Using NFS network mount contains two steps. First, Creating a persistent volume on a network path. Second, define this network path as a persistent volume and use it.

第二步非常简单.它在kubernetes文档中进行了解释，甚至还有示例yaml. 文档: https://kubernetes.io/docs/concepts/storage /persistent-volumes/#persistent-volumes 示例: https://github.com/kubernetes/examples/blob/master/staging/volumes/nfs/nfs-pv.yaml

Second step pretty straight forward. Its is explained in kubernetes documentation and there is even sample yaml. documentation:https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistent-volumes example: https://github.com/kubernetes/examples/blob/master/staging/volumes/nfs/nfs-pv.yaml

第一部分似乎也很简单.其在以下文件中说明

First part also seems straight forward. Its explained in following document

但是，当将路径导出为NFS路径时，应该进行一些配置并赋予客户端一些权限.基本上，您需要客户端IP.

But when you export a path as a NFS path you should make some configuration and give clients some rights. Basically you need client ip.

对于kubernetes，我们使用诸如pod之类的抽象，我们不想处理真实的机器及其IP地址.因此，问题从这里开始.

With kubernetes we use abstraction such as pods and we don't want to deal with real machines and theirs ip addresses. So, the problem startes here.

因此，我不想将节点ip提供给nfs服务器. (它们可能会在第一位置发生变化.)应该有一个更好的解决方案，即所有Pod(在任何节点中)都应该能够连接到NFS网络路径.

So, I don't want to give nodes ip to nfs server. (They might change in he first place.) There should be a better solution that all pods (in any node) should be able to connect to NFS network path.

即使没有限制地允许所有IP或允许ip范围也可以解决此问题.我想听听是否有这样的解决方案.但是，我也想听听什么是最佳实践.其他人如何使用来自kubernetes的NFS网络路径.

Even allowing all ip without restriction or allowing an ip range might solve the issue. I would like to hear if there is such solution. But, I would also like to hear what is the best practice. How everybody else use NFS network path from kubernetes.

我找不到任何解决方案.如果您解决了类似的问题，请让我知道您如何解决.关于这个问题的任何文件资料也将是好的.预先感谢！

I could not find any solution yet. If you solved similar problem, please let me know how you solve it. Any documenatation on this issue will be good too. Thanks in advance!

推荐答案

您询问了最佳做法，从我发现的情况来看，我认为最好的选择是将IP地址列入白名单.由于您不想这样做，因此还有一些变通方法 NSO中动态IP客户端遇到类似问题的人在SO 上发布的答案.您可以使用 glusterfs 查找部署的链接. a>在发布的答案中.如果您希望NFS具有动态IP(因为它可以更改)，则可以使用DNS名称代替IP.如果需要动态配置，请使用glusterfs.

You asked for best practices and from what I've found I think that the best option would be white-listing the IP addresses. Since you do not want to do that, there are also some workarounds answers posted on SO created by people who had similar issues with dynamic IP clients in NFS. You can find a link to deployment using glusterfs in the posted answers. If you want NFS with dynamic IP (because it can change), you can use DNS names instead of IP. If you need dynamic provisioning, use glusterfs.

我将根据您的要求添加一些有关卷的信息.可能会让您对该主题有所了解并帮助解决该问题.
由于吊舱是临时的，因此您需要将卷移动到吊舱外部-因此使其独立于吊舱-因此，如果吊舱发生故障，该卷将保持其状态. Kubernetes支持多种类型的卷.
您可以使用NFS(在上一个链接中有更多有关NFS的信息)-因此，在删除Pod之后，该卷将被卸载，但它仍然存在.在您的情况下，也不希望这样做，因为用户需要知道文件系统类型以及有关将要连接到的卷的其他详细信息.当您转到有关NFS yaml文件的文档中的示例时，您会看到它们的类型定义为持续批量声明.
此方法基于创建一系列允许节点连接到持久卷的抽象，但是用户不需要任何后端详细信息，此外，您的节点可以连接到许多提供程序.

I will add some information about the volumes as you asked. Might give you some light on the topic and help with the issue.
Since pods are ephemeral you need to move the volume outside the Pod - therefore making it independent from the Pods - so the volume would persist its state in case of Pod failure. Kubernetes supports several types of Volumes.
You could use NFS (more on NFS in the previous link) - so after the Pod is removed the volume gets unmounted, but it still exists. This is also not desired in your situation as the user needs to know the file system type and other details about the volume it will want to connect to. When you go to the examples in the documentation about NFS yaml files, you will see that their kind is defined as a Persistent Volume Claim.
This method is based on creating a series of abstractions that will allow a Node to connect to the Persistent Volume, but the user will not need any backend details, in addition, your node can connect to many providers.

这篇关于使用nfs网络路径作为kubernetes持久卷的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！