标签：ota 也有 删除 get 一起 bubuko 管理 应用 rda
容器磁盘上的文件的生命周期是短暂的，这就使得在容器中运行重要应用时会出现一些问题。首先，当容器崩溃时，kubelet 会重启它，但是容器中的文件将丢失——容器以干净的状态（镜像最初的状态）重新启动。其次，在 Pod 中同时运行多个容器时，这些容器之间通常需要共享文件。Kubernetes 中的 Volume 抽象就很好的解决了这些问题。在原docker环境中也有存储卷的概念，但docker环境的存储卷调度在宿主机上的目录，当docker重新创建的时候存储卷还会挂载统一宿主机上，但我们知道Kubernetes是分布式集群，当我们销毁一个pod的时候，可能pod会在其他节点上启动，但其他节点宿主机上并没有这个目录，这样就不会挂载到原来的数据了。为此Kubernetes不同类型的持久卷。
我们可以通过kubectl explain pods.spec.volumes来查看支持的存储卷：
hostPath 主机目录emptyDir 空目录（pod销毁也随之销毁）
rbd 分布式存储之ceph块存储
local 卷表示挂载的本地存储设备，如磁盘、分区或目录
cephfs 分布式存储之cephfs
awsElasticBlockStore aws云存储
azureDisk azure云存储
azureFile azure云存储
glusterfs 分布式存储之glusterfs
fc 卷挂载到 pod 中。您可以使用卷配置中的 targetWWN 参数指定单个或多个目标全球通用名称（World Wide Name）。如果指定了多个 WWN，则 targetWWN 期望这些 WWN 来自多路径连接。iscsi 卷允许将现有的 iSCSI卷挂载到容器中。不像 emptyDir，删除 Pod 时 iscsi 卷的内容将被保留，卷仅仅是被卸载。这意味着 iscsi 卷可以预先填充数据，并且这些数据可以在 pod 之间“切换”。kubectl explain pod.spec.volumes.emptyDir 指定emptyDir存储卷
kubectl explain pod.spec.containers.volumeMounts 指定挂载哪些存储卷
下面实例为 一个pod中的两个容器共享同一个存储
apiVersion: v1 kind: Pod metadata: name: my-demo namespace: default labels: name: myapp tier: appfront spec: containers: - name: myapp image: ikubernetes/myapp:v1 ports: - name: http containerPort: 80 volumeMounts: - name: appindex mountPath: /usr/share/nginx/html/ - name: busybox image: busybox imagePullPolicy: IfNotPresent volumeMounts: - name: appindex mountPath: /data/ command: - "/bin/sh" - "-c" - "while true; do echo $(date) >> /data/index.html; sleep 2; done" volumes: - name: appindex emptyDir: {}
curl 10.244.3.14 Mon Sep 17 06:03:53 UTC 2018 Mon Sep 17 06:03:55 UTC 2018 Mon Sep 17 06:03:57 UTC 2018 Mon Sep 17 06:03:59 UTC 2018 Mon Sep 17 06:04:01 UTC 2018 Mon Sep 17 06:04:03 UTC 2018
kubectl explain pod.spec.volumes.hostPath
目录自动创建
apiVersion: v1 kind: Pod metadata: name: my-demo namespace: default labels: name: myapp tier: appfront spec: containers: - name: myapp image: ikubernetes/myapp:v1 ports: - name: http containerPort: 80 volumeMounts: - name: appindex mountPath: /usr/share/nginx/html/ volumes: - name: appindex hostPath: path: /data/pod/myapp type: DirectoryOrCreate
kubectl explain pod.spec.volumes.nfs
apiVersion: v1 kind: Pod metadata: name: my-demo-nfs namespace: default labels: name: myapp tier: appfront spec: containers: - name: myapp image: ikubernetes/myapp:v1 ports: - name: http containerPort: 80 volumeMounts: - name: appindex mountPath: /usr/share/nginx/html/ volumes: - name: appindex nfs: server: 172.16.132.241 path: /data
手动在/data目录下增加一个index.html
验证
kubectl get pods -o wide NAME READY STATUS RESTARTS AGE IP NODE my-demo 1/1 Running 0 3h 10.244.2.4 k8s-node02 my-demo-nfs 1/1 Running 0 2m 10.244.3.15 k8s-node03 $ curl 10.244.3.15 nfs
我们前面提到kubernetes提供那么多储存接口，但是首先kubernetes的各个Node节点能管理这些存储，但是各种存储参数也需要专业的存储工程师才能了解，由此我们的kubernetes管理变的更加复杂的。由此kubernetes提出了PV和PVC的概念，这样开发人员和使用者就不需要关注后端存储是什么，使用什么参数等问题。如下图：
当我们pod中定义volume的时候，我们只需要使用pvs存储卷就可以，pvc必须与对应的pv建立关系，pvc会根据定义去pv申请，而pv是由存储空间创建出来的。pv和pvc是kubernetes抽象出来的一种存储资源。
PersistentVolume 是由管理员设置的存储，它是群集的一部分。就像节点是集群中的资源一样，PV 也是集群中的资源。 PV 是 Volume 之类的卷插件，但具有独立于使用 PV 的 Pod 的生命周期。此 API 对象包含存储实现的细节，即 NFS、iSCSI 或特定于云供应商的存储系统。可根据上图看清他们之间的关系
PV有两种配置方式：动态和静态
静态：
集群管理员创建一些 PV。它们带有可供群集用户使用的实际存储的细节。
动态：
当管理员创建的静态 PV 都不匹配用户的 PersistentVolumeClaim 时，集群可能会尝试动态地为 PVC 创建卷。此配置基于 StorageClasses：PVC 必须请求存储类，并且管理员必须创建并配置该类才能进行动态创建。声明该类为 "" 可以有效地禁用其动态配置。
要启用基于存储级别的动态存储配置，集群管理员需要启用 API server 上的 DefaultStorageClass 准入控制器。例如，通过确保 DefaultStorageClass 位于 API server 组件的 --admission-control 标志，使用逗号分隔的有序值列表中，可以完成此操作。
kubectl explain pv.spec
定义一个nfs格式的pv
apiVersion: v1 kind: PersistentVolume metadata: name: pv01 labels: name: pv01 spec: nfs: path: /data/pv/01 server: 172.16.132.241 accessModes: ["ReadWriteMany","ReadWriteOnce"] capacity: storage: 2Gi --- apiVersion: v1 kind: PersistentVolume metadata: name: pv02 labels: name: pv02 spec: nfs: path: /data/pv/02 server: 172.16.132.241 accessModes: ["ReadOnlyMany","ReadWriteOnce"] capacity: storage: 5Gi
查看详细
kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pv01 2Gi RWO,RWX Retain Available 1m
pv02 5Gi RWO,ROX Retain Available 1m
当pod结束 volume 后可以回收资源对象删除PVC，而绑定关系就不存在了，当绑定关系不存在后这个PV需要怎么处理，而PersistentVolume 的回收策略告诉集群在存储卷声明释放后应如何处理该卷。目前，volume 的处理策略有保留、回收或删除。
此策略允许手动回收资源，当pvc被删除后，pv依然存在，volume 被视为“已释放”。但是由于前一个声明人的数据仍然存在，所以还不能马上进行其他声明。管理员可以通过以下步骤手动回收卷。
PV。在删除 PV 后，外部基础架构中的关联存储空间（如 AWS EBS、GCE PD、Azure Disk 或 Cinder 卷）仍然存在。PersistentVolume。在 volume上执行情况数据（rm -rf /thevolume/*），可以再次被其他pvc调度
对于支持删除回收策略的卷插件，删除操作将从 Kubernetes 中删除 PV 对象，并删除外部基础架构（如 AWS EBS、GCE PD、Azure Disk 或 Cinder 卷）中的关联存储空间。动态配置的卷继承其 StorageClass 的回收策略，默认为 Delete。管理员应该根据用户的期望来配置 StorageClass，否则就必须要在 PV 创建后进行编辑或修补。
PersistentVolumeClaim 是用户存储的请求。它与 Pod 相似。Pod 消耗节点资源，PVC 消耗 PV 资源。Pod 可以请求特定级别的资源（CPU 和内存）。声明可以请求特定的大小和访问模式（例如，可以以读/写一次或 只读多次模式挂载）。
虽然 PersistentVolumeClaims 允许用户使用抽象存储资源，但用户需要具有不同性质（例如性能）的 PersistentVolume 来解决不同的问题。集群管理员需要能够提供各种各样的 PersistentVolume，这些PersistentVolume 的大小和访问模式可以各有不同，但不需要向用户公开实现这些卷的细节。对于这些需求，StorageClass 资源可以实现。可根据上图看清他们之间的关系
kubectl explain pvc.spec
定义pvc资源对象
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: mypvc namespace: default spec: accessModes: ["ReadWriteMany"] resources: requests: storage: 5Gi --- apiVersion: v1 kind: Pod metadata: name: my-demo-pvc namespace: default labels: name: myapp tier: appfront spec: containers: - name: myapp image: ikubernetes/myapp:v1 ports: - name: http containerPort: 80 volumeMounts: - name: appindex mountPath: /usr/share/nginx/html/ volumes: - name: appindex persistentVolumeClaim: claimName: mypvc
查看
$ kubectl get pv NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE pv02 5Gi RWO,ROX Retain Bound default/mypvc 1h
$ kubectl describe pod my-demo-pvc Name: my-demo-pvc Namespace: default Priority: 0 PriorityClassName: <none> Node: k8s-node02/172.16.138.42 Start Time: Thu, 20 Sep 2018 05:23:04 -0400 Labels: name=myapp tier=appfront Annotations: kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"v1","kind":"Pod","metadata":{"annotations":{},"labels":{"name":"myapp","tier":"appfront"},"name":"my-demo-pvc","namespace":"default"},"s... Status: Running IP: 10.244.2.6 Containers: myapp: Container ID: docker://6727e1b45fba703f98d7a11f16a60706b8f5c2925026707b412c13ef80f5ac52 Image: ikubernetes/myapp:v1 Image ID: docker-pullable://ikubernetes/myapp@sha256:9c3dc30b5219788b2b8a4b065f548b922a34479577befb54b03330999d30d513 Port: 80/TCP Host Port: 0/TCP State: Running Started: Thu, 20 Sep 2018 05:23:06 -0400 Ready: True Restart Count: 0 Environment: <none> Mounts: /usr/share/nginx/html/ from appindex (rw) /var/run/secrets/kubernetes.io/serviceaccount from default-token-lplp6 (ro) ......
标签：ota 也有 删除 get 一起 bubuko 管理 应用 rda
原文地址：https://www.cnblogs.com/xzkzzz/p/9633308.html
