Distribuire un cluster Kubernetes con il motore del servizio Azure Kubernetes nell'hub di Azure Stack

È possibile distribuire un cluster Kubernetes nell'hub di Azure Stack da una macchina virtuale client che esegue il motore del servizio Azure Kubernetes. In questo articolo viene esaminata la scrittura di una specifica del cluster, la distribuzione di un cluster con il file apimodel.json e il controllo del cluster distribuendo MySQL con Helm.

Definire una specifica del cluster

È possibile specificare una specifica del cluster in un file di documento usando il formato JSON denominato modello API. Il motore del servizio Azure Kubernetes usa una specifica del cluster nel modello API per creare il cluster.

È possibile trovare esempi del modello API per il sistema operativo e il numero di versione del motore del servizio Azure Kubernetes per le versioni recenti nel motore del servizio Azure Kubernetes e il mapping delle immagini corrispondente.

  1. Trovare il numero di versione del motore del servizio Azure Kubernetes, ad esempio , v.0.63.0nella tabella .
  2. Nella tabella Api Model samples (Esempi di modelli API) selezionare e aprire il collegamento per il sistema operativo.
  3. Selezionare Non elaborato. È possibile usare l'URL nelle istruzioni seguenti.

Un URL del modello API può essere simile al seguente:

https://raw.githubusercontent.com/Azure/aks-engine-azurestack/master/examples/azure-stack/kubernetes-azurestack.json

Per ognuno degli esempi seguenti sostituire <URL for the API Model> con l'URL.

Aggiornare il modello API

Questa sezione esamina la creazione di un modello API per il cluster.

  1. Per iniziare, usare un file del modello di API dell'hub di Azure Stack per Linux o Windows. Dal computer è stato installato il motore del servizio Azure Kubernetes, eseguire:

    curl -o kubernetes-azurestack.json <URL for the API Model>
    

    Nota

    Se si è disconnessi, è possibile scaricare il file e copiarlo manualmente nel computer disconnesso in cui si prevede di modificarlo. È possibile copiare il file nel computer Linux usando strumenti come PuTTY o WinSCP.

  2. Per aprire il modello API in un editor, è possibile usare nano:

    nano ./kubernetes-azurestack.json
    

    Nota

    Se nano non è installato, è possibile installare nano in Ubuntu: sudo apt-get install nano.

  3. Nel file kubernetes-azurestack.json trovare orchestratorRelease e orchestratorVersion. Selezionare una delle versioni di Kubernetes supportate; è possibile trovare la tabella delle versioni nelle note sulla versione. Specificare come orchestratorRelease x.xx e orchestratorVersion come x.xx.x. Per un elenco delle versioni correnti, vedere Versioni del motore del servizio Azure Kubernetes supportate

  4. Trovare customCloudProfile e fornire l'URL al portale tenant. Ad esempio: https://portal.local.azurestack.external.

  5. Aggiungere "identitySystem":"adfs" se si usa AD FS. ad esempio:

        "customCloudProfile": {
            "portalURL": "https://portal.local.azurestack.external",
            "identitySystem": "adfs"
        },
    

    Nota

    Se si usa Microsoft Entra ID per il sistema di identità, non è necessario aggiungere il campo identitySystem .

  6. In masterProfileimpostare i campi seguenti:

    Campo Descrizione
    dnsPrefix Immettere una stringa univoca che servirà per identificare il nome host delle macchine virtuali. Ad esempio, un nome basato sul nome del gruppo di risorse.
    numero Immettere il numero di master desiderati per la distribuzione. Il valore minimo per una distribuzione a disponibilità elevata è 3, ma 1 è consentito per le distribuzioni non a disponibilità elevata.
    vmSize Immettere una dimensione supportata dall'hub di Azure Stack, ad esempio Standard_D2_v2.
    distribuzione Immettere aks-ubuntu-18.04 o aks-ubuntu-20.04.
  7. In agentPoolProfiles aggiornamento:

    Campo Descrizione
    numero Immettere il numero di agenti desiderati per la distribuzione. Il numero massimo di nodi da usare per ogni sottoscrizione è 50. Se si distribuiscono più cluster per sottoscrizione, assicurarsi che il numero totale di agenti non vada oltre 50. Assicurarsi di usare gli elementi di configurazione specificati nel file JSON del modello API di esempio.
    vmSize Immettere una dimensione supportata dall'hub di Azure Stack, ad esempio Standard_D2_v2.
    distribuzione Immettere aks-ubuntu-18.04o aks-ubuntu-20.04 Windows.
    Usare Windows per gli agenti che verranno eseguiti in Windows. Ad esempio, vedere kubernetes-windows.json
  8. In linuxProfile aggiornamento:

    Campo Descrizione
    adminUsername Immettere il nome utente amministratore della macchina virtuale.
    ssh Immettere la chiave pubblica che verrà usata per l'autenticazione SSH con le macchine virtuali. Usare ssh-rsa e quindi la chiave. Per istruzioni sulla creazione di una chiave pubblica, vedere Creare una chiave SSH per Linux.

    Se si esegue la distribuzione in una rete virtuale personalizzata, è possibile trovare istruzioni su come trovare e aggiungere la chiave e i valori necessari agli array appropriati nel modello API in Distribuire un cluster Kubernetes in una rete virtuale personalizzata.

    Nota

    Il motore del servizio Azure Kubernetes per l'hub di Azure Stack non consente di fornire certificati personalizzati per la creazione del cluster.

  9. Se si usa Windows, aggiornare windowsProfile i valori di adminUsername: e adminPassword:

    "windowsProfile": {
    "adminUsername": "azureuser",
    "adminPassword": "",
    "sshEnabled": true
    }
    

Altre informazioni sul modello API

  • Per un riferimento completo di tutte le opzioni disponibili nel modello API, vedere Definizioni di cluster.
  • Per informazioni dettagliate sulle opzioni specifiche per l'hub di Azure Stack, vedere le specifiche della definizione del cluster dell'hub di Azure Stack.

Aggiungere un certificato quando si usa ASDK

Se si distribuisce un cluster in Azure Stack Development Kit (ASDK) e si usa Linux, è necessario aggiungere il certificato radice all'archivio certificati attendibile della macchina virtuale client che esegue il motore del servizio Azure Kubernetes.

  1. Trovare il certificato radice nella macchina virtuale in questa directory: /var/lib/waagent/Certificates.pem.
  2. Copiare il file del certificato:
    sudo cp /var/lib/waagent/Certificates.pem /usr/local/share/ca-certificates/azurestacka.crt
    sudo update-ca-certificates
    

Distribuire un cluster Kubernetes

Dopo aver raccolto tutti i valori necessari nel modello API, è possibile creare il cluster. A questo punto è necessario:

Chiedere all'operatore hub di Azure Stack di:

  • Verificare l'integrità del sistema, suggerire l'esecuzione Test-AzureStack e lo strumento di monitoraggio hardware del fornitore OEM.
  • Verificare la capacità del sistema, incluse risorse quali memoria, archiviazione e indirizzi IP pubblici.
  • Specificare i dettagli della quota associata alla sottoscrizione in modo da poter verificare che sia ancora disponibile spazio sufficiente per il numero di macchine virtuali che si prevede di usare.

Procedere alla distribuzione di un cluster:

  1. Esaminare i parametri disponibili per il motore del servizio Azure Kubernetes nei flag dell'interfaccia della riga di comando dell'hub di Azure Stack.

    Parametro Esempio Descrizione
    azure-env AzureStackCloud Per indicare al motore del servizio Azure Kubernetes che la piattaforma di destinazione è l'hub di Azure Stack usare AzureStackCloud.
    identity-system adfs Facoltativo. Specificare la soluzione di gestione delle identità se si usa Active Directory Federated Services (AD FS).
    location local Nome dell'area per l'hub di Azure Stack. Per ASDK, l'area è impostata su local.
    resource-group kube-rg Immettere il nome di un nuovo gruppo di risorse o selezionare un gruppo di risorse esistente. Il nome della risorsa deve essere alfanumerico e minuscolo.
    api-model ./kubernetes-azurestack.json Percorso del file di configurazione del cluster o modello API.
    output-directory kube-rg Immettere il nome della directory per contenere il file di output apimodel.json e altri file generati.
    client-id xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx Immettere il GUID dell'entità servizio. ID client identificato come ID applicazione quando l'amministratore dell'hub di Azure Stack ha creato l'entità servizio.
    client-secret xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx Immettere il segreto dell'entità servizio. Il segreto client viene configurato durante la creazione del servizio.
    subscription-id xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx Immettere l'ID sottoscrizione. È necessario fornire una sottoscrizione per il tenant. La distribuzione nella sottoscrizione amministrativa non è supportata. Per altre informazioni, vedere Sottoscrivere un'offerta

    Ecco un esempio:

    Nota

    Per AKSe versione 0.75.3 e successive, il comando per distribuire un cluster del motore del servizio Azure Kubernetes è aks-engine-azurestack deploy.

    aks-engine deploy \
    --azure-env AzureStackCloud \
    --location <for asdk is local> \
    --resource-group kube-rg \
    --api-model ./kubernetes-azurestack.json \
    --output-directory kube-rg \
    --client-id xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx \
    --client-secret xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx \
    --subscription-id xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx \
    --identity-system adfs # required if using AD FS
    
  2. Se per qualche motivo l'esecuzione ha esito negativo dopo la creazione della directory di output, è possibile correggere il problema ed eseguire nuovamente il comando. Se si esegue nuovamente la distribuzione e si è usata la stessa directory di output in precedenza, il motore del servizio Azure Kubernetes restituirà un errore che informa che la directory esiste già. È possibile sovrascrivere la directory esistente usando il flag : --force-overwrite.

  3. Salvare la configurazione del cluster del motore del servizio Azure Kubernetes in un percorso protetto e crittografato.

    Individuare il file apimodel.json. Salvarlo in una posizione sicura. Questo file verrà usato come input in tutte le altre operazioni del motore del servizio Azure Kubernetes.

    Il file di apimodel.json generato contiene l'entità servizio, il segreto e la chiave pubblica SSH usata nel modello API di input. Il file include anche tutti gli altri metadati necessari al motore del servizio Azure Kubernetes per eseguire tutte le altre operazioni. Se si perde il file, il motore del servizio Azure Kubernetes non sarà in grado di configurare il cluster.

    I segreti non sono crittografati. Mantenere il file in un luogo crittografato e sicuro.

Verificare il cluster

Controllare il cluster connettendosi a kubectl, ottenere le informazioni e quindi ottenere gli stati dei nodi.

  1. Ottenere il kubeconfig file da connettere al piano di controllo.

    • Se è già kubectl stato installato, controllare il kubeconfig file per il cluster appena creato in questo percorso /kubeconfig/kubeconfig.jsondi directory . È possibile aggiungere alla /kubeconfig.json .kube directory e rinominarlo in "config" per accedere al nuovo cluster.
      Se non è stato installato kubectl, vedere Installare strumenti per installare lo strumento da riga di comando kubernetes. In caso contrario, seguire le istruzioni seguenti per accedere al cluster da uno dei nodi del piano di controllo.
  2. Ottenere l'indirizzo IP pubblico di uno dei nodi del piano di controllo usando il portale dell'hub di Azure Stack.

  3. Da un computer con accesso all'istanza dell'hub di Azure Stack connettersi tramite SSH al nuovo nodo del piano di controllo usando un client come PuTTY o MobaXterm.

  4. Per il nome utente SSH, usare "azureuser" e il file di chiave privata della coppia di chiavi fornita per la distribuzione del cluster.

  5. Verificare che gli endpoint del cluster siano in esecuzione:

    kubectl cluster-info
    

    L'output dovrebbe essere simile al seguente:

    Kubernetes master is running at https://democluster01.location.domain.com
    CoreDNS is running at https://democluster01.location.domain.com/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
    Metrics-server is running at https://democluster01.location.domain.com/api/v1/namespaces/kube-system/services/https:metrics-server:/proxy
    
  6. Esaminare quindi gli stati del nodo:

    kubectl get nodes
    

    L'output avrà un aspetto analogo al seguente:

    k8s-linuxpool-29969128-0   Ready      agent    9d    v1.15.5
    k8s-linuxpool-29969128-1   Ready      agent    9d    v1.15.5
    k8s-linuxpool-29969128-2   Ready      agent    9d    v1.15.5
    k8s-master-29969128-0      Ready      master   9d    v1.15.5
    k8s-master-29969128-1      Ready      master   9d    v1.15.5
    k8s-master-29969128-2      Ready      master   9d    v1.15.5
    

Risolvere i problemi di distribuzione del cluster

Quando si verificano errori durante la distribuzione di un cluster Kubernetes tramite il motore del servizio Azure Kubernetes, è possibile controllare:

  1. Si usano le credenziali dell'entità servizio corrette (SPN)?
  2. Il nome SPN ha un ruolo "Collaboratori" per la sottoscrizione dell'hub di Azure Stack?
  3. Si dispone di una quota sufficiente nel piano dell'hub di Azure Stack?
  4. L'istanza dell'hub di Azure Stack ha una patch o un aggiornamento applicato?

Per altre informazioni, vedere l'articolo Sulla risoluzione dei problemi nel repository GitHub Azure/aks-engine-azurestack .

Ruotare il segreto dell'entità servizio

Dopo la distribuzione del cluster Kubernetes con il motore del servizio Azure Kubernetes, l'entità servizio (SPN) viene usata per gestire le interazioni con Azure Resource Manager nell'istanza dell'hub di Azure Stack. A un certo punto, il segreto per questa entità servizio potrebbe scadere. Se il segreto scade, è possibile aggiornare le credenziali in base a:

  • Aggiornamento di ogni nodo con il nuovo segreto dell'entità servizio.
  • Oppure aggiornare le credenziali del modello API ed eseguire l'aggiornamento.

Aggiornare manualmente ogni nodo

  1. Ottenere un nuovo segreto per l'entità servizio dall'operatore cloud. Per istruzioni sull'hub di Azure Stack, vedere Usare un'identità dell'app per accedere alle risorse dell'hub di Azure Stack.
  2. Usare le nuove credenziali fornite dall'operatore cloud per aggiornare /etc/kubernetes/azure.json in ogni nodo. Dopo aver eseguito l'aggiornamento, riavviare sia kubele che kube-controller-manager.

Aggiornare il cluster con l'aggiornamento del motore del servizio Azure Kubernetes

In alternativa, è possibile sostituire le credenziali nella apimodel.json ed eseguire l'aggiornamento usando il file di .json aggiornato alla stessa versione di Kubernetes o successiva. Per istruzioni sull'aggiornamento del modello, vedere Aggiornare un cluster Kubernetes nell'hub di Azure Stack

Passaggi successivi