Condividi tramite

Avvio rapido: Connettere un cluster Kubernetes esistente ad Azure Arc

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, vedere Azure 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

Eseguire il comando seguente:

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

Risultato:

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 utilizzata 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

Risultato:

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 diverso, specificare --location <region> o -l <region> al momento di esecuzione del comando az connectedk8s connect.

Importante

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

Connettersi utilizzando un server proxy per il 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 il traffico in uscita.

  1. Nel computer di distribuzione impostare le variabili di ambiente necessarie per l'interfaccia della riga di comando di Azure per utilizzare il server proxy per il 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 utilizza solo HTTP, è possibile utilizzare 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 utilizzare il parametro --proxy-skip-range per specificare l'intervallo CIDR e gli endpoint delimitandoli da virgole in modo che qualsiasi comunicazione dagli agenti a questi endpoint non venga eseguita tramite il proxy in uscita. Come 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 è necessario 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, se si specifica solo un certificato attendibile, è possibile eseguire az connectedk8s connect con solo il parametro --proxy-cert specificato.

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

Se sono presenti più certificati attendibili, la catena di certificati (certificato foglia, certificato intermedio, certificato radice) deve essere combinata in un singolo file passato nel --proxy-cert parametro .

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.

Verificare la connessione al cluster

Eseguire il comando seguente:

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

Risultato:

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

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

Nota

Dopo l'onboarding del cluster, occorrono fino a dieci minuti affinché i metadati del cluster (come la versione del cluster e il numero di nodi) siano visualizzati nella pagina di panoramica della risorsa Kubernetes abilitata per Azure Arc nel portale di Azure.

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.

    Risultato:

     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 ed eventuali agenti in esecuzione nel cluster usando il comando seguente:

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

Se il processo di eliminazione non ha esito positivo, utilizzare il comando seguente per forzare l'eliminazione (aggiungendo -y se si vuole ignorare il prompt di conferma):

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

È possibile utilizzare 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. Per questo motivo, è consigliabile eliminare la risorsa Kubernetes abilitata per Azure Arc usando az connectedk8s delete anziché eliminare la risorsa nel portale di Azure.

Passaggi successivi