做线上网站的目的,暴雪手游,wordpress 默认字体,aws wordpress cdnK8S#xff08;Kubernetes#xff09;的存储是容器化应用程序中非常重要的一部分#xff0c;它帮助用户在不同场景下管理和存储数据。K8S提供了多种存储方式#xff0c;以满足不同的存储需求。以下是对K8S存储的详细解析#xff1a;
一、K8S存储类型
K8S的存储类型主要分…K8SKubernetes的存储是容器化应用程序中非常重要的一部分它帮助用户在不同场景下管理和存储数据。K8S提供了多种存储方式以满足不同的存储需求。以下是对K8S存储的详细解析
一、K8S存储类型
K8S的存储类型主要分为两大类临时存储和持久存储。
临时存储
EmptyDirEmptyDir 是一种在 Pod 中创建的空目录用于在容器之间共享文件。EmptyDir 的数据存在于 Pod 所在节点的本地磁盘上当 Pod 被删除时数据也会被删除。这种存储方式适用于需要临时存储数据的场景如缓存数据。HostPathHostPath 卷将主机节点上的文件系统路径挂载到容器中。这种存储卷通常用于测试和开发环境因为它直接将宿主机的文件系统暴露给容器存在安全风险因此不建议在生产环境中使用。
持久存储
NFSNFS 卷将网络文件系统NFS挂载到容器中。这种存储卷可以跨多个 Pod 和节点共享数据适用于需要共享数据的分布式系统。PersistentVolume (PV) 和 PersistentVolumeClaim (PVC)PV 是一种由管理员配置的存储资源而 PVC 是用户请求的存储资源。PVC 允许用户抽象地请求存储资源而不需要关心具体的存储后端。PV 和 PVC 的结合使用可以动态地分配和释放存储资源提高存储的灵活性和可管理性。ConfigMap 和 SecretConfigMap 和 Secret 卷将配置文件和密钥挂载到容器中。这种存储卷可以用于配置 Pod 中的应用程序或存储敏感数据如数据库密码等。StatefulSetStatefulSet 卷是一种特殊的 PVC 卷它可以为有状态应用程序提供稳定的、持久的存储。StatefulSet 卷会为每个 Pod 分配唯一的持久卷并且可以按照顺序启动和关闭 Pod适用于需要持久化存储状态的有状态应用程序。
二、K8S存储插件
除了上述基本的存储类型外K8S还支持动态存储卷和CSIContainer Storage Interface存储插件。
动态存储卷是一种自动化管理存储资源的方法它可以根据需求动态地创建和删除存储卷。这种存储方式提高了存储资源的利用率和灵活性。CSI 存储插件是一种标准化的存储插件接口它可以与多种不同类型的存储后端集成。通过 CSI 存储插件K8S 可以支持更多的存储解决方案满足用户多样化的存储需求。
三、K8S存储应用场景
K8S的存储可以应用于多种场景包括但不限于
持久化数据如数据库、文件系统等需要持久化存储数据的场景。分布式存储如分布式数据库、分布式文件系统等需要跨多个节点共享数据的场景。日志和监控将日志和监控数据存储在持久存储卷中以便在容器被删除或重新启动后继续存在。静态资源如Web应用程序中的图像、CSS文件和JavaScript文件等静态资源。大数据分析在大数据分析中需要处理大量的数据可以使用K8S中的大数据存储来存储和管理数据。
四、总结
K8S提供了丰富的存储方式来满足不同场景下的存储需求。用户可以根据实际需求选择合适的存储类型并通过动态存储卷和CSI存储插件等高级功能来提高存储的灵活性和可管理性。同时K8S的存储也可以应用于多种场景帮助用户更好地管理和存储数据。
存储
EmptyDir
EmptyDir是一种在Pod中创建的空目录用于在容器之间共享文件。它在Pod被调度到节点上时创建并在Pod从节点上删除时被销毁。
特性
临时性EmptyDir卷的生命周期与Pod相同。当Pod被删除时EmptyDir中的数据也会被清除。共享性Pod中的所有容器都可以读写EmptyDir卷这使得它适合用作共享存储。性能由于数据存储在节点的本地存储上EmptyDir卷通常具有较高的性能。数据持久性EmptyDir卷不提供持久化存储所有数据在Pod终止时都会丢失。
应用场景
应用程序的临时工作空间EmptyDir可以作为应用程序运行时的临时文件存储区如缓存数据或临时文件。容器间共享数据在Pod内部不同的容器可能需要共享某些数据。EmptyDir卷提供了一个方便的方式来实现这一需求。检查点或恢复点对于耗时较长的计算任务EmptyDir可以用作检查点或恢复点以便在任务中断后能够恢复执行。
示例
apiVersion: v1
kind: Pod
metadata: name: pod-with-emptydir
spec: containers: - name: container1 image: nginx volumeMounts: - name: emptydir-volume mountPath: /var/www/html - name: container2 image: busybox command: [/bin/sh, -c, sleep 3600] volumeMounts: - name: emptydir-volume mountPath: /data volumes: - name: emptydir-volume emptyDir: {}注意 数据丢失风险由于EmptyDir卷不提供持久化存储因此当Pod被删除时存储在其中的数据也会丢失。对于需要持久化的数据应该使用PersistentVolumePV和PersistentVolumeClaimPVC等持久化存储解决方案。空间限制EmptyDir卷的大小可能受到节点上可用存储空间的限制。因此在配置EmptyDir卷时需要考虑节点的存储容量。节点故障如果节点发生故障并且Pod需要被重新调度到其他节点上存储在EmptyDir卷中的数据将不会保留。这是因为EmptyDir卷是绑定到特定节点的。 HostPath
HostPath卷将节点上的文件或目录挂载到Pod中使得Pod可以直接访问这些文件或目录。这种挂载方式适用于需要将Pod与宿主机上的文件系统紧密集成的场景。
特性 直接访问宿主机文件系统HostPath卷允许Pod直接访问节点上的文件系统这可以用于特定的应用场景如日志收集、数据库存储等。数据持久性与EmptyDir不同HostPath卷中的数据不会随着Pod的删除而丢失除非节点上的数据也被删除。因此它提供了一种数据持久化的方式。节点依赖性由于HostPath卷直接挂载到节点上的文件系统因此它依赖于特定的节点。如果Pod被重新调度到其他节点它将无法访问之前节点上的HostPath卷。 应用场景 日志收集将Pod中的日志文件写入到节点上的特定目录中然后通过日志收集工具如Fluentd、Logstash等进行统一收集和处理。数据库存储对于一些轻量级的数据库应用如Redis、Memcached等可以使用HostPath卷来存储数据。但需要注意的是这种方式存在数据丢失的风险如果节点故障或数据未被备份。应用依赖如果Pod中的应用需要访问节点上的特定文件或目录如配置文件、密钥文件等可以使用HostPath卷来实现。 示例
apiVersion: v1
kind: Pod
metadata: name: pod-with-hostpath
spec: containers: - name: redis image: redis:7-alpine volumeMounts: - name: redis-data mountPath: /data volumes: - name: redis-data hostPath: path: /data/redis type: DirectoryOrCreate注意 数据丢失风险由于HostPath卷直接挂载到节点上的文件系统因此当节点发生故障或数据未被备份时存储在其中的数据可能会丢失。节点依赖性如前所述HostPath卷依赖于特定的节点。如果Pod被重新调度到其他节点它将无法访问之前节点上的HostPath卷。安全性问题由于Pod可以直接访问节点上的文件系统因此可能会带来安全性问题。需要确保Pod中的容器不会恶意访问或修改节点上的敏感数据。 NFS
NFS是一种分布式文件系统协议允许系统通过网络与其他系统共享目录和文件。在K8S中NFS存储可以用于实现数据的持久化和共享解决Pod在重建或重新调度到其他节点时无法访问原有数据的问题。
创建PersistentVolumePV PV是K8S中用于描述持久化存储资源的对象。要使用NFS存储需要创建指向NFS共享目录的PV。PV的YAML配置文件示例如下
apiVersion: v1
kind: PersistentVolume
metadata: name: nfs-pv
spec: capacity: storage: 10Gi accessModes: - ReadWriteMany nfs: path: /path/to/nfs/share server: nfs-server-ip persistentVolumeReclaimPolicy: Retain在这个示例中nfs.path指定了NFS共享目录的路径nfs.server指定了NFS服务器的IP地址。accessModes定义了PV的访问模式ReadWriteMany表示多个节点可以同时读写。 2. 创建PersistentVolumeClaimPVC PVC是用户对存储资源的请求。创建PVC时需要指定所需的存储大小和访问模式以便K8S能够找到匹配的PV进行绑定。PVC的YAML配置文件示例如下
apiVersion: v1
kind: PersistentVolumeClaim
metadata: name: nfs-pvc
spec: accessModes: - ReadWriteMany resources: requests: storage: 5Gi storageClassName: # 如果使用了StorageClass则需要指定在这个示例中PVC请求了5Gi的存储空间并指定了访问模式为ReadWriteMany。 3. 在Pod中使用PVC 一旦PVC与PV成功绑定就可以在Pod的YAML配置文件中通过volumeMounts和volumes字段将PVC挂载到Pod中的容器。示例如下
apiVersion: v1
kind: Pod
metadata: name: my-pod
spec: containers: - name: my-container image: nginx volumeMounts: - name: nfs-volume mountPath: /usr/share/nginx/html volumes: - name: nfs-volume persistentVolumeClaim: claimName: nfs-pvc在这个示例中Pod中的容器将/usr/share/nginx/html目录挂载到PVC指定的NFS共享目录上。
PersistentVolume (PV)
PersistentVolumePV是一种网络存储资源它用于在集群中提供持久化存储。PV的生命周期独立于任何使用它的Pod这使得它成为存储数据的理想选择特别是当Pod被删除或重新调度时数据仍然可以保留。
PV
静态PV管理员手动创建的PV。它们存在于集群中等待被用户通过PersistentVolumeClaimPVC请求。动态PV当PVC被创建时如果集群中没有匹配的静态PV集群可以动态地创建一个新的PV来满足PVC的需求。这通常通过StorageClass来实现。
YAML配置 PV的YAML配置文件包含了关于存储资源的详细信息如容量、访问模式、存储类型等。以下是一个简单的PV配置示例
apiVersion: v1
kind: PersistentVolume
metadata: name: example-pv
spec: capacity: storage: 10Gi volumeMode: Filesystem # 或者 Block accessModes: - ReadWriteOnce # - ReadOnlyMany # - ReadWriteMany persistentVolumeReclaimPolicy: Retain storageClassName: slow nfs: path: /exports server: nfs.example.com在这个示例中
capacity 指定了PV的存储容量。volumeMode 定义了卷的类型可以是文件系统Filesystem或块设备Block。accessModes 定义了PV的访问模式。常见的访问模式包括 ReadWriteOnce单个节点以读写模式挂载。ReadOnlyMany多个节点以只读模式挂载。ReadWriteMany多个节点以读写模式挂载注意并非所有类型的存储都支持此模式。 persistentVolumeReclaimPolicy 定义了当PV不再被任何PVC绑定时其回收策略。常见的策略包括 Retain保留数据需要手动清理。Recycle已弃用清除数据但并非所有类型的存储都支持此操作。Delete删除存储资源这通常用于动态PV。 storageClassName 指定了PV所属的StorageClass可选。nfs 是一个特定的存储类型配置表示这是一个NFS卷并指定了NFS服务器的地址和共享路径。 注意 在使用PV时需要确保集群中的节点能够访问指定的存储资源例如NFS服务器必须可从所有节点访问。不同的存储类型如NFS、GlusterFS、AWS EBS等可能有不同的配置要求和限制。管理员需要仔细规划PV的容量和回收策略以避免资源浪费和数据丢失。动态PV的创建依赖于StorageClass和相应的存储提供者如云提供商的存储服务。 PersistentVolumeClaim (PVC)
PersistentVolumeClaim (PVC) 是一种存储请求机制允许用户声明对存储资源的需求而无需关心具体的存储后端实现细节。
PVC
定义PersistentVolumeClaimPVC是用户对存储资源的请求。它与Pod类似Pod消耗节点资源而PVC消耗PersistentVolumePV资源。PVC能够请求特定大小和访问模式的存储资源。作用PVC提供了一种抽象层使得用户能够专注于其应用程序的需求而无需关心存储系统的具体配置和管理。
PVC与PV的关系
绑定机制PVC通过标签选择器label selector或存储类StorageClass与PV进行绑定。当PVC被创建时Kubernetes会尝试找到一个与PVC请求相匹配的PV并将其绑定到PVC上。一对一映射PVC与PV之间的绑定是一对一的即一个PVC只能绑定到一个PV上反之亦然。访问模式PVC可以指定所需的访问模式如ReadWriteOnceRWO、ReadWriteManyRWM或ReadOnlyManyROM。这些访问模式决定了PV如何被挂载和使用。
创建与使用
创建PVC用户通过YAML文件或Kubernetes API创建一个PVC对象指定所需的存储大小、访问模式和其他相关参数。自动绑定当PVC被创建后Kubernetes会自动查找可用的PV并根据PVC的请求参数进行匹配和绑定。Pod中使用PVC一旦PVC与PV绑定成功用户就可以在Pod的volume配置中引用PVC从而使用PVC所代表的存储资源。
回收策略
回收策略当PVC被删除时其绑定的PV会根据PVC的回收策略进行处理。常见的回收策略包括Retain保留、Recycle回收和Delete删除。 Retain保留PV和底层存储资源但PVC的数据仍然保留在PV中需要手动清理。Recycle删除PV中的数据但不删除底层存储资源。需要注意的是Recycle策略在Kubernetes的后续版本中可能被移除。Delete删除PV和底层存储资源同时删除PV中的数据。
优势
提高存储资源的利用率通过PVC用户可以根据实际需求动态申请存储资源避免了存储资源的浪费。简化存储管理PVC提供了一种抽象层使得用户无需关心存储系统的具体配置和管理从而简化了存储管理的复杂性。增强应用程序的可移植性PVC允许用户在不修改应用程序代码的情况下将应用程序部署到不同的Kubernetes集群中并自动适应不同的存储环境。
样例
apiVersion: v1
kind: PersistentVolumeClaim
metadata: name: my-pvc namespace: default # 命名空间这里使用默认命名空间
spec: accessModes: - ReadWriteOnce # 访问模式这里指定为ReadWriteOnce即卷可以被一个节点以读写方式挂载 resources: requests: storage: 1Gi # 请求的存储大小为1GiB storageClassName: manual # 存储类名称这里假设使用名为manual的存储类或者如果不指定storageClassName则使用默认存储类 volumeMode: Filesystem # 卷模式这里指定为文件系统模式说明:
apiVersion: 指定Kubernetes API的版本这里为v1。kind: 指定资源类型为PersistentVolumeClaim。metadata: 包含PVC的元数据如名称和命名空间。 name: PVC的名称这里为my-pvc。namespace: PVC所属的命名空间这里使用默认命名空间default。 spec: 包含PVC的规格说明。 accessModes: 指定PV的访问模式这里为ReadWriteOnce表示卷可以被一个节点以读写方式挂载。其他访问模式包括ReadOnlyMany多个节点只读和ReadWriteMany多个节点读写。resources: 指定PVC所需的资源这里仅指定了存储资源。requests: 指定PVC请求的存储大小这里为1Gi。storageClassName: 指定PVC使用的存储类名称。存储类用于动态创建PV。如果不指定将使用默认存储类如果存在。volumeMode: 指定卷的模式这里为Filesystem表示文件系统卷。其他模式可能包括Block块设备卷。 注意 PVC的创建依赖于PV或存储类的存在。如果指定了storageClassNameKubernetes将尝试使用相应的存储类动态创建PV。如果没有指定或存储类无法创建PVPVC将处于Pending状态直到找到匹配的PV。PVC与PV之间的绑定是自动完成的但前提是PVC的请求参数如存储大小、访问模式与某个PV的规格相匹配。PVC的生命周期与Pod不同步。即使Pod被删除PVC和绑定的PV仍然存在除非显式删除PVC。 ConfigMap
ConfigMap是一种用于存储配置数据的API对象它属于Kubernetes中的核心对象之一。ConfigMap的主要作用是将应用程序的配置信息与容器镜像分离以便在不重新构建镜像的情况下进行配置的修改和更新。
定义与特点
定义ConfigMap用于存储键值对、文本文件或以特定格式组织的配置文件如环境变量、命令行参数等。特点 解耦将配置数据与应用程序分离提高应用的可移植性和可维护性。灵活性支持多种数据格式包括键值对、文本文件等。集中管理提供一个集中管理和传递配置信息的机制便于统一管理配置数据。
用途
环境变量ConfigMap可以作为环境变量注入到Pod中的容器中供应用程序使用。配置文件ConfigMap还可以将文件直接挂载到Pod的容器内部使应用程序可以直接读取这些配置文件。
示例
创建ConfigMap 假设有一个名为my-config的ConfigMap里面包含了一些键值对数据YAML文件定义如下
apiVersion: v1
kind: ConfigMap
metadata: name: my-config
data: config.properties: | key1value1 key2value2将ConfigMap挂载为文件 在Pod的YAML文件中可以将上面创建的ConfigMap挂载为文件。示例如下
apiVersion: v1
kind: Pod
metadata: name: my-pod
spec: containers: - name: my-container image: nginx volumeMounts: - name: config-volume mountPath: /etc/config volumes: - name: config-volume configMap: name: my-config将ConfigMap作为环境变量 同样也可以在Pod的YAML文件中将ConfigMap中的数据作为环境变量注入到容器中。示例如下
apiVersion: v1
kind: Pod
metadata: name: my-pod-with-env
spec: containers: - name: my-container image: nginx env: - name: SOME_KEY valueFrom: configMapKeyRef: name: my-config key: key1Secret
Secret是一种用于存储敏感信息的对象如密码、OAuth令牌、ssh密钥等。这些敏感信息通常以Base64编码的形式存储在Secret对象中以避免在Kubernetes中明文传输从而提高安全性。
定义与特点
**定义**Secret用于存储和管理敏感数据如密码、OAuth令牌和ssh密钥等。特点 所有数据都要经过Base64编码。默认情况下Kubernetes Secret未加密地存储在API服务器的底层数据存储etcd中。拥有API访问权限的人可以检索或修改Secret因此需要通过其他方式如静态加密、RBAC规则等来增强安全性。
类型 Kubernetes提供了多种类型的Secret每种类型都适用于不同的场景
Opaque用于存储任意类型的数据最常见的是用于存储密码、密钥等。它不对数据内容进行解释或编码只要求value是Base64编码的字符串。kubernetes.io/service-account-token由Kubernetes自动创建用于向Pod中的Service Account提供API访问令牌。kubernetes.io/dockerconfigjson用于存储私有Docker Registry的认证信息。TLS用于存储TLS证书和私钥用于加密Pod之间的通信
使用方式 Pod可以通过以下方式使用Secret作为挂载到一个或多个容器中的存储卷中的文件
将Secret挂载为Pod中的Volume容器可以通过文件路径访问Secret中的数据。
作为容器的环境变量
将Secret中的数据设置为Pod中容器的环境变量容器可以通过环境变量读取Secret中的数据。
由kubelet在拉取容器镜像时使用
对于存储在私有Docker Registry中的镜像kubelet在拉取时需要认证信息。可以通过创建kubernetes.io/dockerconfigjson类型的Secret并在Pod的imagePullSecrets字段中引用该Secret以实现镜像的拉取。
安全性 由于Secret默认未加密地存储在etcd中因此需要通过以下方式来提高其安全性
启用静态加密通过加密插件对etcd中的Secret进行加密存储。以最小特权访问Secret通过RBAC基于角色的访问控制规则限制对Secret的访问权限。限制Secret对特定容器的访问确保只有需要访问Secret的容器才能访问到它。考虑使用外部Secret存储驱动将Secret存储在外部安全存储中以增强安全性。
样例
创建Secret Base64编码
echo -n admin | base64 # 输出: YWRtaW4
echo -n password123 | base64 # 输出: cGFzc3dvcmQxMjM- YAML文件来定义apiVersion: v1
kind: Secret
metadata: name: my-secret
type: Opaque
data: username: YWRtaW4 password: cGFzc3dvcmQxMjM- 执行kubectl apply -f my-secret.yaml使用Secret 作为挂载的Volume 可以将Secret挂载为Pod中的一个Volume容器可以通过文件路径访问Secret中的数据。以下是一个Pod的YAML文件示例展示了如何将my-secret挂载为Volume
apiVersion: v1
kind: Pod
metadata: name: my-pod
spec: containers: - name: my-container image: nginx volumeMounts: - name: secret-volume mountPath: /etc/secret-data readOnly: true volumes: - name: secret-volume secret: secretName: my-secret在这个例子中my-secret被挂载到Pod的/etc/secret-data目录下容器中的进程可以通过读取该目录下的文件来访问Secret中的数据。 2. 作为环境变量 将Secret中的数据设置为Pod中容器的环境变量。以下是一个Pod的YAML文件示例展示了如何设置环境变量
apiVersion: v1
kind: Pod
metadata: name: my-pod-with-env
spec: containers: - name: my-container image: nginx env: - name: MY_USERNAME valueFrom: secretKeyRef: name: my-secret key: username - name: MY_PASSWORD valueFrom: secretKeyRef: name: my-secret key: password在这个例子中my-secret中的username和password分别被设置为Pod中容器的环境变量MY_USERNAME和MY_PASSWORD。容器中的进程可以通过读取这些环境变量来访问Secret中的数据。
StatefulSet
StatefulSet是一种用于管理有状态应用的资源对象。与Deployment和ReplicaSet等无状态服务的管理方式不同StatefulSet提供了对Pod集合的有序部署、扩缩、更新和删除以及持久化存储的支持。 一. 概念 StatefulSet是Kubernetes中的一个核心概念用于管理有状态应用的Pod部署和伸缩。它主要用于部署需要持久化存储和唯一标识的应用如数据库、消息队列等。StatefulSet为每个Pod实例分配一个唯一的标识符并根据这个标识符进行有序的创建、更新和删除操作。 二. 特点
稳定的网络标识符StatefulSet中的每个Pod都有一个稳定的网络标识符如DNS名称这使得它们可以方便地被其他应用或服务引用。有序部署和扩展StatefulSet保证Pod的部署和扩展是按照确定的顺序进行的这对于需要按顺序启动和停止的应用程序非常重要。持久化存储StatefulSet支持使用持久化卷PersistentVolume来存储Pod的状态数据确保即使Pod被重新调度到其他节点其状态数据也不会丢失。自主管理的标识符StatefulSet可以为每个Pod分配一个自主管理的标识符这些标识符在Pod重新启动或重新调度后保持不变。 三. 组成 三个部分组成
Headless Service无头服务用于为StatefulSet中的Pod提供DNS解析。Headless Service没有Cluster IP它通过DNS记录为每个Pod提供一个可解析的域名。StatefulSet ControllerStatefulSet控制器负责根据StatefulSet的定义来管理Pod的创建、更新、删除等操作。VolumeClaimTemplate卷申请模板用于为StatefulSet中的每个Pod生成独立的持久化存储卷PersistentVolumeClaim。 四、示例 以下是一个使用StatefulSet来部署MySQL数据库的示例包括存储的配置
apiVersion: apps/v1
kind: StatefulSet
metadata: name: mysql-statefulset
spec: serviceName: mysql replicas: 3 selector: matchLabels: app: mysql template: metadata: labels: app: mysql spec: containers: - name: mysql-container image: mysql:latest ports: - containerPort: 3306 env: - name: MYSQL_ROOT_PASSWORD value: password volumeMounts: - name: mysql-storage mountPath: /var/lib/mysql volumeClaimTemplates: - metadata: name: mysql-storage spec: accessModes: [ReadWriteOnce] storageClassName: standard resources: requests: storage: 1Gi在这个示例中volumeClaimTemplates部分定义了每个Pod的持久化存储卷。当StatefulSet创建Pod时它会为每个Pod生成一个独立的PersistentVolumeClaimPVC并请求绑定到一个PersistentVolumePV。这样每个Pod都有自己的专用存储卷用于存储MySQL数据库的数据。
