update diagram

Author: paigecalvert

docs/vendor/embedded-overview.mdx

@@ -14,7 +14,7 @@ If you are instead looking for information about creating Kubernetes Installers
 
 <EmbeddedCluster/>
 
-{/* [V2 ARCHITECTURE CONTENT] ## Architecture and Built-In Extensions
+## Architecture and Built-In Extensions
 
 This section describes the Embedded Cluster architecture, including the built-in extensions deployed by Embedded Cluster.
 
@@ -28,13 +28,11 @@ The following diagram shows the architecture of a single-node Embedded Cluster i
 
 As shown in the diagram above, the user downloads the Embedded Cluster installation assets as a `.tgz` in their installation environment. These installation assets include the Embedded Cluster binary, the user's license file, and (for air gap installations) an air gap bundle containing the images needed to install and run the release in an environment with limited or no outbound internet access. 
 
-When the user runs the Embedded Cluster install command, the Embedded Cluster binary first installs the k0s cluster as a systemd service. This systemd service is named using the slug of the application (for example, `gitea`).
+When the user runs the Embedded Cluster install command, the Embedded Cluster binary first installs the k0s cluster as a systemd service.
 
-After all the Kubernetes components for the cluster are available, the Embedded Cluster binary then installs the Embedded Cluster built-in extensions and any Helm extensions that were included in the [`extensions`](/reference/embedded-config#extensions) field of the Embedded Cluster Config. Each built-in extension is installed in its own namespace. The namespace or namespaces where Helm extensions are installed is defined by the vendor in the Embedded Cluster Config. */}
+After all the Kubernetes components for the cluster are available, the Embedded Cluster binary then installs the Embedded Cluster built-in extensions and any Helm extensions that were included in the [`extensions`](/reference/embedded-config#extensions) field of the Embedded Cluster Config.
 
-## Embedded Cluster Built-In Extensions
-
-Embedded Cluster deploys built-in extensions to provide capabilities such as application management and storage. These extensions are deployed by default and do not require configuration.
+The built-in extensions provide capabilities such as application management and storage. Each built-in extension is installed in its own namespace. The namespace or namespaces where Helm extensions are installed is defined by the vendor in the Embedded Cluster Config.
 
 The built-in extensions include:
 
@@ -46,7 +44,7 @@ The built-in extensions include:
 
 * **(Air Gap Only) Image registry:** For air gap installations in environments with limited or no outbound internet access, Embedded Cluster installs an image registry where the images required to install and run the application are pushed. For more information about installing in air-gapped environments, see [Air Gap Installation with Embedded Cluster](/enterprise/installing-embedded-air-gap).
 
-{/* [V2 ARCHITECTURE CONTENT] Finally, after the built-in extensions and any Helm extensions are installed, The Embedded Cluster binary deploys a second systemd service on the node named `APP_SLUG-manager` (for example, `gitea-manager`). This manager service orchestrates Embedded Cluster and communicates with the KOTS instance running in the cluster through a websocket.
+Finally, after the built-in extensions and any Helm extensions are installed, the Embedded Cluster binary installs the Embedded Cluster Operator. The Operator orchestrates Embedded Cluster and communicates with the KOTS instance running in the cluster.
 
 ### Multi-Node Architecture
 
@@ -62,7 +60,7 @@ High availability (HA) for multi-node installations with Embedded Cluster is Alp
 
 As shown in the diagram above, in multi-node installations, an instance of the Embedded Cluster manager systemd service runs on each node and communicates with the KOTS instance running on the primary node through a websocket. This allows Embedded Cluster and KOTS to manage installations where workloads are running on multiple nodes in a cluster.
 
-Additionally, for installations that include disaster recovery with Velero, the Velero Node Agent also runs on each node in the cluster. The Node Agent is a Kubernetes DaemonSet that performs backup and restore tasks such as creating snapshots and transferring data during restores. */}
+Additionally, for installations that include disaster recovery with Velero, the Velero Node Agent also runs on each node in the cluster. The Node Agent is a Kubernetes DaemonSet that performs backup and restore tasks such as creating snapshots and transferring data during restores.
 
 ## Comparison to kURL