管理 Kubernetes 群集中的 Pod 存储

已完成

尽管你打算部署到 Azure Stack HCI 上的 AKS 的大多数应用程序都是无状态的,但 Contoso 开发人员发现了一些他们计划容器化的有状态工作负载。 为了适应这一需求,你需要通过依赖 Kubernetes 永久性卷来探索对暂留正在运行的 Pod 的状态的支持。

为 Azure Stack HCI 上的 AKS 实现永久性卷

默认情况下,单个 Pod 作为无状态资源运行。 如果作为部署一部分的 Pod 由于某种原因失败,Kubernetes 计划程序会自动创建一个提供匹配功能的新 Pod,从而确保容器化应用程序仍然可用。 但是,如果没有用于暂留状态的额外预配,那么失败的 Pod 可能正在处理的任何数据都会丢失。

在某些情况下,Pod 必须能够暂留并共享其数据和状态。 在这种情况下,可以使用永久性卷,这些卷是群集资源,可用于在单个 Pod 的生命周期之外存储容器化工作负载的数据。

若要在 Kubernetes 群集中实现卷,你需要为特定的存储类定义永久性卷声明。 存储类表示基础存储的特征,如性能或对共享访问的支持。 永久性卷声明包含有关所需访问模式和卷大小的信息。 Kubernetes API 服务器使用永久性卷声明定义在部署的 Pod 需要时动态预配合适的存储卷。

备注

Azure Stack HCI 上的 AKS 提供了默认存储类来实现基于 VHDX 的磁盘。

通过在相应的清单文件中包含永久性卷规范,定义已部署的 Pod 的存储要求。 除了触发动态预配外,这还会自动在 Pod 内装载卷。

例如,以下清单为使用默认存储类的 100 GB 非共享磁盘定义了永久性卷声明。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: pvc-akshci
spec:
 accessModes:
 - ReadWriteOnce
 resources:
  requests:
   storage: 100Gi

若要实现此永久性卷声明,可以将此清单存储为 YAML 文件,然后运行 kubectl 命令行实用工具来创建相应的资源(其中 pvc_definition.yaml 表示 YAML 文件):

kubectl create -f pvc_definition.yaml

若要为 Pod 定义相应的永久性卷,可以使用以下清单:

kind: Pod
apiVersion: v1
metadata:
  name: win-appserver
spec:
  containers:
    - name: win-appserver
      image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019 
      volumeMounts:
      - name: akshciscsi
        mountPath: "/mnt/akshciscsi"
  volumes:
    - name: akshciscsi
      persistentVolumeClaim:
        claimName: pvc-akshci
  nodeSelector:
     kubernetes.io/os: windows

若要也实现此永久性卷,可以将 Pod 清单存储为 YAML 文件,然后运行 kubectl 命令行实用工具来预配并装载卷(其中 pv_definition.yaml 表示 YAML 文件):

kubectl create -f pv_definition.yaml

生成的 Pod 将有一个大小为 100 GB 的卷装载在由 mountPath 元素的值指定的文件系统路径中。

若要删除永久性卷声明,则需要首先删除当前正在使用它的所有 Pod 和部署。 此时,若要完成任务,可以使用 kubectl delete PersistentVolumeClaim 命令,后面加上永久性卷声明的名称。

知识检查

1.

由于 Contoso 开发人员正致力于将有状态工作负载容器化,因此你需要使用 Azure Stack HCI 上的 AKS 部署来测试永久性 Pod 存储的实现。 你首先要定义什么?