Condividi tramite

Avvio rapido: Connettere un cluster Kubernetes esistente ad Azure Arc

  • Articolo

Per iniziare a usare Kubernetes abilitato per Azure Arc, usare l'interfaccia della riga di comando di Azure o Azure PowerShell per connettere un cluster Kubernetes esistente ad Azure Arc.

Per un'analisi concettuale sulla connessione dei cluster ad Azure Arc, vedere Panoramica dell'agente Kubernetes abilitato per Azure Arc. Per provare le attività in un'esperienza di esempio/pratica, visitare laAzure Arc Jumpstart.

Prerequisiti

Importante

Oltre a questi prerequisiti, assicurarsi di soddisfare tutti i requisiti di rete per Kubernetes abilitato per Azure Arc.

Registrare i provider per Kubernetes abilitato per Azure Arc

  1. Immettere i comandi seguenti:

    az provider register --namespace Microsoft.Kubernetes
az provider register --namespace Microsoft.KubernetesConfiguration
az provider register --namespace Microsoft.ExtendedLocation

  2. Monitorare il processo di registrazione. La registrazione può richiedere fino a 10 minuti.

    az provider show -n Microsoft.Kubernetes -o table
az provider show -n Microsoft.KubernetesConfiguration -o table
az provider show -n Microsoft.ExtendedLocation -o table

    Dopo la registrazione, lo stato di RegistrationState per questi spazi dei nomi dovrebbe cambiare in Registered.

Creare un gruppo di risorse

Esegui questo comando:

az group create --name AzureArcTest --location EastUS --output table

Output:

Location    Name
----------  ------------
eastus      AzureArcTest

Connettere un cluster Kubernetes esistente

Eseguire il comando seguente per connettere il cluster. Questo comando distribuisce gli agenti di Azure Arc nel cluster e installa Helm v. 3.6.3 nella cartella .azure del computer di distribuzione. Questa installazione di Helm 3 viene usata solo per Azure Arc e non rimuove o modifica le versioni di Helm installate in precedenza nel computer.

In questo esempio il nome del cluster è AzureArcTest1.

az connectedk8s connect --name AzureArcTest1 --resource-group AzureArcTest

Output:

Helm release deployment succeeded

    {
      "aadProfile": {
        "clientAppId": "",
        "serverAppId": "",
        "tenantId": ""
      },
      "agentPublicKeyCertificate": "xxxxxxxxxxxxxxxxxxx",
      "agentVersion": null,
      "connectivityStatus": "Connecting",
      "distribution": "gke",
      "id": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/AzureArcTest/providers/Microsoft.Kubernetes/connectedClusters/AzureArcTest1",
      "identity": {
        "principalId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
        "tenantId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
        "type": "SystemAssigned"
      },
      "infrastructure": "gcp",
      "kubernetesVersion": null,
      "lastConnectivityTime": null,
      "location": "eastus",
      "managedIdentityCertificateExpirationTime": null,
      "name": "AzureArcTest1",
      "offering": null,
      "provisioningState": "Succeeded",
      "resourceGroup": "AzureArcTest",
      "tags": {},
      "totalCoreCount": null,
      "totalNodeCount": null,
      "type": "Microsoft.Kubernetes/connectedClusters"
    }

Suggerimento

Il comando precedente senza il parametro location specificato crea la risorsa Kubernetes abilitata per Azure Arc nella stessa posizione del gruppo di risorse. Per creare la risorsa Kubernetes abilitata per Azure Arc in un percorso differente, specificare --location <region> o -l <region> quando si esegue il comando az connectedk8s connect.

Importante

Se la distribuzione non riesce a causa di un errore di timeout, vedere la guida alla risoluzione dei problemi per informazioni dettagliate su come risolvere questo problema.

Connettersi usando un server proxy per traffico in uscita

Se il cluster si trova dietro un server proxy per traffico in uscita, le richieste devono essere instradate tramite il server proxy per traffico in uscita.

  1. Nel computer di distribuzione impostare le variabili di ambiente necessarie per l'interfaccia della riga di comando di Azure per usare il server proxy per traffico in uscita:

    export HTTP_PROXY=<proxy-server-ip-address>:<port>
export HTTPS_PROXY=<proxy-server-ip-address>:<port>
export NO_PROXY=<cluster-apiserver-ip-address>:<port>

  2. Nel cluster Kubernetes eseguire il comando Connetti con i parametri proxy-https e proxy-http specificati. Se il server proxy è configurato con HTTP e HTTPS, assicurarsi di usare --proxy-http per il proxy HTTP e --proxy-https per il proxy HTTPS. Se il server proxy usa solo HTTP, è possibile usare tale valore per entrambi i parametri.

    az connectedk8s connect --name <cluster-name> --resource-group <resource-group> --proxy-https https://<proxy-server-ip-address>:<port> --proxy-http http://<proxy-server-ip-address>:<port> --proxy-skip-range <excludedIP>,<excludedCIDR> --proxy-cert <path-to-cert-file>

Nota

  • alcune richieste di rete, ad esempio quelle che coinvolgono la comunicazione da servizio a servizio nel cluster, devono essere separate dal traffico instradato tramite il server proxy per la comunicazione in uscita. È possibile usare il parametro --proxy-skip-range per specificare l'intervallo CIDR e gli endpoint delimitati da virgole in modo che qualsiasi comunicazione dagli agenti a questi endpoint non venga eseguita tramite il proxy in uscita. Come valore minimo, l'intervallo CIDR dei servizi nel cluster deve essere specificato come valore per questo parametro. Si supponga, ad esempio, che kubectl get svc -A restituisca un elenco di servizi in cui tutti i servizi hanno valori ClusterIP nell'intervallo 10.0.0.0/16. Quindi, il valore da specificare per --proxy-skip-range è 10.0.0.0/16,kubernetes.default.svc,.svc.cluster.local,.svc.
  • --proxy-http, --proxy-https e --proxy-skip-range sono previsti per la maggior parte degli ambienti proxy in uscita. --proxy-cert è necessario solo se bisogna inserire certificati attendibili previsti dal proxy nell'archivio certificati attendibili dei pod agente.
  • Il proxy in uscita deve essere configurato per consentire le connessioni WebSocket.

Per i server proxy in uscita in cui è necessario specificare solo un certificato attendibile senza gli input dell'endpoint server proxy, az connectedk8s connect può essere eseguito solo con l'input --proxy-cert specificato. Nel caso in cui siano previsti più certificati attendibili, la catena di certificati combinata può essere fornita in un singolo file usando il parametro --proxy-cert.

Nota

  • --custom-ca-cert è un alias per --proxy-cert. Entrambi i parametri possono essere usati in modo intercambiabile. Il passaggio di entrambi i parametri nello stesso comando rispetta quello passato per ultimo.

Eseguire il comando connect con il parametro --proxy-cert specificato:

az connectedk8s connect --name <cluster-name> --resource-group <resource-group> --proxy-cert <path-to-cert-file>

Verificare la connessione al cluster

Esegui questo comando:

az connectedk8s list --resource-group AzureArcTest --output table

Output:

Name           Location    ResourceGroup
-------------  ----------  ---------------
AzureArcTest1  eastus      AzureArcTest

Nota

Dopo l'onboarding del cluster, sono necessari da 5 a 10 minuti per visualizzare i metadati del cluster (versione del cluster, versione dell'agente, numero di nodi e così via) nella pagina di panoramica della risorsa Kubernetes abilitata per Azure Arc nel portale di Azure.

Suggerimento

Per informazioni sulla risoluzione dei problemi durante la connessione del cluster, vedere Diagnosticare i problemi di connessione per i cluster Kubernetes abilitati per Azure Arc.

Vedere Agenti Azure Arc per Kubernetes

Kubernetes abilitato per Azure Arc distribuisce diversi agenti nello spazio dei nomi azure-arc.

  1. Visualizzare le distribuzioni e i pod seguenti usando:

    kubectl get deployments,pods -n azure-arc

  2. Verificare che tutti i pod siano in uno stato Running.

    Output:

     NAME                                        READY   UP-TO-DATE   AVAILABLE   AGE
 deployment.apps/cluster-metadata-operator   1/1     1            1           13d
 deployment.apps/clusterconnect-agent        1/1     1            1           13d
 deployment.apps/clusteridentityoperator     1/1     1            1           13d
 deployment.apps/config-agent                1/1     1            1           13d
 deployment.apps/controller-manager          1/1     1            1           13d
 deployment.apps/extension-manager           1/1     1            1           13d
 deployment.apps/flux-logs-agent             1/1     1            1           13d
 deployment.apps/kube-aad-proxy              1/1     1            1           13d
 deployment.apps/metrics-agent               1/1     1            1           13d
 deployment.apps/resource-sync-agent         1/1     1            1           13d

 NAME                                            READY   STATUS    RESTARTS   AGE
 pod/cluster-metadata-operator-9568b899c-2stjn   2/2     Running   0          13d
 pod/clusterconnect-agent-576758886d-vggmv       3/3     Running   0          13d
 pod/clusteridentityoperator-6f59466c87-mm96j    2/2     Running   0          13d
 pod/config-agent-7cbd6cb89f-9fdnt               2/2     Running   0          13d
 pod/controller-manager-df6d56db5-kxmfj          2/2     Running   0          13d
 pod/extension-manager-58c94c5b89-c6q72          2/2     Running   0          13d
 pod/flux-logs-agent-6db9687fcb-rmxww            1/1     Running   0          13d
 pod/kube-aad-proxy-67b87b9f55-bthqv             2/2     Running   0          13d
 pod/metrics-agent-575c565fd9-k5j2t              2/2     Running   0          13d
 pod/resource-sync-agent-6bbd8bcd86-x5bk5        2/2     Running   0          13d

Per altre informazioni su questi agenti, vedere Panoramica dell'agente Kubernetes abilitato per Azure Arc.

Pulire le risorse

È possibile eliminare la risorsa Kubernetes abilitata per Azure Arc, tutte le risorse di configurazione associate e gli agenti in esecuzione nel cluster usando l'interfaccia della riga di comando di Azure usando il comando seguente:

az connectedk8s delete --name AzureArcTest1 --resource-group AzureArcTest

Se il processo di eliminazione non riesce, usare il comando seguente per forzare l'eliminazione (aggiungendo -y se si desidera ignorare il prompt di conferma):

az connectedk8s delete -n AzureArcTest1 -g AzureArcTest --force

È possibile usare questo comando anche se si verificano problemi durante la creazione di una nuova distribuzione del cluster (a causa della mancata rimozione completa delle risorse create in precedenza).

Nota

L'eliminazione della risorsa Kubernetes abilitata per Azure Arc tramite il portale di Azure rimuove tutte le risorse di configurazione associate, ma non rimuove gli agenti in esecuzione nel cluster. La procedura consigliata consiste nell'eliminare la risorsa Kubernetes abilitata per Azure Arc usando az connectedk8s delete anziché eliminare la risorsa nel portale di Azure.

Passaggi successivi