Anexar um nó flex a um cluster do AKS (versão prévia)

Importante

As funcionalidades em versão preliminar do AKS estão disponíveis de forma optativa e por autoatendimento. As versões prévias são fornecidas “no estado em que se encontram” e “conforme disponíveis” e são excluídas dos contratos de nível de serviço e da garantia limitada. As versões prévias do AKS são parcialmente cobertas pelo suporte ao cliente em uma base de melhor esforço. Dessa forma, esses recursos não são destinados ao uso em produção. Para obter mais informações, consulte os seguintes artigos:

Depois de preparar o AKS (Serviço de Kubernetes do Azure) cluster, rede, pool de nós flex, host e identidade, inicialize o host e anexe-o ao pool de destino.

Neste artigo você:

  • Baixe e verifique o lançamento do nó flexível.
  • Inicialize o host usando sua identidade Azure selecionada para recuperar novos dados do pool.
  • Verifique o nó do Kubernetes, a máquina do Azure, o estado da rede e o serviço do agente.
  • Valide a alocação da carga de trabalho, as chamadas de retorno do Kubernetes e a conectividade entre nós.

Execute os comandos de gerenciamento neste artigo em um ambiente Bash compatível com Linux que tenha as ferramentas necessárias e o acesso à rede. Este artigo se refere a esse ambiente como seu ambiente Bash. O computador separado que ingressa no cluster é o host do nó flex; execute os comandos nele somente quando uma etapa instruir você explicitamente a fazer isso.

Para um cluster privado do AKS, execute todos os comandos kubectl de um ambiente Bash que podem resolver e alcançar o servidor de API privado. Você pode executar comandos da CLI do Azure, de download de artefatos, SSH e SCP em seu ambiente Bash quando ele tiver o acesso necessário ao Azure e ao host. A rede de host do nó flex também deve resolver e alcançar o ponto de extremidade da API privada.

Antes de começar

  • Conclua a configuração de rede e crie um pool de nós flex no AKS.
  • Conclua Preparar um host e a identidade de um nó flexível.
  • Instale CLI do Azure, a aks-preview extensão, uma versão em uma kubectl versão secundária de AKS_VERSION, jq, curl, sha256sumum cliente OpenSSH e scp em seu ambiente Bash.
  • Para identidade gerenciada ou entidade de serviço, use uma conta Azure que possa recuperar dados de inicialização para o pool de nós flex selecionado.
  • Verifique se o ambiente Bash consegue acessar o host do nó flex pelo caminho de gerenciamento SSH aprovado.
  • Verifique se o host do nó Flex consegue acessar, via HTTPS, os endpoints dos artefatos de versão e de inicialização retornados nos dados de bootstrap do pool, o Azure Resource Manager, o Microsoft Entra ID e o endpoint da API do AKS selecionado.

Note

Não armazene credenciais, certificados, chaves privadas, tokens de acesso, dados de inicialização ou conteúdo kubeconfig no arquivo de ambiente compartilhado.

Carregar o ambiente de implantação

Inicie uma nova sessão bash, identifique o arquivo de ambiente e carregue-o. Substitua <deployment-name> pelo rótulo de implantaçã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 arquivo de ambiente fornece os valores de implantação compartilhados que este artigo lê, incluindo WORK_DIR, o diretório em seu ambiente Bash em que este artigo armazena downloads e arquivos gerados. Por padrão, WORK_DIR é ~/.local/share/aksflexnode/<deployment-name>. O artigo deriva todas as outras variáveis necessárias. Se você ainda não criou o arquivo de ambiente, conclua Planejar a implantação dos nós flexíveis primeiro. Não prossiga além desta etapa caso o shell relate um erro.

Defina a assinatura ativa e exiba os alvos do Azure, do Kubernetes e do 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

Confirme se ResourceId corresponde AKS_RESOURCE_ID, o nome do host do plano de controle do Kubernetes corresponde ao ApiServer e o comando SSH retorna FLEX_HOST_NAME. Se qualquer destino não corresponder, pare e corrija o arquivo de ambiente, o kubeconfig ou o destino SSH antes de transferir ou executar arquivos.

Baixar e verificar a versão do Flex Node

  1. Identifique a arquitetura do host e selecione o arquivo de versão 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. Baixe o arquivo e o manifesto de somas de verificação do lançamento selecionado.

    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 checksum para o arquivo compactado e verifique o arquivo.

    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 de checksum indique que o arquivo é OK.

  4. Baixe o script de inicialização da mesma tag de versão e valide sua sintaxe em 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"

    No momento, a versão não publica uma soma de verificação separada para esse script. Baixe-o sem redirecioná-lo para um shell, mantenha-o na mesma versão do arquivo compactado verificado do agente e interrompa se a verificação de sintaxe falhar.

Obter os dados de inicialização do pool atual

Os caminhos de identidade gerenciada e entidade de serviço usam dados de inicialização que você recupera em seu ambiente Bash. Se você selecionou Azure Arc identidade gerenciada, ignore esta seção. O comando bootstrap do Arc recupera dados atualizados por meio da identidade da máquina do Arc.

Para identidade gerenciada ou entidade de serviço, obtenha os dados imediatamente antes de transferir arquivos para o host. A resposta contém um token de inicialização que expira após uma hora. Não imprima a resposta nem armazene-a em anotações.

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"

Continue quando ${WORK_DIR}/base-config.json existir e não estiver vazio. Conclua a transferência e a inicialização do host dentro de uma hora. Se o token expirar, execute o comando novamente e substitua o arquivo antigo.

Transferir arquivos e preparar o host

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

    {
    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 arquivos de versão verificados e o arquivo de entrega 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 gerenciada ou principal de serviço, copie também os dados de inicialização protegidos:

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

  4. Conecte-se ao host e inicie um shell de root:

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

  5. Carregue os valores de transferência não sigilosos e valide os arquivos 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 -

    Prossiga quando o comando de soma de verificação informar que o arquivo é OK. Pare se a soma de verificação ou a verificação da sintaxe do script falhar.

  6. Para identidade gerenciada ou entidade de serviço, instale os dados de inicialização:

    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 o host

Conclua apenas a seção que corresponde à identidade configurada no artigo anterior.

Use esta seção apenas depois que o recurso de máquina do Arc corresponder ao host SSH, himdsd estiver ativo, a verificação do HIMDS retornar HTTP 200 para o recurso exato do AKS e a atribuição de função com escopo no AKS estiver presente, conforme verificado no artigo anterior. Esse caminho recupera dados de inicialização novos por meio da identidade do computador Arc e não usa o base-config.json arquivo do seu 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 informar Arc preflight: OK, o registro da máquina for concluído e o script de bootstrap relatar que o serviço do agente do nó flex foi iniciado. Se o bootstrap não puder recuperar dados, verifique a conexão do Arc, himdsd a atribuição de função no escopo do AKS e o acesso do host ao Azure Resource Manager.

Remover arquivos de lançamento temporários

Depois que o bootstrap for concluído com sucesso, remova do host o script transitório, o arquivo compactado e o arquivo de transferência:

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

O primeiro exit sai do shell de root. O segundo fecha a sessão SSH e retorna ao seu 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 da entidade de serviço enquanto o host estiver anexado. O agente em execução usa essa configuração para a reconciliação do nó e do Azure Machine.

Verificar o nó do Kubernetes

Defina o nome do nó como o nome do host do Linux registrado no ambiente compartilhado. Primeiro, aguarde a criação do objeto Node e aguarde até 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ó for Ready. Se o nó não for criado ou não ficar pronto, verifique a saída do bootstrap, a conectividade com a API e o serviço do agente antes de executar o bootstrap novamente.

Verificar o recurso Azure Machine

  1. Liste os Computadores no pool de nós flex de destino.

    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 o Computador que registrou o nó do Kubernetes preparado:

    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 retornar exatamente um nome do Computador.

  3. Mostrar esse computador:

    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 existir, fizer referência a FLEX_NODE_NAME e indicar um estado de provisionamento bem-sucedido. Registre o nome da máquina para operações do ciclo de vida:

    set_flexnode_env FLEX_MACHINE_NAME "${FLEX_MACHINE_NAME}"

Verificar a rede de nós flex

  1. Exiba o site Flex, 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 relacionados ao Unbounded-Net.

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

  3. Exiba os pods do Unbounded-Net agendados no nó flex.

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

Não continue na validação da carga de trabalho, a menos que:

  • O nó é Ready.
  • O Site é o Unbounded-Net site flex configurado no artigo de rede.
  • O CIDR do pod pertence ao intervalo FLEX_POD_CIDR planejado.
  • A chave pública do WireGuard é preenchida.
  • O cluster-flex-private-l3 SitePeering faz referência aos sites flex-site e cluster.
  • Cada pod do Unbounded-Net retornado no nó é Running.
  • Para uma topologia pública de WireGuard, existe o pareamento esperado do pool de gateways.

Verifique o agente do nó flex

Aguarde até um minuto para que o serviço se torne ativo. Caso contrário, exiba o estado do serviço e os registros 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 contiver ActiveState=active, SubState=runninge Result=success.

Se o agente reiniciar repetidamente porque não consegue listar os recursos MachineOperation, volte para a etapa temporária de RBAC do daemon flex em Configurar a rede e criar um pool de nós flex no AKS, verifique se a função e a vinculaçã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 o posicionamento e a conectividade da carga de trabalho

Criar uma carga de trabalho de validação

Crie um namespace dedicado. Se esse namespace já existir, limpe a execução de validação anterior antes de tentar novamente.

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 agendador do Kubernetes coloca no nó flex e exponha-o por meio 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 conectividade de serviço local

Verifique os logs e a execução de comandos usando o caminho de callback do servidor de API do 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 uma solicitação 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 redirecionamento de porta

No terminal atual, encaminhe uma porta local por meio do servidor de API do Kubernetes. Esse comando usa o ambiente de implantação e o kubeconfig que você carregou anteriormente:

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

Em um segundo terminal, faça uma solicitação ao endpoint encaminhado:

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 de um nó gerenciado pelo AKS

Encontre um nó de sistema gerenciado pelo 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 mostra o registro do nó. Isso, por si só, não comprova a rede da carga de trabalho, operações de retorno de chamada ou operações do ciclo de vida do Azure.

Limpar a carga de trabalho de validação

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

kubectl delete namespace "${VALIDATION_NAMESPACE}"

Próximas etapas

Depois, gerencie, atualize, faça upgrade ou remova o nó flexível anexado.

  • Última atualização em