chore(docs): Minor fixes for images and texts (#950)

* On click the images should zoom in and open in new tab
* Minor text updates for Introduction section
* Minor fixes in text in Concept section

Signed-off-by: anupriya0703 <[email protected]>

docs/architecture.md

@@ -10,7 +10,7 @@ OpenEBS is the leading Open Source implementation of the [Container Attached Sto
 
 
 <br>
-<img src="/docs/assets/openebs-hld.svg" alt="drawing" width="80%"/>
+<a href="/docs/assets/openebs-hld.svg" target="_blank"><img src="/docs/assets/openebs-hld.svg" alt="drawing" width="80%"/></a>
 <br>
 
 OpenEBS has many components, which can be grouped into the following two broad categories.
@@ -28,12 +28,12 @@ The data engines are responsible for:
 - Provide volume services like - synchronous replication, compression, encryption, maintain snapshots, access to the incremental or full snapshots of data and so forth
 - Provide strong consistency while persisting the data to the underlying storage devices
 
-OpenEBS follow micro-services model to implement the data engine where the functionality is further decomposed into different layers, allowing for flexibility to interchange the layers and make data engines future ready for changes coming in the application and data center technologies. 
+OpenEBS follow micro-services model to implement the data engine where the functionality is further decomposed into different layers, allowing for flexibility to interchange the layers and make data engines future-ready for changes coming in the application and data center technologies. 
 
 The OpenEBS Data Engines comprise of the following layers:
 
 <br>
-<img src="/docs/assets/data-engine-overview.svg" alt="drawing" width="80%"/>
+<a href="/docs/assets/data-engine-overview.svg" target="_blank"><img src="/docs/assets/data-engine-overview.svg" alt="drawing" width="80%"/></a>
 <br>
 
 ### Volume Access Layer
@@ -50,7 +50,7 @@ This layer is often called as the Volume Target Layer or even Volume Controller
 
 The implementation pattern used by data engines to provide high availability is what differentiates OpenEBS from other traditional storage controllers. Unlike using a single storage controller for performing the IOs on multiple volumes, OpenEBS creates one storage controller (called Target/Nexus) per volume, with a specific list of nodes where the volume data will be saved. Each node will have complete data of the volume distributed using synchronous replication. 
 
-Using single controller to implement synchronous replication of data to fixed set of nodes (instead of distribution via multiple metadata controller), reduces the overhead in managing the metadata and also reduces the blast radius related to a node failure and other nodes participating in the rebuild of the failed node. 
+Using a single controller to implement synchronous replication of data to fixed set of nodes (instead of distribution via multiple metadata controller), reduces the overhead in managing the metadata and also reduces the blast radius related to a node failure and other nodes participating in the rebuild of the failed node. 
 
 The OpenEBS volume services layer exposes the volumes as:
 - Device or Directory paths in case of Local PV, 
@@ -66,7 +66,7 @@ OpenEBS Data engines create a Volume Replica on top of the Storage Layer. Volume
 - Logical Volume - in case the storage layer used is a device pool coming from LVM or ZFS. 
 
 
-In case the applications require only local storage, then the Persistent Volume will be created using one of the above directory, device (or partition) or logical volume. OpenEBS [control plane](#control-plane) will be used to provision one of the above replicas. 
+In case the applications require only local storage, then the Persistent Volume will be created using one of the above directories, device (or partition) or logical volume. OpenEBS [control plane](#control-plane) will be used to provision one of the above replicas. 
 
 OpenEBS can add the layer of high availability on top of the local storage using one of its replicated engines - Jiva, cStor and Mayastor. In this case, OpenEBS uses a light-weight storage defined storage controller software that can receive the read/write operations over a network end-point and then be passed on to the underlying storage layer. OpenEBS then uses this Replica network end-points to maintain a synchronous copy of the volume across nodes. 
 
@@ -82,7 +82,7 @@ OpenEBS Volume Replicas typically go through the following states:
 
 Storage Layer forms the basic building blocks for persisting the data. The Storage Layer comprise of block devices attached to the node (either locally via PCIe, SAS, NVMe or via remote SAN/Cloud). The Storage Layer could also be a sub-directory on top of a mounted filesystem. 
 
-Storage Layer is outside the purview of the OpenEBS Data Engines and are available to the Kubernetes storage constructs using standard operating system or linux software constructs.  
+Storage Layer is outside the purview of the OpenEBS Data Engines and are available to the Kubernetes storage constructs using standard operating system or Linux software constructs.  
 
 The Data Engines consume the storage as a device or a device pool or a filesystem directory. 
 
@@ -100,12 +100,12 @@ The control plane in the context of OpenEBS refers to a set of tools or componen
 OpenEBS Control Plane comprises of a set of micro-services that are themselves managed by Kubernetes, making OpenEBS truly Kubernetes native. The configuration managed by the OpenEBS Control Plane is saved as Kubernetes custom resources. The functionality of the control plane can be decomposed into the various stages as follows:
 
 <br>
-<img src="/docs/assets/openebs-control-plane.svg" alt="drawing" width="80%"/>
+<a href="/docs/assets/openebs-control-plane.svg" target="_blank"><img src="/docs/assets/openebs-control-plane.svg" alt="drawing" width="80%"/></a>
 <br>
 
 ### YAML or Helm chart
 
-OpenEBS components can be installed by the administrator using an highly configurable Helm chart or kubectl/YAML. OpenEBS installation is also supported via the Management Kubernetes offerings such as OpenShift, EKS, DO, Rancher as marketplace applications or as add-on or plugins tightly integrated into Kubernetes distributions such as MicroK8s, Kinvolk, Kubesphere. 
+OpenEBS components can be installed by the administrator using a highly configurable Helm chart or kubectl/YAML. OpenEBS installation is also supported via the Management Kubernetes offerings such as OpenShift, EKS, DO, Rancher as marketplace applications or as add-on or plugins tightly integrated into Kubernetes distributions such as MicroK8s, Kinvolk, Kubesphere. 
 
 As part of the OpenEBS install, the control plane components for the selected data engines will be installed as cluster and/or node components using standard Kubernetes primitives like Deployments, DaemonSets, Statefulsets and such. The OpenEBS installation also takes care of loading the OpenEBS custom resource definitions into the Kubernetes. 
 
@@ -115,9 +115,9 @@ OpenEBS control plane components are all stateless and depend on the Kubernetes
 
 OpenEBS supports Declarative API for managing all of its operations and the APIs are exposed as Kubernetes custom resources. Kubernetes CRD validators and admission webhooks are used to validate the inputs provided by the users and to validate if the operations are allowed.  
 
-The Declarative API is a natural extension to what Kubernetes administrators and user are accustomed to, where they can define the intent via an YAML and then Kubernetes and associated OpenEBS Operators will reconcile the state with the user's intent. 
+The Declarative API is a natural extension to what Kubernetes administrators and user are accustomed to, where they can define the intent via a YAML and then Kubernetes and associated OpenEBS Operators will reconcile the state with the user's intent. 
 
-The Declarative API can be used to configure the Data Engines and setup volume profiles / policies.  Even upgrades of the data engines are performed using this API. The API can be used to: 
+The Declarative API can be used to configure the Data Engines and setup volume profiles/policies.  Even upgrades of the data engines are performed using this API. The API can be used to: 
 - Manage the configuration for each of the Data engine
 - Manage the way the storage needs to be managed or storage pools 
 - Manage the volumes and its services - creation, snapshots, clones, backup, restore, deletion
@@ -150,15 +150,15 @@ The Storage Drivers are responsible for:
 
 OpenEBS focuses on storage operations and provides plugins for other popular tools for performing the operations that fall outside of the core storage functionality but are very important for running OpenEBS in production. Examples of such operations are:
 - Application Consistent Backup and Recovery (provided via integrations into Velero) 
-- Monitoring and Alerting ( provided via integrations into Prometheus,Grafana, Alert manager) 
+- Monitoring and Alerting ( provided via integrations into Prometheus, Grafana, Alert manager) 
 - Enforcing Security Policies ( provided via integrations with PodSecurityPolicies or Kyerno) 
 - Logging ( provide via integration to any standard Logging stack setup by administrators like ELK, Loki, Logstash) 
 - Visualizations  (provided via standard Kubernetes Dashboards or custom Grafana dashboards)
 
 
 ### CLI 
 
-All the management functions on OpenEBS can be carried out via `kubectl` as OpenEBS uses Custom Resources for managing all of its configuration and reporting the status of the components. 
+All the management functions on OpenEBS can be carried out via `kubectl` as OpenEBS uses Custom Resources for managing all of its configurations and reporting the status of the components. 
 
 In addition, OpenEBS also has released as alpha version `kubectl plugin` to help with providing information about the pools and volumes using a single command that aggregates the information obtained via multiple `kubectl` commands.
 

docs/benefits.md

@@ -16,7 +16,7 @@ sidebar_label: Benefits
 <br>
 
 :::tip
-For information on how OpenEBS is used in production,  visit the [use cases](/docs/next/usecases.html) section or see examples of users and their stories on the OpenEBS Adopters section [here](https://github.com/openebs/openebs/blob/master/ADOPTERS.md) where you can also share your experience.
+For information on how OpenEBS is used in production,  visit the [use cases](/docs/next/usecases.html) section or see examples of users and their stories on the [OpenEBS Adopters section](https://github.com/openebs/openebs/blob/master/ADOPTERS.md), where you can also share your experience.
 :::
 
 ### Open Source Cloud Native Storage for Kubernetes

docs/cas.md

@@ -12,21 +12,21 @@ sidebar_label: Container Attached Storage
 
 Container Attached Storage(CAS) is a software that includes microservice based storage controllers that are orchestrated by Kubernetes.  These storage controllers can run anywhere that Kubernetes can run which means any cloud or even bare metal servers or on top of a traditional shared storage system. Critically, the data itself is also accessed via containers as opposed to being stored in an off platform shared scale out storage system.
 
-<img src="/docs/assets/cas.svg" alt="Container Attached Storage" width="600px">
+<a href="/docs/assets/cas.svg" target="_blank"><img src="/docs/assets/cas.svg" alt="Container Attached Storage" width="600px"></a>
 
 CAS is a pattern very much in line with the trend towards disaggregated data and the rise of small, autonomous teams running small, loosely coupled workloads.  In other words, my team might need Postgres for our microservice, and yours might depend on Redis and MongoDB. Some of our use cases might require performance, some might be gone in 20 minutes, others are write intensive, others read intensive, and so on. In a large organization, the technology that teams depend on will vary more and more as the size of the organization grows and as organizations increasingly trust teams to select their own tools.
 
-CAS means that developers can work without worrying about the underlying requirements of their organizations storage architecture. To CAS, a cloud disk is the same as a SAN which is the same as bare metal or virtualized hosts.  Developers and Platform SREs don’t have meetings to select the next storage vendor or to argue for settings to support their use case, Developers can spin their our own CAS containers with whatever storage is available to the Kubernetes clusters.
+CAS means that developers can work without worrying about the underlying requirements of their organizations' storage architecture. To CAS, a cloud disk is the same as a SAN which is the same as bare metal or virtualized hosts.  Developers and Platform SREs don’t have meetings to select the next storage vendor or to argue for settings to support their use case, Developers can spin their own CAS containers with whatever storage is available to the Kubernetes clusters.
 
-CAS reflects a broader trend of solutions – many of which are now part of Cloud Native Foundation – that reinvent particular categories or create new ones – by being built on Kubernetes and micro services and that deliver capabilities to Kubernetes based microservice environments. For example, new projects for security, DNS, networking, network policy management, messaging, tracing, logging and more have emerged in the cloud-native ecosystem and often in CNCF itself.
+CAS reflects a broader trend of solutions – many of which are now part of Cloud Native Foundation – that reinvent particular categories or create new ones – by being built on Kubernetes and microservice and that deliver capabilities to Kubernetes based microservice environments. For example, new projects for security, DNS, networking, network policy management, messaging, tracing, logging and more have emerged in the cloud-native ecosystem and often in CNCF itself.
 
 
 
 ## Advantages of CAS
 
 ### Agility
 
-Each storage volume in CAS has a containerized storage controller and corresponding containerized replicas. Hence, maintenance and tuning of the resources around these components are truly agile. The Kubernetes rolling upgrades capability enables seamless upgrades of storage controller and  storage replicas. Resources such as CPU and memory, can be tuned using container cGroups. 
+Each storage volume in CAS has a containerized storage controller and corresponding containerized replicas. Hence, maintenance and tuning of the resources around these components are truly agile. The Kubernetes rolling upgrades capability enables seamless upgrades of storage controller and  storage replicas. Resources such as CPU and memory can be tuned using container cGroups. 
 
 ### Granularity of Storage Policies
 
@@ -40,11 +40,11 @@ Avoiding cloud vendor lock-in is the common goal for most users and enterprises.
 
 CAS containerizes the storage software and uses Kubernetes Custom Resource Definitions (CRDs) to represent the low-level storage resources, such as disks and storage pools. This model enables storage to be integrated into other cloud-native tools seamlessly. The storage resources can be provisioned, monitored, managed using cloud-native tools such as Prometheus, Grafana, Fluentd, Weavescope, Jaeger, and others.
 
-Similar to hyperconverged systems, storage and performance of a volume in CAS is scalable. As each volume is having it's own storage controller, the storage can scale up within the permissible limits of a storage capacity of a node. As the number of container applications increase in a given Kubernetes cluster, more nodes are added, which increases the overall availability of storage capacity and performance, thereby making the storage available to the new application containers. This process is exactly similar to the successful hyperconverged systems like Nutanix. 
+Similar to hyperconverged systems, storage and performance of a volume in CAS are scalable. As each volume is having it's own storage controller, the storage can scale up within the permissible limits of a storage capacity of a node. As the number of container applications increases in a given Kubernetes cluster, more nodes are added, which increases the overall availability of storage capacity and performance, thereby making the storage available to the new application containers. This process is exactly similar to the successful hyperconverged systems like Nutanix. 
 
 ### Lower blast radius
 
-CAS architecture does not follow a typical distributed storage architecture that ends up having higher blast radius when nodes fail or rebuild is in progress. 
+CAS architecture does not follow a typical distributed storage architecture that ends up having a higher blast radius when nodes fail or rebuild is in progress. 
 
 With synchronous replication from storage controller onto the fixed storage replicas, the storage becomes highly available. The metadata required to maintain the replicas is simplified to saving the information of the nodes that have replicas and information about the status of replicas to help with quorum. If a node fails, the storage controller, which is a stateless container in this case, is spun on a node where second or third replica is running and data continues to be available. Hence, with CAS there the blast radius is much lower and also localized to the volumes that have replicas on that node.