Issue 1:
Objective

The purpose of this document is to consolidated the major Kubernetes Volume issues/feature requests, and introduce high-level designs that ensure alignment between all of them.

Background

There are three big designs currently being considered for Kubernetes Volume Storage:

Dynamic Provisioning of Volumes

Design proposal by @markturansky in issue #17056

Volume Attach Detach Controller

Design proposal by @saad-ali in issue #15524

Flex Volume Plugin

Proposed implementation by @NELCY in PR #13840

The solutions to all three can be considered and designed in isolation, however they touch on overlapping issues. Therefore, it makes sense to first agree on an overall design direction for the Kubernetes Volume architecture, before finalizing on the the specifics of each of these.

Goals

Introduce Dynamic Provisioning

Introduce ability for cluster to automatically (dynamically) create (provision) volumes instead of relying on a cluster admin to manually create them ahead of time.

Update (Jul 1, 2016): Introduced in v1.2 (#14537) as alpha. Being fully flushed out in v1.4 (#26908).

Make Attach/Detach Robust

Make volume attachment and detachment independent of individual node availability.

Update (Jul 1, 2016): Introduced in v1.3 (#26351).

Improve Plugin Model

Establish a plugin model that allows new storage plugins to be written without recompiling Kubernetes code.

Update (Jul 1, 2016): discussion is ongoing.

Enable Modularity and Improve Deployment

Make it easy for cluster admins to select which volume types they want to support, and easily configure/deploy the plugin(s) across the cluster.

Volume Selector

Enable users to select specific storage based on some implementation specific characteristics (specific rack, etc.).

Update (Jul 1, 2016): Introduced in v1.3 #25917.

Volume Classes

Create an abstraction layer (classes) for Kubernetes volumes users so they can request different grades of storage without worrying about the specifics of any one storage implementation.

Update (Jul 1, 2016): Being fully flushed out as part of dynamic provisioning design in v1.4 (#26908).

Proposal 1: Single Controller

Replace the existing persistent volume controllers that do binding (volumes to claims) and recycling (wiping volumes for reuse), with one controller that does provisioning (creating new volumes), binding, and recycling. This controller could monitor PersistentVolume and PersistentVolumeClaim objects via the API server to determine when a new volume needs to be created.

Another new controller would be responsible for attaching and detaching volumes by monitoring PersistentVolume and Pod objects to determine when to attach/detach a volume from the node.

For a seamless transition, in the immediate term, the existing volume plugin model could be used largely as is (although some refactoring would be needed). To implement a storage plugin a third party would need to provide methods to create/delete/attach/detach and optionally mount/unmount a volume. The new controllers and kubelet would call out to these methods as needed.

The Flex Volume plugin (which adds support for exec based plugins), would be a first step towards enabling creators of third party storage plugin to add support for new volume types without having to add code to Kubernetes. The problem with the Flex plugin is that it doesn’t provide a good deployment mechanism. In order to support a new volume plugin, an admin needs to drop scripts into the correct directories on each node. However, once all the volume controllers move to the master, the exec scripts would only need to be dropped on to the master (not the nodes, since the flex plugin currently doesn’t support custom mount/unmount logic).

Longer term all third party plugin code would be containerized and removed from the Kubernetes code base. The controllers on master could “docker run” the plugin container with the correct parameters to create/delete/attach/detach volumes. In order to support fully custom mount/unmount logic, the containerized plugin could contain mount/unmount code that Kubelet could similarly “docker run” (this will have to wait until Docker makes the changes needed to allow an executable running inside a container to mount to the host).

The controllers and kubelet will need need to know which plugin container corresponds to which volume plugin and the other plugin specific configuration information. This will require the cluster to maintain a one to one mapping of volume-type strings to a plugin container path + any cluster wide plugin configuration for that plugin (e.g. GCE maps to {container: “k8s-volume-plugin-gce”, maxVolumesToProvision: 20, … }). This mapping must be available to both the controllers and kubelet (it could be stored in config data or a new API object).

When a cluster administrator wants to add support for a new volume-type they would simply add a new key-value pair to this mapping.

Pros:

More concrete contract between Kubernetes and volume plugins.

Easier to implement volume plugins

Plugin writers just have to provide implementations for methods like create, attach, detach, etc. and NOT controller logic which is more complicated.

All plugins benefit from fixes/improvements to common controllers.

More performant to run a single controller vs n controllers.

Smaller incremental steps required to get to proposal’s end state.

Cons:

Kubernetes core still responsible for maintaining a lot of volume logic.

Less flexibility for individual plugins (i.e will the API be sufficient for all possible volume plugins?).

Proposal 2: Multiple Controllers

Alternatively, instead of a set of Kubernetes provided controllers, the entire controller implementation could be left up to individual plugins. So each plugin would have a controller that would monitor the API Server for PV, PVC, and Pod objects, and when it finds a PVC that it can fulfill, it will claim it, bind it, and be responsible for it through attachment, detachment, all the way to recycling.

Similar to the other proposal, plugins should be containerized. But instead of the container containing a binary that is triggered for specific tasks (attach, provision, etc.), it would contain the entire controller and run for the life of the cluster (or until the volume type is no longer needed) maybe via a replication controller (to ensure availability). Fully custom mount/unmount logic could be supported similar to the other proposal: by containerizing the mount/unmount code and having Kubelet execute it via a “docker run” (requires Docker support).

Pros:

More flexibility for plugin writers.

Authors can decide how to implement pretty much everything.

Less Kubernetes exposure.

Since the plugin configuration can be passed directly to the controller rather than through kubernetes, that’s one less thing that must be added to config data or a new API object.

Slightly simpler installation

Support for a plugin can be added simply by running the plugin container. (Although the other proposal is not much more complicated.)

Aligns with Kubernetes Networking plugin design

Cons:

Would lead to code duplication.

Most controllers will likely be implementing very similar logic for the controller portion, leading to code duplication/proliferation of bugs.

Could be worked around by creating a library that plugin writers could use for standard implementations.

Less performant.

Having to run a controller for each plugin adds overhead, especially for small clusters.

Comparison

Dynamic Provisioning and Attach/Detach Controller

Differs for each proposal: Single controller vs multiple controller. See proposals above for details.

Improve Plugin Model

Differs for each proposal. See proposals above for details.

Enable Modularity and Improve Deployment

Once all plugins are containerized as both plans propose, we should get the kind of plugin modularity we’re hoping for.

To deploy a new volume-type the cluster administrator would have to:

Installing plugin client binaries on each node.

Short term: the admin must manually copy these files.

Long term: these should be containerized and deployed as deamonset pods.

Configure volume classes (optional)--see below for details.

Short term: Config data created and maintained by admin.

Long term: Kubectl command for adding and removing classes that does this automatically.

In addition, only for proposal 1, the cluster admin would have to:

Add an entry to the key-value list keeping track of supported plugins to plugin container path/plugin config.

Short term: Config data manually updated by admin.

Long term: Kubectl command for adding and removing supported plugins (i.e. admin specifies a volume-type and config, and Kubectl automatically adds it to Config Data).

And, for proposal 2, the cluster admin would have to:

Start the controller container (maybe as a replication controller) with the correct parameters (plugin config) so that it can start watching for PVCs, etc.

Volume Selector

Volume selection support can be added the same way regardless of which proposal is implemented. Add “Labels” to the PersistentVolume object and “Selectors” to the PersistentVolumeClaim object. The binding controller(s) must resolve labels as it tries to fulfill PVCs.

Volume Classes

Volume Classes are a way to create an abstraction layer over Kubernetes volumes so that users can request different grades of storage (classes) without worrying about the specifics of any one storage implementation.

Implementation of classes can not be pushed into the plugin, because if individual plugins define the classes they support, then the whole point of the abstraction is lost. Instead, the cluster administrator must define the set of classes the cluster should support and the mapping of classes to the “knobs” exposed by individual plugins. More concretely, this means, for both proposals, that the cluster must maintain a mapping of admin-defined class strings to a list of parameters for each plugin that fulfills that class (e.g. “Gold” maps to “GCE plugin with parameter SSD” and “NFS with parameter XYZ”). This mapping must be maintained outside of the plugin (maybe in config data or a new API object).

Weather the blob is a simple string, a list of key-value pairs, or structured JSON is up for debate. It can be argued that a simple string or key-value pair list may not be sufficient to express some more complicated configuration options possible for some plugins. If that is the case, the map could maintain a structured JSON blob that the plugin would be responsible for parsing. For convenience, plugin writer could provide a “JSON blob creation tool” to make it easier for cluster admins to generate the blob.

CC @thockin @kubernetes/goog-cluster @kubernetes/rh-storage

We'll use this document to drive the discussion at the Storage Special Interest Group meeting on Dec. 8, 2015 11 AM PST.

Issue 2:
At github page https://github.com/kubernetes/kubernetes/blob/master/docs/getting-started-guides/ubuntu.md

Mentioned one page: http://kubernetes.github.io/docs/getting-started-guides/ubuntu/

The above link was not found (see attached screenshot)