This document introduces the emptyDirClone
Container Storage Interface (CSI) plugin, aiming to simulate the behavior of a Kubernetes emptyDir
for educational purposes.
CSI was developed as a standard for exposing arbitrary block and file storage storage systems to containerized workloads on Container Orchestration Systems (COs) like Kubernetes. With the adoption of the Container Storage Interface, the Kubernetes volume layer becomes truly extensible. The advantage of using CSI is that external storage providers can create and deploy plugins to introduce new storage systems in Kubernetes without having to modify the core Kubernetes code directly.
For more information, you can refer to the resources provided in the Required Reading and Optional Reading sections. The CSI specification itself is included in the Optional Reading section. Keep in mind that this guide is designed to be beginner-friendly and serve as a quick start for CSI plugins. The additional tutorials and resources listed in the Required Reading section are considered sufficient for understanding the topic.
We will call the plugin emptyDirClone
.
See the instructions for running locally.
Understanding emptyDir
Volumes
emptyDir
volumes are temporary directories exposed to the pod. These do not persist beyond the lifetime of a pod. This is implemented by Kubernetes itself(as opposed to a separate plugin).
apiVersion: v1
kind: Pod
metadata:
name: test-pd
spec:
containers:
- image: registry.k8s.io/test-webserver
name: test-container
volumeMounts:
- mountPath: /cache
name: cache-volume
volumes:
- name: cache-volume
emptyDir:
sizeLimit: 500Mi
- Provide a temporary directory
- Provide
ReadWriteOnce
capability. See Access Modes - Support ephemeral inline volume requests
- It should have a invocation similar to the following
kind: Pod apiVersion: v1 metadata: name: my-csi-app spec: containers: - name: my-frontend image: busybox:1.28 volumeMounts: - mountPath: "/data" # Mount path for the volume name: my-csi-inline-vol command: [ "sleep", "1000000" ] volumes: - name: my-csi-inline-vol csi: driver: inline.storage.kubernetes.io # Name of the CSI driver volumeAttributes: foo: bar # Attributes passed to the driver to configure the volume
-
Implement the CSI
Identity
service.service Identity { rpc GetPluginInfo(GetPluginInfoRequest) returns (GetPluginInfoResponse) {} rpc GetPluginCapabilities(GetPluginCapabilitiesRequest) returns (GetPluginCapabilitiesResponse) {} rpc Probe (ProbeRequest) returns (ProbeResponse) {} }
-
Implement the CSI
Node
service. For ephemeral inline volume request, we only need theNodePublishVolume
(read mount volume),NodeUnpublishVolume
(read unmount volume)stateDiagram-v2 direction TB [*] --> Published: NodePublishVolume Published --> Unpublished: NodeUnpublishVolume Unpublished--> [*]
service Node { rpc NodeStageVolume (NodeStageVolumeRequest) returns (NodeStageVolumeResponse) {} rpc NodeUnstageVolume (NodeUnstageVolumeRequest) returns (NodeUnstageVolumeResponse) {} rpc NodePublishVolume (NodePublishVolumeRequest) returns (NodePublishVolumeResponse) {} rpc NodeUnpublishVolume (NodeUnpublishVolumeRequest) returns (NodeUnpublishVolumeResponse) {} rpc NodeGetVolumeStats (NodeGetVolumeStatsRequest) returns (NodeGetVolumeStatsResponse) {} rpc NodeExpandVolume(NodeExpandVolumeRequest) returns (NodeExpandVolumeResponse) {} rpc NodeGetCapabilities (NodeGetCapabilitiesRequest) returns (NodeGetCapabilitiesResponse) {} rpc NodeGetInfo (NodeGetInfoRequest) returns (NodeGetInfoResponse) {} }
- Volumes
- Configure a Pod to Use a Volume for Storage
- Volumes
- Tutorial blog post - How to write a Container Storage Interface (CSI) plugin
- Kubernetes Container Storage Interface (CSI) Documentation
- Recommended Mechanism for Deploying CSI Drivers on Kubernetes
- Example implementation - csi-driver-host-path
- Local Testing tool -
csc