【K8S in Action】第六章 卷：将磁盘挂载到容器
1. 介绍卷
每个新容器都是通过在构建镜像时加入的详细配置文件来启动的。 将此与pod 中容器重新启动的现象结合起来。
存储卷是 pod 的一个组成部分。这意味着在 pod 启动时创建卷， 并在删除 pod时销毁卷。 因此， 在容器重新启动期间， 卷的内容将保持不变， 在重新启动容器之后， 新容器可以识别前一个容器写入卷的所有文件。
另外，如果一个 pod 包含多个容器， 那这个卷可以同时被所有的容器使用。
1.1 卷类型
• emptyDir 用于存储临时数据的简单空目录。
• hostPath 用于将目录从工作节点的文件系统挂载到pod中。
• gitRepo 通过检出Git仓库的内容来初始化的卷。
• nfs 挂载到pod中的NFS共享卷。
2. 通过卷在容器之间共享数据
2.1 使用 emptyDir
关注它是如何用于在 pod 的多个容器之间共享数据的。卷从一个 目录开始，运行在 pod 内的应用程序可以写入它需要 的任何文件。pod 含两个容器和 个挂载在两个容器中的共用的卷，但在不同的路径上。
apiVersion: vl
kind: Pod
metadata:
name : fortune
spec:
containers:
-image: luksa/fortune
name: html generator
volumeMounts:
- name: html
mountPath: /var/htdocs 名为html的卷挂载在/var/htdocs
- image: nginx:alpine
name: web-server
volumeMounts :
- name: html
mountPath: /usr/share/nginx/html
readOnly: true
ports:
- containerPort: 80
protocol: TCP
volumes
- name: html 叫html的emptyDir卷，挂载在上面的两个容器中
emptyDir: {}
将端口从本地机器转发到 pod 来实现，计算机的 808 端口来访问服务
kubectl port-forward fortune 8080:80
volumes:
- name: html
emptyDir
medium: Memory # 存在内存上
2.2 使用 Git 仓库作为存储卷
gitRepo 卷基本上也是 emptyDir 卷，它通过克隆 Git 仓库并在 pod时（但在创建容器之前 检出特定版本来填充数据。
注意：
- 在创建gitRepo 卷后，它并不能和对应 repo 保持同步。 当向库推送新增 的提交时，文件将不会被更新。
- 然而，如果所用 pod 是由ReplicationController 管理的，删除这个 pod 将触发新建一个新的 pod ，而这个新 pod
的卷中将包含最新的提交。
apiVersion : vl
kind: Pod
metadata:
name: gi trepo-volume-pod
spec:
containers:
- image: nginx:alpine
name: web -server
volumeMounts :
- name : html
mountPath: / usr/share/nginx/ html
readOnly: true
ports:
containerPort: 80
protocol： TCP
volumes
- name: html
gitRepo: https://githubo.com/...
revision: master github 库的mater分支下载
directory: . 创建在根目录
如果想要将私有的 Git repo 克隆到容器中， 则应该使用 gitsync sidecar 或类似的方法， 而不是使用 gitRepo 卷。
3 访问工作节点文件系统上的文件（hostPath卷）
大多数 pod 应该忽略它们的主机节点， 因此它们不应该访问节点文件系统上的任何文件。
hostPath 卷指向节点文件系统上的特定文件或目录。 在同一个节点上运行并在其 hostPath 卷中使用相同路径的 pod 可以看到相同的文件。
hostPath 卷是我们介绍的第 一种类型的持久性存储。切勿使用它们来持久化跨 pod的数据。
kubect1 get pod s --namespace kube-system
查看hostpaht 的使用， 切勿使用它们来持久化跨 pod的数据
kubectl describe po fluentd-kubia-4ebc2fle-9a3e --namespace kube-system
4 使用持久化存储
当运行在一个 pod 中的应用程序需要将数据保存到磁盘上， 并且即使该 pod 重新调度到另 一个节点时也要求具有相同的数据可用。此必须将其存储在某种类型的网络存储 (NAS) 中。
4.1 使用 GCE 持久磁盘作为底层存储机制。
同 一区域的 Kubemetes 集群中创建
gcloud container clusters list
NAME ZONE MASTER VERSION MASTER_IP
kubia europe-westl-b 1.2.5 104.155.84.137
在europe-westl-b 区域中创建了集群 创建GCE 持久磁盘。创建了一个 1GiB 容量并命名为 mongodb的GCE 待久磁盘。
gcloud compute disks create --size=lGiB --zone=europe-west-b mongodb
创建—个使用GCE持久磁盘卷的pod。 Pod 直接使用了持久磁盘卷。
apiVersion: vl
kind: Pod
metadata:
name: mongodb
spec:
volumes:
- name: mongodb-data 卷名， 与挂载卷一致
gcePersistentDisk: 类型是GCE持久磁盘
pdName: mongodb 名称需要与创建的PD一致
fsType: ext4 文件系统类型
containers:
- image: mongo
name: mongodb
volumeMountS:
- name: mongodb-data 挂载卷
mountPath: /data/db
ports:
- containerPort: 27017
protocol: TCP
4.2 通过底层持久化存储使用其他类型的卷
如果集群是运行在自有的一组服务器上，那么就有大量其他可移植的选项在卷内挂载外部存储。例如，要挂载一个简单的NFS 共享，只需指定NFS 服务器和共享路径，如下面的代码清单所示
mongodb-pod-aws.yaml
volumes:
- name: mongodb-data
nfs: 这个卷受NFS共享支持
server: 1.2.3.4 NFS 服务IP
path: /some/path 服务器提供的路径
要了解每个卷类型设置需要哪些属性的详细信息，可以转到KubemetesAPI引用中的KubernetesAPI定义，或者通过第三章展示的通过kubectl explain查找信息。
通过pod的卷来隐藏真实的底层基础设施，不就是Kubernetes存在的意义吗。研发人员来指定NFS 服务器的主机名会是一件感觉很糟糕的事情。
5 从底层存储技术解耦pod
Kubernetes 的基本理念， 这个理念旨在向应用程序及其开发人员隐藏真实的基础设施， 使他们不必担心基础设施的具体状态， 并使应用程序可在大量云服务商和数据企业之间进行功能迁移。 （每当有这种想法，就会创造出新的岗位，专门管理基础设施与集群配置。）
5.1 介绍持久卷和持久卷声明
由集群管理员设置底层存储， 然后通过Kubernetes API 服务器创建持久卷并注册。
持久卷声明可以当作 pod 中的一个卷来使用， 其他用户不能使用相同的持久卷。
创建持久卷
apiVersion: vl
kind: PersistentVolume
metadata：
name: mongodb-pv
spec:
capacity:
storage: lGi 对应的容量需求
accessModes:
- ReadWriteOnce 可以被单个客户端挂载为读写模
- ReadOnlyMany 可以被多个客户端挂载为只读
persistentVolumeReclaimPolicy: Retain 声明被释放后被保留（不清理和删除）
gcePersistentDisk: PV 指定为之前创建的GCE持久磁盘.
pdName: mongodb 持久卷支持的实际存储类型、 位置和其他属性。
fsType: ext4 与直接Pod 直接使用GCE 的配置一样
create 创建后, 查看所有的持久卷, 持久卷不属于任何命名空间,集群层面的资源。
kubectl get pv
NAME CAPACITY RECLAIMPOLICY ACCESSMODES STATUS
mongodb-pv lGi Retain RWO,ROX Available
创建持久卷声明
需要部署持久化存储的 pod ，将要用到之前创建的持久卷，但是不能直接在 pod 内使用，需要先声明一个。
创建好声明,k8s就会找到适当的持久卷并将其绑定到声明 ：
- 持久卷的容量必须足够大以满足声明的需求，
- 并且卷的模式必须包含声明中指定的访模式 必须包含声明中的访问模式。
在该示例中，声明请求 1GiB 的存储空间和 ReadWriteOnce 访问模式。之前创建的持久卷符合刚刚声明中 的这两个条件，所以它被绑定到对应的声明中。
持久卷声明又只在特定的命名空间创建，所以持久卷和持久卷声明只能被同命名空间内的 pod 创建使用。
apiVersion: vl
kind: PersistentVolumeClaim
metadata：
name: mongodb-pvc 声明的名称，给pod 使用时需要用到
spec:
resources:
request:
storage: lGi 申请1G空间
accessModes:
- ReadWriteOnce 可以被单个客户端挂载为读写模
storageClassName :”” 动态配置章节介绍
kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESSMODES AGE
mongodb-pvc Bound mongodb-pvc l Gi RWO,ROX 3s
pod 中使用持久卷声明
apiVersion: vl
kind: Pod
metadata:
name: mogodb
spec:
containers:
- image: mongo
name: mongodb
volumeMounts:
- name : mogodb-data
mountPath: /data/db
ports:
- containerPort: 27017
protocol: TCP
volumes·
- name: mongodb data
persistentVolumeClaim:
claimName: mongodb-pvc 在 pod 的卷中引用持久卷声明名称
继续创建 pod ，现在检查这个 pod 是否确实在使用相同的持久卷和底层 GCEPD 。通过再次运行 MongoDB shell， 查看之前的数据
kubectl exec -it mongodb mongo
...
> use mystore
switched to db mystore
>db.foe.find()
{"_id "： Objectid （"7a6leb9deOcfd512374cc75")，"name"："fpp"}
回收持久卷
先 删除 pod 和 持久卷声明， 如果再次创建持久卷声明会怎样？持久卷声明的状态显示为 Pending。未清理前不可绑定到全新的声明中。
通过使用相同的持久卷，新 pod 可以读取由前一个 pod 存放的数据，即使声明和pod 是在不同的命名空间中创建的（因此有可能属于不同的集群租户）
$ kubectl delete pod mongodb
pod ” rnongodb" deleted
$ ubectl delete pvc ngodb-pvc
persistentvolurneclairn ” rnongodb pvc" deleted
$ kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESSMODES AGE
mogodb-pvc Pending 13s
列出持久卷
NAME CAPACITY ACCESSMODES STATUS CLAIM REASON AGE
mogodb-pv lGi RWO,ROX Released default/rnongodb-pvc
手动回收持久卷：
persistentVolumeReclaimPolicy 设置为 Reta ： 在持久卷从持久卷声明中释放后仍然能保留它的卷和数据内容。唯一方法是删除和 新创建 持久卷资源。
自动回收持久卷：
- Recycle 第一种删除卷的内容并使卷可用于再次声明
- Delete 策略删除底层存储
6 持久卷的动态卷配置
通过动态配置持久卷来自动执行此任务。集群管理员可以创建持久卷配置，并定义一个或多个 Storage Class, 从而让用户选择他们想要的持久卷类型而不仅仅只是创建持久卷。
创建 Storage Class资源后，用户可以在其持久卷声明中按名称引用存储类
apiVersion: storage.kBs.io/vl
kind: StorageClass
metadata :
name: fast
provisioner: kubernetes.io/gce-pd 置备程序, 配置持久卷的插件
parameters: 传达parameters的参数
type:pd-ssd
zone:europe-westl-b
apiVersion: vl
kind: PersistentVolumeClaim
metadata：
name: mongodb-pvc 声明的名称，给pod 使用时需要用到
spec:
storageClassName:fast PVC 请求自定义存储类
resources:
request:
storage: lGi 申请1G空间
accessModes:
- ReadWriteOnce 可以被单个客户端挂载为读写模
不指定存储类的动态配置
将看将持久卷附加到的最新和最简单的方法。SC 作为 storageclass 的简写。可以在不指定 storageClassName 属性的情况下创建 PVC，并且（在 Google K8s引擎上〉将为你提供 pd-standard 类型的 GCE 持久磁盘
列出存储类
$ kubectl get sc
NAME TYPE
fast kubernetes.io/gce-pd
standard (default) kubernetes.io/gce-pd
检查默认存储类
kubectl get sc standard -o yaml
annotations: 将存储类型标记为默认
storageclass.beta.kubernetes io/is-default-class:“true"
parameters:
type: pd-standard
provisi r: kubernetes.io/gce-pd
如果持久卷声明没有明确指出要使用哪个存储类， 默认存储类会用于动态提供持久卷的内容。
apiVersion: vl
kind: PersistentVolumeClaim
metadata：
name: mongodb-pvc2 声明的名称，给pod 使用时需要用到
spec:
resources: 没有指定PVC 请求自定义存储类
request:
storage: lGi 申请1G空间
accessModes:
- ReadWriteOnce 可以被单个客户端挂载为读写模
kubect1 getpvc mongodb-pvc2
NAME STATUS VOLUME CAPACITY ACCESSMODES STORAGECLASS
mongodb-pvc2 Bound pvc-95a5ecl2 lGi RWO standard
强制将持久卷声明绑定到预配置的其中一个持久卷
kind: PersistentVolumeClaim
spec:
StorageClassName: ""
为什么将 storageClassNarne 设置为一个空字符串，当你想让 PVC 绑定到你手动配置的 PV 时。
如果尚未将 storageClassName 属性设置为空字符串， 则尽管已存在适当的预配置待久卷， 但动态卷置备程序仍将配置新的持久卷。