节点存储卷 hostPath
hostPath类型的存储卷是指将工作节点上某文件系统的目录或文件挂载于Pod中的一种存储卷，它可独立于Pod资源的生命周期，因而具有持久性。但它是工作节点本地的存储空间，仅适用于特定情况下的存储卷使用需求，例如，将工作节点上的文件系统关联为Pod的存储卷，从而使得容器访问接待您文件系统上的数据。这一点在运行有管理任务的系统级Pod资源需要访问节点上的文件时比较有用。
配置hostPath存储卷的嵌套字段共有两个：一个是用于指定工作节点上的目录路径的必须按字段path ,一个是指定存储卷类型的type，它支持使用的卷类型包含如下几种：
- DirectoryOrCreate：指定的路径不存在时自动将其创建为权限是0755的空目录，属主属组均为kubelet。
- Directory：必须存在的目录路径
- FileOrCreate：指定的路径不存在时自动将其创建为权限0644的空文件，属主和属组同是kubelet。
- File：必须存在的文件路径
- Socket：必须存在的Socket文件路径
- CharDevice：必须存在的字符设备文件路径
- BlockDevice：必须存在的块设备文件路径
下面是定义在vo-hostpath.yaml配置文件中的Pod资源，它运行着日志收集代理应用filebeat，负责收集工作节点及容器相关的日志信息发往Redis服务器，它使用了三个hostPath类型的存储卷：
1.创建资源配置清单
apiVersion: v1
kind: Pod
metadata:
name: vo-hostpath-pod
spec:
containers:
- name: filebeat
image: ikubernetes/filebeat:5.6.7-alpine
env: #定义变量
- name: REDIS_HOST #变量名
value: redis.ilinux.io:6379 #变量值
- name: LOG_LEVEL #变量明
value: info #变量值
volumeMounts: #卷挂载配置
- name: varlog #挂载名称为varlog的卷
mountPath: /var/log #挂载到容器中的/var/log目录中
- name: socket #挂载名称为socket的卷
mountPath: /var/run/docker.sock#挂载到容器中的/var/run/docker.sock
- name: varlibdockercontainers #挂载名称为varlibdockercontainers的卷
mountPath: /var/lib/docker/containers#挂载到容器中的/var/lib/docker/containers目录中
readOnly: true #为只读挂载
volumes: #卷配置
- name: varlog #自定义的卷名称
hostPath: #节点路径配置
path: /var/log #在节点上的路径
type: DirectoryOrCreate #节点上不存在/var/log目录时，则自动创建权限为0755的目录，属性信息为kubelet用户
- name: varlibdockercontainers
hostPath:
path: /var/lib/docker/containers
type: Directory
- name: socket
hostPath:
path: /var/run/docker.sock
type: Socket #节点上必须存在/var/run/docker.sock，否则创建Pod失败
2.创建Pod对象
kubectl apply -f vo-hostpath.yaml
3.查看Pod对象详细信息 如下命令可以到Pod的挂载信息
kubectl describe pods/vo-hostpath-pod | grep -A 12 Volumes
Volumes:
varlog:
Type: HostPath (bare host directory volume)
Path: /var/log
HostPathType:
varlibdockercontainers:
Type: HostPath (bare host directory volume)
Path: /var/lib/docker/containers
HostPathType:
socket:
Type: HostPath (bare host directory volume)
Path: /var/run/docker.sock
HostPathType:
如下这台Pod运行在了Node02节点之上，那么就会把Node02上的 /var/log 、/var/lib/docker/containers目录以及 /var/run/docker.sock文件挂载至我们创建的Pod之中。
kubectl get pods -o wide | grep vo-hostpath-pod
vo-hostpath-pod 1/1 Running 0 3m37s 172.20.2.28 k8s-node02 <none> <none>
4.进入Pod查看挂载信息
kubectl exec -it pods/vo-hostpath-pod -- /bin/sh
#查看/var/log
/ # ls /var/log
alternatives.log chrony kern.log syslog.2.gz vmware-vmsvc-root.1.log
alternatives.log.1 cloud-init-output.log kern.log.1 syslog.3.gz vmware-vmsvc-root.2.log
apt cloud-init.log kern.log.2.gz syslog.4.gz vmware-vmsvc-root.3.log
auth.log containers kern.log.3.gz syslog.5.gz vmware-vmsvc-root.log
auth.log.1 dist-upgrade kern.log.4.gz syslog.6.gz vmware-vmtoolsd-root.log
auth.log.2.gz dpkg.log landscape syslog.7.gz wtmp
auth.log.3.gz dpkg.log.1 lastlog tallylog wtmp.1
auth.log.4.gz dpkg.log.2.gz lxd unattended-upgrades
bootstrap.log faillog pods vmware-network.1.log
btmp installer syslog vmware-network.2.log
btmp.1 journal syslog.1 vmware-network.log
#查看/var/lib/docker/containers信息
/ # ls /var/lib/docker/containers/
222ff7ab4b939691d4690ebd353e4dae39782d48dba190f6473d02f65e35e9c5 9b362d8f03d2f87573487a8d6a266c1a77b6e2cfb28654ba5a3016008155564f
2ddb2bd4c2dfd44b48a430502e8f0479651ac2084b14070c7bd6f128907e6d27 d2e2af23b3a406d941a1f19a989c6a529b7cfda32a75579ff171148e3bce771d
2f0c31b8e6fff99953a096af8153b37b572f71a3e98a9e09665486b6ca6d940f e0d8e9913767ef45c700648f20f025440f1313be242b6f0cf3577b1b92d61acb
31baeb1aef75acf16544042add63293e8547008c1ae1d40ab62f8fd24fa203a4 ee09c6588feb6665d24f61a887fe4a9d4df366625f80e9b7b0520c6066b3a754
3dbada0509671af1193b39b86f72d1ed9022914f7ba7886bd975cfa70c554559 ef1fcc1b0de6817b2d2c8b81a187e72a93c960c816ee118bf5ba9d1a07fff7d6
47686a866a3e9f1e0b82bb582072c612b95ea0d1c68951ea44b3f751eb49dbcb f52a7a55801bec13b26f2c02fbc5c32cb758f690de5480ff246f379ebbb3fac7
6bc85638f22115f3479ef025b94159a7d8e5e5988fb508c28d118f510c767e0f f6b5e6bc12ba8121d2aceca137eaf31929d46664648154b45800697a8bd5a23c
9afc7bb18dc7d858f514ec001ad47c6fd6d5ac67f25aa0e777c4762b9ccfaf45
#查看/var/run/docker.sock文件
/ # ls -lrth /var/run/docker.sock
srw-rw---- 1 root ping 0 May 8 03:27 /var/run/docker.sock
/ # exit;
这类Pod资源通常受控于daemonset类型的Pod控制器，它运行于集群中的每个工作节点之上，负责收集工作节点上系统级的相关逐句，因此使用hostPath存储卷也是理所应当的。
读者在创建上述Pod资源时，如果有可用的Redis服务器，则可通过REDIS_HOST传递给Pod资源，待其Ready之后即可通过Redis服务器查看到由其发送的日志信息。在filebeat应用架构中。这些日志信息会发到Elasticsearch，并通过Kibana进行展示。
另外，使用hostPath存储卷时需要注意到，不同节点上的文件或许并不完全相同，于是，那些要求事先必须存在的文件或目录的满足状态也可能会有所不同；另外基于资源可用状态的调度器Pod时，hostPath资源的可用性状态不会被考虑在内；再者，在节点中创建的文件或目录默认仅有root可写，若期望容器内的进程拥有写权限，则要么将它们运行为特权容器，要么修改节点上的目录权限。
那些并非执行系统级管理任务的且不受控于Daemonset控制器的无状态应用在Pod资源被重新调度至其它节点运行时，此前创建的文件或目录大多数都不会存在。因此hostPath存储卷虽然能持久保存数据，但对被调度器按需调度的应用来说并不适用，这时需要用到的是独立于集群节点的持久性存储卷、即网络存储卷。
数据卷：hostPath
hostPath卷：
挂载Node文件系统（Pod所在节点）上文件或者目录到Pod中的容器。
应用场景：
Pod中容器需要访问宿主机文件
hostPath Volume 的作用是将 Docker Host 文件系统中已经存在的目录 mount 给 Pod 的容器。大部分应用都不会使用 hostPath Volume，因为这实际上增加了 Pod 与节点的耦合，限制了 Pod 的使用。不过那些需要访问 Kubernetes 或 Docker 内部数据（配置文件和二进制库）的应用则需要使用 hostPath。
Mysql 与 Yaml
[root@k8s-master ~]# cat mysql-deploy.yml
apiVersion: apps/v1
kind: Deployment
metadata:
name: mysql
namespace: default
spec:
selector:
matchLabels:
app: mysql
template:
metadata:
labels:
app: mysql
spec:
containers:
- name: mysql
image: mysql:5.6
env:
- name: MYSQL_ROOT_PASSWORD
value: password
ports:
- name: mysql
containerPort: 3306
volumeMounts:
- name: mysql-persistent-storage
mountPath: /var/lib/mysql
volumes:
- name: mysql-persistent-storage
hostPath:
path: /var/lib/mysql
# 这里定义了1个 hostPath volume mysql-persistent-storage，对应Host目录/var/lib/mysql
[root@k8s-master ~]# cat mysql-svc.yml
apiVersion: v1
kind: Service
metadata:
name: mysql
namespace: default
spec:
selector:
app: mysql
type: NodePort
ports:
- protocol: TCP
port: 3000
targetPort: 3306
nodePort: 30080
[root@k8s-master ~]# kubectl apply -f mysql-deploy.yml
deployment.apps/mysql created
[root@k8s-master ~]# kubectl apply -f mysql-svc.yml
service/mysql created
[root@k8s-master ~]# kubectl get pod -o wide | awk 'NR==1 || $1=="mysql-7d94b44649-jttrw"'
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
mysql-7d94b44649-jttrw 1/1 Running 0 11m 10.244.1.14 k8s-node1 <none> <none>
[root@k8s-master ~]# kubectl get svc | awk 'NR==1 || $1=="mysql"'
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
mysql NodePort 10.0.0.170 <none> 3000:30080/TCP 11m
[root@k8s-master ~]# kubectl exec -it mysql-7d94b44649-jttrw /bin/bash
root@mysql-7d94b44649-jttrw:/# ls /var/lib/mysql
auto.cnf ib_logfile0 ib_logfile1 ibdata1 mysql performance_schema
[root@k8s-node1 mysql]# ls
auto.cnf ibdata1 ib_logfile0 ib_logfile1 mysql performance_schema
如果 Pod 被销毁了，hostPath 对应的目录也还会被保留，从这点看，hostPath 的持久性比 emptyDir 强。不过一旦 Host 崩溃，hostPath 也就没法访问了。
[root@k8s-master ~]# kubectl delete -f mysql-deploy.yml
deployment.apps "mysql" deleted
[root@k8s-master ~]# kubectl apply -f mysql-deploy.yml
deployment.apps/mysql created
[root@k8s-node1 mysql]# ls
auto.cnf ibdata1 ib_logfile0 ib_logfile1 mysql performance_schema
总结
hostpath也不适合做数据持久化，因为局限于节点，除非pod就调度到该节点，比如使用调度策略标签选择器，这样就不能实现高可用了
最理想的就是一个节点挂掉，在另外一个节点起来，要使得数据卷可以使用之前的数据，就可以通过网络去连接共享存储，共享存储独立于集群之外。所以pod不管在哪个节点上只要能够连接到共享存储都能访问到之前的数据。实现了高可用。
