Merge branch 'main' of https://github.com/MicrosoftDocs/azure-docs-pr into ingress-options

Author: asudbring

articles/azure-arc/kubernetes/conceptual-connectivity-modes.md

@@ -1,22 +1,25 @@
 ---
 title: "Azure Arc-enabled Kubernetes connectivity modes"
-ms.date: 08/22/2022
+ms.date: 03/26/2024
 ms.topic: conceptual
 description: "This article provides an overview of the connectivity modes supported by Azure Arc-enabled Kubernetes"
 ---
 
 # Azure Arc-enabled Kubernetes connectivity modes
 
-Azure Arc-enabled Kubernetes requires deployment of Azure Arc agents on your Kubernetes clusters so that capabilities such as configurations (GitOps), extensions, Cluster Connect and Custom Location are made available on the cluster. Kubernetes clusters deployed on the edge may not have constant network connectivity, and as a result, in a semi-connected mode the agents may not always be able to reach the Azure Arc services. This topic explains how Azure Arc features can be used with semi-connected modes of deployment.
+Azure Arc-enabled Kubernetes requires deployment of Azure Arc agents on your Kubernetes clusters so that capabilities such as [configurations (GitOps)](conceptual-gitops-flux2.md), extensions, [cluster connect](conceptual-cluster-connect.md), and [custom location](conceptual-custom-locations.md) are made available on the cluster. Because Kubernetes clusters deployed on the edge may not have constant network connectivity, the agents may not always be able to reach the Azure Arc services while in a semi-connected mode.
 
 ## Understand connectivity modes
 
 When working with Azure Arc-enabled Kubernetes clusters, it's important to understand how network connectivity modes impact your operations.
 
 - **Fully connected**: With ongoing network connectivity, agents can consistently communicate with Azure. In this mode, there is typically little delay with tasks such as propagating GitOps configurations, enforcing Azure Policy and Gatekeeper policies, or collecting workload metrics and logs in Azure Monitor.
+
 - **Semi-connected**:  Azure Arc agents can pull desired state specification from the Arc services, then later realize this state on the cluster.
+
   > [!IMPORTANT]
   > The managed identity certificate pulled down by the `clusteridentityoperator` is valid for up to 90 days before it expires. The agents will try to renew the certificate during this time period; however, if there is no network connectivity, the certificate may expire, and the Azure Arc-enabled Kubernetes resource will stop working. Because of this, we recommend ensuring that the connected cluster has network connectivity at least once every 30 days. If the certificate expires, you'll need to delete and then recreate the Azure Arc-enabled Kubernetes resource and agents in order to reactivate Azure Arc features on the cluster.
+
 - **Disconnected**: Kubernetes clusters in disconnected environments that are unable to access Azure are not currently supported by Azure Arc-enabled Kubernetes.
 
 ## Connectivity status
@@ -27,10 +30,11 @@ The connectivity status of a cluster is determined by the time of the latest hea
 | ------ | ----------- |
 | Connecting | The Azure Arc-enabled Kubernetes resource has been created in Azure, but the service hasn't received the agent heartbeat yet. |
 | Connected | The Azure Arc-enabled Kubernetes service received an agent heartbeat within the previous 15 minutes. |
-| Offline | The Azure Arc-enabled Kubernetes resource was previously connected, but the service hasn't received any agent heartbeat for 15 minutes. |
+| Offline | The Azure Arc-enabled Kubernetes resource was previously connected, but the service hasn't received any agent heartbeat for at least 15 minutes. |
 | Expired | The managed identity certificate of the cluster has expired. In this state, Azure Arc features will no longer work on the cluster. For more information on how to address expired Azure Arc-enabled Kubernetes resources, see the [FAQ](./faq.md#how-do-i-address-expired-azure-arc-enabled-kubernetes-resources). |
 
 ## Next steps
 
 - Walk through our quickstart to [connect a Kubernetes cluster to Azure Arc](./quickstart-connect-cluster.md).
 - Learn more about creating connections between your cluster and a Git repository as a [configuration resource with Azure Arc-enabled Kubernetes](./conceptual-configurations.md).
+- Review the [Azure Arc networking requirements](network-requirements.md).

articles/azure-arc/kubernetes/conceptual-custom-locations.md

@@ -1,35 +1,35 @@
 ---
-title: "Custom Locations - Azure Arc-enabled Kubernetes"
-ms.date: 07/21/2022
+title: "Custom locations with Azure Arc-enabled Kubernetes"
+ms.date: 03/26/2024
 ms.topic: conceptual
-description: "This article provides a conceptual overview of the custom locations capability of Azure Arc-enabled Kubernetes"
+description: "This article provides a conceptual overview of the custom locations capability of Azure Arc-enabled Kubernetes."
 ---
 
-# Custom locations on top of Azure Arc-enabled Kubernetes
+# Custom locations with Azure Arc-enabled Kubernetes
 
 As an extension of the Azure location construct, the *custom locations* feature provides a way for tenant administrators to use their Azure Arc-enabled Kubernetes clusters as target locations for deploying Azure services instances. Examples of Azure offerings that can be deployed on top of custom locations include databases, such as SQL Managed Instance enabled by Azure Arc and Azure Arc-enabled PostgreSQL server.
 
 Similar to Azure locations, end users within the tenant who have access to Custom Locations can deploy resources there using their company's private compute.
 
-[ ![Arc platform layers](./media/conceptual-arc-platform-layers.png) ](./media/conceptual-arc-platform-layers.png#lightbox)
+:::image type="content" source="media/conceptual-arc-platform-layers.png" alt-text="Diagram showing the Arc platform layers.":::
 
-You can visualize custom locations as an abstraction layer on top of Azure Arc-enabled Kubernetes cluster, cluster connect, and cluster extensions. Custom locations create the granular [RoleBindings and ClusterRoleBindings](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding) necessary for other Azure services to access the cluster. These other Azure services require cluster access to manage resources that the customer wants to deploy on their clusters.
+You can visualize custom locations as an abstraction layer on top of Azure Arc-enabled Kubernetes clusters, cluster connect, and cluster extensions. Custom locations create the granular [RoleBindings and ClusterRoleBindings](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding) necessary for other Azure services to access the cluster. These other Azure services require cluster access to manage deployed resources.
 
 ## Architecture
 
-When the admin [enables the custom locations feature on the cluster](custom-locations.md), a ClusterRoleBinding is created on the cluster, authorizing the Microsoft Entra application used by the custom locations resource provider. Once authorized, the custom locations resource provider can create ClusterRoleBindings or RoleBindings needed by other Azure resource providers to create custom resources on this cluster. The cluster extensions installed on the cluster determine the list of resource providers to authorize.
+When the admin [enables the custom locations feature on the cluster](custom-locations.md), a `ClusterRoleBinding` is created on the cluster, authorizing the Microsoft Entra application used by the custom locations resource provider. Once authorized, the custom locations resource provider can create `ClusterRoleBinding` or `RoleBinding` objects that are needed by other Azure resource providers to create custom resources on this cluster. The cluster extensions installed on the cluster determine the list of resource providers to authorize.
 
-[ ![Use custom locations](./media/conceptual-custom-locations-usage.png) ](./media/conceptual-custom-locations-usage.png#lightbox)
+:::image type="content" source="media/conceptual-custom-locations-usage.png" alt-text="Diagram of custom locations architecture, using Arc-enabled data services as an example." lightbox="media/conceptual-custom-locations-usage.png":::
 
 When the user creates a data service instance on the cluster:
 
 1. The PUT request is sent to Azure Resource Manager.
-1. The PUT request is forwarded to the Azure Arc-enabled Data Services RP.
+1. The PUT request is forwarded to the Azure Arc-enabled data services resource provider.
 1. The RP fetches the `kubeconfig` file associated with the Azure Arc-enabled Kubernetes cluster on which the custom location exists.
    * Custom location is referenced as `extendedLocation` in the original PUT request.
-1. The Azure Arc-enabled Data Services resource provider uses the `kubeconfig` to communicate with the cluster to create a custom resource of the Azure Arc-enabled Data Services type on the namespace mapped to the custom location.
-   * The Azure Arc-enabled Data Services operator was deployed via cluster extension creation before the custom location existed.
-1. The Azure Arc-enabled Data Services operator reads the new custom resource created on the cluster and creates the data controller, translating into realization of the desired state on the cluster.
+1. The Azure Arc-enabled data services resource provider uses the `kubeconfig` to communicate with the cluster to create a custom resource of the Azure Arc-enabled data services type on the namespace mapped to the custom location.
+   * The Azure Arc-enabled data services operator was deployed via cluster extension creation before the custom location existed.
+1. The Azure Arc-enabled data services operator reads the new custom resource created on the cluster and creates the data controller, translating into realization of the desired state on the cluster.
 
 The sequence of steps to create the SQL managed instance and PostgreSQL instance are identical to the sequence of steps described above.
 

articles/azure-arc/kubernetes/conceptual-gitops-flux2-ci-cd.md

@@ -1,7 +1,7 @@
 ---
 title: "CI/CD Workflow using GitOps (Flux v2) - Azure Arc-enabled Kubernetes"
 description: "This article provides a conceptual overview of a CI/CD workflow using GitOps."
-ms.date: 08/08/2023
+ms.date: 03/26/2024
 ms.topic: conceptual
 author: eedorenko
 ms.author: iefedore
@@ -16,9 +16,9 @@ This article describes how GitOps fits into the full application change lifecycl
 
 This diagram shows the CI/CD workflow for an application deployed to one or more Kubernetes environments.
 
-:::image type="content" source="media/gitops/gitops-flux2-ci-cd-arch.png" alt-text="Diagram showing GitOps CI/CD architecture.":::
+:::image type="content" source="media/gitops/gitops-flux2-ci-cd-arch.png" alt-text="Diagram showing GitOps CI/CD architecture." lightbox="media/gitops/gitops-flux2-ci-cd-arch.png":::
 
-### Application repository
+### Application code repository
 
 The application repository contains the application code that developers work on during their inner loop. The application's deployment templates live in this repository in a generic form, such as Helm or Kustomize. Environment-specific values aren't stored in the repository.
 
@@ -32,7 +32,7 @@ For more information, see [How to consume and maintain public content with Azure
 
 ### PR pipeline
 
-Pull requests to the application repository are gated on a successful run of the PR pipeline. This pipeline runs the basic quality gates, such as linting and unit tests on the application code. The pipeline tests the application and lints Dockerfiles and Helm templates used for deployment to a Kubernetes environment. Docker images should be built and tested, but not pushed. Keep the pipeline duration relatively short to allow for rapid iteration.
+Pull requests from developers made to the application repository are gated on a successful run of the PR pipeline. This pipeline runs the basic quality gates, such as linting and unit tests on the application code. The pipeline tests the application and lints Dockerfiles and Helm templates used for deployment to a Kubernetes environment. Docker images should be built and tested, but not pushed. Keep the pipeline duration relatively short to allow for rapid iteration.
 
 ### CI pipeline
 
@@ -46,9 +46,9 @@ At this stage, application tests that are too consuming for the PR pipeline can
 
 By the end of the CI build, artifacts are generated. These artifacts can be used by the CD step to consume in preparation for deployment.
 
-### Flux
+### Flux cluster extension
 
-Flux is an agent that runs in each cluster and is responsible for maintaining the desired state. The agent polls the GitOps repository at a user-defined interval, then reconciles the cluster state with the state declared in the Git repository.
+Flux is an agent that runs in each cluster as a cluster extension. This Flux cluster extension is responsible for maintaining the desired state. The agent polls the GitOps repository at a user-defined interval, then reconciles the cluster state with the state declared in the Git repository.
 
 For more information, see [Tutorial: Deploy applications using GitOps with Flux v2](tutorial-use-gitops-flux2.md).