Update get-started-with-cluster-registry.md

Author: msftadam

articles/operator-service-manager/get-started-with-cluster-registry.md

@@ -86,25 +86,25 @@ The cluster registry feature deploys helper pods on the target edge cluster to a
 * This pod stores and retrieves container images for CNF.
 
 ### Cluster registry garbage collection
-AOSM cluster extension runs a background garbage collection (GC) job to regularly clean up container images. This job will run based on a schedule, check if the cluster registry usage has reached the specified threshold, and if so, initiate the garbage collection process. The job schedule and threshold is configured by the end-user, but by default the job runs once per day at a 0% utilization threshold. 
+AOSM cluster extension runs a background garbage collection (GC) job to regularly clean up container images. This job runs based on a schedule, check if the cluster registry usage reaches the specified threshold, and if so, initiate the garbage collection process. The end-user configures the job schedule and threshold, but by default the job runs once per day at a 0% utilization threshold. 
 
 #### Clean up garbage image manifests
-AOSM maintains references between pod owner resource and consuming images in cluster registry. Upon initiating the images cleanup process, images will be identified which are not linked to any pods, issuing a soft delete to remove them from cluster registry. This type of soft delete doesn't immediately free cluster registry storage space. Actual image files removal depends on the CNCF distribution registry garbage collection outlined below.
+AOSM maintains references between pod owner resource and consuming images in cluster registry. Upon initiating the images cleanup process, images unlinked to any pods are identified and a soft delete is issued to remove them from cluster registry. This type of soft delete doesn't immediately free cluster registry storage space. Actual image files removal depends on the actual registry garbage collection settings.
 
 > [!NOTE]
-> The reference between a pod's owner and its container images ensures that AOSM does not mistakenly delete images. For example, if a replicaset pod goes down, AOSM will not dereference the container images. AOSM only dereferences container images when the replicaset is deleted. The same principle applies to pods managed by Kubernetes jobs and daemonsets.
+> The reference between a pod's owner and its container images ensures that AOSM does not mistakenly delete images. For example, if a replicaset pod goes down, AOSM doesn't dereference the container images. AOSM only dereferences container images when the replicaset is deleted. The same principle applies to pods managed by Kubernetes jobs and daemonsets.
 
 #### CNCF garbage collection distribution
-AOSM sets up the cluster registry using open source [CNCF distribution registry](https://distribution.github.io/distribution/). Therefore, AOSM relies on garbage collection capabilities that provided by [Garbage collection | CNCF Distribution](https://distribution.github.io/distribution/about/garbage-collection/#:~:text=About%20garbage%20collection,considerable%20amounts%20of%20disk%20space.). Overall, it follows standard 2 phase “mark and sweep” process to delete image files to free registry storage space.
+AOSM sets up the cluster registry using open source [CNCF distribution registry](https://distribution.github.io/distribution/). Therefore, AOSM relies on garbage collection capabilities that provided by [Garbage collection | Public Distribution](https://distribution.github.io/distribution/about/garbage-collection/#:~:text=About%20garbage%20collection,considerable%20amounts%20of%20disk%20space.). Overall, it follows standard 2 phase “mark and sweep” process to delete image files to free registry storage space.
 
 > [!NOTE]
-> This process requires the cluster registry in read-only mode. If images are uploaded when registry not in read-only mode, there is the risk that images layers are mistakenly deleted leading to a corrupted image. Registry requires lock in read-only mode for a duration of up to 1 minute. Consequently, AOSM will defer other NF deployment when cluster registry in read-only mode.
+> This process requires the cluster registry in read-only mode. If images are uploaded when registry not in read-only mode, there is the risk that images layers are mistakenly deleted leading to a corrupted image. Registry requires lock in read-only mode for a duration of up to 1 minute. AOSM will defer other NF deployment when cluster registry in read-only mode.
 
 #### Garbage collection configuration parameters
 The following parameters configure the schedule and threshold for the garbage collection job.
 * global.networkfunctionextension.clusterRegistry.clusterRegistryGCCadence
 * global.networkfunctionextension.clusterRegistry.clusterRegistryGCThreshold
-* For more configuration details, please refer to the latest [Network function extension installation instructions](manage-network-function-operator.md)
+* For more configuration details, refer to the latest [Network function extension installation instructions](manage-network-function-operator.md)
 
 ## High availability and resiliency considerations 
 The AOSM NF extension relies uses a mutating webhook and edge registry to support key features. 
@@ -129,7 +129,7 @@ With HA, cluster registry and webhook pods now support a replicaset with a minim
 * A policy disruption budget (PDB) protects pods from voluntary disruption and is deployed alongside Deployment, ReplicaSet, or StatefulSet objects. For AOSM operator pods, a PDB with minAvailable parameter of 2 is used.
 #### Pod anti-affinity
 * Pod anti-affinity controls distribution of application pods across multiple nodes in your cluster. With HA enabled, AOSM implements the following anti-affinity rules:
-  * A preferredDuringSchedulingIgnoredDuringExecution(Soft) rule type is used. With sof scheduling, topologies that meet the preference criteria are available, Kubernetes schedules the pod. If no such topologies are available, the pod can still be scheduled on other nodes that do not meet the preference. 
+  * A preferredDuringSchedulingIgnoredDuringExecution(Soft) rule type is used. With soft scheduling, topologies that meet the preference criteria are available, Kubernetes schedules the pod. If no such topologies are available, the pod can still be scheduled on other nodes that do not meet the preference. 
   * A topology key is used based on the value of kubernetes.io/hostname.
   * A weight of 100 is used.
 #### Node affinity
@@ -138,7 +138,7 @@ Nexus node placement is spread evenly across zones by design, resulting in zonal
 * Prefer nodes with 'system' mode (weight: 20)
 
 #### Storage
-* Since AOSM edge registry has multiple replicas which are spread across nodes, the persistent volume must support ReadWriteMany (RWX) access mode. PVC “nexus-shared” volume is available on Nexus clusters and supports RWX access mode.
+* Since AOSM edge registry has multiple replicas which are spread across nodes, the persistent volume must support ReadWriteManyX (RWX) access mode. PVC “nexus-shared” volume is available on Nexus clusters and supports RWX access mode.
 
 #### Monitoring via Readiness Probes
 * AOSM uses http readiness probes to know when a container is ready to start accepting traffic. A pod is considered ready when all containers are ready. When a Pod is not ready, it is removed from the service load balancers. 
@@ -175,7 +175,7 @@ The following command can be used to list files in a human readable format:
 ```bash
  kubectl get artifacts -A -o jsonpath='{range .items[*]}{.spec.sourceArtifact}'
 ```
-This command should produce output similar to the following:
+This command should produce the following output:
 ```bash
  ppleltestpublisheras2f88b55037.azurecr.io/nginx:1.0.0
 ```