[K8S] K8S-Volume存储(6)

XJzz3

于 2024-07-22 17:29:28 发布

阅读量987

点赞数 9

分类专栏： K8S 文章标签： kubernetes 容器云原生

本文链接：https://blog.csdn.net/weixin_46965089/article/details/140613395

版权

K8S 专栏收录该内容

6 篇文章 1 订阅

订阅专栏

文章目录

准备镜像 k8s集群每个node节点需要下载镜像：

docker pull mariadb:10.5.2

在 Kubernetes 中，Volume 是一种抽象概念，用于持久化存储容器中的数据。Kubernetes 提供了多种类型的Volume，每种类型都适用于不同的场景和需求。

1. EmptyDir 临时卷

描述: EmptyDir 是一种临时性 Volume，它在 Pod 被调度到节点上时创建，随着 Pod 的删除而被清除。它通常用于需要临时存储数据的场景，如容器之间共享数据。使用很少

volumes:
  - name: temp-volume
    emptyDir: {}

2. HostPath 文件目录挂载

描述: HostPath 允许将主机节点（Node）上的文件系统目录直接挂载到 Pod 中。这种 Volume 适合需要直接访问主机文件系统的应用场景，但在生产环境中使用时需注意安全性和可移植性问题。
例如只支持单节点（Node），而且只支持 “ReadWriteOnce”模式

volumes:
  - name: host-path-volume
    hostPath:
      path: /data

指定node节点 kubectl label nodes k8s-node01 mariadb=mariadb

查看node节点label值 kubectl get nodes --show-labels

HOSTPATH的用法：在volimeMountes中指定容器内部的路径和外部 hostPath的名称
在定义卷中定义

containers 
	volumeMounts: 
		- mountPath: /var/lib/mysql 
		  name: mariadb-volume
.......
volumes:
	 - name: mariadb-volume 
	   hostPath: 
	 	  	path: /data/mariadb
			type: Directory

3. PersistentVolumeClaim (PVC & PV)

部署mysql之前我们需要先了解一个概念有状态服务。这是一种特殊的服务，简单的归纳下就是会产生需要持久化的数据，并且有很强的I/O需求，且重启需要依赖上次存储到磁盘的数据。如典型的mysql，kafka，zookeeper等等。

描述: PersistentVolumeClaim 允许 Pod 使用持久化存储，如云存储卷（AWS EBS、Azure Disk 等）或者集群中的网络存储（NFS、GlusterFS 等）。PVC 提供了一种抽象机制，使得 Pod 可以独立于存储技术进行部署和管理。

volumes:
  - name: pvc-volume
    persistentVolumeClaim:
      claimName: my-pvc

3.1 PV&&PVC理论补充

存储机制介绍在 Kubernetes 中，存储资源和计算资源(CPU、Memory)同样重要，Kubernetes 为了能让管理员方便
管理集群中的存储资源，同时也为了让使用者使用存储更加方便，所以屏蔽了底层存储的实现细节，将存储抽象出两个 API 资源
PersistentVolume 和 PersistentVolumeClaim 对象来对存储进行管理。

PersistentVolume（持久化卷）： PersistentVolume 简称 PV，是对底层共享存储的一种抽象，将共享存储定义为一种资源，它属于集群级别资源，不属于任何 Namespace，用户使用 PV 需要通过 PVC
申请。PV 是由管理员进行创建和配置，它和具体的底层的共享存储技术的实现方式有关，比如说 Ceph、GlusterFS、NFS
等，都是通过插件机制完成与共享存储的对接，且根据不同的存储 PV 可配置参数也是不相同。

PersistentVolumeClaim（持久化卷声明）： PersistentVolumeClaim 简称 PVC，是用户存储的一种声明，类似于对存储资源的申请，它属于一个 Namespace 中的资源，可用于向 PV 申请存储资源。PVC 和
Pod 比较类似，Pod 消耗的是 Node 节点资源，而 PVC 消耗的是 PV 存储资源，Pod 可以请求 CPU 和 Memory，而
PVC 可以请求特定的存储空间和访问模式。

上面两种资源 PV 和 PVC 的存在很好的解决了存储管理的问题，不过这些存储每次都需要管理员手动创建和管理，如果一个集群中有很多应用，并且每个应用都要挂载很多存储，那么就需要创建很多 PV 和 PVC 与应用关联。为了解决这个问题 Kubernetes 在 1.4 版本中引入了 StorageClass 对象。当我们创建 PVC 时指定对应的 StorageClass 就能和 PV的StorageClass 关联，StorageClass 会交由与他关联 Provisioner 存储插件来创建与管理存储，它能帮你创建对应的 PV 和在远程存储上创建对应的文件夹，并且还能根据设定的参数，删除与保留数据。所以管理员只要在 StorageClass 中配置好对应的参数就能方便的管理集群中的存储资源。

3.2 PV

PV概念 persistentVolume：是由管理员设置的存储，它是集群的一部分。就像节点时集群中的资源一样，PV也是集群中的资源。PV是Volumes之类的卷插件，但具有独立于使用PV的pod的生命周期。此API对象包含存储实现的细节，即NFS、iSCSI或者特定于云供应商的存储系统

apiVersion: v1 
kind: PersistentVolume 
metadata: 
	labels: 
		app: mariadb-pv
	name: data-mariadb-pv
spec: 
	accessModes: 
		- ReadWriteOnce
	capacity: 
		storage: 10Gi
	hostPath: 
		path: /data/mariadb 
		type: DirectoryOrCreate
	persistentVolumeReclaimPolicy: Retain 
	storageClassName: standard
	volumeMode: Filesystem

3.2.1 PV生命周期

PV 的生命周期 PV 生命周期总共四个阶段：

Available（可用）—— 可用状态，尚未被 PVC 绑定。
Bound（已绑定）—— 绑定状态，已经与某个 PVC 绑定。
Released（已释放）—— 与之绑定的 PVC 已经被删除，但资源尚未被集群回收。
Failed（失败）—— 当删除 PVC 清理资源，自动回收卷时失败，所以处于故障状态。

命令行会显示绑定到 PV 的 PVC 的名称 ——kubectl get pv命令

3.2.2 PV 的常用配置参数

存储能力（capacity）
PV 可以通过配置 capacity 中的 storage 参数，对 PV 挂多大存储空间进行设置。目前 capacity 只有一个设置存储大小的选项，未来可能会增加。

存储卷模式（volumeMode）
PV 可以通过配置 volumeMode 参数，对存储卷类型进行设置，可选项包括：
Filesystem：文件系统，默认是此选项。
Block：块设备目前 Block 模式只有 AWSElasticBlockStore、AzureDisk、FC、GCEPersistentDisk、iSCSI、
LocalVolume、RBD、VsphereVolume 等支持）。

挂载参数（mountOptions）
PV 可以根据不同的存储卷类型，设置不同的挂载参数，每种类型的存储卷可配置参数都不相同。如 NFS存储，可以设置 NFS 挂载配置，如下：
下面例子只是 NFS 支持的部分参数，其它参数请自行查找 NFS 挂载参数。 mountOptions: - hard

nfsvers=4

存储类（storageClassName）
PV 可以通过配置 storageClassName 参数指定一个存储类 StorageClass 资源，具有特定 StorageClass 的 PV 只能与指定相同 StorageClass 的 PVC 进行绑定，没有设置 StorageClass
的 PV 也是同样只能与没有指定 StorageClass 的 PVC 绑定。

回收策略（persistentVolumeReclaimPolicy）
PV 可以通过配置 persistentVolumeReclaimPolicy 参数设置回收策略，可选项如下： Retain（保留）：保留数据，需要由管理员手动清理。 Recycle（回收）：删除数据，即删除目录下的所有文件，比如说执行 rm -rf /thevolume/* 命令，目前只有 NFS 和 HostPath 支持。 Delete（删除）：删除存储资源，仅仅部分云存储系统支持，比如删除 AWS EBS 卷，目前只有
AWS EBS，GCE PD，Azure 磁盘和 Cinder 卷支持删除。

3.3 PVC

PVC概念 peresistentVolumeClaim是用户存储的请求。它与pod相似，pod消耗节点资源，PVC消耗PV资源。 pod可以请求特定级别的资源(CPU和内存)。盛名可以请求特定的大小和访问模式。例如：可以以读/写一次或者只读多次模式挂载。

apiVersion: v1 
kind: PersistentVolumeClaim 
metadata: 
	name: k8sdemo-mariadb-pvclaim 
	labels: 
		app: k8sdemo-mariadb-pvc
spec: 
	accessModes: 
		- ReadWriteOnce
	storageClassName: standard 
	resources: 
		requests:
			storage: 1Gi
     volumes: 
     	- name: mysqlvolume 
     	  persistentVolumeClaim:
     	  	claimName: k8sdemo-mariadb-pvclaim

3.3.1 PVC 的常用配置参数

筛选器（selector）
PVC 可以通过在 Selecter 中设置 Laberl 标签，筛选出带有指定 Label 的 PV 进行绑定。 Selecter 中可以指定 matchLabels 或 matchExpressions，如果两个字段都设定了就需要同时满足才能匹配。

资源请求（resources）
PVC 设置目前只有 requests.storage 一个参数，用于指定申请存储空间的大小。

存储类（storageClass）
PVC 要想绑定带有特定 StorageClass 的 PV 时，也必须设定 storageClassName 参数，且名称也必须要和 PV 中的 storageClassName 保持一致。如果要绑定的 PV 没有设置 storageClassName 则PVC 中也不需要设置。

访问模式（accessModes）
PVC 中可设置的访问模式与 PV 种一样，用于限制应用对资源的访问权限。

4. ConfigMap 和 Secret

描述: ConfigMap 和 Secret 分别用于将配置文件和敏感信息（如密码、密钥等）注入到 Pod 中。它们可以作为 Volume 使用，使得应用程序可以从这些资源中读取配置或者密钥信息。

volumes:
  - name: configmap-volume
    configMap:
      name: my-configmap

  - name: secret-volume
    secret:
      secretName: my-secret

4.1 configmap

ConfigMap顾名思义，是用于保存配置数据的键值对，可以用来保存单个属性，也可以保存配置文件。 ConfigMaps允许你将配置构件与映像内容解耦，以保持容器化应用程序的可移植性。configmap 可以从文件、目录或者 key-value 字符串创建等创建 ConfigMap。也可以通过 kubectl create -f从描述文件创建。可以使用 kubectl create创建命令。创建ConfigMap的方式有4种：

直接在命令行中指定configmap参数创建，即–from-literal。
指定文件创建，即将一个配置文件创建为一个ConfigMap–from-file=<文件>
指定目录创建，即将一个目录下的所有配置文件创建为一个ConfigMap，–from-file=<目录>
先写好标准的configmap的yaml文件，然后kubectl create -f 创建

创建configmap kubectl create configmap helloconfigmap --from-literal=lagou.hello=world

查看configmap
kubectl get configmap helloconfigmap -o go-template='{{.data}}'

4.2 secret

Secret 解决了密码、token、密钥等敏感数据的配置问题，而不需要把这些敏感数据暴露到镜像或者 Pod Spec中。Secret 可以以 Volume 或者环境变量的方式使用。

Secret 有三种类型：

Service Account ：用来访问 Kubernetes API，由 Kubernetes 自动创建，并且会自动挂载到 Pod 的/run/secrets/kubernetes.io/serviceaccount 目录中。
Opaque ：base64编码格式的Secret，用来存储密码、密钥等
kubernetes.io/dockerconfigjson ：用来存储私有 docker registry 的认证信息

4.2.1 Service Account

Service Account简称sa， Service Account 用来访问 Kubernetes API，由 Kubernetes 自动创建，并且会自动挂载到 Pod的/run/secrets/kubernetes.io/serviceaccount 目录中。

查询命名空间为kube-system的pod信息 
kubectl get pod -n kube-system
进入pod:
kube-proxy-48bz4 kubectl exec -it kube-proxy-48bz4 -n kube-system sh
cd /run/secrets/kubernetes.io/serviceaccount ls
cat ca.crt cat namespace
cat token

4.2.2 Opaque Secret

Opaque 类型的数据是一个 map 类型，要求 value 是 base64 编码格式。加密、解密
使用命令行方式对需要加密的字符串进行加密。例如:mysql数据库的密码

对admin字符串进行base64加密:获得admin的加密字符串
“YWRtaW4=” echo -n “admin” | base64

base64解密：对加密后的字符串进行解密 echo -n “YWRtaW4=” | base64 -d

5.CSI (Container Storage Interface)

描述: CSI 允许第三方存储提供商实现自定义的存储解决方案，并将其集成到 Kubernetes 中。CSI Volume 可以支持更复杂的存储需求，如多副本、备份和恢复等操作。

volumes:
  - name: csi-volume
    csi:
      driver: my-csi-driver
      volumeHandle: volume-id

除了上述常见的 Volume 类型外，Kubernetes 还支持一些其他类型的 Volume，如 downwardAPI、projected 等，用于更复杂的应用场景和数据管理需求。

6. 安装mariaDB

部署service maria/mariadb.yml

apiVersion: apps/v1 
kind: Deployment 
metadata: 
	name: mariadb 
	labels: 
		app: mariadb
spec: 
	replicas: 1 
	template: 
		metadata: 
			name: mariadb 
			labels: 
				app: mariadb
		spec:
			containers:
				- name: mariadb 
				  image: mariadb:10.5.2 
				  imagePullPolicy: IfNotPresent 
				  env: 
				  	- name: MYSQL_ROOT_PASSWORD 
				  	  value: admin
					- name: TZ 
					  value: Asia/Shanghai
				  args: 
				  	- "--character-set-server=utf8mb4" - "
				  	- --collation-server=utf8mb4_unicode_ci"
				  ports: 
				  	- containerPort: 3306
			restartPolicy: Always
		selector: 
			matchLabels: 
				app: mariadb
				
--apiVersion: v1 
kind: Service 
metadata: 
	name: mariadb-svc
spec: 
	selector: 
		app: mariadb
	ports: 
		- port: 3306 
		  targetPort: 3306 
		  nodePort: 30036
	type: NodePort

运行服务
kubectl apply -f .
kubectl get pod -o wide

客户端测试
IP:192.168.198.157
username:root
password:admin
prot: 30036

删除service
kubectl delete -f mariadb.yml

7. 集群调度原理

Scheduler调度步骤

首先用户在通过 Kubernetes 客户端 Kubectl 提交创建 Pod 的 Yaml 的文件，向Kubernetes 系统发起资源请求，该资源请求被提交到Kubernetes 系统。
Kubernetes 系统中，用户通过命令行工具 Kubectl 向 Kubernetes 集群即 APIServer 用的方式发送“POST”请求，即创建 Pod 的请求。
APIServer 接收到请求后把创建 Pod 的信息存储到 Etcd 中，从集群运行那一刻起，资源调度系统 Scheduler 就会定时去监控 APIServer
通过 APIServer 得到创建 Pod 的信息，Scheduler 采用 watch 机制，一旦 Etcd 存储 Pod 信息成功便会立即通知APIServer，
APIServer会立即把Pod创建的消息通知Scheduler，Scheduler发现 Pod 的属性中 Dest Node 为空时（Dest Node=“”）便会立即触发调度流程进行调度。
而这一个创建Pod对象，在调度的过程当中有3个阶段：节点预选、节点优选、节点选定，从而筛选出最佳的节点