kubernetes pv pvc configmap secret 使用

pv pvc使用

1、概述，我们可以这样来组织我们的存储，在pod中我们只需要定义一个存储卷并且定义的时候我只需要说明我需要多大的存储卷就行了，这个存储卷叫pvc类型的存储卷，而pvc类型的存储卷必须与当前名称空间中的pvc建立直接绑定关系，而pvc必须与pv建立绑定关系，而pv应该是真正某个存储设备上的存储空间，所以pv和pvc是k8s系统之上的抽象的但也算是标准的资源，pvc是一种资源，pv也是一种资源，他的创建方式和我们此前创建其它资源方式是一样的，但是用户需要怎么做呢？存储工程师把每个存储空间先划割好，k8s管理员需要把每一个存储空间映射到系统上做成pv，用户就自己定义pod，在pod中定义使用pvc就可以了，但是pvc也需要创建，也需要我们k8s工程师把pvc也做好，但是pv和pvc之间，在pvc不被调用时是空载没有用的，当有pod调用pvc的时候他需要与某个pv绑定起来，相当于这个pvc上的数据是放在哪个pv上的，pvc要绑定哪个pv取决于pod创建者用户在创建中定义我要请求使用多大的存储空间。比如我要使用一个5G的，于是在当前系统上我们要找一个pvc与容纳5G的pv建立绑定关系，2G的就不符合条件。并且我们还可以指明说我创建使用这个pv必须只能有一个人挂载和读写使用。

KIND:     Pod
VERSION:  v1

RESOURCE: persistentVolumeClaim <Object>

DESCRIPTION:
     PersistentVolumeClaimVolumeSource represents a reference to a
     PersistentVolumeClaim in the same namespace. More info:
     https://kubernetes.io/docs/concepts/storage/persistent-volumes#persistentvolumeclaims

     PersistentVolumeClaimVolumeSource references the user‘s PVC in the same
     namespace. This volume finds the bound PV and mounts that volume for the
     pod. A PersistentVolumeClaimVolumeSource is, essentially, a wrapper around
     another type of volume that is owned by someone else (the system).

FIELDS:
   claimName    <string> -required- #需要使用的pvc名称
     ClaimName is the name of a PersistentVolumeClaim in the same namespace as
     the pod using this volume. More info:
     https://kubernetes.io/docs/concepts/storage/persistent-volumes#persistentvolumeclaims

   readOnly    <boolean> #当前名称空间中已经有一个用户做好pvc了
     Will force the ReadOnly setting in VolumeMounts. Default false.

kubectl explain pods.spec.volumes.persistentVolumeClaim

KIND:     PersistentVolumeClaim
VERSION:  v1

RESOURCE: spec <Object>

DESCRIPTION:
     Spec defines the desired characteristics of a volume requested by a pod
     author. More info:
     https://kubernetes.io/docs/concepts/storage/persistent-volumes#persistentvolumeclaims

     PersistentVolumeClaimSpec describes the common attributes of storage
     devices and allows a Source for provider-specific attributes

FIELDS:
   accessModes    <[]string> #访问模型，
     AccessModes contains the desired access modes the volume should have. More
     info:
     https://kubernetes.io/docs/concepts/storage/persistent-volumes#access-modes-1

   resources    <Object> #资源限制，至少多少，如果设置为10G的那么至少需要10G的pv
     Resources represents the minimum resources the volume should have. More
     info:
     https://kubernetes.io/docs/concepts/storage/persistent-volumes#resources

   selector    <Object> #标签选择器，表示可以必须选择哪个pv建立关联关系，不加标签就在所有里面找最佳匹配
     A label query over volumes to consider for binding.

   storageClassName    <string> #存储类名称
     Name of the StorageClass required by the claim. More info:
     https://kubernetes.io/docs/concepts/storage/persistent-volumes#class-1

   volumeMode    <string> #后端存储卷模式
     volumeMode defines what type of volume is required by the claim. Value of
     Filesystem is implied when not included in claim spec. This is an alpha
     feature and may change in the future.

   volumeName    <string> #卷名称，后端pv的名称，精确选择时候匹配
     VolumeName is the binding reference to the PersistentVolume backing this
     claim.

kubectl explain pvc.spec

创建完pvc后就会找系统上合适的pv绑定，如果有就绑定，如果没有就pvc pending（挂起），表示没有合适的pv被这个pvc所claim，pvc此时被阻塞，直到有合适的pv被此pvc所调用为止。

　　　　首先我们系统上应该是要有存储设备，存储管理员在上面划割好了很多很多可被独立使用的存储空间，然后我们的集群管理工程师把这每一个空间都引入到集群中把它定义成pv，因为我们集群管理员或存储工程师才更了解这些存储设备的参数，他们必须要了解存储设备怎么被创建，并且知道这些参数怎么被调用，随后我们的k8s使用者创建pod时要先创建一个pvc，意思是说我们要在当前的k8s集群中找一个符合我们条件的存储空间来用，于是就定义pvc的使用标准，而后我们系统就在里面找哪个最合适，然后申请。pv和pvc是一一对应关系，也就是说如果某个pv被某个pvc占用了意味着他就不能再被其它pvc所占用了，如果pvc被占用了会显示这个状态叫binding，意思说被绑定在使用了，就不可能再被其它pv所占用了，但是一个pvc创建以后这个pvc就相当于是一个存储卷了，这个存储卷可以被多个pod所访问，假如多个pod挂载同一个存储卷就叫多路访问，因此我们创建pvc时最好确保下面有pv存在，如果不存在那么就绑定不了。

创建PV和PVC(以NFS为例)

NFS server上创建多个挂载目录，并共享

mkdir -p /data/volumes/v{1..5} && ls /data/volumes/

创建 nfs 挂载目录

vi /etc/exports

编辑内容如下　　

/data/volumes/v1 192.168.228.0/24(rw,no_root_squash)
/data/volumes/v2 192.168.228.0/24(rw,no_root_squash)
/data/volumes/v3 192.168.228.0/24(rw,no_root_squash)
/data/volumes/v4 192.168.228.0/24(rw,no_root_squash)
/data/volumes/v5 192.168.228.0/24(rw,no_root_squash)

　

重新加载 nfs 挂载配置　

exportfs -arv

查看 nfs 挂载的目录

showmount -e


apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv001
  labels:
    name: pv001
spec:
  nfs:
    path: /data/volumes/v1
    server: 192.168.228.138
  accessModes: ["ReadWriteMany","ReadWriteOnce"] #多路读写，多路只读和单路读写
  capacity:
    storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv002
  labels:
    name: pv002
spec:
  nfs:
    path: /data/volumes/v2
    server: 192.168.228.138
  accessModes: ["ReadWriteOnce"] #多路读写，多路只读和单路读写
  capacity:
    storage: 5Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv003
  labels:
    name: pv003
spec:
  nfs:
    path: /data/volumes/v3
    server: 192.168.228.138
  accessModes: ["ReadWriteMany","ReadWriteOnce"] #多路读写，多路只读和单路读写
  capacity:
    storage: 20Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv004
  labels:
    name: pv004
spec:
  nfs:
    path: /data/volumes/v4
    server: 192.168.228.138
  accessModes: ["ReadWriteMany","ReadWriteOnce"] #多路读写，多路只读和单路读写
  capacity:
    storage: 10Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv005
  labels:
    name: pv005
spec:
  nfs:
    path: /data/volumes/v5
    server: 192.168.228.138
  accessModes: ["ReadWriteMany","ReadWriteOnce"] #多路读写，多路只读和单路读写
  capacity:
    storage: 10Gi
---

pv-demo.yaml

创建 pv

处于绑定状态下的pv无法直接被删除，如果需要删除被绑定的pv，需要先删除申请绑定的PVC

RECLAIM POLICY  回收策略是指，如果某个pvc绑定这个pv，在里面存数据了，但是后面这个pvc又释放了，我把pvc删了这个绑定就不存在了，一旦绑定不存在时里面存在数据的pv怎么办呢？ Retain表示保留着，recover表示回收，表示把里面数据全删了，把pv置于空闲状态让其它pvc绑。还有一种叫delete，用完直接删除。一般来讲我们默认使用Retain。

定义pvc

VERSION:  v1

RESOURCE: spec <Object>

DESCRIPTION:
     Spec defines the desired characteristics of a volume requested by a pod
     author. More info:
     https://kubernetes.io/docs/concepts/storage/persistent-volumes#persistentvolumeclaims

     PersistentVolumeClaimSpec describes the common attributes of storage
     devices and allows a Source for provider-specific attributes

FIELDS:
   accessModes    <[]string> #他要求的访问模式一定是现存的某个pv的子集
     AccessModes contains the desired access modes the volume should have. More
     info:
     https://kubernetes.io/docs/concepts/storage/persistent-volumes#access-modes-1

   resources    <map> #资源要求，一旦给了以后pv一定要大于等于这个值才能被使用
     Resources represents the minimum resources the volume should have. More
     info:
     https://kubernetes.io/docs/concepts/storage/persistent-volumes#resources

   selector    <Object>
     A label query over volumes to consider for binding.

   storageClassName    <string>
     Name of the StorageClass required by the claim. More info:
     https://kubernetes.io/docs/concepts/storage/persistent-volumes#class-1

   volumeMode    <string>
     volumeMode defines what type of volume is required by the claim. Value of
     Filesystem is implied when not included in claim spec. This is an alpha
     feature and may change in the future.

   volumeName    <string>
     VolumeName is the binding reference to the PersistentVolume backing this
     claim.

kubectl explain pvc.spec

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mypvc
  namespace: default
spec:
  accessModes: ["ReadWriteMany"]
  resources:
    requests:
      storage: 1Gi
---
apiVersion: v1
kind: Pod
metadata:
  name: pod-vol-pvc
  namespace: default
spec:
  containers:
  - name: myapp
    image: ikubernetes/myapp:v1
    volumeMounts:
    - name: html
      mountPath: /usr/share/nginx/html/
  volumes:
  - name: html
    persistentVolumeClaim: #使用pvc
      claimName: mypvc #pvc名字

pod-vol-pvc.yaml

创建pvc 并声明 pod 使用

访问pod

　　

原文地址：https://www.cnblogs.com/crazymagic/p/11333400.html

时间： 2024-10-08 22:30:51

kubernetes pv pvc configmap secret 使用的相关文章

Kubernetes Pv &amp; Pvc

Kubernetes PV & pvc 介绍 PersistentVolume(pv)和PersistentVolumeClaim(pvc)是k8s提供的两种API资源,用于抽象存储细节.管理员关注于如何通过pv提供存储功能而无需 关注用户如何使用,同样的用户只需要挂载pvc到容器中而不需要关注存储卷采用何种技术实现. pvc和pv的关系与pod和node关系类似,前者消耗后者的资源.pvc可以向pv申请指定大小的存储资源并设置访问模式,这就可以通过Provision -> Claim 的方

Kubernetes PV在Retain策略Released状态下重新分配到PVC恢复数据

Kubernetes PV在Retain策略Released状态下重新分配到PVC恢复数据 [TOC] 1. 实验目的和环境说明 原由:在使用helm update stable/sonatype-nexus从1.6版本更新到1.13版本后,出现PVC删除,重新创建PVC的情况,好在原来PV为Retain.故研究下Retain的PV怎么恢复数据. 实验目的:PVC删除后,PV因Retain策略,状态为Released,将PV内数据恢复成PVC,挂载到POD内,达到数据恢复. 环境说明: Kube

Kubernetes 存储卷管理 PV&amp;PVC(十)

为了持久化保存容器的数据,可以使用 Kubernetes Volume. Volume 的生命周期独立于容器,Pod 中的容器可能被销毁和重建,但 Volume 会被保留. 本质上,Kubernetes Volume 是一个目录,这一点与 Docker Volume 类似.当 Volume 被 mount 到 Pod,Pod 中的所有容器都可以访问这个 Volume.Kubernetes Volume 也支持多种 backend 类型,包括 emptyDir.hostPath.GCE Persi

Serverless Kubernetes全面升级2.0架构：支持多命名空间、RBAC、CRD、PV/PVC等功能

Serverless Kubernetes概述: 阿里云Serverless Kubernetes容器服务最新开放香港.新加坡.悉尼区域,同时全面开放2.0架构,帮助用户更加便捷.轻松地步入“以应用为中心”的全新架构.通过Serverless Kubernetes,用户50秒内可从零启动500应用容器,而无需关心底层服务器资源. Serverless Kubernetes 2.0新架构 Serverless Kubernetes 2.0对后台架构进行了彻底升级,从之前的基于Namespace的多

kubernetes 的pv/pvc存储

kubernetes 的pv/pvc存储 标签(空格分隔): kubernetes系列 一: kubernetes的PV/PVC存储 一: kubernetes的PV/PVC存储 1.1 pv PersistentVolume (PV) 是由管理员设置的存储,它是群集的一部分.就像节点是集群中的资源一样,PV 也是集群中的资源. PV 是 Volume 之类的卷插件,但具有独立于使用 PV 的 Pod 的生命周期.此 API 对象包含存储实现的细节,即 NFS. iSCSI 或特定于云供应商的存

kubernetes之使用ConfigMap管理Pod配置文件

简介 ConfigMaps可以使容器镜像与配置文件解耦,实现容器化应用程序的可移植性.此文提供一系列的方法示例讲述如何创建ConfigMaps,使用存储在ConfigMaps中的数据配置Pod. 备注:此文档参考官方文档,并加以自己的理解.如有误导性的内容,请批评指正. 创建一个ConfigMap 我们可以使用kubectl create configmap或kustomization.yaml中的ConfigMap生成器创建一个ConfigMap.从Kubernetes 1.14版本开始,ku

Kubernetes Harbor等资源--secret和ServiceAccount配置

Kubernetes Harbor等资源--secret和ServiceAccount配置 ![]来啦,老弟########## 用途 secret对象类型主要目的是保存和处理敏感信息/私密数据.将这些信息放在secret对象中比 直接放在pod或docker image中更安全,也更方便使用.在一个已经创建好的secrets对象有两种方式被pod对象使用,其一,在container中的volume对象里以file的形式被使用,其二,在pull images时被kubelet使用. ######

Kubernetes数据持久化之Secret与ConfigMap

ConfigMap和Secret是Kubernetes中两种特殊类型的存储卷,ConfigMap这种资源对象主要用于提供配置数据以定制程序行为,不过一些敏感的配置信息,比如像用户名.密码.密钥等通常都是由Secret这种资源对象来进行配置的,他们将相应的配置信息保存于对象中,而后在Pod资源上以存储卷的形式将其挂载并获取相应配置,以实现配置与镜像文件的解耦. 一.Secret资源对象 1) Secret概述 Secret资源对象存储数据的方式是以键值对的方式进行存储的,在Pod资源进行Secre

kubernetes(五)--存储之configmap/secret/volume/Persistent Volume

一.configmap 1.1.configmap简介 ConfigMap 功能在 Kubernetes1.2 版本中引入,许多应用程序会从配置文件.命令行参数或环境变量中读取配置信息.ConfigMap API 给我们提供了向容器中注入配置信息的机制,ConfigMap 可以被用来保存单个属性,也可以用来保存整个配置文件或者 JSON 二进制对象 1.2.ConfigMap 的创建 1.2.1.使用目录创建 [[email protected] dir]# ls game.propertie