做印刷在哪个网站接单好好/杭州关键词排名工具

实验环境依旧是三个节点拉取镜像，然后在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配置被修改以监听不同的端口或使用其他网络配置。

创建出来：

然后登录到容器中进行验证：

然后登录到另外一个容器中应该能够看到创建的文件；

1. 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之间。以下是一些常见的容器退出状态码及其含义：

1. 0

：表示容器正常退出，没有发生错误。这通常意味着容器内的应用程序按照预期完成了其任务并正常关闭。

1. 1

：通常表示一般性错误。这可能是由于程序错误、命令行参数错误、Dockerfile中引用不存在的文件等原因导致的。

1. 126

：表示命令调用错误，可能是由于权限问题或命令不可执行。容器尝试执行没有权限或不可执行的命令时，会返回此状态码。

1. 127

：表示找不到命令。容器尝试执行一个不存在的命令时，会返回此状态码。

1. 128 + N（N为信号编号）

：表示容器收到一个信号并退出。例如，128 + 9（即137）表示容器收到了SIGKILL信号，这通常是由于用户手动停止容器或系统因为资源不足（如OOMKilled）而强制终止容器。

1. 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

：包含了Pod的元数据。

：定义了Pod的规格说明。

总结来说，这个Pod定义了一个名为pvc-nfs的Pod，它运行了一个Nginx 1.7.9版本的容器。这个容器将监听80端口，并提供HTTP服务。Pod还定义了一个名为pvc-nfs01的卷，该卷通过mypvc-nfs PVC来提供持久化存储，并被挂载到容器的/usr/share/nginx/html目录下。因此，Nginx将从这个目录中提供网页内容，而这些内容存储在由PVC管理的NFS持久化存储中。注意，Pod的名称（pvc-nfs）和卷的名称（pvc-nfs01）并不要求与PVC的名称（mypvc-nfs）有直接的关系，它们只是用于在Kubernetes中唯一标识这些资源的。

登录进去：