[RA2 Ch04] Restructuring 4.6 Storage Components

doc/ref_arch/kubernetes/chapters/chapter04.md

@@ -206,10 +206,13 @@ In order for the storage solution(s) to be conformant with the Reference Archite
 
 |Ref|Specification|Details|Requirement Trace|
 |---|---|---|---|
-|`ra2.stg.001`||||
-|`ra2.stg.002`||||
-|`ra2.stg.003`||||
-|`ra2.stg.004`||||
+|`ra2.stg.001`| Ephemeral Storage | An implementation must support ephemeral storage, for the unpacked container images to be stored and executed from, as a directory in the filesystem on the worker node on which the container is running <br>See the [Container runtimes](#4.4) section above for more information how this meets the requirement for ephemeral storage for containers <br>Ephemeral storage exists for the life of a container<br>Kubernetes Volumes attached using a Volume plugin can also be used to deliver Ephemeral Storage (may require additional tasks to ensure dleetion of ephemral storge on teh shutting down of a container) ||
+|`ra2.stg.002`| Kubernetes Volumes | An implementation may attach additional storage to containers using Kubernetes Volumes. This additional storage, that is attached to a container using a Kubernetes Volume, does not live and die with the container but instead follows the lifecycle of the Pod that the container is a part of ||
+|`ra2.stg.003`| Kubernetes Volumes | An implementation may use Volume Plugins (see `ra2.stg.005` below) to allow the use of a storage protocol (e.g. iSCSI, NFS) or management API (e.g. Cinder, EBS) for the attaching and mounting of storage into a Pod ||
+|`ra2.stg.004`| Persisten Volumes | An implemenetation may suppost Kubernetes Persisten Volumes (PV) to provide persistent storage for Pods (requirement 'req.inf.stg.01'<br>Persistent Volumes exist independnet of the lifecycle of containers and/or pods  ||
+|`ra2.stg.005`| Storage Extension | Volume plugins must allow for the use of a range of backend storage systems<br>The implementation may utilise either an In-tree or Out-of-tree type of Volume plugin<br>In-tree plugins are built, linked, compiled and shipped with the core Kubernetes binaries and, thus, require the core KUbernetes code to be changed whenever a new backend storage system needs to be supported<br>Out-of-tree plugins allow new backend storage systems to be supported without any changes to the core Kubernetes code ||
+|`ra2.stg.006`| Container Storage Interface (CSI) | An implementation may support the Container Storage Interface (CSI), an Out-of-tree plugin<br>In order to support CSI, the  feature gates `CSIDriverRegistry` and `CSINodeInfo` must be enabled<br>The implementation must use a CSI driver (a full list of CSI drivers can be found [here](https://kubernetes-csi.github.io/docs/drivers.html)) <br>An implementation may support ephemeral storage  through a CSI-compatible volume plugin in which case the `CSIInlineVolume` feature gate must be enabled<br>An implementation may support Persistent Volumes through a CSI-compatible volume plugin in which case  the `CSIPersistentVolume` feature gate must be enabled  | |
+ |`ra2.stg.007`|  | An implementation should use Kubernetes Storage Classes to support automation and the separation of concerns between providers of a service and consumers of the service<br>Storage Classes allow a consumer of the Kubernetes platform to request Persistent Storage using a Persistent Volume Claim and for a Persistent Volume to be dynamically created based on the "class" that has been requested. This avoids having to grant `create`/`update`/`delete` permissions in RBAC to PersistentVolume resources, which are cluster-scoped rather than namespace-scoped (meaning an identity can manage all PVs or none) | |
 
 <p align="center"><b>Table 4-5:</b> Storage Solution Specifications</p>