POD 存储、PV、PVC

容器如何持久化存储？

PV和PVC

为什么不能直接在 Pod 或容器中存储数据？

什么是 PV和 PVC？

可以使用本地磁盘空间创建PV吗？

POD%E9%87%8C%E9%9D%A2%EF%BC%9F-toc" style="margin-left:80px;">如何让客户端通过ftp上传到远端服务器的POD里面？

POD%E6%83%B3%E8%AE%BF%E9%97%AEftp%E7%9A%84POD%E9%87%8C%E9%9D%A2%E7%9A%84%E6%96%87%E4%BB%B6%E6%80%8E%E4%B9%88%E5%8A%9E%EF%BC%9F-toc" style="margin-left:80px;">另一个POD想访问ftp的POD里面的文件怎么办？

容器如何持久化存储？

在 Docker 或 Kubernetes 中，容器的数据存储行为是 基于层（layer）的，并且容器内的数据在容器生命周期内是持久的，直到容器被删除为止。

1. 容器和镜像的关系

容器是基于镜像（Image）创建的。镜像本身是只读的，而容器在启动时会创建一个可写层，容器对文件系统的所有更改都会写入这个可写层。这就意味着：

镜像：是静态的、不可变的，只包含基础文件和应用程序的环境配置。
容器的可写层：在容器运行时创建，这个层用于保存容器的所有更改，包括安装的应用、修改的文件、生成的数据等。

因此，容器内的文件和更改不会被直接丢失，除非容器被删除。如果容器被停止或重启，但 容器没有被删除，它的可写层中的数据将仍然保留。

2. 容器重启

如果容器被重启，它会重新启动容器本身，但不会丢失之前的更改，因为容器的可写层是持久存在的（即使容器停止或重启，也不会丢失数据，除非容器本身被删除）。

容器停止并重启：容器的文件系统保持不变，所有在容器内做的更改（如修改配置文件、写入日志等）会在容器重启后仍然存在。
容器被删除：如果容器被删除，无论它是否重启，容器内的更改都会丢失。

3. 举个例子

假设你启动了一个容器，在容器内创建了一个文件 /tmp/test.txt，然后停止并重启容器：

重启容器：容器内的 /tmp/test.txt 文件将会保留。
删除容器并重新启动：容器内的 /tmp/test.txt 文件会丢失，因为容器被完全删除，重建了一个新的容器实例。

4. 容器存储与持久化

容器的可写层是 临时的，它绑定到容器的生命周期。如果你希望数据在容器重启或删除后仍然存在，通常需要使用 持久化存储。在 Kubernetes 中，通常使用 Persistent Volumes (PV) 和 Persistent Volume Claims (PVC) 来解决这个问题。

5. 总结：

容器内的数据在容器重启时不会丢失，只要容器本身没有被删除，容器的可写层中的所有更改会保留。
如果容器被删除，容器内的所有数据（包括在可写层中存储的文件）都会丢失。
持久化存储（如 PV 和 PVC）可以确保数据即使在容器删除或重启后也能保持不丢失。

持久化存储解决方案

对于需要长期存储数据的应用，推荐将数据存储在持久化存储上，而不是直接保存在容器的文件系统中。通过挂载 Persistent Volume (PV) 和 Persistent Volume Claim (PVC)，数据将独立于容器的生命周期存在，这样即使容器删除或重启，数据也能得到持久保存。

//没有k8s，直接把容器目录挂载到主机目录即可持久化存储。

PV和PVC

为什么不能直接在 Pod 或容器中存储数据？

直接在 Pod 或容器内存储数据确实是可能的，但这样做有几个问题，尤其是在容器化环境和 Kubernetes 集群中：

容器的短暂性：Kubernetes 中的容器（以及 Pod）通常是短暂的，可能会被删除、重启或重新调度。如果容器被删除，容器内的数据会丢失。因此，容器内部存储的文件是临时的，并且在 Pod 的生命周期内无法保持持久性。
Pod 调度和重启：Pod 可能会因为各种原因被删除或重新调度到其他节点。Kubernetes 通过其调度机制决定将 Pod 放在哪个节点运行，这意味着如果没有外部持久存储，每个节点的本地存储都会是独立的，无法共享，也可能在 Pod 重启时丢失数据。
存储共享的需求：如果你需要让多个 Pod 访问相同的数据（例如，多个 Pod 需要读取或写入相同的文件），则必须依赖于共享的存储系统。

什么是 PV和 PVC？

Persistent Volume (PV)：是 Kubernetes 集群中一个 具体的存储资源，通常由集群管理员预配置。PV 是对物理存储资源的抽象，它可以是多种类型的存储后端（如 NFS、iSCSI、Ceph、云存储等）。它拥有明确的生命周期，并且独立于 Pod 和容器的生命周期。
Persistent Volume Claim (PVC)：是用户对存储的请求。它类似于对 PV 的“租用”请求。PVC 定义了存储的需求（如大小、访问模式等），Kubernetes 调度器会自动匹配一个合适的 PV 来满足 PVC 的要求。PVC 是用户和存储之间的接口，它让用户无需直接关心存储的具体实现方式，而是专注于声明自己需要什么样的存储。

可以使用本地磁盘空间创建PV吗？

可以使用本地磁盘空间创建 Persistent Volume (PV)。在 Kubernetes 中，你可以使用本地磁盘（例如，物理硬盘、SSD 或本地挂载的存储）来创建一个 PV。这通常通过 hostPath 或 local 类型的存储来实现。

但是，使用本地磁盘作为持久存储时，需要考虑一些因素，例如 数据的可靠性 和 Pod 的迁移性。因为如果 Pod 运行在某个节点上，而这个节点出现故障或被删除，存储在该节点上的数据将无法访问。为了确保数据的持久性和可靠性，通常会使用 分布式存储系统 或 网络存储（如 NFS、Ceph、iSCSI 等）。但是，若你只是为了测试、开发或某些特定用途，使用本地磁盘作为 PV 是完全可以的。

1. 通过 hostPath 创建本地磁盘的 PV

hostPath 类型的 PV 允许你直接将本地节点的目录或磁盘挂载到容器中。这适用于在单个节点上使用本地磁盘，但不推荐在生产环境中使用，因为它依赖于特定的节点，且不支持跨节点共享。

示例：使用 hostPath 创建 PV

apiVersion: v1
kind: PersistentVolume
metadata:name: local-pv
spec:capacity:storage: 10Gi  # 存储大小volumeMode: FilesystemaccessModes:- ReadWriteOnce  # 单节点读写persistentVolumeReclaimPolicy: Retain  # 数据不会自动删除storageClassName: manual  # 存储类（手动配置）hostPath:path: /mnt/disks/mydisk  # 本地磁盘的挂载路径type: DirectoryOrCreate  # 如果目录不存在则创建

解释：

hostPath 指定了本地磁盘路径（例如 /mnt/disks/mydisk）。
accessModes 设置为 ReadWriteOnce，表示该 PV 只能由一个节点的一个 Pod 进行读写访问。
persistentVolumeReclaimPolicy 设置为 Retain，表示当 PV 被删除时，数据不会被删除。
storageClassName 设置为 manual，表示使用手动配置的存储类。

2. 通过 local 类型创建本地磁盘的 PV（推荐方法）

在 Kubernetes 1.14 及以上版本，官方引入了 local 类型的 PV，它更好地支持本地存储设备，并且可以在集群节点上通过 local 存储提供持久存储。这种方式相较于 hostPath 更适合生产环境中的本地存储。

示例：使用 local 类型创建 PV

apiVersion: v1
kind: PersistentVolume
metadata:name: local-pv
spec:capacity:storage: 10Gi  # 存储大小volumeMode: FilesystemaccessModes:- ReadWriteOnce  # 单节点读写persistentVolumeReclaimPolicy: Retain  # 数据不会自动删除storageClassName: manual  # 存储类（手动配置）local:path: /mnt/disks/mydisk  # 本地磁盘的挂载路径fsType: ext4  # 文件系统类型

解释：

local 类型的 PV 和 hostPath 类似，指定本地路径（如 /mnt/disks/mydisk）。
fsType 用于指定文件系统类型（例如 ext4、xfs 等）。
volumeMode 设置为 Filesystem，意味着文件存储。
persistentVolumeReclaimPolicy 设置为 Retain，以保留数据。

3. 创建 PVC（Persistent Volume Claim）来请求本地存储

一旦 PV 创建完毕，你可以创建一个 PVC（Persistent Volume Claim）来请求这个本地存储。PVC 是应用程序对存储资源的请求，Kubernetes 会根据 PVC 的要求选择合适的 PV。

示例：创建 PVC 来使用本地 PV

apiVersion: v1
kind: PersistentVolumeClaim
metadata:name: local-pvc
spec:accessModes:- ReadWriteOnce  # 单节点读写resources:requests:storage: 10Gi  # 请求的存储大小storageClassName: manual  # 与 PV 的 storageClassName 配置一致

解释：

accessModes 与 PV 配置一致，表示 PVC 请求的存储只能由一个节点的一个 Pod 使用。
resources.requests.storage 定义了 PVC 请求的存储大小。
storageClassName 需要与 PV 配置中的 storageClassName 保持一致。

4. 将 PVC 挂载到 Pod 中

创建 PVC 后，你可以将其挂载到 Pod 中，使用本地存储。

示例：在 Pod 中挂载 PVC

apiVersion: v1
kind: Pod
metadata:name: local-pod
spec:containers:- name: my-containerimage: nginxvolumeMounts:- mountPath: /data  # 容器中的挂载路径name: local-storagevolumes:- name: local-storagepersistentVolumeClaim:claimName: local-pvc  # 引用 PVC

解释：

volumeMounts 将 PVC 挂载到容器的 /data 路径。
volumes 使用 PVC local-pvc 作为数据卷。

使用 本地磁盘（如 hostPath 或 local 类型）创建的PV是节点特定的，这意味着它只能由存储它的节点上的 Pod 访问。简而言之，其他节点上的 Pod 无法访问该 PV，除非它们也在同一节点上运行。

POD%E9%87%8C%E9%9D%A2%EF%BC%9F">如何让客户端通过ftp上传到远端服务器的POD里面？

目标是让客户端通过FTP上传文件到一个Kubernetes Pod内，而不是直接上传到服务器上。这是可以做到的，但需要通过一些间接的方式来配置和管理。Kubernetes本身并不提供FTP服务。

以下是实现这个需求的几种方法：

1. 使用FTP服务器作为Pod的容器

你可以在Kubernetes集群中部署一个包含FTP服务的Pod。客户端通过FTP上传文件到该Pod后，文件可以直接存储在Pod的文件系统中。这样，你就实现了客户端通过FTP上传文件到Pod内的需求。

步骤：

创建一个Docker镜像，包含FTP服务（例如vsftpd或者ProFTPD）。
在Kubernetes集群中创建一个Pod来运行FTP服务。
配置该Pod的持久化存储（Persistent Volume，PV）和持久化卷声明（Persistent Volume Claim，PVC）来存储上传的文件。
配置该Pod的端口映射，使FTP服务的端口暴露出来，客户端可以通过FTP客户端连接到这个Pod。

示例：

创建一个简单的FTP容器镜像（基于vsftpd）：Dockerfile

FROM alpine:latest
RUN apk --no-cache add vsftpd
COPY vsftpd.conf /etc/vsftpd.conf
EXPOSE 21
CMD ["vsftpd", "/etc/vsftpd.conf"]

Kubernetes部署FTP Pod：

apiVersion: apps/v1
kind: Deployment
metadata:name: ftp-server
spec:replicas: 1selector:matchLabels:app: ftp-servertemplate:metadata:labels:app: ftp-serverspec:containers:- name: vsftpdimage: your-ftp-image:latestports:- containerPort: 21volumeMounts:- mountPath: /srv/ftpname: ftp-datavolumes:- name: ftp-datapersistentVolumeClaim:claimName: ftp-pvc

创建PVC来存储数据：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:name: ftp-pvc
spec:accessModes:- ReadWriteOnceresources:requests:storage: 1Gi

创建Service来暴露FTP端口：
```
apiVersion: v1
kind: Service
metadata:name: ftp-service
spec:selector:app: ftp-serverports:- protocol: TCPport: 21targetPort: 21type: LoadBalancer
```
POD%E6%83%B3%E8%AE%BF%E9%97%AEftp%E7%9A%84POD%E9%87%8C%E9%9D%A2%E7%9A%84%E6%96%87%E4%BB%B6%E6%80%8E%E4%B9%88%E5%8A%9E%EF%BC%9F">另一个POD想访问ftp的POD里面的文件怎么办？

最常见且推荐的方法是使用 Kubernetes 中的 Persistent Volume (PV) 和 Persistent Volume Claim (PVC)。通过将一个 PVC 挂载到 FTP Pod 上的目录并共享该 PVC，另一个 Pod 可以访问同一个存储资源。这样，无论哪个 Pod 上传文件，其他 Pod 都能读取。

步骤：

创建 Persistent Volume：你可以创建一个 PV，并指定存储的类型，比如使用 NFS、Ceph、或者其他共享存储系统。该 PV 会存储所有文件，并由多个 Pod 共享。
创建 Persistent Volume Claim (PVC)：每个 Pod 都需要通过 PVC 来访问这个 PV。FTP Pod 和另一个远程 Pod 都需要挂载这个 PVC。

示例配置：

Persistent Volume（PV） 配置：

apiVersion: v1
kind: PersistentVolume
metadata:name: shared-pv
spec:capacity:storage: 10GiaccessModes:- ReadWriteMany  # 多个Pod可以读写persistentVolumeReclaimPolicy: RetainstorageClassName: standardnfs:path: /mnt/data  # NFS共享路径server: <nfs-server-ip>  # NFS服务器地址

Persistent Volume Claim（PVC） 配置：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:name: shared-pvc
spec:accessModes:- ReadWriteManyresources:requests:storage: 10Gi

FTP Pod 配置：将 PVC 挂载到 FTP Pod 中：

apiVersion: apps/v1
kind: Deployment
metadata:name: ftp-server
spec:replicas: 1selector:matchLabels:app: ftp-servertemplate:metadata:labels:app: ftp-serverspec:containers:- name: vsftpdimage: your-ftp-image:latestports:- containerPort: 21volumeMounts:- mountPath: /srv/ftp  # FTP服务存储目录name: ftp-datavolumes:- name: ftp-datapersistentVolumeClaim:claimName: shared-pvc  # 挂载同一个PVC

远端 Pod 配置：另一个 Pod 可以挂载同一个 PVC，读取上传的文件

apiVersion: apps/v1
kind: Deployment
metadata:name: data-processor
spec:replicas: 1selector:matchLabels:app: data-processortemplate:metadata:labels:app: data-processorspec:containers:- name: processorimage: your-data-processor-image:latestvolumeMounts:- mountPath: /data/uploads  # 数据存储目录name: shared-datavolumes:- name: shared-datapersistentVolumeClaim:claimName: shared-pvc  # 同样挂载同一个PVC

这样，FTP Pod 会将文件存储到 /srv/ftp，而 远端 Pod 可以访问 /data/uploads 目录，读取 FTP 上传的文件。