Collegare un nodo flex a un cluster AKS (anteprima)

Importante

Le funzionalità in anteprima di AKS sono disponibili in modalità self-service, su base volontaria. Le anteprime vengono fornite "così come sono" e "come disponibili" e sono escluse dai contratti di servizio e dalla garanzia limitata. Le anteprime di AKS sono coperte solo parzialmente dall'assistenza clienti nei limiti del possibile. Di conseguenza, queste funzionalità non sono destinate all'uso in produzione. Per altre informazioni, vedere gli articoli di supporto seguenti:

• Criteri di supporto di AKS
• Domande frequenti sul supporto tecnico di Azure

Dopo aver preparato il cluster Servizio Azure Kubernetes (AKS), la configurazione di rete, il pool di nodi flex, l'host e l'identità, inizializzare l'host e collegarlo al pool di destinazione.

In questo articolo, tu:

• Scaricare e verificare la versione del nodo flex.
• Inizializza l'host utilizzando l'identità Azure selezionata per recuperare i dati aggiornati del pool.
• Verifica il nodo Kubernetes, la macchina Azure, lo stato della rete e il servizio dell'agente.
• Convalidare il posizionamento del carico di lavoro, i callback kubernetes e la connettività tra nodi.

Eseguire i comandi di gestione in questo articolo in un ambiente Bash compatibile con Linux con gli strumenti e l'accesso alla rete necessari. Questo articolo definisce quell'ambiente il tuo ambiente Bash. Il computer separato che si unisce al cluster è l'host del nodo Flex; esegui i comandi lì solo quando un passaggio lo indica esplicitamente.

Per un cluster AKS privato, esegui tutti i comandi kubectl da un ambiente Bash in grado di risolvere e raggiungere il server API privato. È possibile eseguire i comandi di interfaccia della riga di comando di Azure, scaricamento degli artefatti, SSH e SCP dall'ambiente Bash se questo dispone degli accessi necessari ad Azure e all'host. La rete host del nodo Flex deve anche risolvere e raggiungere l'endpoint API privato.

Prima di iniziare

• Completa Configurare la rete e creare un pool di nodi flex in AKS.
• Completare la preparazione di un host e dell'identità di un nodo flex.
• Installa interfaccia della riga di comando di Azure, l'estensione aks-preview, una versione di kubectl che rientri in una versione secondaria di AKS_VERSION, jq, curl, sha256sum, un client OpenSSH e scp nell'ambiente Bash.
• Per un'identità gestita o un'entità servizio, usare un account Azure in grado di recuperare i dati di bootstrap per il pool di nodi flessibili selezionato.
• Assicurarsi che l'ambiente Bash possa raggiungere l'host del nodo flex tramite il percorso di gestione SSH approvato.
• Assicurarsi che l'host del nodo Flex possa raggiungere tramite HTTPS gli endpoint degli artefatti di rilascio e bootstrap restituiti nei dati di bootstrap del pool, Azure Resource Manager, Microsoft Entra ID e l'endpoint API di AKS selezionato.

Note

Non archiviare credenziali, certificati, chiavi private, token di accesso, dati bootstrap o contenuto kubeconfig nel file dell'ambiente condiviso.

Caricare l'ambiente di distribuzione

Avviare una nuova sessione Bash, identificare il file di ambiente e caricarlo. Sostituire <deployment-name> con l'etichetta di distribuzione usata negli articoli precedenti.

export FLEXNODE_DEPLOYMENT="<deployment-name>"
export FLEXNODE_ENV_FILE="${HOME}/.config/aks-flexnode/${FLEXNODE_DEPLOYMENT}.env"
test -s "${FLEXNODE_ENV_FILE}"
source "${FLEXNODE_ENV_FILE}"
export KUBECONFIG="${FLEXNODE_KUBECONFIG}"
install -d -m 0700 "${WORK_DIR:?Load the deployment environment first.}"

Il file di ambiente fornisce i valori di distribuzione condivisi letti da questo articolo, inclusa WORK_DIRla directory nell'ambiente Bash in cui questo articolo archivia i file scaricati e generati. Per impostazione predefinita, WORK_DIR è ~/.local/share/aksflexnode/<deployment-name>. L'articolo deriva tutte le altre variabili necessarie. Se non hai ancora creato il file dell'ambiente, completa prima Pianifica la distribuzione dei nodi flessibili. Non continuare oltre questo passaggio se la shell segnala un errore.

Impostare la sottoscrizione attiva e visualizzare le destinazioni Azure, Kubernetes e host:

az account set --subscription "${SUBSCRIPTION_ID}"

az aks show \
    --resource-group "${RESOURCE_GROUP}" \
    --name "${CLUSTER_NAME}" \
    --query "{Cluster:name,ResourceId:id,ApiServer:(privateFqdn || fqdn)}" \
    --output table

kubectl cluster-info

printf 'Recorded flex host: %s\n' "${FLEX_HOST_NAME}"
ssh -i "${SSH_PRIVATE_KEY_PATH}" "${FLEX_HOST_SSH_TARGET}" hostname

Verificare che ResourceId corrisponda a AKS_RESOURCE_ID, il nome host del piano di controllo Kubernetes corrisponde a ApiServer e il comando SSH restituisce FLEX_HOST_NAME. Se una destinazione non corrisponde, interrompi e correggi il file dell'ambiente, kubeconfig o la destinazione SSH prima di trasferire o eseguire i file.

Scaricare e verificare la versione del nodo flessibile

1. Identificare l'architettura host e selezionare l'archivio di versione corrispondente.

   HOST_ARCH="$(ssh \
       -i "${SSH_PRIVATE_KEY_PATH}" \
       "${FLEX_HOST_SSH_TARGET}" \
       uname -m)"
   export HOST_ARCH
   
   case "${HOST_ARCH}" in
       x86_64) export AGENT_ARCH="amd64" ;;
       aarch64|arm64) export AGENT_ARCH="arm64" ;;
       *)
           printf 'Unsupported host architecture: %s\n' "${HOST_ARCH}" >&2
           false
           ;;
   esac
   
   export AGENT_ARCHIVE="aks-flex-node-linux-${AGENT_ARCH}.tar.gz"
   printf 'Selected release archive: %s\n' "${AGENT_ARCHIVE}"
   

2. Scaricare l'archivio e il file manifesto dei checksum dalla versione selezionata.

   curl --fail --location --silent --show-error \
       --proto '=https' \
       --tlsv1.2 \
       "https://github.com/Azure/AKSFlexNode/releases/download/${AKS_FLEX_NODE_VERSION}/${AGENT_ARCHIVE}" \
       --output "${WORK_DIR}/${AGENT_ARCHIVE}"
   
   curl --fail --location --silent --show-error \
       --proto '=https' \
       --tlsv1.2 \
       "https://github.com/Azure/AKSFlexNode/releases/download/${AKS_FLEX_NODE_VERSION}/checksums.txt" \
       --output "${WORK_DIR}/checksums.txt"
   

3. Selezionare esattamente una voce di checksum per l'archivio e verificare il file.

   AGENT_CHECKSUM_ENTRY="$(awk \
       -v file="${AGENT_ARCHIVE}" \
       '$2 == file {print}' \
       "${WORK_DIR}/checksums.txt")"
   export AGENT_CHECKSUM_ENTRY
   
   test "$(printf '%s\n' "${AGENT_CHECKSUM_ENTRY}" |
       sed '/^$/d' |
       wc -l)" -eq 1
   
   (
       cd "${WORK_DIR:?Load the deployment environment first.}"
       printf '%s\n' "${AGENT_CHECKSUM_ENTRY}" |
           sha256sum --check --strict -
   )
   
   export AGENT_SHA256="${AGENT_CHECKSUM_ENTRY%% *}"
   test -n "${AGENT_SHA256}"
   

   Non continuare a meno che il comando checksum non segnala che l'archivio è OK.

4. Scaricare lo script bootstrap dallo stesso tag di versione e convalidarne la sintassi Bash.

   curl --fail --location --silent --show-error \
       --proto '=https' \
       --tlsv1.2 \
       "https://raw.githubusercontent.com/Azure/AKSFlexNode/${AKS_FLEX_NODE_VERSION}/scripts/bootstrap.sh" \
       --output "${WORK_DIR}/bootstrap.sh"
   
   chmod 0700 "${WORK_DIR}/bootstrap.sh"
   bash -n "${WORK_DIR}/bootstrap.sh"
   

   La release non pubblica attualmente un checksum separato per questo script. Scaricarlo senza reindirizzarlo tramite pipe a una shell, mantenerlo allineato, in termini di versione, all'archivio verificato dell'agente e interrompere l'operazione se il controllo di sintassi non va a buon fine.

Recuperare i dati di bootstrap del pool corrente

I percorsi dell'identità gestita e dell'entità servizio usano i dati bootstrap recuperati nell'ambiente Bash. Se è stata selezionata l'identità gestita di Azure Arc, ignorare questa sezione. Il comando bootstrap di Arc recupera nuovi dati tramite l'identità macchina di Arc.

Per l'identità gestita o l'entità servizio, recuperare i dati immediatamente prima di trasferire i file all'host. La risposta contiene un token bootstrap che scade dopo un'ora. Non stampare la risposta o archiviarla in note.

az aks nodepool get-bootstrap-data \
    --resource-group "${RESOURCE_GROUP}" \
    --cluster-name "${CLUSTER_NAME}" \
    --name "${FLEX_POOL_NAME}" \
    --output json \
    > "${WORK_DIR}/base-config.json"

chmod 0600 "${WORK_DIR}/base-config.json"
test -s "${WORK_DIR}/base-config.json"

Continuare quando ${WORK_DIR}/base-config.json esiste e non è vuoto. Completa il trasferimento e l'inizializzazione dell'host entro un'ora. Se il token scade, eseguire di nuovo il comando e sostituire il file precedente.

Trasferire i file e preparare l'host

1. Crea un file di handoff host non segreto.

   {
       printf 'export AGENT_ARCHIVE=%q\n' "${AGENT_ARCHIVE}"
       printf 'export AGENT_SHA256=%q\n' "${AGENT_SHA256}"
       printf 'export AKS_FLEX_NODE_VERSION=%q\n' "${AKS_FLEX_NODE_VERSION}"
       printf 'export AKS_RESOURCE_ID=%q\n' "${AKS_RESOURCE_ID}"
       printf 'export FLEX_POOL_NAME=%q\n' "${FLEX_POOL_NAME}"
       printf 'export FLEX_HOST_PRIVATE_IP=%q\n' "${FLEX_HOST_PRIVATE_IP}"
       printf 'export HOST_IDENTITY_CLIENT_ID=%q\n' "${HOST_IDENTITY_CLIENT_ID:-}"
       printf 'export SP_TENANT_ID=%q\n' "${SP_TENANT_ID:-}"
       printf 'export SP_CLIENT_ID=%q\n' "${SP_CLIENT_ID:-}"
   } > "${WORK_DIR}/host-bootstrap.env"
   
   chmod 0600 "${WORK_DIR}/host-bootstrap.env"
   

2. Copiare i file della versione verificati e il file di passaggio all'host.

   scp -i "${SSH_PRIVATE_KEY_PATH}" \
       "${WORK_DIR}/${AGENT_ARCHIVE}" \
       "${WORK_DIR}/bootstrap.sh" \
       "${WORK_DIR}/host-bootstrap.env" \
       "${FLEX_HOST_SSH_TARGET}:/tmp/"
   

3. Per l'identità gestita o l'entità servizio, copiare anche i dati di bootstrap protetti:

   scp -i "${SSH_PRIVATE_KEY_PATH}" \
       "${WORK_DIR}/base-config.json" \
       "${FLEX_HOST_SSH_TARGET}:/tmp/"
   

4. Connettiti all'host e avvia una shell di root:

   ssh -i "${SSH_PRIVATE_KEY_PATH}" "${FLEX_HOST_SSH_TARGET}"
   sudo -i
   

5. Caricare i valori non riservati del passaggio e verificare i file trasferiti:

   source /tmp/host-bootstrap.env
   chmod 0600 "/tmp/${AGENT_ARCHIVE}" /tmp/host-bootstrap.env
   chmod 0700 /tmp/bootstrap.sh
   bash -n /tmp/bootstrap.sh
   printf '%s  %s\n' \
       "${AGENT_SHA256}" \
       "/tmp/${AGENT_ARCHIVE}" |
       sha256sum --check --strict -
   

   Continuare quando il comando checksum segnala che l'archivio è OK. Interrompere se il checksum o il controllo della sintassi dello script fallisce.

6. Per l'identità gestita o l'entità servizio, installare i dati di bootstrap:

   install -d -o root -g root -m 0700 /etc/aks-flex-node
   install -o root -g root -m 0600 \
       /tmp/base-config.json \
       /etc/aks-flex-node/base-config.json
   test -s /etc/aks-flex-node/base-config.json
   

Inizializza l'host

Completare solo la sezione corrispondente all'identità configurata nell'articolo precedente.

identità gestita di Azure Arc

Usare questa sezione solo dopo che la risorsa macchina Arc corrisponde all'host SSH, himdsd è attiva, la verifica HIMDS restituisce HTTP 200 per la risorsa AKS esatta e l'assegnazione di ruolo con ambito AKS è presente, come verificato nell'articolo precedente. Questo percorso recupera dati bootstrap aggiornati di recente tramite l'identità macchina di Arc e non usa il file base-config.json presente nell'ambiente Bash.

CONFIG_OVERRIDES="$(jq -cn \
    --arg nodeIP "${FLEX_HOST_PRIVATE_IP}" \
    '{node:{kubelet:{nodeIP:$nodeIP}}}')"
export CONFIG_OVERRIDES

bash /tmp/bootstrap.sh \
    --auth arc \
    --fetch-bootstrap-data \
    --cluster-resource-id "${AKS_RESOURCE_ID}" \
    --agent-pool-name "${FLEX_POOL_NAME}" \
    --agent-url "file:///tmp/${AGENT_ARCHIVE}" \
    --agent-sha256 "${AGENT_SHA256}" \
    --config-overrides "${CONFIG_OVERRIDES}"

Continua quando l'output riporta Arc preflight: OK, la registrazione della macchina è completata e lo script di bootstrap segnala che il servizio dell'agente del nodo flex è stato avviato. Se bootstrap non riesce a recuperare i dati, verifica la connessione ad Arc, himdsdl'assegnazione di ruolo con ambito AKS e l'accesso dell'host ad Azure Resource Manager.

Entità servizio

Prima di continuare, assicurati che il certificato PEM combinato e la chiave privata siano disponibili sull'host in /etc/aks-flex-node/credentials/sp-client-certificate tramite il processo approvato di gestione delle credenziali. La directory delle credenziali deve essere di proprietà di root con permessi 700. Non archiviare le credenziali o il relativo percorso nel file dell'ambiente condiviso.

Nella shell root dell'host, impostare il percorso del certificato e verificarne il proprietario e le autorizzazioni:

export FLEX_SP_CLIENT_CERTIFICATE_FILE="/etc/aks-flex-node/credentials/sp-client-certificate"
test -s "${FLEX_SP_CLIENT_CERTIFICATE_FILE}"
stat -c '%U %G %a %n' "${FLEX_SP_CLIENT_CERTIFICATE_FILE}"

Continuare solo quando il file esiste, è di proprietà di root roote dispone delle autorizzazioni 600. Mantienilo disponibile dopo il bootstrap perché l'agente in esecuzione lo usa per la riconciliazione della macchina Azure.

Eseguire bootstrap con il file protetto base-config.json recuperato nell'ambiente Bash:

env AKS_FLEX_NODE_BASE_CONFIG_FILE=/etc/aks-flex-node/base-config.json \
    bash /tmp/bootstrap.sh \
    --auth service-principal \
    --sp-tenant-id "${SP_TENANT_ID}" \
    --sp-client-id "${SP_CLIENT_ID}" \
    --sp-client-certificate-file "${FLEX_SP_CLIENT_CERTIFICATE_FILE}" \
    --agent-url "file:///tmp/${AGENT_ARCHIVE}" \
    --agent-sha256 "${AGENT_SHA256}"

Continua quando viene completata la registrazione della macchina e lo script di bootstrap segnala che il servizio dell'agente del nodo flex è stato avviato. Se il bootstrap non riesce, non rimuovere le credenziali dell’entità servizio finché l’host rimane collegato o l’agente le utilizza.

Controllare la configurazione visualizzata dell'entità servizio

Eseguite i comandi nella shell root dell'host dopo il completamento corretto del processo di bootstrap.

Gli identificatori dell'entità servizio e il file di certificato costituiscono input per il processo di bootstrap. Lo script li unisce ai dati bootstrap del pool per produrre la configurazione dell'agente:

File	Purpose	Manipolazione
/etc/aks-flex-node/base-config.json	Dati di bootstrap del pool recuperati prima del collegamento, incluso un token di bootstrap di breve durata.	Mantieni protetto; non stampare o condividere il contenuto.
/etc/aks-flex-node/config.json	È stato eseguito il rendering della configurazione del nodo flex, inclusi il cluster e il pool di destinazione, le impostazioni dei nodi, le origini degli artefatti e le impostazioni di autenticazione Azure.	Di proprietà di root con permessi 0600; non stampare o condividere il file completo.
/etc/aks-flex-node/credentials/sp-client-certificate	Certificato PEM combinato e chiave privata usata dall'agente in esecuzione.	Di proprietà della radice con modalità 0600 nella directory delle credenziali protette; mantenere mentre è collegato.

Nello script bootstrap.sh per la versione dell'agente che la distribuzione aggiunge in AKS_FLEX_NODE_VERSION, --sp-client-certificate-file scrive il percorso del certificato in azure.servicePrincipal.clientSecretFile. Nonostante il nome, questo campo fa riferimento al file di certificato in questo flusso di lavoro, non a un valore del segreto client. Non rinominarlo in clientCertificateFile. Lo script rimuove azure.managedIdentity e imposta azure.arc.enabled su false quando si seleziona l'autenticazione tramite service principal.

Nell'esempio seguente è illustrata la forma di una configurazione dell'entità servizio basata su certificati. Non è uno schema di configurazione completo o un file da copiare in un host. Continuare a generare la configurazione con lo script bootstrap corrispondente alla versione.

{
  "azure": {
    "bootstrapToken": {
      "token": "<redacted-bootstrap-token>"
    },
    "resourceManagerEndpoint": "https://management.azure.com",
    "targetAgentPoolName": "<flex-node-pool-name>",
    "targetCluster": {
      "resourceId": "<aks-cluster-resource-id>"
    },
    "arc": {
      "enabled": false
    },
    "servicePrincipal": {
      "tenantId": "<microsoft-entra-tenant-id>",
      "clientId": "<application-client-id>",
      "clientSecretFile": "/etc/aks-flex-node/credentials/sp-client-certificate"
    }
  },
  "components": {
    "kubernetes": "<kubernetes-version-from-bootstrap-data>"
  },
  "networking": {
    "dnsServiceIP": "<kubernetes-dns-service-ip>"
  },
  "node": {
    "kubelet": {
      "caCertData": "<cluster-ca-data>",
      "clusterFQDN": "<aks-api-server-fqdn>"
    },
    "labels": {
      "pool-generation": "initial"
    },
    "maxPods": 75,
    "taints": [
      "pool-generation=initial:NoSchedule"
    ]
  },
  "bootstrap": {
    "ociImage": "<published-root-filesystem-artifact-url>",
    "offlineArtifacts": {
      "source": "<published-kubernetes-bootstrap-artifact-url>"
    }
  },
  "agent": {
    "nodeName": "<linux-host-name>"
  }
}

Il token di bootstrap di Kubernetes e l'entità servizio di Azure hanno scopi diversi. Il token instaura il rapporto di trust iniziale di Kubernetes; il service principal fornisce un'autenticazione Azure persistente. L'ID oggetto dell'entità servizio utilizzato per l'assegnazione del ruolo di Azure non è l'ID client dell'applicazione archiviato in questa configurazione.

1. Ispeziona solo un insieme consentito di campi non segreti di destinazione e identità. Non sostituire questa proiezione con cat o jq . nella configurazione completa.

   jq '{
       azure: {
           targetCluster: {resourceId: .azure.targetCluster.resourceId},
           targetAgentPoolName: .azure.targetAgentPoolName,
           arc: {enabled: .azure.arc.enabled},
           servicePrincipal: {
               tenantId: .azure.servicePrincipal.tenantId,
               clientId: .azure.servicePrincipal.clientId,
               clientSecretFile: .azure.servicePrincipal.clientSecretFile
           }
       },
       agent: {nodeName: .agent.nodeName}
   }' /etc/aks-flex-node/config.json
   

   Verificare il cluster, il pool, il nome host, l'ID tenant, l'ID client dell'applicazione e il percorso del certificato previsti. Questi campi non sono credenziali, ma esaminano gli identificatori di risorsa prima di condividere l'output di diagnostica.

2. Verificare che la configurazione generata selezioni l'entità servizio e il certificato previsti, con le altre modalità di identità Azure disabilitate.

   if jq -e \
       --arg tenantId "${SP_TENANT_ID}" \
       --arg clientId "${SP_CLIENT_ID}" \
       --arg certificateFile "${FLEX_SP_CLIENT_CERTIFICATE_FILE}" \
       '
       .azure.servicePrincipal.tenantId == $tenantId and
       .azure.servicePrincipal.clientId == $clientId and
       .azure.servicePrincipal.clientSecretFile == $certificateFile and
       (.azure | has("managedIdentity") | not) and
       .azure.arc.enabled == false
       ' /etc/aks-flex-node/config.json >/dev/null; then
       printf 'Service principal configuration matches the selected certificate identity.\n'
   else
       printf 'Service principal configuration mismatch; stop and review bootstrap inputs.\n' >&2
       false
   fi
   

   Arrestare se il controllo non riesce. Non modificare manualmente il file generato per ignorare una mancata corrispondenza dell'identità.

3. Verificare le autorizzazioni per la configurazione e il file di certificato.

   stat -c '%U %G %a %n' \
       /etc/aks-flex-node/config.json \
       "${FLEX_SP_CLIENT_CERTIFICATE_FILE}"
   

   Entrambi i file devono essere di proprietà di root root con autorizzazioni 600. Questa ispezione conferma la configurazione selezionata; I controlli di nodo, computer e carico di lavoro seguenti convalidano il comportamento di runtime.

identità gestita della macchina virtuale Azure

Per un'identità gestita assegnata dal sistema, HOST_IDENTITY_CLIENT_ID rimane vuota. Un'identità gestita assegnata dall'utente usa l'ID client registrato nell'ambiente condiviso. Entrambe le opzioni usano il file protetto base-config.json recuperato nell'ambiente Bash.

Per un'identità gestita assegnata dal sistema, eseguire:

env AKS_FLEX_NODE_BASE_CONFIG_FILE=/etc/aks-flex-node/base-config.json \
    bash /tmp/bootstrap.sh \
    --auth msi \
    --agent-url "file:///tmp/${AGENT_ARCHIVE}" \
    --agent-sha256 "${AGENT_SHA256}"

Per un'identità gestita assegnata dall'utente, aggiungere il relativo ID client:

env AKS_FLEX_NODE_BASE_CONFIG_FILE=/etc/aks-flex-node/base-config.json \
    bash /tmp/bootstrap.sh \
    --auth msi \
    --msi-client-id "${HOST_IDENTITY_CLIENT_ID}" \
    --agent-url "file:///tmp/${AGENT_ARCHIVE}" \
    --agent-sha256 "${AGENT_SHA256}"

Continua quando viene completata la registrazione della macchina e lo script di bootstrap segnala che il servizio dell'agente del nodo flex è stato avviato.

Rimuovere i file di versione temporanea

Dopo che bootstrap ha avuto esito positivo, rimuovere lo script temporaneo, l'archivio e il file handoff dall'host:

rm -f \
    "/tmp/${AGENT_ARCHIVE}" \
    /tmp/bootstrap.sh \
    /tmp/base-config.json \
    /tmp/host-bootstrap.env
exit
exit

Il primo exit esce dalla shell di root. Il secondo chiude la sessione SSH e torna all'ambiente Bash.

Rimuovere le copie nell'ambiente Bash:

rm -f \
    "${WORK_DIR:?Load the deployment environment first.}/${AGENT_ARCHIVE}" \
    "${WORK_DIR}/bootstrap.sh" \
    "${WORK_DIR}/base-config.json" \
    "${WORK_DIR}/host-bootstrap.env" \
    "${WORK_DIR}/checksums.txt"

Mantieni /etc/aks-flex-node e le credenziali del service principal finché l'host rimane associato. L'agente in esecuzione usa questa configurazione per la riconciliazione dei nodi e di Azure Machine.

Verificare il nodo Kubernetes

Impostare il nome del nodo sul nome host Linux registrato nell'ambiente condiviso. Prima di tutto, attendere che l'oggetto Node venga creato e quindi attendere che diventi pronto:

export FLEX_NODE_NAME="$(printf '%s' "${FLEX_HOST_NAME}" | tr -d '[:space:]' | tr '[:upper:]' '[:lower:]')"

kubectl wait \
    --for=create \
    "node/${FLEX_NODE_NAME}" \
    --timeout=5m

kubectl wait \
    --for=condition=Ready \
    "node/${FLEX_NODE_NAME}" \
    --timeout=10m

kubectl get node "${FLEX_NODE_NAME}" -o wide

Continuare quando il nodo è Ready. Se il nodo non viene creato o non è pronto, verificare l'output bootstrap, la connettività API e il servizio agente prima di riprovare a eseguire il bootstrap.

Verificare la risorsa Azure Machine

1. Elenca le macchine nel pool di nodi flex di destinazione.

   az aks machine list \
       --resource-group "${RESOURCE_GROUP}" \
       --cluster-name "${CLUSTER_NAME}" \
       --nodepool-name "${FLEX_POOL_NAME}" \
       --query "[].{name:name,state:properties.provisioningState,nodeName:properties.kubernetes.nodeName,version:properties.kubernetes.currentOrchestratorVersion}" \
       --output table
   

2. Trovare il computer che ha registrato il nodo Kubernetes preparato:

   FLEX_MACHINE_NAME="$(az aks machine list \
       --resource-group "${RESOURCE_GROUP}" \
       --cluster-name "${CLUSTER_NAME}" \
       --nodepool-name "${FLEX_POOL_NAME}" \
       --query "[?properties.kubernetes.nodeName=='${FLEX_NODE_NAME}'].name | [0]" \
       --output tsv)"
   export FLEX_MACHINE_NAME
   
   printf 'Machine: %s\n' "${FLEX_MACHINE_NAME}"
   

   Continuare quando il comando restituisce esattamente un solo nome della macchina.

3. Mostra la macchina:

   az aks machine show \
       --resource-group "${RESOURCE_GROUP}" \
       --cluster-name "${CLUSTER_NAME}" \
       --nodepool-name "${FLEX_POOL_NAME}" \
       --machine-name "${FLEX_MACHINE_NAME}" \
       --output yaml
   

   Continua quando la macchina esiste, fa riferimento a FLEX_NODE_NAME e riporta uno stato di provisioning riuscito. Registrare il nome della macchina per le operazioni del ciclo di vita:

   set_flexnode_env FLEX_MACHINE_NAME "${FLEX_MACHINE_NAME}"
   

Verifica della rete dei nodi Flex

1. Visualizzare il flex site, il pod CIDR e la chiave pubblica di WireGuard.

   kubectl get node "${FLEX_NODE_NAME}" \
       -L net.unbounded-cloud.io/site \
       -o wide
   
   kubectl get node "${FLEX_NODE_NAME}" \
       -o jsonpath='{.metadata.name}{" site="}{.metadata.labels.net\.unbounded-cloud\.io/site}{" podCIDR="}{.spec.podCIDR}{" wg="}{.metadata.annotations.net\.unbounded-cloud\.io/wg-pubkey}{"\n"}'
   

2. Verificare i Siti e le relative risorse di rete di Unbounded-Net.

   kubectl get \
       sites,sitenodeslices,gatewaypools,sitegatewaypoolassignments,gatewaypoolpeerings \
       -o wide
   

3. Visualizza i pod Unbounded-Net assegnati al nodo flex.

   kubectl get pods --all-namespaces \
       --field-selector "spec.nodeName=${FLEX_NODE_NAME}" \
       -o wide
   

Non procedere con la convalida del carico di lavoro a meno che:

• Il nodo è Ready.
• Il sito è il sito Flex Unbounded-Net configurato nell'articolo sul networking.
• Il CIDR del pod appartiene all'intervallo previsto FLEX_POD_CIDR.
• La chiave pubblica WireGuard viene popolata.
• cluster-flex-private-l3 SitePeering fa riferimento ai cluster e flex-site siti.
• Ogni pod di rete non associata restituito nel nodo è Running.
• Per una topologia pubblica WireGuard, è presente il peering previsto del pool di gateway.

Verificare l'agente del nodo flex

Attendere fino a un minuto prima che il servizio diventi attivo. In caso contrario, visualizzare lo stato del servizio e i log recenti:

ssh -i "${SSH_PRIVATE_KEY_PATH}" "${FLEX_HOST_SSH_TARGET}" \
    'set -euo pipefail
     for attempt in {1..12}; do
         if sudo systemctl is-active --quiet aks-flex-node-agent; then
             sudo systemctl show aks-flex-node-agent \
                 -p ActiveState \
                 -p SubState \
                 -p Result \
                 -p NRestarts
             exit 0
         fi
         sleep 5
     done

     sudo systemctl show aks-flex-node-agent \
         -p ActiveState \
         -p SubState \
         -p Result \
         -p NRestarts
     sudo journalctl -u aks-flex-node-agent --no-pager -n 80
     exit 1'

Continuare quando l'output contiene ActiveState=active, SubState=runninge Result=success.

Se l'agente si riavvia ripetutamente perché non riesce a elencare le risorse MachineOperation, torna al passaggio temporaneo RBAC del daemon Flex in Configurare la rete e creare un pool di nodi Flex in AKS, verifica che il ruolo e il binding esistano e quindi riavvia l'agente:

ssh -i "${SSH_PRIVATE_KEY_PATH}" "${FLEX_HOST_SSH_TARGET}" \
    'sudo systemctl restart aks-flex-node-agent'

Convalidare il posizionamento e la connettività del carico di lavoro

Creare un carico di lavoro di convalida

Creare uno spazio dei nomi dedicato. Se questo spazio dei nomi esiste già, eliminare gli elementi della precedente esecuzione della convalida prima di riprovare.

export VALIDATION_NAMESPACE="flex-node-validation"

if kubectl get namespace "${VALIDATION_NAMESPACE}" >/dev/null 2>&1; then
    printf 'Validation namespace already exists: %s\n' \
        "${VALIDATION_NAMESPACE}" >&2
    false
fi

kubectl create namespace "${VALIDATION_NAMESPACE}"
kubectl label namespace "${VALIDATION_NAMESPACE}" \
    app.kubernetes.io/managed-by=flex-node-article

Creare un server HTTP che l'utilità di pianificazione Kubernetes inserisce nel nodo flex ed esporla tramite un servizio ClusterIP:

kubectl --namespace "${VALIDATION_NAMESPACE}" run flex-http-server \
    --image=busybox:1.36 \
    --restart=Never \
    --labels app=flex-http \
    --overrides="{\"spec\":{\"nodeSelector\":{\"kubernetes.io/hostname\":\"${FLEX_NODE_NAME}\"},\"tolerations\":[{\"operator\":\"Exists\"}]}}" \
    --command -- sh -c \
    'mkdir -p /www; echo flex-network-ok >/www/index.html; exec httpd -f -p 8080 -h /www'

kubectl --namespace "${VALIDATION_NAMESPACE}" wait \
    --for=condition=Ready \
    pod/flex-http-server \
    --timeout=3m

kubectl --namespace "${VALIDATION_NAMESPACE}" expose pod flex-http-server \
    --name=flex-http-service \
    --port=8080 \
    --target-port=8080

Verificare i callback e la connettività del servizio locale

Controllare i log e l'esecuzione dei comandi usando il percorso di callback del server API Kubernetes:

kubectl --namespace "${VALIDATION_NAMESPACE}" logs flex-http-server --tail=5
kubectl --namespace "${VALIDATION_NAMESPACE}" exec flex-http-server -- \
    sh -c 'printf "exec-callback-ok\n"'

Recupera il ClusterIP e richiedi il servizio dal workload del nodo flex:

SERVICE_IP="$(kubectl --namespace "${VALIDATION_NAMESPACE}" \
    get service flex-http-service \
    --output jsonpath='{.spec.clusterIP}')"
export SERVICE_IP

kubectl --namespace "${VALIDATION_NAMESPACE}" exec flex-http-server -- \
    wget -qO- "http://${SERVICE_IP}:8080"

La risposta prevista è:

flex-network-ok

Verifica il port forwarding

Nel terminale corrente inoltrare una porta locale tramite il server API Kubernetes. Questo comando usa l'ambiente di distribuzione e kubeconfig caricato in precedenza:

kubectl --namespace "${VALIDATION_NAMESPACE}" \
    port-forward pod/flex-http-server 18080:8080

In un secondo terminale, richiedi l'endpoint reindirizzato:

curl -fsS http://127.0.0.1:18080

La risposta prevista è flex-network-ok. Premere CTRL+C nel primo terminale dopo il controllo.

Verificare la connettività da un nodo gestito da AKS

Trovare un nodo di sistema pronto gestito da AKS:

SYSTEM_NODE="$(kubectl get nodes \
    --selector agentpool=systempool \
    --output json |
    jq -r '
        .items[]
        | select(any(.status.conditions[];
            .type == "Ready" and .status == "True"))
        | .metadata.name
    ' |
    head -n 1)"
export SYSTEM_NODE

test -n "${SYSTEM_NODE}"
printf 'Managed-node test target: %s\n' "${SYSTEM_NODE}"

Eseguite un pod client su quel nodo e verificate la risposta prevista:

kubectl --namespace "${VALIDATION_NAMESPACE}" run system-http-client \
    --image=busybox:1.36 \
    --restart=Never \
    --overrides="{\"spec\":{\"nodeSelector\":{\"kubernetes.io/hostname\":\"${SYSTEM_NODE}\"}}}" \
    --command -- sh -c \
    "test \"\$(wget -qO- http://${SERVICE_IP}:8080)\" = flex-network-ok"

kubectl --namespace "${VALIDATION_NAMESPACE}" wait \
    --for=jsonpath='{.status.phase}'=Succeeded \
    pod/system-http-client \
    --timeout=3m

kubectl --namespace "${VALIDATION_NAMESPACE}" \
    get pod flex-http-server system-http-client -o wide

Un nodo Kubernetes nello stato Ready indica la registrazione del nodo. Di per sé, non dimostra la rete dei carichi di lavoro, le operazioni di callback o le operazioni del ciclo di vita di Azure.

Pulire il carico di lavoro di convalida

Rimuovi solo le risorse temporanee che hai creato in questo articolo.

kubectl delete namespace "${VALIDATION_NAMESPACE}"

Passo successivo

Successivamente, gestire, aggiornare, eseguire l'upgrade di o rimuovere il nodo flex associato.