实验环境依旧是三个节点拉取镜像,然后在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