k8sday15
今天的学习主要是针对上一组学习，也就是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/v1kind: StorageClassmetadata:name: sc-test # PVC 通过这个名字引用（可自定义）provisioner: kubernetes.io/aws-ebs # 底层存储驱动parameters:type: gp3 # AWS EBS 的 gp3 SSDiops: "3000"encrypted: "true"reclaimPolicy: Delete # PVC 删除后自动回收 EBS常见命令：
# 查看集群有哪些 StorageClasskubectl get sc# 查看详情kubectl describe sc <你的存储类名称># 设置默认 StorageClasskubectl 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也是注入的策略
Ⅰ、使用（消费）方式
①、作为环境变量（不支持热更新）
apiVersion: v1kind: Podmetadata:name: demo # 定义一个Pod，名字叫demospec:containers:- name: appimage: 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 变量②、作为卷挂载（支持热更新）
apiVersion: v1kind: Podmetadata:name: demolabels:myname: downwardapitest # 该容器的 labels 标签,将被写入下方生成的 labels 文件spec:containers:- name: appimage: busybox:1.36.1command: ["sh","-c","cat /etc/podinfo/labels && sleep 3600"]# 容器启动后，把标签文件打印出来再保持运行volumeMounts:- name: podinfo # 要挂载的卷的名称mountPath: /etc/podinfo # 要挂载到的路径readOnly: true # 只读volumes:- name: podinfo # 定义一个叫 podinfo 卷downwardAPI: # 卷的类型是 DownwardAPIitems:- 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供给进行授权管理以完成完整学习