Anexar um nó flex a um cluster AKS (pré-visualização)

Importante

As funcionalidades de pré-visualização do AKS estão disponíveis num regime de autosserviço e de adesão voluntária. As visualizações prévias são fornecidas "como estão" e "conforme disponíveis" e são excluídas dos contratos de nível de serviço e da garantia limitada. As versões de pré-visualização do AKS são apenas parcialmente abrangidas pelo suporte ao cliente, na medida do possível. Assim sendo, estas funcionalidades não se destinam ao uso em produção. Para obter mais informações, consulte os seguintes artigos de suporte:

• Políticas de suporte do AKS
• Perguntas frequentes sobre o suporte do Azure

Depois de preparar o cluster do Azure Kubernetes Service (AKS), a rede, o pool de nós flexível, o anfitrião e a identidade, inicialize o anfitrião e anexe-o ao pool de destino.

Neste artigo, você:

• Descarregue e verifique a versão do nó flex.
• Inicie o host usando a sua identidade Azure selecionada para recuperar dados frescos do pool.
• Verifique o Nó Kubernetes, a máquina Azure, o estado da rede e o serviço do agente.
• Validar o posicionamento das cargas de trabalho, os callbacks do Kubernetes e a conectividade entre os nós.

Execute os comandos de gestão deste artigo num ambiente Bash compatível com Linux, que tenha as ferramentas necessárias e acesso à rede. Este artigo chama a esse ambiente o teu ambiente Bash. A máquina separada que se junta ao cluster é o host do nó flex; execute comandos aí apenas quando um passo lhe der instruções explícitas nesse sentido.

Para um cluster AKS privado, execute todos os kubectl comandos a partir de um ambiente Bash que possam resolver e aceder ao servidor API privado. Podes executar comandos CLI do Azure, download de artefactos, SSH e SCP a partir do teu ambiente Bash quando este tiver o acesso necessário ao Azure e ao host. A rede anfitriã de nó flexível também deve resolver e alcançar o endpoint privado da API.

Antes de começares

• Concluir Configurar a rede e criar um conjunto de nós flexível no AKS.
• Conclua Preparar um anfitrião e a identidade de um nó Flex.
• Instala o CLI do Azure, a aks-preview extensão, uma kubectl versão dentro de uma versão menor de AKS_VERSION, jq, curl, sha256sum, um cliente OpenSSH, e scp no teu ambiente Bash.
• Para identidade gerida ou principal de serviço, use uma conta Azure que possa recuperar dados bootstrap para o pool de nós flexíveis selecionado.
• Garanta que o seu ambiente Bash consegue aceder ao host do nó flex via o caminho de gestão SSH aprovado.
• Assegure-se de que o anfitrião do nó Flex consegue aceder, através de HTTPS, aos pontos finais dos artefactos de lançamento e de arranque devolvidos nos dados de arranque do conjunto, ao Azure Resource Manager, ao Microsoft Entra ID e ao ponto final selecionado da API do AKS.

Observação

Não guarde credenciais, certificados, chaves privadas, tokens de acesso, dados de bootstrap ou conteúdo kubeconfig no ficheiro de ambiente partilhado.

Carregar o ambiente de implementação

Inicia uma nova sessão Bash, identifica o ficheiro de ambiente e carrega-o. Substitua <deployment-name> pelo rótulo de implementação usado nos artigos anteriores.

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

O ficheiro de ambiente fornece os valores partilhados de implementação que este artigo lê, incluindo WORK_DIR, o diretório no seu ambiente Bash onde este artigo armazena os downloads e ficheiros gerados. Por padrão, WORK_DIR é ~/.local/share/aksflexnode/<deployment-name>. O artigo deriva quaisquer outras variáveis que necessite. Se ainda não criaste o ficheiro de ambiente, conclui primeiro Planear a implementação dos teus Flex Nodes. Não continue para além deste passo se o shell apresentar um erro.

Defina a subscrição ativa e apresente o Azure, o Kubernetes e os destinos do anfitrião:

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

Confirme que ResourceId corresponde a AKS_RESOURCE_ID, que o nome do anfitrião do plano de controlo do Kubernetes corresponde a ApiServer e que o comando SSH devolve FLEX_HOST_NAME. Se algum alvo não coincidir, pare e corrija o ficheiro de ambiente, kubeconfig ou alvo SSH antes de transferir ou executar ficheiros.

Descarregue e verifique a libertação do nó flexível

1. Identifique a arquitetura do host e selecione o arquivo de lançamento correspondente.

   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. Descarregue o arquivo e o manifesto de somas de verificação da versão selecionada.

   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. Selecione exatamente uma entrada de verificação para o arquivo e verifique o ficheiro.

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

   Não continue a menos que o comando checksum indique que o arquivo está OK.

4. Descarregue o script de arranque a partir da mesma tag release e valide a sua sintaxe 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"
   

   A versão não publica atualmente um checksum separado para este script. Descarregue-o sem o encaminhar por pipe para uma shell, mantenha-o com a mesma versão do arquivo verificado do agente e interrompa se a verificação de sintaxe falhar.

Obter os dados atuais de inicialização do grupo

Os percursos da identidade gerida e da entidade de serviço utilizam dados de arranque inicial que recupera no ambiente Bash. Se selecionou identidade gerida do Azure Arc, salte esta secção. O comando bootstrap do Arc obtém dados atualizados através da identidade de máquina do Arc.

Para identidade gerida ou principal de serviço, obtenha os dados imediatamente antes de transferir ficheiros para o host. A resposta contém um token bootstrap que expira após uma hora. Não imprimas a resposta nem a guardes nas notas.

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"

Continuar se ${WORK_DIR}/base-config.json existir e não estiver vazio. Conclua a transferência e o arranque do host no prazo de uma hora. Se o token expirar, execute novamente o comando e substitua o ficheiro antigo.

Transferir ficheiros e preparar o host

1. Crie um ficheiro de transferência de host não secreto.

   {
       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. Copie os ficheiros de release verificados e o ficheiro de handoff para o 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. Para identidade gerida ou principal de serviço, copie também os dados de bootstrap protegidos:

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

4. Estabelece ligação ao anfitrião e inicia uma sessão de root:

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

5. Carregue os valores não confidenciais de transferência e valide os ficheiros transferidos:

   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 -
   

   Continue quando o comando checksum indicar que o arquivo é OK. Interrompa se a verificação da soma de verificação ou da sintaxe do script falhar.

6. Para identidade gerida ou principal de serviço, instale os dados de arranque:

   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
   

Inicializar a máquina anfitriã

Preencha apenas a secção que corresponda à identidade configurada no artigo anterior.

Azure Arc managed identity

Utilize esta secção apenas depois de o recurso de máquina Arc corresponder ao host SSH, himdsd estar ativo, a verificação HIMDS devolver HTTP 200 para o recurso AKS específico e a atribuição de função no âmbito do AKS estar presente, conforme verificado no artigo anterior. Este caminho obtém dados de inicialização atualizados através da identidade da máquina do Arc e não utiliza o ficheiro base-config.json do 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}"

Continue quando a saída reporta Arc preflight: OK, o registo da máquina estiver concluído e o script de arranque reportar que o serviço do agente flex node foi iniciado. Se o bootstrap não conseguir recuperar dados, verifique a ligação ao Arc, himdsd, a atribuição de funções no âmbito do AKS e o acesso do anfitrião ao Azure Resource Manager.

Serviço principal

Antes de continuar, disponibilize o certificado PEM combinado e a chave privada no host através /etc/aks-flex-node/credentials/sp-client-certificate do seu processo de gestão de credenciais aprovado. O diretório de credenciais deve ser propriedade do utilizador root, com permissões 700. Não guarde a credencial nem o seu caminho no ficheiro do ambiente partilhado.

Na shell root do anfitrião, defina o caminho do certificado e verifique o respetivo proprietário e as permissões:

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

Continue apenas quando o ficheiro existe, pertence a root root, e tem permissões 600. Mantenha-o disponível após o arranque porque o agente em execução o utiliza para a reconciliação das máquinas do Azure.

Executa o bootstrap com o ficheiro protegido base-config.json que recuperaste no teu 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}"

Prossiga quando o registo da máquina estiver concluído e o script de inicialização indicar que o serviço do agente do flex node foi iniciado. Se o bootstrap falhar, não remova a credencial do principal de serviço enquanto o host estiver ligado ou enquanto o agente ainda a utiliza.

Inspecionar a configuração do principal de serviço prestado

Executa os comandos na shell raiz do host depois de o processo de arranque ter sucesso.

Os identificadores do principal de serviço e o ficheiro de certificado são dados de entrada do processo de arranque. O script combina-os com os dados de arranque do conjunto para produzir a configuração do agente:

Ficheiro	Purpose	Manuseamento
/etc/aks-flex-node/base-config.json	Dados de bootstrap do pool recuperados antes da anexação, incluindo um token de bootstrap de curta duração.	Mantenha-se protegido; não imprima nem partilhe o seu conteúdo.
/etc/aks-flex-node/config.json	Configuração do nó flexível renderizado, incluindo o cluster e pool de destino, definições do nó, fontes de artefactos e definições de autenticação do Azure.	Pertencente ao root, com modo 0600; não imprima nem divulgue o ficheiro completo.
/etc/aks-flex-node/credentials/sp-client-certificate	Certificado PEM combinado e chave privada usados pelo agente em execução.	Pertencente ao root com modo 0600 no diretório de credenciais protegidas; manter enquanto estiver associado.

No script bootstrap.sh da versão do agente que a sua implantação fixa em AKS_FLEX_NODE_VERSION, --sp-client-certificate-file escreve o caminho do certificado em azure.servicePrincipal.clientSecretFile. Apesar do nome, este campo faz referência ao ficheiro de certificado neste fluxo de trabalho, não a um valor secreto de cliente. Não o renomes para clientCertificateFile. O script remove azure.managedIdentity e define azure.arc.enabled como false ao selecionar a autenticação de principal de serviço.

O seguinte exemplo censurado mostra a forma de uma configuração de principal de serviço baseada em certificados. Não é um esquema de configuração completo nem um ficheiro para copiar para um host. Continue a gerar a configuração com o script bootstrap correspondente à versão.

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

O token de arranque do Kubernetes e o principal de serviço do Azure têm finalidades diferentes. O token estabelece a confiança inicial do Kubernetes; o principal de serviço fornece autenticação persistente no Azure. O ID do objeto principal do serviço usado para a atribuição de funções no Azure não é o ID do cliente da aplicação armazenado nesta configuração.

1. Inspecione apenas um conjunto permitido de campos de alvo e identidade não secretos. Não substitua esta projeção por cat ou jq . na configuração 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
   

   Confirme o cluster esperado, pool, nome do host, ID do inquilino, ID do cliente da aplicação e caminho do certificado. Estes campos não são credenciais, mas reveja os identificadores de recursos antes de partilhar a saída de diagnóstico.

2. Verifique se a configuração gerada seleciona o principal de serviço pretendido e o certificado, com os outros modos de identidade do Azure desativados.

   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
   

   Pare se a verificação falhar. Não edite manualmente o ficheiro gerado para contornar uma incompatibilidade de identidade.

3. Verifique as permissões de configuração e do ficheiro de certificação.

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

   Ambos os ficheiros devem ser propriedade de root root com permissões 600. Esta inspeção confirma a configuração selecionada; as seguintes verificações de Nó, Máquina e carga de trabalho validam o comportamento em tempo de execução.

Azure VM managed identity

Para uma identidade gerida atribuída pelo sistema, HOST_IDENTITY_CLIENT_ID permanece vazio. Uma identidade gerida atribuída pelo utilizador utiliza o ID do cliente registado no ambiente partilhado. Ambas as opções usam o ficheiro protegido base-config.json que recuperou no seu ambiente Bash.

Para uma identidade gerida atribuída pelo sistema, execute:

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

Para uma identidade gerida atribuída pelo utilizador, adicione o seu ID de cliente:

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

Prossiga quando o registo da máquina estiver concluído e o script de inicialização indicar que o serviço do agente do flex node foi iniciado.

Remover ficheiros temporários de versão

Após o sucesso do bootstrap, remova o script transitório, o arquivo e o ficheiro de handoff do host:

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

A primeira exit sai da casca da raiz. O segundo fecha a sessão SSH e regressa ao teu ambiente Bash.

Remova as cópias no seu 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"

Mantenha /etc/aks-flex-node e a credencial do principal de serviço enquanto o host estiver ligado. O agente em execução utiliza esta configuração para a reconciliação dos nós e do Azure Machine.

Verificar o nó Kubernetes

Defina o nome do nó para o nome de host Linux registado no ambiente partilhado. Primeiro, espere que o objeto Node seja criado e depois espere que ele fique 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

Continue quando o nó estiver Ready. Se o nó não for criado ou não estiver pronto, verifique a saída do bootstrap, a conectividade da API e o serviço do agente antes de tentar novamente o bootstrap.

Verificar o recurso Azure Machine

1. Liste as Máquinas no pool de nós flexíveis alvo.

   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. Localize a máquina que registou o nó preparado do Kubernetes:

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

   Continue quando o comando devolver exatamente um nome de máquina.

3. Mostra essa Máquina:

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

   Continue quando a Máquina existe, faz referência FLEX_NODE_NAMEe reporta um estado de provisionamento bem-sucedido. Registe o nome da máquina para as operações do ciclo de vida:

   set_flexnode_env FLEX_MACHINE_NAME "${FLEX_MACHINE_NAME}"
   

Verificar a rede de nós flexíveis

1. Mostrar o flex site, o pod CIDR e a chave pública do 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. Verifique os Sites e os recursos de rede do Unbounded-Net relacionados.

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

3. Exibe os pods do Unbounded-Net programados para o nó flex.

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

Não continue a validar a carga de trabalho a menos que:

• O nó é Ready.
• O Site é o site Flex Unbounded-Net configurado no artigo sobre redes.
• O CIDR do pod pertence ao intervalo previsto FLEX_POD_CIDR.
• A chave pública do WireGuard está preenchida.
• O cluster-flex-private-l3 SitePeering faz referência aos cluster e flex-site Sites.
• Todos os pods Unbounded-Net devolvidos no nó são Running.
• Para uma topologia pública de WireGuard, existe o peering esperado em pool de gateways.

Verifique o agente do nó flex

Espere até um minuto para que o serviço fique ativo. Se não fizer, mostre o estado do serviço e os registos recentes:

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'

Continue quando a saída contém ActiveState=active, SubState=running, e Result=success.

Se o agente reinicia repetidamente porque não consegue listar recursos MachineOperation, volte ao passo temporário do RBAC do daemon flex em Configurar a rede e criar um conjunto de nós flex no AKS, verifique se a função e a associação existem e, em seguida, reinicie o agente:

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

Validar a colocação da carga de trabalho e a conectividade

Criar uma carga de trabalho de validação

Crie um namespace dedicado. Se este espaço de nomes já existir, limpa os vestígios da execução anterior da validação antes de voltar a tentar.

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

Crie um servidor HTTP que o escalonador do Kubernetes agende no nó flex e exponha-o através de um serviço 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

Verificar retornos de chamada e ligação ao serviço local

Verifique logs e execução de comandos usando o caminho de callback do servidor 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"'

Obtenha o ClusterIP e faça um pedido ao serviço a partir da carga de trabalho do nó 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"

A resposta esperada é:

flex-network-ok

Verificar o reencaminhamento de portas

No terminal atual, encaminhe uma porta local através do servidor API Kubernetes. Este comando usa o ambiente de implementação e o kubeconfig que carregaste anteriormente:

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

No segundo terminal, faça um pedido ao endpoint reencaminhado:

curl -fsS http://127.0.0.1:18080

A resposta esperada é flex-network-ok. Pressione Ctrl+C no primeiro terminal após a verificação.

Verificar a conectividade a partir de um nó gerido por AKS

Encontre um nó de sistema gerido por AKS disponível:

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

Execute um pod cliente nesse nó e verifique a resposta esperada:

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

Um nó do Kubernetes no estado Ready indica o registo do nó. Por si só, não prova a rede de carga de trabalho, operações de callback ou operações do ciclo de vida do Azure.

Limpar a carga de validação

Remova apenas os recursos temporários que criou neste artigo.

kubectl delete namespace "${VALIDATION_NAMESPACE}"

Passo seguinte

Em seguida, gere, atualize, faça a atualização ou remova o nó Flex anexado.