今天的学习主要是针对上一组学习，也就是k8s数据存储的补充，因为现在网络上的学习各有不同，所以我在对比了几类课程后，再进行融合等等操作，当然，今天的补充知识，我之后会将其更新回k8sday12---k8sday14
补充一、PV和PVC的动态供给
之前我们在PV和PVC章节所讲的是静态供给策略，用户将需要的资源要求发送给PVC来进行PV的匹配，如果有符合的就绑定，没有就不绑定，如用户要2.88GI，现在有的PV只有3GI且没有和其他的PVC绑定，这个3GI的PV就会和2.88GI的PVC绑定，但是如果这时候又有用户要0.18GI,当前没有和他匹配的PV，就不会进行绑定。
现在所讲的动态供给策略就是对静态供给的一种优化，因为静态补给是我们管理员已经提前创建好了PV，但不一定是用户所需要的，所以可能导致PV和PVC不绑定，即使满足绑定要求，也不一定是最好的，如3GI的PV和2.88GI的PVC绑定。而动态供给是用户提出需求给PVC，PVC和云供应商在集群内的抽象（存储类）沟通，这时候按照请求来"定制"一个PV，使之绑定。
精简总结：++静态PV是管理员提前创建好的，动态PV是等提出需求后按照需求创建的++
StorageClass 是 Kubernetes 用来 "抽象并自动化持久存储供给（Provisioning）" 的一组对象。一句话：告诉集群"我需要什么类型、什么性能、多少副本的存储"，集群就按这个模板自动给你创建 PV。
| 存储类核心功能 | 说明 |
|---|---|
| 动态供给 | PVC（PersistentVolumeClaim）一旦声明 StorageClass，集群会自动创建匹配的 PV，无需管理员手工建 PV。 |
| 参数模板 | 存储类型、IOPS、副本数、加密、磁盘格式等全部写在 StorageClass 里，PVC 只需引用名字。 |
| 回收策略 | 可指定 PV 释放后 Delete / Retain / Recycle 的行为。 |
提供一个简单StorageClass的示例：
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: sc-test # PVC 通过这个名字引用（可自定义）
provisioner: kubernetes.io/aws-ebs # 底层存储驱动
parameters:
type: gp3 # AWS EBS 的 gp3 SSD
iops: "3000"
encrypted: "true"
reclaimPolicy: Delete # PVC 删除后自动回收 EBS常见命令：
bash
# 查看集群有哪些 StorageClass
kubectl get sc
# 查看详情
kubectl describe sc <你的存储类名称>
# 设置默认 StorageClass
kubectl patch sc fast-ssd -p '{"metadata":{"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'| 常见云厂商 | provisioner 示例 |
|---|---|
| AWS | kubernetes.io/aws-ebs |
| GCP | kubernetes.io/gce-pd |
| Azure | kubernetes.io/azure-disk / azurefile |
| 阿里云 | diskplugin.csi.alibabacloud.com |
| 腾讯云 | com.tencent.cloud.csi.cbs |
| 本地 | rancher.io/local-path, openebs.io/local, rook-ceph.rbd.csi.ceph.com ... |
想使用动态供给还需要我们完成k8s集群安全机制的学习，进行授权管理等等，所以现在就不演示
补充二、元数据投影 Volume
Downward API 是 Kubernetes 提供的一种 "自省" 机制：把 Pod / 容器自身的元数据（而不是用户配置）以"文件"或"环境变量"的形式注入到容器内部，方便应用动态获取当前运行上下文，而无需调用 Kubernetes API。
精简总结：++把 Kubernetes 自己知道的 Pod 信息告诉容器------ 不是存储，只是 只读投影。++
Downward API也是注入的策略
Ⅰ、使用（消费）方式
①、作为环境变量（不支持热更新）
bash
apiVersion: v1
kind: Pod
metadata:
name: demo # 定义一个Pod，名字叫demo
spec:
containers:
- name: app
image: busybox:1.36.1 # 镜像版本
command: ["sh","-c","echo Running as $MY_POD_NAME in $MY_NODE"]
# command命令 指容器启动后打印环境变量 MY_POD_NAME 和 MY_NODE 的值
# 将当前Pod 的元数据注入容器
env:
- name: MY_POD_NAME # 容器内已有变量
valueFrom: # 值来源
fieldRef:
fieldPath: metadata.name # 将当前 Pod 的metadata.name 即demo给 MY_POD_NAME 变量
- name: MY_NODE # 容器内已有变量
valueFrom: # 值来源
fieldRef:
fieldPath: spec.nodeName # 将当前Pod 的spec.nodeName 给 MY_POD_NAME 变量②、作为卷挂载（支持热更新）
bash
apiVersion: v1
kind: Pod
metadata:
name: demo
labels:
myname: downwardapitest # 该容器的 labels 标签,将被写入下方生成的 labels 文件
spec:
containers:
- name: app
image: busybox:1.36.1
command: ["sh","-c","cat /etc/podinfo/labels && sleep 3600"]
# 容器启动后，把标签文件打印出来再保持运行
volumeMounts:
- name: podinfo # 要挂载的卷的名称
mountPath: /etc/podinfo # 要挂载到的路径
readOnly: true # 只读
volumes:
- name: podinfo # 定义一个叫 podinfo 卷
downwardAPI: # 卷的类型是 DownwardAPI
items:
- path: "labels" # 在mountPath路径下生成一个labels文件
fieldRef: # 文件内容来源
fieldPath: metadata.labels # 将该容器的 labels 标签全部写入刚刚生成的 labels 文件
- path: "cpu_limit" # 在 mountPath 路径下生成一个 cpu_limit 文件
resourceFieldRef: # 文件内容来源
containerName: app # 指定 containerName 叫 app 的容器
resource: limits.cpu # 将 CPU 的 limit 指写入刚刚生成的 cpu_limit 文件
# 当你对文件进行更新修改后，其对应的文件回进行热更新，同步你的更新完成了今天的补充工作，下周将继续我们调度器，安全机制等等的学习，学了安全机制后，我们会将现在的downward API和动态PV供给进行授权管理以完成完整学习