WIP: Persistent disks proposal

This is a draft proposal for expanding GCEPersistentDisk to a fuller PersistentDisk framework.



> On Dec 19, 2014, at 10:40 AM, Mark Turansky <notifications@github.com> wrote:
> 
> In docs/design/persistentdisks.md:
> 
> > +## Disk performance attributes -- Requesting a disk 
> > +
> > +Pod authors can request storage by its characteristics, specifically size, performance, and filesystem.  Kubernetes maps the request to the underlying cloud provider and chooses the best match.
> > +
> > +> Example: Alice requests 1gb of space for a WordPress installation expected to have low traffic.  She requests "1gb, ext4, 100 IOPS".   Kubernetes is running in AWS and matches this request to an EBS Magnetic Volume (max oops 40-200).  K8s uses the AWS API to create the disk, attach it to the host, format the filesystem, mount the volume, and then deploys Alice's pod.
> > +
> > +> Example:  Ralph requests 10gb of high performance disk space for a MySQL database.  He requests "10gb, xfs, 10000 IOPS".  Cabernets is running in GCE and matches this request to a 
> > +SSD Persistent Disk (read/write 10k/15k IOPS, respectively).  K8s uses the GCE API to create Ralph's disk, just as it did in Alice's example above.
> > +
> > +    
> > +## DiskController
> > +
> > +Add a new daemon to master that watches for changes to PersistentDisk in etcd.
> > +
> > +New disk requests are posted to the API server and are stored in etcd with "pending" status.  The DiskController sees the
> > +change and creates the disk using the cloud provider under which Kubernetes is running (i.e, AWS and GCE). Each provider knows how to make disks for its infrastructure.
> The "cluster" scripts and the "cloudprovider" package work in tandem to provide an "environment".
> 
> Shouldn't an administrator be able to define their own environment, including storage?
> 
That's not really a fundamental property of the system.  The system can be driven by a cloud provider, but the core system does not need to know about cloud providers.  So storage is above the core system, not below.
> I am imagining a Spring application where dependencies and their various implementations are injected. The application can be configured to run in any environment and the code doesn't know any differently because of strong interfaces.
> 
> Wouldn't all of the capabilities be baked into K8s (cloud apis, nfs support, ceph, whatever) and then it's configuration details that define how K8s is running?
> 
Not really - Kube is a core system that other systems are built on top of.  That includes storage because there is not a 1:1 between a cluster and storage.
> —
> Reply to this email directly or view it on GitHub.
>