- Manifest ManagementManifest Management
- Application Update LifecycleApplication Update Lifecycle
- Volume ManagementVolume Management
- Dynamic ParametersDynamic Parameters
- Kubernetes Cluster SupportKubernetes Cluster Support
- Kubernetes RBACKubernetes RBAC
- Network & Traffic managementNetwork & Traffic management
- Kubernetes AutoscalingKubernetes Autoscaling
- Associating Pods To NodesAssociating Pods To Nodes
- Integration with VM (Legacy) ServicesIntegration with VM (Legacy) Services
Volume Management
Pain Point
Kubernetes has the concept of volumes (storage) to work with persistent data. A volume can be backed by a variety of implementations, including AWS Elastic Block Store (EBS), Azure Disk, GCE Persistent Disk, etc.
Configuring volumes in Kubernetes is a complex process, placing the burden on the developer. It requires configuring storage class, persistent volume claims, and persistent volumes for each Docker container. Binding persistent volume with claims depends on the size specified and storage class in each.
Every public cloud provider has its own persistent storage structure and types requiring the developer to learn about each provider’s persistent storage. Each Docker container can be configured with multiple persistent volumes. As the number of containers increases, it becomes difficult and time consuming to manage the large number of volumes. If a developer misconfigures a persistent volume claim, persistent volume or storage class, the volume will not attach with the container and the container will remain in this pending state.
The following are examples of YAML config files for manually configuring one SSD volume in GCP for a single Docker container.
storage-class.yaml
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: faster provisioner: kubernetes.io/gce-pd //cloudprovider dependent configurations parameters: type: pd-ssd //cloudprovider dependent configurations
persistent-volume-claim.yaml
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: pv-claim-demo spec: storageClassName: "faster" volumeName: pv-demo accessModes: - ReadWriteOnce resources: requests: storage: 50G
persistent-volume.yaml
apiVersion: v1 kind: PersistentVolume metadata: name: pv-demo spec: storageClassName: "faster" capacity: storage: 50G accessModes: - ReadWriteOnce
microservice-pod.yaml
ports: - containerPort: 80 name: "http-server" volumeMounts: - mountPath: "/usr/share/nginx/html" name: task-pv-storage ... volumes: - name: task-pv-storage persistentVolumeClaim: claimName: pv-claim-demo
How CloudPlex addresses your pain
CloudPlex automatically configures storage class, persistent volume, persistent volume claim, and their associations. Users simply provide basic information about the size of the volume and the identity of the container with which to associate. CloudPlex provides a uniform interface for all public clouds. The screenshot below shows visual configuration of storage where the developer provides the size of the storage and identity of the Docker container.

