0.CDI用途

CDI是什么？¶

CDI是Containerized Data Importer的缩写，即容器化数据导入器。

CDI是k8s的一个持久化存储管理插件，它的主要目的是提供一种声明式的方式来为Kubevirt虚拟机在PVC上构建虚拟机磁盘。 CDI与标准核心的k8s资源一起工作，并且与存储设备无关。

虽然CDI主要是为Kubevirt构建磁盘镜像，但它在Kubevirt之外也很有用，比如，可以用于数据初始化k8s卷，即通过CDI预先往PVC中导入数据，然后被pod挂载使用。 CDI支持导入的磁盘镜像格式包括：qcow2, VMDK, VDI, VHD, VHDX, raw XZ-compressed, gzip-compressed,未压缩的raw格式文件。所有这些上传后都会转换成raw格式。

CDI用途¶

CDI主要用途是为Kubevirt构建磁盘镜像。

CDI提供了用VM镜像(qcow、raw、iso)或其他数据填充pvc的能力。数据源可以是:一个URL(minio)、容器镜像仓库(harbor)、另一个PVC(克隆)或来自客户端(virtctl)的上传。

官方描述的源可以是：http, https, 使用basic-auth的http, docker registry, S3 buckets, GCS Buckets, 客户端上传upload。在Kubevirt上下文之外，CDI也可以用于初始化带有数据的k8s卷。

CDI安装¶

kubectl create -f https://github.com/kubevirt/containerized-data-importer/releases/download/$VERSION/cdi-operator.yaml
kubectl create -f https://github.com/kubevirt/containerized-data-importer/releases/download/$VERSION/cdi-cr.yaml

DataVolumes(DV)¶

CDI包括一个CustomResourceDefinition (CRD)，它提供了一个datvolume类型的对象。 datvolume是在k8s PVC之上的一种抽象，可用于自动创建PVC并在PVC中填充数据。虽然可以直接将PVC与CDI一起使用，但DataVolumes是首选的方法，因为它们提供了完整的功能、稳定的API以及与kubevirt更好的集成。

使用DataVolumes填充PVC，数据源有4种：

从一个URL中导入¶

参考官档示例

# 这里的示例改成了使用ceph rgw 对象存储，使用s3协议
---
apiVersion: v1
kind: Secret
metadata:
  name: endpoint-rgw-secret
  labels:
    app: containerized-data-importer
type: Opaque
# 使用ceph s3 不需要进行base64编码转换，所以使用 stringData，与官方示例差异
stringData:
  accessKeyId: "J694KWR3JL1HWXIPM270"
  secretKey:    "pDWKVYxpAiHYZAGw97xD6gxTVrAudNr7DLveO5p6"
---
# This example assumes you are using a default storage class
apiVersion: cdi.kubevirt.io/v1beta1
kind: DataVolume
metadata:
  name: my-data-volume
  annotations:
    # 这个注解是调试用，表示在dv填充好pvc之后，仍然保留传输的pod，参考debug.md
    cdi.kubevirt.io/storage.pod.retainAfterCompletion: "true"
spec:
  source:
    s3:
      url: "http://rgw.testgw/images/cirros-0.5.1-x86_64-disk.img"
      secretRef: endpoint-rgw-secret
  pvc:
    storageClassName: "ceph-hdd-block"
    volumeMode: Block
    accessModes:
      - ReadWriteMany
    resources:
      requests:
        storage: 500Mi
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: cirros-vm01
  namespace: default
spec:
  storageClassName: "ceph-hdd-block"
  volumeMode: Block
  accessModes:
    - ReadWriteMany
  dataSource:
    kind: PersistentVolumeClaim
    name: my-data-volume
  resources:
    requests:
      storage: 1Gi
---
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: cirros-vm01
  namespace: default
spec:
  running: true
  template:
    metadata:
      labels:
        kubevirt.io/size: small
        kubevirt.io/domain: cirros-vm01
      #annotations:
      #  ovn.kubernetes.io/ip_address: 10.244.10.203
    spec:
      domain:
        cpu:
          cores: 1
          model: host-passthrough
        memory:
          guest: 1Gi
        devices:
          disks:
            - name: root-disk
              disk:
                bus: virtio
          interfaces:
            - name: default
              masquerade: {}
        resources:
          requests:
            memory: 1024M
      networks:
        - name: default
          pod: {}
      volumes:
        - name: root-disk
          persistentVolumeClaim:
            claimName: cirros-vm01

说明：此处示例使用ceph对象网关，先创建桶images，并将测试用到的镜像文件cirros-0.5.1-x86_64-disk.img上传到桶中

# s3cmd mb s3://images
# s3cmd put ./cirros-0.5.1-x86_64-disk.img s3://images
# s3cmd ls s3://images
2023-10-14 09:01     12716032  s3://images/cirros-0.5.1-x86_64-disk.img

如果源不是s3或者说URL不需要认证，则dv填充pvc的yaml示例如下：

apiVersion: cdi.kubevirt.io/v1beta1
kind: DataVolume
metadata:
  name: my-data-volume
spec:
  source:
    http:
      url: "http://dl.demo.com:10080/images/cirros-0.5.1-x86_64-disk.img"
  pvc:
    storageClassName: "ceph-hdd-block"
    accessModes:
      - ReadWriteMany
    resources:
      requests:
        storage: 500Mi
    volumeMode: Block

从容器镜像仓库导入，如从harbor镜像仓库将一个包含vm镜像的容器镜像填充到PVC中。¶

示例

从另一个PVC克隆，详细会在后面DataVolume克隆中介绍¶

示例

apiVersion: cdi.kubevirt.io/v1beta1
kind: DataVolume
metadata:
  name: dv-cirros
  namespace: default
spec:
  source:
    pvc:
      namespace: default
      name: img-cirros
  pvc:
    storageClassName: "ceph-hdd-block"
    accessModes:
      - ReadWriteMany
    resources:
      requests:
        storage: 2Gi
    volumeMode: Block

从客户端(virtctl)上传，不同版本的客户端，命令会有差异。¶

示例1，创建DV方式，上传后PVC的access_modes为ReadWriteMany，volume_mode为block
## DV
virtctl image-upload dv dv-image-cirros01 \
--size 2Gi \
--insecure \
--uploadproxy-url=https://12.107.65.150 \
--image-path=./cirros-0.5.1-x86_64-disk.img
示例2，创建PVC方式（不会创建DV），上传时要指定--volume-mode=block和access-mode=ReadWriteMany，否则--volume-mode=Filesystem --access-mode=ReadWriteOnce，即RWO
## pvc
virtctl image-upload pvc pvc-image-cirros01 \
--size 2Gi \
--access-mode=ReadWriteMany \
--volume-mode=block \
--insecure \
--uploadproxy-url=https://12.107.65.150  \
--image-path=./cirros-0.5.1-x86_64-disk.img
说明：CDI在v1.55之前，dv始终与其创建的pvc有映射关系，但到CDI v1.55，即使创建dv，在pvc创建成功后，dv会被当做垃圾回收掉，这是正常的行为。 DataVolumes 在完成后不再有任何用途，因为它们本质上是一种用于填充 PVC 的机制。PVC才是虚拟机实际使用的issue

DataVolume垃圾回收的确是一个有用的功能，它能够在DataVolume完成数据导入任务后自动删除相关资源。然而，这个特性违反了k8s的一个基本原则：除非明确被删除，否则自定义资源（CR，如DataVolume）在完成其角色后不应被自动删除。Job资源的TTLSecondsAfterFinished字段是个例外，因为它允许Job在完成后一定时间后自动清理。

当垃圾回收功能启用时，某些依赖于CR持久性的系统（比如GitOps工具ArangoCD）将受到影响参考issue ，所以dv被垃圾回收的功能在v1.57 后默认又被禁用了，同时增加了cdi.spec.config.dataVolumeTTLSeconds，该参数未设置时，值为-1表示禁用。如果设置dataVolumeTTLSeconds: 300表示dv创建成功后，再等5分钟，dv将被垃圾回收。设置该参数其实是在DV上添加一个注解：cdi.kubevirt.io/storage.deleteAfterCompletion: "true"，允许dv被删除，我们可以将该值改成false，让某些DV不被删除。

CDI最近还新增了一个featureGates，DataVolumeClaimAdoption，该featureGate的作用是说，在许多灾难恢复（DR）和备份场景中，可能先存在Persistent Volume Claim (PVC)，然后才创建DataVolume。通常情况下，在创建DataVolume时会由于该PVC已存在而导致错误。此PR提供两种新的机制来避免这种错误，并允许DataVolume控制器“采纳”已存在的PVC。所谓采纳PVC意味着DataVolume会立即进入Succeeded状态，并且不会尝试向PVC写入任何数据。

cdi.kubevirt.io/allowClaimAdoption: "true"