Merge pull request #231477 from MicrosoftDocs/repo_sync_working_branch

huypub · web-flow · commit 9ecddf28daa3 · 2023-03-21T09:51:43.000-07:00
Confirm merge from repo_sync_working_branch to main to sync with https://github.com/MicrosoftDocs/azure-docs (branch main)
diff --git a/articles/aks/ingress-tls.md b/articles/aks/ingress-tls.md
@@ -444,11 +444,11 @@ In the following example, traffic is routed as such:
     spec:
       ingressClassName: nginx
       tls:
-     - hosts:
+      - hosts:
         - hello-world-ingress.MY_CUSTOM_DOMAIN
         secretName: tls-secret
       rules:
-     - host: hello-world-ingress.MY_CUSTOM_DOMAIN
+      - host: hello-world-ingress.MY_CUSTOM_DOMAIN
         http:
           paths:
           - path: /hello-world-one(/|$)(.*)
@@ -483,11 +483,11 @@ In the following example, traffic is routed as such:
     spec:
       ingressClassName: nginx
       tls:
-     - hosts:
+      - hosts:
         - hello-world-ingress.MY_CUSTOM_DOMAIN
         secretName: tls-secret
       rules:
-     - host: hello-world-ingress.MY_CUSTOM_DOMAIN
+      - host: hello-world-ingress.MY_CUSTOM_DOMAIN
         http:
           paths:
           - path: /static(/|$)(.*)
diff --git a/articles/aks/operator-best-practices-network.md b/articles/aks/operator-best-practices-network.md
@@ -116,11 +116,12 @@ The *ingress resource* is a YAML manifest of `kind: Ingress`. It defines the hos
 The following example YAML manifest would distribute traffic for *myapp.com* to one of two services, *blogservice* or *storeservice*. The customer is directed to one service or the other based on the URL they access.
 
 ```yaml
+apiVersion: networking.k8s.io/v1
 kind: Ingress
 metadata:
  name: myapp-ingress
-   annotations: kubernetes.io/ingress.class: "PublicIngress"
 spec:
+ ingressClassName: PublicIngress
  tls:
  - hosts:
    - myapp.com
@@ -131,12 +132,14 @@ spec:
       paths:
       - path: /blog
         backend:
-         serviceName: blogservice
-         servicePort: 80
+         service
+           name: blogservice
+           port: 80
       - path: /store
         backend:
-         serviceName: storeservice
-         servicePort: 80
+         service
+           name: storeservice
+           port: 80
 ```
 
 ### Ingress controller
diff --git a/articles/aks/virtual-nodes.md b/articles/aks/virtual-nodes.md
@@ -40,7 +40,7 @@ Virtual nodes functionality is heavily dependent on ACI's feature set. In additi
 * Virtual nodes support scheduling Linux pods. You can manually install the open source [Virtual Kubelet ACI](https://github.com/virtual-kubelet/azure-aci) provider to schedule Windows Server containers to ACI.
 * Virtual nodes require AKS clusters with Azure CNI networking.
 * Using api server authorized ip ranges for AKS.
-* Volume mounting Azure Files share support [General-purpose V2](../storage/common/storage-account-overview.md#types-of-storage-accounts) and [General-purpose V1](../storage/common/storage-account-overview.md#types-of-storage-accounts). Follow the instructions for mounting [a volume with Azure Files share](azure-files-csi.md).
+* Volume mounting Azure Files share support [General-purpose V2](../storage/common/storage-account-overview.md#types-of-storage-accounts) and [General-purpose V1](../storage/common/storage-account-overview.md#types-of-storage-accounts). However, virtual nodes currently don't support [Persistent Volumes](concepts-storage.md#persistent-volumes) and [Persistent Volume Claims](concepts-storage.md#persistent-volume-claims). Follow the instructions for mounting [a volume with Azure Files share as an inline volume](azure-csi-files-storage-provision.md#mount-file-share-as-an-inline-volume).
 * Using IPv6 isn't supported.
 * Virtual nodes don't support the [Container hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) feature.
 
diff --git a/articles/aks/workload-identity-migrate-from-pod-identity.md b/articles/aks/workload-identity-migrate-from-pod-identity.md
@@ -108,7 +108,7 @@ Serviceaccount/workload-identity-sa created
 Use the [az identity federated-credential create][az-identity-federated-credential-create] command to create the federated identity credential between the managed identity, the service account issuer, and the subject. Replace the values `resourceGroupName`, `userAssignedIdentityName`, `federatedIdentityName`, `serviceAccountNamespace`, and `serviceAccountName`.
 
 ```azurecli
-az identity federated-credential create --name federatedIdentityName --identity-name userAssignedIdentityName --resource-group resourceGroupName --issuer ${AKS_OIDC_ISSUER} --subject system:serviceaccount:${SERVICE_ACCOUNT_NAMESPACE}:${SERVICE_ACCOUNT_NAME}
+az identity federated-credential create --name federatedIdentityName --identity-name userAssignedIdentityName --resource-group resourceGroupName --issuer ${AKS_OIDC_ISSUER} --subject system:serviceaccount:${SERVICE_ACCOUNT_NAMESPACE}:${SERVICE_ACCOUNT_NAME} --audience api://AzureADTokenExchange
 ```
 
 > [!NOTE]
diff --git a/articles/application-gateway/application-gateway-create-probe-portal.md b/articles/application-gateway/application-gateway-create-probe-portal.md
@@ -50,7 +50,7 @@ Probes are configured in a two-step process through the portal. The first step i
    |**Path**|/ or any valid path|The remainder of the full url for the custom probe. A valid path starts with '/'. For the default path of http:\//contoso.com, just use '/'.  You can also input a server path to a file for a static health check instead of web based.  File paths should be used while using public / private ip, or public ip dns entry as the hostname entry.|
    |**Interval (secs)**|30|How often the probe is run to check for health. It isn't recommended to set the lower than 30 seconds.|
    |**Timeout (secs)**|30|The amount of time the probe waits before timing out. If a valid response isn't received within this time-out period, the probe is marked as failed. The timeout interval needs to be high enough that an http call can be made to ensure the backend health page is available. The time-out value shouldn't be more than the ‘Interval’ value used in this probe setting or the ‘Request timeout’ value in the HTTP setting, which will be associated with this probe.|
-   |**Unhealthy threshold**|3|Number of consecutive failed attempts to be considered unhealthy. The threshold can be set to 1 or more.|
+   |**Unhealthy threshold**|3|Number of consecutive failed attempts to be considered unhealthy. The threshold can be set to 0 or more.|
    |**Use probe matching conditions**|Yes or No|By default, an HTTP(S) response with status code between 200 and 399 is considered healthy. You can change the acceptable range of backend response code or backend response body. [Learn more](./application-gateway-probe-overview.md#probe-matching)|
    |**HTTP Settings**|selection from dropdown|Probe will get associated with the HTTP settings selected here and therefore, will monitor the health of that backend pool, which is associated with the selected HTTP setting. It will use the same port for the probe request as the one being used in the selected HTTP setting. You can only choose those HTTP settings, which aren't associated with any other custom probe. <br>The only HTTP settings that are available for association are those that have the same protocol as the protocol chosen in this probe configuration, and have the same state for the *Pick Host Name From Backend HTTP setting* switch.|
    
diff --git a/articles/application-gateway/application-gateway-troubleshooting-502.md b/articles/application-gateway/application-gateway-troubleshooting-502.md
@@ -41,7 +41,7 @@ Similarly, the presence of a custom DNS in the VNet could also cause issues. An
 
 Validate NSG, UDR, and DNS configuration by going through the following steps:
 
-1. Check NSGs associated with the application gateway subnet. Ensure that communication to backend isn't blocked.
+1. Check NSGs associated with the application gateway subnet. Ensure that communication to backend isn't blocked. For more information, see [Network security groups](/azure/application-gateway/configuration-infrastructure#network-security-groups).
 2. Check UDR associated with the application gateway subnet. Ensure that the UDR isn't directing traffic away from the backend subnet. For example, check for routing to network virtual appliances or default routes being advertised to the application gateway subnet via ExpressRoute/VPN.
 
     ```azurepowershell
diff --git a/articles/application-gateway/ingress-controller-letsencrypt-certificate-application-gateway.md b/articles/application-gateway/ingress-controller-letsencrypt-certificate-application-gateway.md
@@ -27,13 +27,13 @@ Follow the steps below to install [cert-manager](https://docs.cert-manager.io) o
     #!/bin/bash
 
     # Install the CustomResourceDefinition resources separately
-    kubectl apply -f https://raw.githubusercontent.com/jetstack/cert-manager/release-0.8/deploy/manifests/00-crds.yaml
+    kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.10.1/cert-manager.crds.yaml
 
     # Create the namespace for cert-manager
     kubectl create namespace cert-manager
 
     # Label the cert-manager namespace to disable resource validation
-    kubectl label namespace cert-manager certmanager.k8s.io/disable-validation=true
+    kubectl label namespace cert-manager cert-manager.io/disable-validation=true
 
     # Add the Jetstack Helm repository
     helm repo add jetstack https://charts.jetstack.io
@@ -46,17 +46,9 @@ Follow the steps below to install [cert-manager](https://docs.cert-manager.io) o
     helm install \
       cert-manager jetstack/cert-manager \
       --namespace cert-manager \
-      --version v1.0.4 \
+      --version v1.10.1 \
       # --set installCRDs=true
-
-    # Helm v2
-    helm install \
-      --name cert-manager \
-      --namespace cert-manager \
-      --version v1.0.4 \
-      jetstack/cert-manager \
-      # --set installCRDs=true
-      
+     
     #To automatically install and manage the CRDs as part of your Helm release, 
     #   you must add the --set installCRDs=true flag to your Helm installation command.
     ```
@@ -81,12 +73,12 @@ Follow the steps below to install [cert-manager](https://docs.cert-manager.io) o
     ```bash
     #!/bin/bash
     kubectl apply -f - <<EOF
-    apiVersion: certmanager.k8s.io/v1alpha1
+    apiVersion: cert-manager.io/v1
     kind: ClusterIssuer
     metadata:
-    name: letsencrypt-staging
+      name: letsencrypt-staging
     spec:
-    acme:
+      acme:
         # You must replace this email address with your own.
         # Let's Encrypt will use this to contact you about expiring
         # certificates, and issues related to your account.
@@ -97,12 +89,15 @@ Follow the steps below to install [cert-manager](https://docs.cert-manager.io) o
         # before moving to production
         server: https://acme-staging-v02.api.letsencrypt.org/directory
         privateKeySecretRef:
-        # Secret resource used to store the account's private key.
-        name: example-issuer-account-key
+          # Secret resource used to store the account's private key.
+          name: example-issuer-account-key
         # Enable the HTTP-01 challenge provider
         # you prove ownership of a domain by ensuring that a particular
         # file is present at the domain
-        http01: {}
+        solvers:
+          - http01:
+               ingress:
+                  class: azure/application-gateway
     EOF
     ```
 
@@ -127,7 +122,7 @@ Follow the steps below to install [cert-manager](https://docs.cert-manager.io) o
     name: guestbook-letsencrypt-staging
     annotations:
         kubernetes.io/ingress.class: azure/application-gateway
-        certmanager.k8s.io/cluster-issuer: letsencrypt-staging
+        cert-manager.io/cluster-issuer: letsencrypt-staging
     spec:
     tls:
     - hosts:
diff --git a/articles/application-gateway/tutorial-multiple-sites-cli.md b/articles/application-gateway/tutorial-multiple-sites-cli.md
@@ -88,7 +88,8 @@ az network application-gateway create \
   --frontend-port 80 \
   --http-settings-port 80 \
   --http-settings-protocol Http \
-  --public-ip-address myAGPublicIPAddress
+  --public-ip-address myAGPublicIPAddress \
+  --priority 10
 ```
 
 It may take several minutes for the application gateway to be created. After the application gateway is created, you can see these new features of it:
@@ -153,15 +154,17 @@ az network application-gateway rule create \
   --resource-group myResourceGroupAG \
   --http-listener contosoListener \
   --rule-type Basic \
-  --address-pool contosoPool
+  --address-pool contosoPool \
+  --priority 200
 
 az network application-gateway rule create \
   --gateway-name myAppGateway \
   --name fabrikamRule \
   --resource-group myResourceGroupAG \
   --http-listener fabrikamListener \
   --rule-type Basic \
-  --address-pool fabrikamPool
+  --address-pool fabrikamPool \
+  --priority 100
 
 az network application-gateway rule delete \
   --gateway-name myAppGateway \
diff --git a/articles/azure-vmware/configure-identity-source-vcenter.md b/articles/azure-vmware/configure-identity-source-vcenter.md
@@ -17,8 +17,8 @@ In this article, you learn how to:
 
 > [!div class="checklist"]
 >
-> * Export the certificate for LDAPS authentication
-> * Upload the LDAPS certificate to blob storage and generate a SAS URL
+> * (Optional) Export the certificate for LDAPS authentication
+> * (Optional) Upload the LDAPS certificate to blob storage and generate a SAS URL
 > * Configure NSX-T DNS for resolution to your Active Directory Domain
 > * Add Active Directory over (Secure) LDAPS (LDAP over SSL) or (unsecure) LDAP
 > * Add existing AD group to cloudadmin group
@@ -27,6 +27,9 @@ In this article, you learn how to:
 > * Remove AD group from the cloudadmin role
 > * Remove existing external identity sources
 
+>[!NOTE]
+>[Export the certificate for LDAPS authentication](#optional-export-the-certificate-for-ldaps-authentication) and [Upload the LDAPS certificate to blob storage and generate a SAS URL](#optional-upload-the-ldaps-certificate-to-blob-storage-and-generate-a-sas-url) are optional steps as now the certificate(s) will be downloaded from the domain controller(s) automatically through the parameter(s) **PrimaryUrl** and/or  **SecondaryUrl** if the parameter **SSLCertificatesSasUrl** is not provided. You can still provide **SSLCertificatesSasUrl** and follow the optional steps to manually export and upload the certificate(s).
+
 ## Prerequisites
 
 - Connectivity from your Active Directory network to your Azure VMware Solution private cloud must be operational.
@@ -38,14 +41,14 @@ In this article, you learn how to:
     - You need to have a valid certificate. To create a certificate, follow the steps shown in [create a certificate for secure LDAP](../active-directory-domain-services/tutorial-configure-ldaps.md#create-a-certificate-for-secure-ldap). Make sure the certificate meets the requirements that are listed after the steps you used to create a certificate for secure LDAP.
     >[!NOTE]
     >Self-sign certificates are not recommended for production environments.  
-    - [Export the certificate for LDAPS authentication](#export-the-certificate-for-ldaps-authentication) and upload it to an Azure Storage account as blob storage. Then, you'll need to [grant access to Azure Storage resources using shared access signature (SAS)](../storage/common/storage-sas-overview.md).  
+    - Optional: The certificate(s) will be downloaded from the domain controller(s) automatically through the parameter(s) **PrimaryUrl** and/or  **SecondaryUrl** if the parameter **SSLCertificatesSasUrl** is not provided. If you prefer to manually export and upload the certificate(s), please [export the certificate for LDAPS authentication](#optional-export-the-certificate-for-ldaps-authentication) and upload it to an Azure Storage account as blob storage. Then, you'll need to [grant access to Azure Storage resources using shared access signature (SAS)](../storage/common/storage-sas-overview.md).  
 
 - Ensure Azure VMware Solution has DNS resolution configured to your on-premises AD. Enable DNS Forwarder from Azure portal. See [Configure DNS forwarder for Azure VMware Solution](configure-dns-azure-vmware-solution.md) for further information.
 
 >[!NOTE]
 >For more information about LDAPS and certificate issuance, see with your security or identity management team.
 
-## Export the certificate for LDAPS authentication
+## (Optional) Export the certificate for LDAPS authentication
 
 First, verify that the certificate used for LDAPS is valid. If you don't already have a certificate, follow the steps to [create a certificate for secure LDAP](../active-directory-domain-services/tutorial-configure-ldaps.md#create-a-certificate-for-secure-ldap) before you continue.
 
@@ -81,7 +84,7 @@ Now proceed to export the certificate
 >[!NOTE]
 >If more than one domain controller is LDAPS enabled, repeat the export procedure in the additional domain controller(s) to also export the corresponding certificate(s). Be aware that you can only reference two LDAPS server in the `New-LDAPSIdentitySource` Run Command. If the certificate is a wildcard certificate, for example ***.avsdemo.net** you only need to export the certificate from one of the domain controllers.
 
-## Upload the LDAPS certificate to blob storage and generate a SAS URL
+## (Optional) Upload the LDAPS certificate to blob storage and generate a SAS URL
 
 - Upload the certificate file (.cer format) you just exported to an Azure Storage account as blob storage. Then [grant access to Azure Storage resources using shared access signature (SAS)](../storage/common/storage-sas-overview.md).
 
@@ -113,7 +116,7 @@ In your Azure VMware Solution private cloud, you'll run the `New-LDAPSIdentitySo
    | **Field** | **Value** |
    | --- | --- |
    | **GroupName**  | The group in the external identity source that gives the cloudadmin access. For example, **avs-admins**.  |
-   | **CertificateSAS** | Path to SAS strings with the certificates for authentication to the AD source. If you're using multiple certificates, separate each SAS string with a comma. For example, **pathtocert1,pathtocert2**.  |
+   | **SSLCertificatesSasUrl** | Path to SAS strings with the certificates for authentication to the AD source. If you're using multiple certificates, separate each SAS string with a comma. For example, **pathtocert1,pathtocert2**.  |
    | **Credential**  | The domain username and password used for authentication with the AD source (not cloudadmin). The user must be in the **username@avslab.local** format. |
    | **BaseDNGroups**  | Where to look for groups, for example, **CN=group1, DC=avsldap,DC=local**. Base DN is needed to use LDAP Authentication.  |
    | **BaseDNUsers**  |  Where to look for valid users, for example, **CN=users,DC=avsldap,DC=local**.  Base DN is needed to use LDAP Authentication.  |
diff --git a/articles/cost-management-billing/savings-plan/choose-commitment-amount.md b/articles/cost-management-billing/savings-plan/choose-commitment-amount.md
diff --git a/articles/mysql/flexible-server/quickstart-create-bicep.md b/articles/mysql/flexible-server/quickstart-create-bicep.md
