Rattacher un nœud flexible à un cluster AKS (version préliminaire)

Important

Les fonctionnalités d’évaluation AKS sont disponibles en libre-service et font l’objet d’un abonnement. Les versions préliminaires sont fournies « en l’état » et « selon leur disponibilité » et ne sont pas couvertes par les accords de niveau de service ni par la garantie limitée. Les versions préliminaires d’AKS sont partiellement couvertes par le support client, dans la limite du raisonnable. Par conséquent, ces fonctionnalités ne sont pas destinées à une utilisation en production. Pour plus d’informations, consultez les articles de support suivants :

• Stratégies de support AKS
• FAQ du support Azure

Après avoir préparé le cluster Azure Kubernetes Service (AKS), la mise en réseau, le pool de nœuds flexibles, l’hôte et l’identité, démarrez l’hôte et attachez-le au pool cible.

Dans cet article, vous :

• Téléchargez et vérifiez la version du nœud flexible.
• Démarrez l’hôte à l’aide de son identité de Azure sélectionnée pour récupérer des données de pool fraîches.
• Vérifiez le nœud Kubernetes, Azure Machine, l’état réseau et le service d’agent.
• Validez le placement des charges de travail, les rappels Kubernetes et la connectivité entre nœuds.

Exécutez les commandes de gestion dans cet article dans un environnement Bash compatible Linux qui dispose des outils et de l’accès réseau requis. Cet article désigne cet environnement comme votre environnement Bash. L’ordinateur distinct qui rejoint le cluster est l’hôte de nœud Flex ; exécutez des commandes sur celui-ci uniquement lorsqu’une étape vous l’indique explicitement.

Pour un cluster AKS privé, exécutez chaque kubectl commande à partir d’un environnement Bash capable de résoudre et d’atteindre le serveur d’API privé. Vous pouvez exécuter des commandes Azure CLI, de téléchargement d’artefacts, SSH et SCP à partir de votre environnement Bash lorsqu’il dispose des Azure et de l’accès hôte requis. Le réseau hôte du nœud Flex doit également résoudre et atteindre le point de terminaison de l’API privée.

Avant de commencer

• Configurez la mise en réseau et créez un pool de nœuds flexibles dans AKS.
• Terminez la Préparation de l’hôte et de l'identité d’un hôte flexible.
• Installez Azure CLI, l’extensionaks-preview, une kubectl version dans une version mineure de AKS_VERSION, jqcurl, , sha256sumun client OpenSSH et scp dans votre environnement Bash.
• Pour l’identité managée ou le principal du service, utilisez un compte Azure capable de récupérer les données d’amorçage du pool de nœuds flex sélectionné.
• Vérifiez que votre environnement Bash peut atteindre l’hôte de nœud flexible via le chemin de gestion SSH approuvé.
• Assurez-vous que l’hôte du nœud flexible peut atteindre, via HTTPS, les points de terminaison des artefacts de publication et d’amorçage renvoyés dans les données d’amorçage du pool, Azure Resource Manager, Microsoft Entra ID, ainsi que le point de terminaison de l’API AKS sélectionné.

Note

Ne stockez pas les informations d’identification, les certificats, les clés privées, les jetons d’accès, les données de démarrage ou le contenu kubeconfig dans le fichier d’environnement partagé.

Charger l’environnement de déploiement

Démarrez une nouvelle session Bash, identifiez le fichier d’environnement et chargez-le. Remplacez <deployment-name> par l’étiquette de déploiement utilisée dans les articles précédents.

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.}"

Le fichier d’environnement fournit les valeurs de déploiement partagées lues par cet article, notamment WORK_DIRle répertoire dans votre environnement Bash où cet article stocke les fichiers téléchargés et générés. Par défaut, WORK_DIR est ~/.local/share/aksflexnode/<deployment-name>. L’article dérive toutes les autres variables dont elle a besoin. Si vous n’avez pas encore créé le fichier d’environnement, commencez par planifier votre déploiement de nœuds flexibles . Ne continuez pas au-delà de cette étape si l’interpréteur de commandes signale une erreur.

Définissez l’abonnement actif et affichez les cibles Azure, Kubernetes et hôte :

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

Vérifiez que ResourceId correspond AKS_RESOURCE_ID, que le nom d’hôte du plan de contrôle Kubernetes correspond à ApiServer et que la commande SSH retourne FLEX_HOST_NAME. Si une cible ne correspond pas, arrête et corrige le fichier d’environnement, kubeconfig ou la cible SSH avant de transférer ou d’exécuter des fichiers.

Télécharger et vérifier la version publiée du nœud flex

1. Identifiez l’architecture de l’hôte et sélectionnez l’archive de mise en production correspondante.

   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. Téléchargez le manifeste d’archivage et de somme de contrôle à partir de la version sélectionnée.

   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. Sélectionnez exactement une entrée de somme de contrôle pour l’archive et vérifiez le fichier.

   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}"
   

   Ne continuez pas à moins que la commande de calcul de somme de contrôle n’indique que l’archive est OK.

4. Téléchargez le script d’amorçage depuis le même tag de version et validez sa syntaxe 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"
   

   Cette version ne fournit actuellement pas de somme de contrôle distincte pour ce script. Téléchargez-le sans le faire passer à un interpréteur de commandes, veillez à ce que sa version corresponde à celle de l’archive vérifiée de l’agent, et arrêtez-vous si la vérification syntaxique échoue.

Récupérer les données d’initialisation du pool actuel

Les chemins d’identité managée et de principal de service utilisent des données de démarrage que vous récupérez dans votre environnement Bash. Si vous avez sélectionné Azure Arc identité managée, ignorez cette section. La commande bootstrap d’Arc récupère des données récentes via l’identité de machine Arc.

Pour l’identité managée ou le principal de service, récupérez les données immédiatement avant de transférer des fichiers vers l’hôte. La réponse contient un jeton de démarrage qui expire après une heure. N’imprimez pas la réponse ou ne la stockez pas dans les notes.

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"

Continuez si ${WORK_DIR}/base-config.json existe et n’est pas vide. Effectuez le transfert et l’hôte bootstrap dans un délai d’une heure. Si le jeton expire, réexécutez la commande et remplacez l’ancien fichier.

Transférer des fichiers et préparer l’hôte

1. Créez un fichier de transfert d’hôte non-secret.

   {
       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. Copiez les fichiers de version vérifiés et le fichier de transmission vers l’hôte.

   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. Pour une identité managée ou un principal de service, copiez également les données d’amorçage protégées :

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

4. Connectez-vous à l’hôte et démarrez un shell root :

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

5. Chargez les valeurs de transfert non-secret et validez les fichiers transférés :

   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 -
   

   Poursuivez lorsque la commande de calcul de somme de contrôle indique que l’archive est OK. Arrêtez si la somme de contrôle ou la vérification de la syntaxe du script échoue.

6. Pour l’identité managée ou le principal de service, installez les données d’amorçage :

   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
   

Initialiser l’hôte

Terminez uniquement la section qui correspond à l’identité configurée dans l’article précédent.

identité managée Azure Arc

Utilisez cette section uniquement après avoir vérifié, comme indiqué dans l’article précédent, que la ressource de machine Arc correspond à l’hôte SSH, que himdsd est actif, que la vérification HIMDS renvoie un code HTTP 200 pour la ressource AKS exacte, et que l’attribution de rôle limitée à AKS est présente. Ce chemin récupère de nouvelles données de démarrage via l’identité de l’ordinateur Arc et n’utilise pas le base-config.json fichier à partir de votre environnement 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}"

Continuez lorsque la sortie affiche Arc preflight: OK, que l’enregistrement de la machine est terminé et que le script d’initialisation indique que le service de l’agent de nœud Flex a démarré. Si bootstrap ne peut pas récupérer de données, vérifiez la connexion à Arc, himdsd, l’attribution de rôle limitée à AKS et l’accès de l’hôte à Azure Resource Manager.

Service principal

Avant de continuer, mettez le certificat PEM combiné et la clé privée à disposition sur l’hôte à l’emplacement /etc/aks-flex-node/credentials/sp-client-certificate au moyen de votre processus approuvé de gestion des informations d’identification. Le répertoire des identifiants doit appartenir à root avec les autorisations 700. Ne stockez pas les informations d’identification ou son chemin d’accès dans le fichier d’environnement partagé.

Dans l’interpréteur de commandes racine de l’hôte, définissez le chemin du certificat et vérifiez son propriétaire et ses autorisations :

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}"

Continuez uniquement lorsque le fichier existe, appartient à root root et a les autorisations 600. Conservez-le disponible après l’amorçage, car l’agent en cours d’exécution l’utilise pour la réconciliation de la machine Azure.

Exécutez le démarrage avec le fichier protégé base-config.json que vous avez récupéré dans votre environnement 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}"

Continuez une fois l’enregistrement de la machine terminé et lorsque le script d’amorçage signale que le service de l’agent de nœud Flex a démarré. Si le démarrage échoue, ne supprimez pas les informations d’identification du principal de service pendant que l’hôte reste attaché ou que l’agent l’utilise toujours.

Inspecter la configuration du principal de service rendu

Exécutez les commandes dans le shell root de l’hôte une fois le processus d’amorçage terminé avec succès.

Les identificateurs de principal de service et le fichier de certificat sont des entrées dans le processus de démarrage. Le script les fusionne avec les données de démarrage du pool pour produire la configuration de l’agent :

Fichier	Purpose	Traitement
/etc/aks-flex-node/base-config.json	Ensemble de données d’amorçage récupérées avant l’attachement, y compris un jeton d’amorçage de courte durée.	Gardez-le protégé ; ne l’imprimez pas et ne partagez pas son contenu.
/etc/aks-flex-node/config.json	Configuration de nœud flexible rendue, y compris le cluster cible et le pool, les paramètres de nœud, les sources d’artefact et les paramètres d’authentification Azure.	Appartenant à root avec les permissions 0600 ; ne l’imprimez pas et ne partagez pas le fichier complet.
/etc/aks-flex-node/credentials/sp-client-certificate	Certificat PEM combiné et clé privée utilisée par l’agent en cours d’exécution.	Propriété racine avec le mode 0600 dans le répertoire des informations d’identification protégées ; conservez-la tant qu’elle est attachée.

Dans le script bootstrap.sh de la version d'agent que votre déploiement épingle dans AKS_FLEX_NODE_VERSION, --sp-client-certificate-file écrit le chemin du certificat dans azure.servicePrincipal.clientSecretFile. Malgré son nom, ce champ fait référence au fichier de certificat dans ce flux de travail, et non à une valeur de clé secrète client. Ne le renommez pas en clientCertificateFile. Le script supprime azure.managedIdentity et définit azure.arc.enabled sur false lors de la sélection de l’authentification du principal de service.

L’exemple adopté suivant montre la forme d’une configuration de principal de service basé sur un certificat. Il ne s’agit pas d’un schéma de configuration complet ou d’un fichier à copier sur un hôte. Continuez à générer la configuration avec le script bootstrap correspondant à la version.

{
  "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>"
  }
}

Le jeton d’amorçage Kubernetes et le principal de service Azure servent à des fins différentes. Le jeton établit la relation de confiance initiale avec Kubernetes ; le principal de service fournit une authentification Azure durable. L'ID d'objet du principal de service utilisé pour l'attribution de rôle Azure n'est pas l'ID client de l'application stocké dans cette configuration.

1. Inspectez uniquement un ensemble autorisé de champs de cible et d’identité non-secret. Ne remplacez pas cette projection par cat ou jq . dans la configuration complète.

   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
   

   Vérifiez le cluster, le pool attendu, le nom d’hôte, l’ID de locataire, l’ID client de l’application et le chemin d’accès au certificat. Ces champs ne sont pas des informations d’identification, mais passez en revue les identificateurs de ressource avant de partager la sortie de diagnostic.

2. Vérifiez que la configuration générée sélectionne le principal de service et le certificat prévus, avec les autres modes d’identité Azure désactivés.

   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
   

   Arrêtez si la vérification échoue. Ne modifiez pas manuellement le fichier généré pour contourner une incompatibilité d’identité.

3. Vérifiez les autorisations de fichier de configuration et de certificat.

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

   Les deux fichiers doivent appartenir à root root et avoir les autorisations 600. Cette inspection confirme la configuration sélectionnée ; les vérifications de nœud, de machine et de charge de travail suivantes valident le comportement d’exécution.

identité managée de machine virtuelle Azure

Pour une identité managée affectée par le système, HOST_IDENTITY_CLIENT_ID reste vide. Une identité managée affectée par l’utilisateur utilise l’ID client enregistré dans l’environnement partagé. Les deux options utilisent le fichier protégé base-config.json que vous avez récupéré dans votre environnement Bash.

Pour une identité managée affectée par le système, exécutez :

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}"

Pour une identité managée attribuée par l’utilisateur, ajoutez son ID de 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}"

Continuez une fois l’enregistrement de la machine terminé et lorsque le script d’amorçage signale que le service de l’agent de nœud Flex a démarré.

Supprimer les fichiers de version temporaire

Une fois le démarrage réussi, supprimez le script temporaire, l’archive et le fichier de transfert de l’hôte :

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

Le premier exit quitte le shell root. La deuxième ferme la session SSH et retourne à votre environnement Bash.

Supprimez les copies dans votre environnement 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"

Conservez /etc/aks-flex-node et les informations d’identification du principal de service tant que l’hôte reste attaché. L’agent en cours d’exécution utilise cette configuration pour la réconciliation des nœuds et des machines Azure.

Vérifier le nœud Kubernetes

Définissez le nom du nœud sur le nom d’hôte Linux enregistré dans l’environnement partagé. Tout d’abord, attendez que l’objet Node soit créé, puis attendez qu’il soit prêt :

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

Continuez lorsque le nœud est Ready. Si le nœud n’est pas créé ou n’est pas prêt, vérifiez la sortie de démarrage, la connectivité d’API et le service d’agent avant de réessayer de démarrer.

Vérifier la ressource Azure Machine

1. Répertoriez les machines dans le pool de nœuds flex cible.

   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. Recherchez la machine qui a inscrit le nœud Kubernetes préparé :

   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}"
   

   Continuez lorsque la commande retourne exactement un nom d’ordinateur.

3. Affichez cette machine :

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

   Continuez lorsque la machine existe, fait référence à FLEX_NODE_NAME et indique un état d’approvisionnement réussi. Notez le nom de la machine pour les opérations du cycle de vie :

   set_flexnode_env FLEX_MACHINE_NAME "${FLEX_MACHINE_NAME}"
   

Vérifier la mise en réseau de nœuds flex

1. Affichez le site Flex, le CIDR du pod et la clé publique 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. Vérifiez les sites et les ressources réseau Unbounded-Net associées.

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

3. Affichez les pods Unbounded-Net planifiés sur le nœud flexible.

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

Ne passez pas à la validation de la charge de travail, sauf si :

• Le nœud est Ready.
• Le site est le site Flex Unbounded-Net configuré dans l’article sur la mise en réseau.
• Le CIDR du pod fait partie de la plage planifiée FLEX_POD_CIDR.
• La clé publique WireGuard est remplie.
• Le cluster-flex-private-l3 SitePeering fait référence aux sites flex-site et cluster.
• Chaque pod Unbounded-Net renvoyé sur le nœud est Running.
• Pour une topologie WireGuard publique, l’appairage attendu du pool de passerelles est présent.

Vérifier l’agent FlexNode

Attendez jusqu’à une minute pour que le service devienne actif. Si ce n’est pas le cas, affichez l’état du service et les journaux récents :

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'

Continuez lorsque la sortie contient ActiveState=active, SubState=runninget Result=success.

Si l’agent redémarre à plusieurs reprises, car il ne peut pas répertorier MachineOperation les ressources, revenez à l’étape RBAC du démon flexible temporaire dans Configurer la mise en réseau et créez un pool de nœuds flexibles dans AKS, vérifiez que le rôle et la liaison existent, puis redémarrez l’agent :

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

Valider l’emplacement et la connectivité de la charge de travail

Créer une charge de travail de validation

Créez un espace de noms dédié. Si cet espace de noms existe déjà, nettoyez l’exécution de validation précédente avant de réessayer.

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

Créez un serveur HTTP que le planificateur Kubernetes place sur le nœud flexible et exposez-le via un service 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

Vérifier les rappels et la connectivité de service local

Vérifiez les journaux et l’exécution de commandes à l’aide du chemin de rappel du serveur d’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"'

Obtenez le ClusterIP et envoyez une requête au service depuis la charge de travail du nœud 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 réponse attendue est la suivante :

flex-network-ok

Vérifier la redirection de port

Dans le terminal actuel, transférez un port local via le serveur d’API Kubernetes. Cette commande utilise l’environnement de déploiement et kubeconfig que vous avez chargés précédemment :

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

Dans un deuxième terminal, demandez le point de terminaison transféré :

curl -fsS http://127.0.0.1:18080

La réponse attendue est flex-network-ok. Appuyez sur Ctrl+C dans le premier terminal après la vérification.

Vérifier la connectivité à partir d’un nœud géré par AKS

Recherchez un nœud système géré par AKS prêt :

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}"

Exécutez un pod client sur ce nœud et vérifiez que vous obtenez la réponse attendue :

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 nœud Kubernetes à l’état Ready indique l’enregistrement du nœud. À elle seule, elle ne prouve pas la mise en réseau des charges de travail, les opérations de rappel ou les opérations du cycle de vie d’Azure.

Nettoyer la charge de travail de validation

Supprimez uniquement les ressources temporaires que vous avez créées dans cet article.

kubectl delete namespace "${VALIDATION_NAMESPACE}"

Étape suivante

Ensuite, gérez, mettez à jour, mettez à niveau ou supprimez le nœud flex attaché.