kubernetes存储入门（kubernetes）
实验环境依旧是三个节点拉取镜像，然后在master节点拉取资源清单：
然后同步会话，导入镜像；
存储入门
ConfigMap
volume卷--》volumemount（挂载卷）
Glusterfs
NFS
ISCSI
HostPath
ConfigMap
Secret
EmptyDir
PVC
云原生存储技术：cephFS
emptydir：并不会在主机上体现出来，会在同一个pod内不同容器间体现出来；
pod（容器1和容器2）：两个容器间共享目录；
docker主机
k8s主机
apiVersion: apps/v1
这指定了使用的Kubernetes API版本，apps/v1是Deployment资源的稳定版本，用于定义和管理应用部署。
kind: Deployment
这指定了YAML文件中定义的资源类型为Deployment。Deployment是Kubernetes中用于声明式地更新应用和服务的高级抽象。
metadata
metadata部分包含了Deployment的元数据。
-
labels: 定义了一组键值对，用于标识和选择对象。这里定义了app: nginx标签，用于选择和标识这个Deployment。
-
name: Deployment的名称，这里是nginx。
-
namespace: Deployment所在的命名空间，默认是default。命名空间用于将集群内的资源逻辑上隔离。
spec
spec部分定义了Deployment的规格。
-
replicas: 指定了需要运行的Pod副本数量，这里是1。
-
selector: 一个标签选择器，用于指定Deployment管理的Pods的标签。这里选择了标签为app: nginx的Pods。
-
template: 定义了Pod的模板，用于创建新的Pods。
-
metadata: Pod模板的元数据，同样包含了labels来定义Pod的标签。
-
spec: Pod模板的规格。
-
containers: 定义了Pod中运行的容器列表。
-
第一个容器使用了nginx:1.7.9镜像，设置了imagePullPolicy为IfNotPresent（如果本地没有镜像，则从远程仓库拉取），并挂载了名为share-volume的卷到/opt目录。
-
第二个容器同样使用了nginx:1.7.9镜像，但通过设置command覆盖了容器的默认启动命令，使容器在启动后执行sh -c sleep 3600命令（即睡眠3600秒），并挂载了share-volume卷到/mnt目录。
-
-
volumes: 定义了Pod中使用的卷。
-
这里定义了一个名为share-volume的空目录卷（emptyDir），它将在Pod的每个容器中共享。注释掉的#medium: Memory表示如果取消注释，这个卷将会存储在内存中，而不是默认的磁盘上，但这通常不是emptyDir卷的标准用法，因为emptyDir卷默认就是基于节点的磁盘存储的。
-
-
-
总结
这个Deployment配置定义了一个包含两个nginx容器的Pod，它们都挂载了同一个空目录卷（share-volume），但第二个容器在启动后不会运行nginx服务，而是睡眠3600秒。这种配置可能用于测试、日志收集或需要容器间共享数据的场景。注意，由于两个容器都试图使用同一个端口（nginx默认端口80），这种配置在实际部署中可能无法正常工作，除非nginx配置被修改以监听不同的端口或使用其他网络配置。
创建出来：
然后登录到容器中进行验证：
然后登录到另外一个容器中应该能够看到创建的文件；
-
UTC与本地时间的差异
：UTC（协调世界时）是全球统一的时间标准，也称为零时区时间。而中国位于东八区，因此中国的标准时间（CST，中国上海时间）是UTC时间加上8小时。
如何解决时间问题：当前是亚洲上海时区；
而容器中是默认的时间。即：格林尼治天文台的时区；
只要把k8s主机上的localtime文件，映射到容器中就可以了。
引出了第二种技术：
HostPath（主机路径）该技术不仅可以指定文件，还可以指定目录；（Directory）
类似于docker中的-v选项：docker run -v /data1/nginx.conf:/data1/nginx.conf
apiVersion: apps/v1 # 指定使用的Kubernetes API版本为apps/v1，这是用于部署（Deployments）的API版本
kind: Deployment # 定义资源的类型为Deployment
metadata: # 元数据部分，用于定义Deployment的标识信息
labels: # 标签，用于组织和选择对象
app: nginx # 定义一个标签，键为app，值为nginx
name: nginx # Deployment的名称
namespace: default # Deployment所在的命名空间，默认为default
spec: # Deployment的规格说明
replicas: 1 # 副本数量，这里设置为1，即只部署一个Pod
selector: # 选择器，用于确定哪些Pods属于这个Deployment
matchLabels: # 通过标签匹配Pods
app: nginx # 匹配标签app=nginx的Pods
template: # Pod模板，用于创建Pods
metadata: # Pod的元数据
labels: # Pod的标签
app: nginx # Pod的标签，键为app，值为nginx
spec: # Pod的规格说明
containers: # 容器列表
- image: nginx:1.7.9 # 容器使用的镜像，这里使用的是nginx的1.7.9版本
imagePullPolicy: IfNotPresent # 镜像拉取策略，如果不存在则拉取
name: nginx # 容器的名称
volumeMounts: # 容器挂载的卷列表
- mountPath: /etc/localtime # 容器内的挂载路径
name: timezone-time # 挂载的卷的名称
volumes: # Pod中定义的卷列表
- name: timezone-time # 卷的名称
hostPath: # 使用宿主机上的文件或目录作为卷
path: /etc/localtime # 宿主机上的路径
type: File # 类型为文件
这个配置创建了一个Deployment，该Deployment会部署一个Pod，Pod中运行一个Nginx容器，容器的Nginx版本为1.7.9。此外，这个配置还通过hostPath卷将宿主机的/etc/localtime文件挂载到容器的/etc/localtime路径下，这样做的目的是为了让容器内的系统时间与宿主机保持一致，避免时区不一致导致的问题。
创建出来并测试：
扩展：
在Kubernetes（K8S）中，容器退出时的状态码（Exit Code）具有特定的含义，用于表示容器的终止原因和运行状态。这些状态码通常遵循Linux操作系统中的退出码约定，其值在0-255之间。以下是一些常见的容器退出状态码及其含义：
-
0
：表示容器正常退出，没有发生错误。这通常意味着容器内的应用程序按照预期完成了其任务并正常关闭。
-
1
：通常表示一般性错误。这可能是由于程序错误、命令行参数错误、Dockerfile中引用不存在的文件等原因导致的。
-
126
：表示命令调用错误，可能是由于权限问题或命令不可执行。容器尝试执行没有权限或不可执行的命令时，会返回此状态码。
-
127
：表示找不到命令。容器尝试执行一个不存在的命令时，会返回此状态码。
-
128 + N（N为信号编号）
：表示容器收到一个信号并退出。例如，128 + 9（即137）表示容器收到了SIGKILL信号，这通常是由于用户手动停止容器或系统因为资源不足（如OOMKilled）而强制终止容器。
-
255
：通常表示退出状态未知或无效。这可能是由于程序以非标准方式退出，或者状态码在转换过程中出现了问题。
当容器退出时，可以通过Kubernetes的命令行工具
kubectl来查看容器的退出状态码。例如，使用
kubectl describe pods 命令可以查看Pod的详细信息，包括容器的退出状态码。这对于排查容器故障和定位问题非常有帮助。
但是以上方式有弊端，因为k8s生成pod的时候会根据调度算法进行调度的，调度到哪个节点具有不确定性。（可能被创建到的节点没有所需的数据）
那么就可以使用共享目录：
NFS：c/s架构；都是安装nfs-utils安装包；
那么就可以分工，101作为服务器端，而102和103作为客户端；
同步会话开始安装对应的软件包；
然后在“服务器端”修改它的配置文件；
-
/opt/wwwroot
：这是NFS服务器上希望共享给客户端的目录路径。在这个例子中，/opt/wwwroot目录将被NFS服务共享出去，允许其他计算机通过网络访问这个目录中的文件。
-
192.168.10.0/24
：这是客户端的IP地址范围，使用的是CIDR（无类别域间路由）表示法。192.168.10.0/24表示从192.168.10.1到192.168.10.254的所有IP地址（包括两端的地址，但通常不包括网络地址192.168.10.0和广播地址192.168.10.255）。这意味着这个NFS共享仅对处于这个子网内的客户端开放。
-
(rw,sync,no_root_squash)
：这是应用于该共享的访问选项，用括号括起来并用逗号分隔。
综上所述，这个NFS配置条目允许子网192.168.10.0/24内的客户端以读写方式访问
/opt/wwwroot目录，且服务器会在回应写请求前将数据同步到磁盘，同时允许客户端的root用户拥有与NFS服务器上/opt/wwwroot目录相同的root权限。
然后创建出来共享目录，且生成测试文件，并启动相应的程序；
查看它对应的资源清单；
这个Kubernetes资源定义文件是一个Deployment对象，用于在Kubernetes集群中部署和管理应用。具体来说，它配置了一个名为nginx的部署，该部署使用Nginx的1.7.9版本镜像，并将一个NFS卷挂载到容器的/usr/share/nginx/html目录中。下面是对这个配置文件的详细解释：
-
apiVersion: apps/v1
：指定了Kubernetes API的版本，这里是apps/v1，它包含了Deployment、StatefulSet等应用部署相关的资源定义。
-
kind: Deployment
：声明了这个YAML文件定义的资源类型是一个Deployment。
-
metadata
：包含了关于这个Deployment的元数据。
：定义了Deployment的规格说明。
这个配置文件创建了一个Deployment，它会启动一个Pod，该Pod中运行一个Nginx容器，并将NFS服务器（IP地址为192.168.10.101）上/opt/wwwroot目录的内容挂载到容器的/usr/share/nginx/html目录中。这样，Nginx服务器就可以通过其Web根目录（即/usr/share/nginx/html）提供NFS服务器上/opt/wwwroot目录中的内容了。
因为创建的时候不确定会创建到哪个节点，所以要保证每个工作节点上都装有nfs；
验证：
pv持久化卷--PVC（C：claim声明）
删除pod不会影响到pvc，因为两个都是独立的资源对象；
删除pvc对pv的影响；
回收策略：
retain保留：删除了pvc，不影响pv；
recycle：删除了pvc，pv还在，只是pv的数据没有了；
delete：删除，删除了pvc，对应的pv也没了；
pvc声明pv的时候的访问策略：
readwriteonce：单路读写（允许被某一个节点使用，一旦被使用，其他的节点无法使用）RWO
readwriteoncepod：单节点读写，只能被一个pod读写。RWOP
readonlymany：多路只读。ROX
readwritemany：多路读写。RWX
先创建pv再创建pvc再创建pod；
创建pv：
静态pv：pv--》pvc--》pod
动态pv：存储类--》pvc--》pv自动创建出来了--》pod
hostpath
NFS
-
kind: PersistentVolume
：指定了这个YAML文件定义的资源类型为PersistentVolume（持久卷）。PersistentVolume是Kubernetes中用于存储数据的抽象，它独立于使用它的Pod的生命周期。
-
apiVersion: v1
：指定了使用的Kubernetes API版本为v1。
-
metadata
：包含了关于这个PersistentVolume的元数据。
：定义了持久卷的具体规格。
总的来说，这个配置定义了一个名为mypv-hostpath的持久卷，它映射到宿主机上的/mnt/data目录，拥有10GiB的存储空间，并且只能被单个节点以读写模式挂载。这个持久卷被归类到pv-hostpath存储类中。
创建出来：
被调用的时候会使用存储类名称（storageclassname）而不会使用pv的名称；
NFS的pv：
注意yaml文件中每个单词首字母大写；遵循了编程中的驼峰原则。
-
apiVersion: v1
：指定了使用的Kubernetes API版本为v1。
-
kind: PersistentVolume
：表明这个YAML文件定义的是一个PersistentVolume资源。
-
metadata
：包含了关于这个PersistentVolume的元数据。
：定义了持久卷的具体规格。
请注意，对于NFS持久卷，persistentVolumeReclaimPolicy设置为Recycle可能不是最佳选择，因为NFS卷通常设计为共享资源，并且Recycle策略可能不适用于这种场景。在实际应用中，您可能需要考虑使用Retain策略，以便在不再需要持久卷时手动管理其回收。
创建出来：
如何创建pvc：（指向hostpathpv的pvc）
-
kind: PersistentVolumeClaim
：这指定了资源类型为PersistentVolumeClaim。
-
apiVersion: v1
：这表示该资源定义遵循Kubernetes API的v1版本。
-
metadata
：这是关于PVC的元数据部分。
：这是PVC的规格说明部分，定义了PVC的具体需求。
：这指定了PVC所使用的StorageClass的名称。StorageClass是一个抽象层，用于定义如何动态地提供存储。在这个例子中，pv-hostpath很可能是一个自定义的StorageClass，它指示Kubernetes使用基于HostPath的存储卷。HostPath卷是将主机节点上文件或目录挂载到Pod中的卷类型，主要用于开发或测试环境。
：这定义了PVC的访问模式。
：这定义了PVC的资源需求。
总的来说，这个PersistentVolumeClaim定义了一个名为mypvc-hostpath的存储卷请求，它请求3GiB的存储空间，通过名为pv-hostpath的StorageClass来动态提供存储，且该存储卷以ReadWriteOnce模式被访问。这允许Kubernetes在集群中自动查找或创建满足这些条件的存储资源，并将其分配给请求它的Pod。
创建出来：
基于nfs的pvc：
-
kind: PersistentVolumeClaim
：这指定了资源类型为PersistentVolumeClaim，即这是一个PVC对象。
-
apiVersion: v1
：这表示该资源定义遵循Kubernetes API的v1版本，这是Kubernetes中最常用和最稳定的API版本之一。
-
metadata
：这是关于PVC的元数据部分。
：这是PVC的规格说明部分，定义了PVC的具体需求。
：这指定了PVC所使用的StorageClass的名称。StorageClass是一个用于定义如何动态地提供存储的抽象层。在这个例子中，pvc-nfs很可能是一个已经定义的StorageClass，它告诉Kubernetes使用NFS作为存储后端来动态创建PV（PersistentVolume）。这意味着，如果集群中存在一个与该StorageClass相关联的NFS服务器，并且有足够的空间来满足这个PVC的请求，Kubernetes将自动为PVC创建一个对应的PV。
：这定义了PVC的访问模式。
：这定义了PVC的资源需求。
总结来说，这个PersistentVolumeClaim定义了一个名为mypvc-nfs的存储卷请求，它请求3GiB的存储空间，通过名为pvc-nfs的StorageClass来动态提供NFS存储，且该存储卷以ReadWriteOnce模式被访问。这使得Kubernetes能够在集群中自动查找或创建满足这些条件的NFS存储资源，并将其分配给请求它的Pod。
创建出来：
如何交给pod去使用：
在Kubernetes中，Pod是最小的可部署的计算单元，它封装了一个或多个容器（如Docker容器），存储资源，以及运行这些容器所需的选项；
-
kind: Pod
：这指定了资源类型为Pod，即这是一个Pod定义。
-
apiVersion: v1
：这表示该资源定义遵循Kubernetes API的v1版本。
-
metadata
：这是关于Pod的元数据部分。
：这是Pod的规格说明部分，定义了Pod的具体配置。
总结来说，这个Pod定义了一个名为hostpath-pv-pod的Pod，它运行了一个Nginx 1.7.9版本的容器。该容器将监听80端口，并提供HTTP服务。此外，Pod还定义了一个名为task-pv-storage的卷，该卷通过mypvc-hostpath PVC来提供持久化存储，并被挂载到容器的/usr/share/nginx/html目录下。这意味着Nginx将从这个目录中提供网页内容，而这些内容存储在由PVC管理的持久化存储中。
pv：
pv的名字
存储类名字--》和pvc关联
pvc
pvc的名字
存储类名字--》和pv关联
pod
pod的名字
pod要调用pvc--》pvc的名字
然后查看pod的详细信息，查看到被调度到了node1上，即：102；
创建文件进行测试：
登录到对应的pod中进行查看：
如果删除pod会对数据有影响吗？？？
文件还在！！！
nfs的pvc的pod：
-
kind: Pod
：指定了这个资源是一个Pod。
-
apiVersion: v1
：表明这个Pod定义遵循Kubernetes API的v1版本。
-
metadata
