New and upcoming Kubernetes Storage Features
Name: John Griffith
PVC (Claim) Request from the user - namespaced
PV - Allocation of storage from SC or backing dev (dynamic or admin created)
SC - Way to map to different types/classes of storage *
The direction forward for storage in K8s
Moves storage plugins out of tree, but keeps things sane by providing well defined interface requirements
Status of GA as of K8s 1.13
Intended for more than just Kubernetes
Everything discussed centers around CSI (ie not back-porting features to Flex)
Just because I talk about them doesn't mean they'll release, or that they'll be as I describe when they do
Use cases and feedback are welcome
1.10 added support for increasing the size of a volume if the volume was not in use
Currently, work is under way to remove the offline limitation. This includes mechanisms to quiesce the file system on the volume
Dynamically increase your mysql volume while pod is running
CSI Plugins are deployed as CRDs, but sometimes that Plugin has node dependencies
One of the things Topology Awareness aims to address is being able to specify which nodes CSI pods are deployed to.
Currently available, continues to improve and targeting GA for 1.14
Typically we use some sort of "shared storage" in our clusters
- iSCSI, NFS, FC etc
But there are use cases where folks need/want performance, and would like to just allocate storage from the nodes local disk
Great for performance, not so great for portability or fail-over
Snapshots are available today (Alpha in 1.12), but continues to grow
Adding additional features like
- consistency handling
apiVersion: snapshot.storage.k8s.io/v1alpha1 kind: VolumeSnapshotContent metadata: name: new-snapshot-content-test spec: snapshotClassName: csi-hostpath-snapclass source: name: pvc-test kind: PersistentVolumeClaim volumeSnapshotSource: csiVolumeSnapshotSource: creationTime: 1535478900692119403 driver: csi-hostpath restoreSize: 10Gi snapshotHandle: 7bdd0de3-aaeb-11e8-9aae-0242ac110002
Volumes defined in the pod-spec
- can choose from persistent and ephemeral
NOT standard PV/PVC model, but instead something handled via the CSI framework and the backend device
Available in the older non csi provisioners, attempting to match parity
apiVersion: v1 kind: Pod metadata: name: testpod spec: containers: ... volumes: - name: vol csi: driver: mock.storage.kubernetes.io volumeAttributes: name: "Mock Volume 1" volumeHandle: "1"
apiVersion: v1 kind: Pod metadata: name: some-pod spec: containers: ... volumes: - name: vol csi: driver: inline.storage.kubernetes.io volumeAttributes: foo: bar
Add the ability to transfer an existing PVC from one Namespace to another
Useful for things like:
Trusted user creating template volumes, then providing them to users in the cluster
Ability to specify a Data Source
Allowing storage to be more "Declarative"
Enables things like create from snapshot then transfer
apiVersion: "populator.k8s.io/v1alpha1" kind: "Populator" metadata: name: "demo-populator" namespace: "default" spec: type: "git" mountpoint: "/git" git: repo: "https://github.com/j-griffith/csi-connectors" branch: "master"
apiVersion: "populator.k8s.io/v1alpha1" kind: "Populator" metadata: name: "https-populator" namespace: "default" spec: type: "https" mountpoint: "/data" https: url: "https://foo.com/my-super-important-data.tar.gz" actions: "tar -xvf"
We have some early stage POC's we can poke around at