Containers are everywhere and they are here to stay. They are great level-playing ground to break the infrastructure dependency and allow developers to release their code to any environment.

Containers also help customers to operate at greater scales with ability to quickly scaling up and down, patching with disruptions, withstand infrastructure component failures, moving easily from on-premises to public clouds, etc.

As per the survey from sysdig lifespan of containers and container images is also very short.

At this stage of the popularity of containers there are two thought processes in the container fan club – Persistent or Non-Persistent Containers

If you explore docker hub top downloads you’ll notice that 7/10 top downloads require data persistence (snippet below)

Let’s understand persistent containers in more details.

Prior to Container Storage Integration CSI, Kubernetes provided in-tree (ie as part of the core code) plugins to support volumes but that posed a problem in that storage vendors had to align to the Kubernetes release process to fix a bug or to release new features among other problems. This also means every storage vendor had their own process to present volumes to Kubernetes.

This heterogeneous non-standard integrations were one of the biggest reasons why CSI was created. CSI was developed as a standard for exposing block and file storage storage systems to containerized workloads on Container Orchestration Systems (COs) like Kubernetes. With the adoption of the Container Storage Interface (CSI), the Kubernetes volume layer becomes truly extensible. Using CSI, third-party storage providers like DellEMC can write and deploy plugins exposing new storage systems in Kubernetes without ever having to touch the core Kubernetes code. This gives Kubernetes users more options for storage and makes the system more secure and reliable. Also this approach makes sure that every vendor has standard way of interacting with Kubernetes.

With CSI Kubernetes supports Persistent Volumes (PV). PVs life-cycle independent of any Kubernetes POD. Kubernetes supports 2 ways to provision PVs

• Static – Admin Pre-provisions / creates a number of PVs

• Dynamic – Cluster “automatically” provisions a volume

No matter which is the method of PV provisioning it can support varying properties such as performance, QOS, backup policies, etc. These properties are defined by StorageClass

There are 3 access modes which are supported on PV. Storage volume cannot be mounted simultaneously in more than one access mode.

1. ReadWriteOnce (RWO) – Volume can be mounted as ready-write by a single node
2. ReadOnlyMany (ROX) – Volume can be mounted read-only by many nodes
3. ReadWriteMany (RWX) – Volume can be mounted as read-write by many nodes

Below is the summary of persistence

DellEMC CSI Support

DellEMC understands that that Enterprise applications require persistent storage. As of now (Nov 2019) DellEMC supports CSI plugins for below storage arrays

• DellEMC XtremIO
• DellEMC PowerMax
• DellEMC VxFlex

Below are few documents around DellEMC CSI integration

• DellEMC CSI Solution Brief
• DellEMC CSI Whitepaper

More blogs on CSI coming up 🙂