Capitulate to some of Acrolynx's ridiculous hatred for present perfect tense since technical documents don't get to magically become less technical

Author: jeremyhouser-ms

articles/operator-nexus/concepts-nexus-kubernetes-cluster.md

@@ -11,7 +11,7 @@ ms.custom: template-concept
 
 # Nexus Kubernetes cluster overview
 
-This article describes core concepts of Nexus Kubernetes Cluster, a managed Kubernetes service that you can use to deploy and operate containerized applications on [Azure Operator Nexus Platform](./overview.md)
+This article describes core concepts of a Nexus Azure Kubernetes Service Cluster, a managed Azure Kubernetes Service that you can use to deploy and operate containerized applications on [Azure Operator Nexus Platform](./overview.md)
 
 ## What is Kubernetes?
 
@@ -21,17 +21,17 @@ deployments, backed by a robust set of APIs for management operations. See [What
 
 ## Nexus Kubernetes Service
 
-Nexus Kubernetes Cluster Service is a Kubernetes distribution designed for on-premises deployment over Nexus instances. It's engineered to streamline the automated creation of containers, and is optimized to run workloads associated for data-intensive network functions.
+Nexus Kubernetes Cluster Service is a Kubernetes distribution designed for on-premises deployment over Nexus instances. It streamlines the automated creation of containers, and is optimized to run workloads associated for data-intensive network functions.
 
 Like any Kubernetes cluster, Nexus Kubernetes cluster has two components:
 
 * Control plane: provides core Kubernetes services and manages the life cycle of application workloads.
 
 * Nodes: To run your applications and supporting services, you need a Kubernetes node. It provides the container runtime environment.
-Each NKS cluster has at least one node. Node is hosted in virtual machine (VM) that runs the [Kubernetes node components](/azure/aks/concepts-clusters-workloads#nodes). 
-VM is created as part of NKS cluster deployment on Nexus instance. There are two types of node pools in Nexus Kubernetes Clusters
+Each Nexus AKS cluster has at least one node. Node is hosted in virtual machine (VM) that runs the [Kubernetes node components](/azure/aks/concepts-clusters-workloads#nodes). 
+VM is created as part of Nexus AKS cluster deployment on Nexus instance. There are two types of node pools in Nexus Kubernetes Clusters
 
-  * When you create an AKS cluster, you define the initial number of nodes and their size (SKU), which creates a system node pool. System node pools host critical system pods.
+  * When you create a Nexus AKS cluster, you define the initial number of nodes and their size (SKU), which creates a system node pool. System node pools host critical system pods.
   * On the other hand, to support applications that have different compute or storage demands, you can create user node pools, also known as Nexus Agent pool. Each VM in a Nexus Agent pool adheres to a uniform configuration, such as CPU, memory, disk and so on. Once an Agent pool is established, the number of VMs within it remains fixed. To scale the capacity of a Nexus Kubernetes cluster, more Agent pools can be created and integrated into the existing cluster. In other words, the Nexus Agent pool supports horizontal scaling by allowing the addition or removal of Agent pools within the Nexus Kubernetes cluster.
 
 However, application pods can be scheduled on system node pools in case user wants only one node pool in their cluster. Every Nexus Kubernetes Cluster must
@@ -45,16 +45,16 @@ Nexus Kubernetes Cluster Features, previously known as "Add-ons" in releases bef
 and Arc for Servers are included by default when clusters are created. The successful completion of the cluster provisioning process depends on these Features being installed successfully. If a required Feature installation fails and can't be fixed, the cluster status is marked as failed.
 
 * Optional Features: Optional Features are supplementary services associated with a Kubernetes Cluster resource. Customers can choose to activate or deactivate these Features on demand.
-Example for supplementary services could include deployment of cluster-level local image caching registry within the NKS cluster to support for disconnected scenarios. NKS enables the customer to observe the status, health,
+Example for supplementary services could include deployment of cluster-level local image caching registry within the Nexus AKS cluster to support for disconnected scenarios. Nexus AKS enables the customer to observe the status, health,
 and version of each required and optional Feature, which can be monitored on Azure portal, or the state can be fetched using Azure Resource Manager APIs.
 
 Features are installed once and can only be updated or upgraded when the customer upgrades the Nexus Kubernetes cluster. It enables customers to apply critical production hotfixes without interference from the underlying infrastructure operations, which could otherwise overwrite their cluster modifications.
 
 ## Nexus Available Zones
 
-Nexus has introduced a concept of Availability Zone. It's delineated at a Rack level and allows customers to spread their workloads across the instance to achieve better availability. For a Nexus instance with eight racks, customers get eight Availability zones.
+Nexus introduces the concept of an Availability Zone. An Availability Zone is delineated at a Rack level and allows customers to spread their workloads across the instance to achieve better availability. For a Nexus instance with eight racks, customers get eight Availability Zones.
 Each Zone comprises a pair of management servers with redundancy and a collection of compute servers that function as a resource pool.
-During multi-rack deployments in Nexus and when performing runtime bundle upgrades, Availability zones provide the added benefit of acting as an upgrade domain. This ensures that, at most, only the servers within a single rack are taken offline for these upgrades.
+During multi-rack deployments in Nexus and when performing runtime bundle upgrades, Availability Zones provide the added benefit of acting as an upgrade domain. This ensures that, at most, only the servers within a single rack are taken offline for these upgrades.
 
 ## Failure domain