Asociación de un nodo flexible a un clúster de AKS (versión preliminar)

Importante

Las características en versión preliminar de AKS están disponibles en régimen de autoservicio y mediante adhesión voluntaria. Las versiones preliminares se proporcionan "tal cual" y "como están disponibles", y están excluidas de los Acuerdos de nivel de servicio y la garantía limitada. Las versiones preliminares de AKS cuentan con soporte parcial por parte del servicio al cliente en la medida de lo posible. Por lo tanto, estas características no están diseñadas para su uso en producción. Para más información, consulte los siguientes artículos de soporte:

Después de preparar el clúster de Azure Kubernetes Service (AKS), la red, el grupo de nodos Flex, el host y la identidad, inicialice el host y adjúntelo al grupo de destino.

En este artículo, encontrarás:

  • Descargue y compruebe la versión del nodo flexible.
  • Inicialice el host usando la identidad de Azure seleccionada para recuperar datos actualizados del grupo.
  • Compruebe el nodo de Kubernetes, Azure machine, el estado de red y el servicio del agente.
  • Validar la ubicación de las cargas de trabajo, los callbacks de Kubernetes y la conectividad entre nodos.

Ejecute los comandos de administración de este artículo en un entorno de Bash compatible con Linux que tenga las herramientas necesarias y el acceso a la red. En este artículo, ese entorno se denomina entorno de Bash. La máquina independiente que se une al clúster es el host del nodo flexible; ejecute comandos en ella solo cuando un paso se lo indique explícitamente.

Para un clúster de AKS privado, ejecute todos los kubectl comandos desde un entorno de Bash que pueda resolver y acceder al servidor de API privado. Puede ejecutar comandos de la CLI de Azure, de descarga de artefactos, SSH y SCP desde su entorno de Bash, siempre que disponga del acceso necesario al host y a Azure. La red del host del nodo flexible también debe resolver y acceder al punto de conexión privado de la API.

Antes de empezar

  • Complete la configuración de red y cree un grupo de nodos flex en AKS.
  • Complete Prepare a flex node host and identity (Preparar un host y una identidad de nodo flexible).
  • Instale CLI de Azure, la extensión aks-preview, una versión de kubectl que no difiera en más de una versión secundaria de AKS_VERSION, jq, curl, sha256sum, un cliente OpenSSH y scp en su entorno de Bash.
  • Para la identidad administrada o la entidad de servicio, utilice una cuenta de Azure que pueda recuperar los datos de arranque para el grupo de nodos flexibles seleccionado.
  • Asegúrese de que el entorno de Bash pueda llegar al host de nodo flexible a través de la ruta de administración de SSH aprobada.
  • Asegúrese de que el host del nodo flexible pueda acceder a los puntos de conexión de los artefactos de versión e inicialización devueltos en los datos de inicialización del grupo, a Azure Resource Manager, a Microsoft Entra ID y al punto de conexión seleccionado de la API de AKS mediante HTTPS.

Note

No almacene credenciales, certificados, claves privadas, tokens de acceso, datos de arranque o contenido kubeconfig en el archivo de entorno compartido.

Carga del entorno de implementación

Inicie una nueva sesión de Bash, identifique el archivo del entorno y cárguelo. Reemplace por <deployment-name> la etiqueta de implementación usada en los artículos 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.}"

El archivo de entorno proporciona los valores de implementación compartidos que lee este artículo, incluido WORK_DIR, el directorio del entorno de Bash donde este artículo almacena descargas y archivos generados. De forma predeterminada, WORK_DIR es ~/.local/share/aksflexnode/<deployment-name>. El artículo deriva cualquier otra variable que necesite. Si aún no has creado el archivo de entorno, completa primero Planificar la implementación de los nodos flex. No continúe después de este paso si el shell notifica un error.

Establezca la suscripción activa y muestre los destinos de Azure, Kubernetes y 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 que ResourceId coincide con AKS_RESOURCE_ID, que el nombre de host del plano de control de Kubernetes coincide con ApiServer y que el comando SSH devuelva FLEX_HOST_NAME. Si algún destino no coincide, detenga y corrija el archivo de entorno, kubeconfig o destino SSH antes de transferir o ejecutar archivos.

Descarga y verifica la versión del nodo flex

  1. Identifique la arquitectura del host y seleccione el archivo de versión coincidente.

    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. Descargue el archivo y el manifiesto de sumas de comprobación de la versión seleccionada.

    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. Selecciona exactamente una entrada de suma de comprobación para el archivo y verifica el archivo.

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

    No continúe a menos que el comando de suma de comprobación notifique que el archivo es OK.

  4. Descargue el script de arranque de la misma etiqueta de lanzamiento y valide la sintaxis 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"

    Actualmente, la versión no publica una suma de comprobación independiente para este script. Descárguelo sin redirigirlo a un intérprete de comandos, manténgalo en la misma versión que el archivo verificado del agente y deténgase si falla la comprobación de sintaxis.

Obtener los datos de arranque del pool actual

Las rutas de la identidad administrada y de la entidad de servicio utilizan datos de arranque que se recuperan en el entorno Bash. Si seleccionó la identidad administrada de Azure Arc, omita esta sección. El comando de inicialización de Arc recupera datos actualizados mediante la identidad de máquina de Arc.

En el caso de una identidad administrada o un principal de servicio, obtenga los datos inmediatamente antes de transferir archivos al host. La respuesta contiene un token de arranque que expira después de una hora. No imprima la respuesta ni almacénela en 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"

Continúe cuando ${WORK_DIR}/base-config.json exista y no esté vacío. Completar la transferencia y la inicialización del host en el plazo de una hora. Si el token expira, vuelva a ejecutar el comando y reemplace el archivo anterior.

Transferir archivos y preparar el host

  1. Cree un archivo de transferencia de host no 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. Copia los archivos de la versión verificada y el archivo de transferencia al 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 la identidad administrada o la entidad de servicio, copie también los datos de arranque protegidos:

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

  4. Conéctese al host e inicie un shell raíz:

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

  5. Cargue los valores de traspaso no secretos y valide los archivos 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 -

    Continúe cuando el comando de suma de verificación indique que el archivo es OK. Detenga si falla la comprobación de la suma de verificación o la comprobación de sintaxis del script.

  6. Para la identidad administrada o el principal de servicio, instale los datos de inicialización:

    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

Inicialice el host

Complete solo la sección que coincida con la identidad configurada en el artículo anterior.

Utilice esta sección solo después de que el recurso de máquina de Arc coincida con el host SSH, himdsd esté activo, la comprobación de HIMDS devuelva HTTP 200 para el recurso de AKS exacto y la asignación de roles con ámbito de AKS esté presente, tal como se verificó en el artículo anterior. Este método recupera datos de inicialización nuevos mediante la identidad de máquina de Arc y no usa el archivo base-config.json del entorno 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}"

Continúe cuando la salida indique Arc preflight: OK, se complete el registro de la máquina y el script de arranque indique que se inició el servicio del agente de nodo Flex. Si bootstrap no puede recuperar datos, compruebe la conexión de Arc, himdsd, la asignación de roles en el ámbito de AKS y el acceso del host a Azure Resource Manager.

Elimina los archivos de lanzamiento temporales

Una vez completado correctamente el bootstrap, elimine del host el script temporal, el archivo comprimido y el archivo de transferencia:

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

El primer exit sale del shell de root. El segundo cierra la sesión SSH y vuelve al entorno de Bash.

Quite las copias en el entorno de 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"

Mantenga /etc/aks-flex-node y la credencial de la entidad de servicio mientras el host siga asociado. El agente en ejecución usa esta configuración para la conciliación de nodo y Azure Machine.

Comprobación del nodo de Kubernetes

Establezca el nombre del nodo en el nombre de host de Linux registrado en el entorno compartido. En primer lugar, espere a que se cree el objeto Node y espere a que esté listo:

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

Continúe cuando el nodo sea Ready. Si el nodo no se crea o no está listo, compruebe la salida del arranque, la conectividad de API y el servicio del agente antes de reintentar el arranque.

Comprobación del recurso Azure Machine

  1. Enumere las máquinas del grupo de nodos 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. Busque la máquina que registró el nodo de 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}"

    Continúe cuando el comando devuelva exactamente un nombre de máquina.

  3. Mostrar esa 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

    Continúa cuando la máquina exista, haga referencia a FLEX_NODE_NAME e informe de un estado de aprovisionamiento correcto. Registre el nombre de la máquina para las operaciones del ciclo de vida:

    set_flexnode_env FLEX_MACHINE_NAME "${FLEX_MACHINE_NAME}"

Comprobación de las redes de nodos flexibles

  1. Muestra la clave pública flex site, pod CIDR y 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 los Sitios y los recursos de red de Unbounded-Net relacionados.

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

  3. Muestra los pods de Unbounded-Net asignados al nodo flex.

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

No continúe con la validación de la carga de trabajo a menos que:

  • El nodo es Ready.
  • El Sitio es el sitio Flex de Unbounded-Net configurado en el artículo sobre redes.
  • El CIDR del pod pertenece al rango previsto FLEX_POD_CIDR.
  • Se rellena la clave pública de WireGuard.
  • El cluster-flex-private-l3 SitePeering hace referencia a los sitios cluster y flex-site.
  • Cada pod de Unbounded-Net devuelto en el nodo es Running.
  • Para una topología pública de WireGuard, existe el emparejamiento de grupo de puertas de enlace esperado.

Comprobación del agente de nodo flexible

Espere hasta un minuto para que el servicio se active. Si no es así, muestre el estado del servicio y los registros recientes:

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'

Continúe cuando la salida contenga ActiveState=active, SubState=runningy Result=success.

Si el agente se reinicia repetidamente porque no puede enumerar los recursos de MachineOperation, vuelva al paso de RBAC del daemon flex temporal en Configurar las redes y crear un grupo de nodos flex en AKS, compruebe que el rol y la asociación existen y, a continuación, reinicie el agente:

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

Validación de la ubicación y conectividad de la carga de trabajo

Creación de una carga de trabajo de validación

Cree un espacio de nombres dedicado. Si este espacio de nombres ya existe, elimine la ejecución de validación anterior antes de volver a intentarlo.

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

Cree un servidor HTTP que el programador de Kubernetes coloque en el nodo flexible y expóralo a través de un servicio 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

Verifica los callbacks y la conectividad con el servicio local

Compruebe los registros y la ejecución de comandos mediante la ruta de retrollamada del servidor de la API de 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"'

Obtenga clusterIP y solicite el servicio desde la carga de trabajo del nodo flexible:

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 respuesta esperada es:

flex-network-ok

Comprobación del reenvío de puertos

En el terminal actual, reenvíe un puerto local a través del servidor de API de Kubernetes. Este comando usa el entorno de implementación y kubeconfig que cargó anteriormente:

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

En un segundo terminal, solicite el punto de conexión reenviado:

curl -fsS http://127.0.0.1:18080

La respuesta esperada es flex-network-ok. Presione Ctrl+C en el primer terminal después de la comprobación.

Comprobación de la conectividad desde un nodo administrado por AKS

Busque un nodo de sistema administrado por AKS listo:

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

Ejecute un pod de cliente en ese nodo y compruebe la respuesta 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

Un nodo de Kubernetes en estado Ready muestra el registro del nodo. Esto no garantiza por sí solo el funcionamiento de la red de la carga de trabajo, las operaciones de devolución de llamada ni las operaciones del ciclo de vida de Azure.

Limpieza de la carga de trabajo de validación

Quite únicamente los recursos temporales que creó para este artículo.

kubectl delete namespace "${VALIDATION_NAMESPACE}"

Paso siguiente

A continuación, administrar, actualizar, mejorar o eliminar el nodo flex adjunto.

  • Se actualizó por última vez el