From 0988c8980ce8e0d5cd9c42c881606d66575bdbc7 Mon Sep 17 00:00:00 2001
From: Pankaj Goyal <52107136+pgoyal01@users.noreply.github.com>
Date: Thu, 6 Aug 2020 13:07:03 -0600
Subject: [PATCH 01/13] [RA2 Ch04] Restructuring 4.6 Storage Components
Restored existing content in new format: Fixes #1638
Observation: there are no requirements for ephemeral and persistent storage
---
doc/ref_arch/kubernetes/chapters/chapter04.md | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/doc/ref_arch/kubernetes/chapters/chapter04.md b/doc/ref_arch/kubernetes/chapters/chapter04.md
index 66599c07ce..267ae393d7 100644
--- a/doc/ref_arch/kubernetes/chapters/chapter04.md
+++ b/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
See the [Container runtimes](#4.4) section above for more information how this meets the requirement for ephemeral storage for containers
Ephemeral storage exists for the life of a container
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'
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
The implementation may utilise either an In-tree or Out-of-tree type of Volume plugin
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
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
In order to support CSI, the feature gates `CSIDriverRegistry` and `CSINodeInfo` must be enabled
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))
An implementation may support ephemeral storage through a CSI-compatible volume plugin in which case the `CSIInlineVolume` feature gate must be enabled
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
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) | |
Table 4-5: Storage Solution Specifications
From 746260b4d8e2f5958629efed0174479a981ca11d Mon Sep 17 00:00:00 2001
From: Pankaj Goyal <52107136+pgoyal01@users.noreply.github.com>
Date: Fri, 7 Aug 2020 07:16:28 -0600
Subject: [PATCH 02/13] Update doc/ref_arch/kubernetes/chapters/chapter04.md
Co-authored-by: Gergely Csatari
---
doc/ref_arch/kubernetes/chapters/chapter04.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/ref_arch/kubernetes/chapters/chapter04.md b/doc/ref_arch/kubernetes/chapters/chapter04.md
index 267ae393d7..fdab710423 100644
--- a/doc/ref_arch/kubernetes/chapters/chapter04.md
+++ b/doc/ref_arch/kubernetes/chapters/chapter04.md
@@ -209,7 +209,7 @@ In order for the storage solution(s) to be conformant with the Reference Archite
|`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
See the [Container runtimes](#4.4) section above for more information how this meets the requirement for ephemeral storage for containers
Ephemeral storage exists for the life of a container
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'
Persistent Volumes exist independnet of the lifecycle of containers and/or pods ||
+|`ra2.stg.004`| Persisten Volumes | An implemenetation may support Kubernetes Persistent Volumes (PV) to provide persistent storage for Pods (requirement 'req.inf.stg.01'
Persistent Volumes exist independent 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
The implementation may utilise either an In-tree or Out-of-tree type of Volume plugin
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
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
In order to support CSI, the feature gates `CSIDriverRegistry` and `CSINodeInfo` must be enabled
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))
An implementation may support ephemeral storage through a CSI-compatible volume plugin in which case the `CSIInlineVolume` feature gate must be enabled
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
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) | |
From d5edba0cdaa0d21c280be70cbabed45a3b58659b Mon Sep 17 00:00:00 2001
From: Pankaj Goyal <52107136+pgoyal01@users.noreply.github.com>
Date: Fri, 7 Aug 2020 07:17:13 -0600
Subject: [PATCH 03/13] Update doc/ref_arch/kubernetes/chapters/chapter04.md
Co-authored-by: Gergely Csatari
---
doc/ref_arch/kubernetes/chapters/chapter04.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/ref_arch/kubernetes/chapters/chapter04.md b/doc/ref_arch/kubernetes/chapters/chapter04.md
index fdab710423..dcb44ffe6c 100644
--- a/doc/ref_arch/kubernetes/chapters/chapter04.md
+++ b/doc/ref_arch/kubernetes/chapters/chapter04.md
@@ -206,7 +206,7 @@ In order for the storage solution(s) to be conformant with the Reference Archite
|Ref|Specification|Details|Requirement Trace|
|---|---|---|---|
-|`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
See the [Container runtimes](#4.4) section above for more information how this meets the requirement for ephemeral storage for containers
Ephemeral storage exists for the life of a container
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.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
See the [Container runtimes](#4.4) section above for more information how this meets the requirement for ephemeral storage for containers
Ephemeral storage exists for the life of a container
Kubernetes Volumes attached using a Volume plugin can also be used to deliver Ephemeral Storage (may require additional tasks to ensure deletion of ephemeral storage on the 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 support Kubernetes Persistent Volumes (PV) to provide persistent storage for Pods (requirement 'req.inf.stg.01'
Persistent Volumes exist independent of the lifecycle of containers and/or pods ||
From 9bdd20891400f9c168efe92aed3589423a89d0d4 Mon Sep 17 00:00:00 2001
From: Pankaj Goyal <52107136+pgoyal01@users.noreply.github.com>
Date: Fri, 7 Aug 2020 07:18:27 -0600
Subject: [PATCH 04/13] Update doc/ref_arch/kubernetes/chapters/chapter04.md
---
doc/ref_arch/kubernetes/chapters/chapter04.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/ref_arch/kubernetes/chapters/chapter04.md b/doc/ref_arch/kubernetes/chapters/chapter04.md
index dcb44ffe6c..ef3d56192c 100644
--- a/doc/ref_arch/kubernetes/chapters/chapter04.md
+++ b/doc/ref_arch/kubernetes/chapters/chapter04.md
@@ -206,7 +206,7 @@ In order for the storage solution(s) to be conformant with the Reference Archite
|Ref|Specification|Details|Requirement Trace|
|---|---|---|---|
-|`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
See the [Container runtimes](#4.4) section above for more information how this meets the requirement for ephemeral storage for containers
Ephemeral storage exists for the life of a container
Kubernetes Volumes attached using a Volume plugin can also be used to deliver Ephemeral Storage (may require additional tasks to ensure deletion of ephemeral storage on the shutting down of a container) ||
+|`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
See the [Container runtimes](#4.4) section above for more information on how this meets the requirement for ephemeral storage for containers
Ephemeral storage exists for the life of a container
Kubernetes Volumes attached using a Volume plugin can also be used to deliver Ephemeral Storage (may require additional tasks to ensure deletion of ephemeral storage on the 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 support Kubernetes Persistent Volumes (PV) to provide persistent storage for Pods (requirement 'req.inf.stg.01'
Persistent Volumes exist independent of the lifecycle of containers and/or pods ||
From 3b796d78adc532b6c77268774255a6a3b41f39f9 Mon Sep 17 00:00:00 2001
From: Pankaj Goyal <52107136+pgoyal01@users.noreply.github.com>
Date: Mon, 10 Aug 2020 11:00:53 -0600
Subject: [PATCH 05/13] Update doc/ref_arch/kubernetes/chapters/chapter04.md
Co-authored-by: Tom Kivlin <52716470+tomkivlin@users.noreply.github.com>
---
doc/ref_arch/kubernetes/chapters/chapter04.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/ref_arch/kubernetes/chapters/chapter04.md b/doc/ref_arch/kubernetes/chapters/chapter04.md
index ef3d56192c..ce511d8139 100644
--- a/doc/ref_arch/kubernetes/chapters/chapter04.md
+++ b/doc/ref_arch/kubernetes/chapters/chapter04.md
@@ -206,7 +206,7 @@ In order for the storage solution(s) to be conformant with the Reference Archite
|Ref|Specification|Details|Requirement Trace|
|---|---|---|---|
-|`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
See the [Container runtimes](#4.4) section above for more information on how this meets the requirement for ephemeral storage for containers
Ephemeral storage exists for the life of a container
Kubernetes Volumes attached using a Volume plugin can also be used to deliver Ephemeral Storage (may require additional tasks to ensure deletion of ephemeral storage on the shutting down of a container) ||
+|`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.
See the [Container runtimes](#4.4) section above for more information on how this meets the requirement for ephemeral storage for containers.
Ephemeral storage exists for the life of a container.
Kubernetes Volumes attached using a Volume plugin can also be used to deliver Ephemeral Storage (may require additional tasks to ensure deletion of ephemeral storage on the 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 support Kubernetes Persistent Volumes (PV) to provide persistent storage for Pods (requirement 'req.inf.stg.01'
Persistent Volumes exist independent of the lifecycle of containers and/or pods ||
From f23847de73f45ab22ffe96931c95af6821a6a876 Mon Sep 17 00:00:00 2001
From: Pankaj Goyal <52107136+pgoyal01@users.noreply.github.com>
Date: Mon, 10 Aug 2020 11:01:23 -0600
Subject: [PATCH 06/13] Update doc/ref_arch/kubernetes/chapters/chapter04.md
Co-authored-by: Tom Kivlin <52716470+tomkivlin@users.noreply.github.com>
---
doc/ref_arch/kubernetes/chapters/chapter04.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/ref_arch/kubernetes/chapters/chapter04.md b/doc/ref_arch/kubernetes/chapters/chapter04.md
index ce511d8139..c10fb511ea 100644
--- a/doc/ref_arch/kubernetes/chapters/chapter04.md
+++ b/doc/ref_arch/kubernetes/chapters/chapter04.md
@@ -208,7 +208,7 @@ In order for the storage solution(s) to be conformant with the Reference Archite
|---|---|---|---|
|`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.
See the [Container runtimes](#4.4) section above for more information on how this meets the requirement for ephemeral storage for containers.
Ephemeral storage exists for the life of a container.
Kubernetes Volumes attached using a Volume plugin can also be used to deliver Ephemeral Storage (may require additional tasks to ensure deletion of ephemeral storage on the 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.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 support Kubernetes Persistent Volumes (PV) to provide persistent storage for Pods (requirement 'req.inf.stg.01'
Persistent Volumes exist independent 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
The implementation may utilise either an In-tree or Out-of-tree type of Volume plugin
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
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
In order to support CSI, the feature gates `CSIDriverRegistry` and `CSINodeInfo` must be enabled
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))
An implementation may support ephemeral storage through a CSI-compatible volume plugin in which case the `CSIInlineVolume` feature gate must be enabled
An implementation may support Persistent Volumes through a CSI-compatible volume plugin in which case the `CSIPersistentVolume` feature gate must be enabled | |
From ef7eb7176604c0e69afa0f721ab0d9b336a1c1bd Mon Sep 17 00:00:00 2001
From: Pankaj Goyal <52107136+pgoyal01@users.noreply.github.com>
Date: Mon, 10 Aug 2020 11:01:45 -0600
Subject: [PATCH 07/13] Update doc/ref_arch/kubernetes/chapters/chapter04.md
Co-authored-by: Tom Kivlin <52716470+tomkivlin@users.noreply.github.com>
---
doc/ref_arch/kubernetes/chapters/chapter04.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/ref_arch/kubernetes/chapters/chapter04.md b/doc/ref_arch/kubernetes/chapters/chapter04.md
index c10fb511ea..79c9546d40 100644
--- a/doc/ref_arch/kubernetes/chapters/chapter04.md
+++ b/doc/ref_arch/kubernetes/chapters/chapter04.md
@@ -210,7 +210,7 @@ In order for the storage solution(s) to be conformant with the Reference Archite
|`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 support Kubernetes Persistent Volumes (PV) to provide persistent storage for Pods (requirement 'req.inf.stg.01'
Persistent Volumes exist independent 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
The implementation may utilise either an In-tree or Out-of-tree type of Volume plugin
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
Out-of-tree plugins allow new backend storage systems to be supported without any changes to the core Kubernetes code ||
+|`ra2.stg.005`| Storage Extension | Volume plugins must allow for the use of a range of backend storage systems.
The implementation may utilise either an In-tree or Out-of-tree type of Volume plugin.
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.
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
In order to support CSI, the feature gates `CSIDriverRegistry` and `CSINodeInfo` must be enabled
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))
An implementation may support ephemeral storage through a CSI-compatible volume plugin in which case the `CSIInlineVolume` feature gate must be enabled
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
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) | |
From 6bc3516a87bc788980b12f0529873d3bcc9b5dc3 Mon Sep 17 00:00:00 2001
From: Pankaj Goyal <52107136+pgoyal01@users.noreply.github.com>
Date: Mon, 10 Aug 2020 11:02:05 -0600
Subject: [PATCH 08/13] Update doc/ref_arch/kubernetes/chapters/chapter04.md
Co-authored-by: Tom Kivlin <52716470+tomkivlin@users.noreply.github.com>
---
doc/ref_arch/kubernetes/chapters/chapter04.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/ref_arch/kubernetes/chapters/chapter04.md b/doc/ref_arch/kubernetes/chapters/chapter04.md
index 79c9546d40..7696fb5175 100644
--- a/doc/ref_arch/kubernetes/chapters/chapter04.md
+++ b/doc/ref_arch/kubernetes/chapters/chapter04.md
@@ -212,7 +212,7 @@ In order for the storage solution(s) to be conformant with the Reference Archite
|`ra2.stg.004`| Persisten Volumes | An implemenetation may support Kubernetes Persistent Volumes (PV) to provide persistent storage for Pods (requirement 'req.inf.stg.01'
Persistent Volumes exist independent 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.
The implementation may utilise either an In-tree or Out-of-tree type of Volume plugin.
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.
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
In order to support CSI, the feature gates `CSIDriverRegistry` and `CSINodeInfo` must be enabled
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))
An implementation may support ephemeral storage through a CSI-compatible volume plugin in which case the `CSIInlineVolume` feature gate must be enabled
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
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) | |
+ |`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.
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). | |
Table 4-5: Storage Solution Specifications
From f5c34e44252c8c95ad08103697a66790d8b09c17 Mon Sep 17 00:00:00 2001
From: Pankaj Goyal <52107136+pgoyal01@users.noreply.github.com>
Date: Mon, 10 Aug 2020 11:02:25 -0600
Subject: [PATCH 09/13] Update doc/ref_arch/kubernetes/chapters/chapter04.md
Co-authored-by: Tom Kivlin <52716470+tomkivlin@users.noreply.github.com>
---
doc/ref_arch/kubernetes/chapters/chapter04.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/ref_arch/kubernetes/chapters/chapter04.md b/doc/ref_arch/kubernetes/chapters/chapter04.md
index 7696fb5175..5a76cd1bb3 100644
--- a/doc/ref_arch/kubernetes/chapters/chapter04.md
+++ b/doc/ref_arch/kubernetes/chapters/chapter04.md
@@ -211,7 +211,7 @@ In order for the storage solution(s) to be conformant with the Reference Archite
|`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 support Kubernetes Persistent Volumes (PV) to provide persistent storage for Pods (requirement 'req.inf.stg.01'
Persistent Volumes exist independent 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.
The implementation may utilise either an In-tree or Out-of-tree type of Volume plugin.
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.
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
In order to support CSI, the feature gates `CSIDriverRegistry` and `CSINodeInfo` must be enabled
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))
An implementation may support ephemeral storage through a CSI-compatible volume plugin in which case the `CSIInlineVolume` feature gate must be enabled
An implementation may support Persistent Volumes through a CSI-compatible volume plugin in which case the `CSIPersistentVolume` feature gate must be enabled | |
+|`ra2.stg.006`| Container Storage Interface (CSI) | An implementation may support the Container Storage Interface (CSI), an Out-of-tree plugin.
In order to support CSI, the feature gates `CSIDriverRegistry` and `CSINodeInfo` must be enabled.
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)).
An implementation may support ephemeral storage through a CSI-compatible volume plugin in which case the `CSIInlineVolume` feature gate must be enabled.
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.
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). | |
Table 4-5: Storage Solution Specifications
From 4fb01354bfbe1592473b6c448734d36925624dc4 Mon Sep 17 00:00:00 2001
From: Pankaj Goyal <52107136+pgoyal01@users.noreply.github.com>
Date: Mon, 10 Aug 2020 11:02:45 -0600
Subject: [PATCH 10/13] Update doc/ref_arch/kubernetes/chapters/chapter04.md
Co-authored-by: Tom Kivlin <52716470+tomkivlin@users.noreply.github.com>
---
doc/ref_arch/kubernetes/chapters/chapter04.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/ref_arch/kubernetes/chapters/chapter04.md b/doc/ref_arch/kubernetes/chapters/chapter04.md
index 5a76cd1bb3..ae6068a4f1 100644
--- a/doc/ref_arch/kubernetes/chapters/chapter04.md
+++ b/doc/ref_arch/kubernetes/chapters/chapter04.md
@@ -209,7 +209,7 @@ In order for the storage solution(s) to be conformant with the Reference Archite
|`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.
See the [Container runtimes](#4.4) section above for more information on how this meets the requirement for ephemeral storage for containers.
Ephemeral storage exists for the life of a container.
Kubernetes Volumes attached using a Volume plugin can also be used to deliver Ephemeral Storage (may require additional tasks to ensure deletion of ephemeral storage on the 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 support Kubernetes Persistent Volumes (PV) to provide persistent storage for Pods (requirement 'req.inf.stg.01'
Persistent Volumes exist independent of the lifecycle of containers and/or pods ||
+|`ra2.stg.004`| Persistent Volumes | An implementation may support Kubernetes Persistent Volumes (PV) to provide persistent storage for Pods (requirement 'req.inf.stg.01'.
Persistent Volumes exist independent 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.
The implementation may utilise either an In-tree or Out-of-tree type of Volume plugin.
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.
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.
In order to support CSI, the feature gates `CSIDriverRegistry` and `CSINodeInfo` must be enabled.
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)).
An implementation may support ephemeral storage through a CSI-compatible volume plugin in which case the `CSIInlineVolume` feature gate must be enabled.
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.
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). | |
From 90afef1863d6929a21c1c50373fe0c93cd83c8e2 Mon Sep 17 00:00:00 2001
From: Pankaj Goyal <52107136+pgoyal01@users.noreply.github.com>
Date: Mon, 10 Aug 2020 11:03:00 -0600
Subject: [PATCH 11/13] Update doc/ref_arch/kubernetes/chapters/chapter04.md
Co-authored-by: Tom Kivlin <52716470+tomkivlin@users.noreply.github.com>
---
doc/ref_arch/kubernetes/chapters/chapter04.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/ref_arch/kubernetes/chapters/chapter04.md b/doc/ref_arch/kubernetes/chapters/chapter04.md
index ae6068a4f1..8141e4b62e 100644
--- a/doc/ref_arch/kubernetes/chapters/chapter04.md
+++ b/doc/ref_arch/kubernetes/chapters/chapter04.md
@@ -207,7 +207,7 @@ In order for the storage solution(s) to be conformant with the Reference Archite
|Ref|Specification|Details|Requirement Trace|
|---|---|---|---|
|`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.
See the [Container runtimes](#4.4) section above for more information on how this meets the requirement for ephemeral storage for containers.
Ephemeral storage exists for the life of a container.
Kubernetes Volumes attached using a Volume plugin can also be used to deliver Ephemeral Storage (may require additional tasks to ensure deletion of ephemeral storage on the 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.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`| Persistent Volumes | An implementation may support Kubernetes Persistent Volumes (PV) to provide persistent storage for Pods (requirement 'req.inf.stg.01'.
Persistent Volumes exist independent 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.
The implementation may utilise either an In-tree or Out-of-tree type of Volume plugin.
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.
Out-of-tree plugins allow new backend storage systems to be supported without any changes to the core Kubernetes code. ||
From b8c17b1b53436040bbb871275e48b2a8d3b0a5d0 Mon Sep 17 00:00:00 2001
From: Pankaj Goyal <52107136+pgoyal01@users.noreply.github.com>
Date: Mon, 10 Aug 2020 11:08:50 -0600
Subject: [PATCH 12/13] [RA2 Ch04] Add link to RA2 Ch02 requirements trace
$.6 Storage components, `ra2.stg.004' added link to RA2 2.3 Requirement req.inf.stg.01
---
doc/ref_arch/kubernetes/chapters/chapter04.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/ref_arch/kubernetes/chapters/chapter04.md b/doc/ref_arch/kubernetes/chapters/chapter04.md
index 8141e4b62e..1011203f50 100644
--- a/doc/ref_arch/kubernetes/chapters/chapter04.md
+++ b/doc/ref_arch/kubernetes/chapters/chapter04.md
@@ -209,7 +209,7 @@ In order for the storage solution(s) to be conformant with the Reference Archite
|`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.
See the [Container runtimes](#4.4) section above for more information on how this meets the requirement for ephemeral storage for containers.
Ephemeral storage exists for the life of a container.
Kubernetes Volumes attached using a Volume plugin can also be used to deliver Ephemeral Storage (may require additional tasks to ensure deletion of ephemeral storage on the 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`| Persistent Volumes | An implementation may support Kubernetes Persistent Volumes (PV) to provide persistent storage for Pods (requirement 'req.inf.stg.01'.
Persistent Volumes exist independent of the lifecycle of containers and/or pods. ||
+|`ra2.stg.004`| Persistent Volumes | An implementation may support Kubernetes Persistent Volumes (PV) to provide persistent storage for Pods (requirement 'req.inf.stg.01'.
Persistent Volumes exist independent of the lifecycle of containers and/or pods. |[req.inf.stg.01](https://github.com/cntt-n/CNTT/blob/master/doc/ref_arch/kubernetes/chapters/chapter02.md#23-kubernetes-architecture-requirements)|
|`ra2.stg.005`| Storage Extension | Volume plugins must allow for the use of a range of backend storage systems.
The implementation may utilise either an In-tree or Out-of-tree type of Volume plugin.
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.
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.
In order to support CSI, the feature gates `CSIDriverRegistry` and `CSINodeInfo` must be enabled.
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)).
An implementation may support ephemeral storage through a CSI-compatible volume plugin in which case the `CSIInlineVolume` feature gate must be enabled.
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.
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). | |
From b16fa6066b427ca12fa3d01a44a4a7bdf6da741a Mon Sep 17 00:00:00 2001
From: Pankaj Goyal <52107136+pgoyal01@users.noreply.github.com>
Date: Mon, 10 Aug 2020 12:01:19 -0600
Subject: [PATCH 13/13] Update chapter04.md
Delete content that belongs to RA Chapter 3:
- from ra2.stg.001: "Ephemeral storage exists for the life of a container.
Kubernetes Volumes attached using a Volume plugin can also be used to deliver Ephemeral Storage (may require additional tasks to ensure deletion of ephemeral storage on the shutting down of a container)"
- from from ra2.stg.002: "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. "
- from ra2.stg.005: "The implementation may utilise either an In-tree or Out-of-tree type of Volume plugin.
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.
Out-of-tree plugins allow new backend storage systems to be supported without any changes to the core Kubernetes code."
- from ra2.stg.007: "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)."
---
doc/ref_arch/kubernetes/chapters/chapter04.md | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/doc/ref_arch/kubernetes/chapters/chapter04.md b/doc/ref_arch/kubernetes/chapters/chapter04.md
index 1011203f50..f090d2a71d 100644
--- a/doc/ref_arch/kubernetes/chapters/chapter04.md
+++ b/doc/ref_arch/kubernetes/chapters/chapter04.md
@@ -206,13 +206,13 @@ In order for the storage solution(s) to be conformant with the Reference Archite
|Ref|Specification|Details|Requirement Trace|
|---|---|---|---|
-|`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.
See the [Container runtimes](#4.4) section above for more information on how this meets the requirement for ephemeral storage for containers.
Ephemeral storage exists for the life of a container.
Kubernetes Volumes attached using a Volume plugin can also be used to deliver Ephemeral Storage (may require additional tasks to ensure deletion of ephemeral storage on the 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.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.
See the [Container runtimes](#4.4) section above for more information on how this meets the requirement for ephemeral storage for containers. ||
+|`ra2.stg.002`| Kubernetes Volumes | An implementation may attach additional storage to containers using Kubernetes Volumes. ||
|`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`| Persistent Volumes | An implementation may support Kubernetes Persistent Volumes (PV) to provide persistent storage for Pods (requirement 'req.inf.stg.01'.
Persistent Volumes exist independent of the lifecycle of containers and/or pods. |[req.inf.stg.01](https://github.com/cntt-n/CNTT/blob/master/doc/ref_arch/kubernetes/chapters/chapter02.md#23-kubernetes-architecture-requirements)|
-|`ra2.stg.005`| Storage Extension | Volume plugins must allow for the use of a range of backend storage systems.
The implementation may utilise either an In-tree or Out-of-tree type of Volume plugin.
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.
Out-of-tree plugins allow new backend storage systems to be supported without any changes to the core Kubernetes code. ||
+|`ra2.stg.005`| Storage Extension | Volume plugins must allow for the use of a range of backend storage systems. ||
|`ra2.stg.006`| Container Storage Interface (CSI) | An implementation may support the Container Storage Interface (CSI), an Out-of-tree plugin.
In order to support CSI, the feature gates `CSIDriverRegistry` and `CSINodeInfo` must be enabled.
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)).
An implementation may support ephemeral storage through a CSI-compatible volume plugin in which case the `CSIInlineVolume` feature gate must be enabled.
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.
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). | |
+ |`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. | |
Table 4-5: Storage Solution Specifications