Подключение гибкого узла к кластеру AKS (предварительная версия)

Important

Предварительные версии функций AKS доступны на условиях самообслуживания и по выбору пользователя. Предварительные версии предоставляются "как есть" и "при наличии". На них не распространяются соглашения об уровне обслуживания и ограниченная гарантия. Предварительные версии AKS сопровождаются частичной поддержкой клиентов на основе принципа лучших усилий. Как таковые, эти функции не предназначены для использования в производстве. Для получения дополнительной информации ознакомьтесь со следующими статьями поддержки:

После того как вы подготовите кластер Azure Kubernetes Service (AKS), сетевую инфраструктуру, пул гибких узлов, хост и идентификационные данные, инициализируйте хост и подключите его к целевому пулу.

В этой статье вы:

  • Скачайте и проверьте релиз Flex node.
  • Инициализируйте узел, используя выбранную идентификацию Azure, чтобы получить актуальные данные пула.
  • Проверьте узел Kubernetes, компьютер Azure, состояние сети и службу агента.
  • Проверьте размещение рабочих нагрузок, обратные вызовы Kubernetes и подключение между узлами.

Выполните команды управления в этой статье в среде Bash, совместимой с Linux, которая имеет необходимые средства и сетевой доступ. В этой статье эта среда называется средой Bash. Отдельный компьютер, который присоединяется к кластеру, — это хост узла Flex; выполняйте там команды, только если в шаге это явно указано.

Для частного кластера AKS выполните каждую kubectl команду из среды Bash, которая может разрешить и достичь частного сервера API. Вы можете выполнять команды Azure CLI, скачивание артефактов, а также команды SSH и SCP из среды Bash, если в ней есть необходимый доступ к Azure и хосту. Сеть хоста гибкого узла также должна разрешать частную конечную точку API и иметь к ней доступ.

Перед тем как начать

  • Выполните настройку сети и создайте пул гибких узлов в AKS.
  • Завершите подготовку узла Flex node и его идентификатора.
  • Установите Azure CLI, расширение aks-preview, версию kubectl в пределах одной промежуточной версии от AKS_VERSION, jq, curl, клиент OpenSSH и scp в среде Bash.
  • Для управляемого удостоверения или субъекта-службы используйте учетную запись Azure, которая может получить загрузочные данные для выбранного пула узлов Flex.
  • Убедитесь, что из среды Bash есть доступ к хосту flex node по утвержденному пути управления SSH.
  • Убедитесь, что хост гибкого узла может получать доступ по HTTPS к конечным точкам артефактов выпуска и начальной загрузки, возвращаемым в данных начальной загрузки пула, а также к Azure Resource Manager, Microsoft Entra ID и выбранной конечной точке API AKS.

Note

Не сохраняйте учетные данные, сертификаты, закрытые ключи, маркеры доступа, данные начальной загрузки или содержимое kubeconfig в файле общей среды.

Загрузка среды развертывания

Запустите новый сеанс Bash, определите файл среды и загрузите его. Замените <deployment-name> меткой развертывания, используемой в предыдущих статьях.

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

Файл среды содержит общие значения для развертывания, которые используются в этой статье, включая WORK_DIR, каталог в среде Bash, где эта статья сохраняет загруженные и созданные файлы. По умолчанию WORK_DIR — это ~/.local/share/aksflexnode/<deployment-name>. Статья получает любые другие переменные, необходимые ему. Если файл среды еще не создан, сначала выполните планирование развертывания гибких узлов . Не переходите к следующим шагам, если оболочка сообщает об ошибке.

Задайте активную подписку и отобразите целевые объекты Azure, Kubernetes и узла:

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

Убедитесь, что ResourceId совпадает с AKS_RESOURCE_ID, имя узла плоскости управления Kubernetes совпадает с ApiServer, а команда SSH возвращает FLEX_HOST_NAME. Если какой-либо целевой объект не соответствует, остановите и исправьте файл среды, kubeconfig или целевой объект SSH перед передачей или запуском файлов.

Скачать и проверить релиз узла Flex

  1. Определите архитектуру узла и выберите соответствующий архив выпуска.

    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. Скачайте архив и манифест контрольных сумм для выбранного релиза.

    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. Выберите только одну запись с контрольной суммой для архива и проверьте файл.

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

    Не продолжайте работу, если команда проверки контрольной суммы не сообщает, что архив — OK.

  4. Скачайте загрузочный скрипт с тем же тегом релиза и проверьте корректность его синтаксиса 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"

    В настоящее время для этого релиза не публикуется отдельная контрольная сумма для этого скрипта. Скачайте его, не передавая через конвейер в оболочку, следите, чтобы его версия совпадала с проверенным архивом агента, и прекратите выполнение, если проверка синтаксиса не пройдёт.

Получение текущих данных начальной загрузки пула

Сценарии для управляемого удостоверения и субъекта-службы используют начальные данные, которые вы получаете в среде Bash. Если вы выбрали управляемое удостоверение Azure Arc, пропустите этот раздел. Команда bootstrap Arc получает актуальные данные через идентификатор машины Arc.

Для управляемого удостоверения или субъекта-службы извлеките данные непосредственно перед передачей файлов на узел. Ответ содержит токен начальной загрузки, который истекает через один час. Не печатайте ответ или не храните его в заметках.

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"

Продолжить, если ${WORK_DIR}/base-config.json существует и не пусто. Завершите передачу и начальную настройку хоста в течение одного часа. Если срок действия маркера истекает, выполните команду еще раз и замените старый файл.

Передача файлов и подготовка узла

  1. Создайте несекретный файл передачи хоста.

    {
    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. Скопируйте проверенные файлы релиза и файл передачи на хост.

    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. Для управляемого удостоверения или субъекта-службы также скопируйте защищённые данные начальной загрузки:

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

  4. Подключитесь к хосту и запустите оболочку root:

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

  5. Загрузите несекретные значения, используемые при передаче, и проверьте переданные файлы:

    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 -

    Продолжайте, когда команда проверки контрольной суммы показывает, что архив — OK. Остановить, если проверка контрольной суммы или синтаксиса скрипта не удалась.

  6. Для управляемой идентификации или субъекта-службы установите начальные данные:

    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

Инициализировать хост

Заполните только тот раздел, который соответствует удостоверению, настроенному в предыдущей статье.

Используйте этот раздел только после того, как ресурс машины Arc соответствует узлу SSH, himdsd активен, проверка HIMDS возвращает код HTTP 200 именно для нужного ресурса AKS и назначение роли с областью действия AKS присутствует, как подтверждено в предыдущей статье. Этот способ получает актуальные загрузочные данные через идентификатор компьютера Arc и не использует файл base-config.json из среды 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}"

Продолжайте, когда в выводе отображается Arc preflight: OK, регистрация компьютера завершена, а загрузочный скрипт сообщает, что служба агента гибкого узла запущена. Если bootstrap не может получить данные, проверьте подключение к Arc, himdsd, назначение роли с областью действия AKS и доступ узла к Azure Resource Manager.

Удалить временные файлы выпуска

После успешного завершения начальной загрузки удалите временный скрипт, архив и файл передачи из узла:

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

exit Первый покидает корневую оболочку. Второй закрывает сеанс SSH и возвращается в среду Bash.

Удалите копии в среде 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"

Сохраняйте /etc/aks-flex-node и учетные данные субъект-службы, пока узел остается подключенным. Работающий агент использует эту конфигурацию для согласования узлов и машин Azure.

Проверка узла Kubernetes

Задайте имя узла равным имени хоста Linux, указанному в общей среде. Сначала дождитесь создания объекта Node, а затем дождитесь его готовности:

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

Продолжайте работу, когда узел находится Ready. Если узел не создан или не переходит в состояние готовности, проверьте вывод bootstrap-процесса, подключение к API и службу агента, прежде чем повторно запускать bootstrap.

Проверка ресурса компьютера Azure

  1. Выведите список машин в целевом пуле flex-узлов.

    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. Найдите машину, которая зарегистрировала подготовленный узел 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}"

    Продолжайте, когда команда возвращает ровно одно имя компьютера.

  3. Показать, что это машина:

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

    Продолжайте, когда машина существует, есть ссылка на FLEX_NODE_NAME и имеет состояние подготовки «Успешно». Запишите имя компьютера для операций жизненного цикла:

    set_flexnode_env FLEX_MACHINE_NAME "${FLEX_MACHINE_NAME}"

Проверка сети гибких узлов

  1. Отображение открытого ключа flex site, pod CIDR и 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. Проверьте сайты и связанные Unbounded-Net сетевые ресурсы.

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

  3. Отобразите поды Unbounded-Net, назначенные узлу flex.

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

Не продолжайте проверку рабочей нагрузки, если только не выполните приведенные ниже действия.

  • Узел имеет значение Ready.
  • Сайт — это сайт Unbounded-Net Flex, настроенный в статье о сети.
  • CiDR pod принадлежит запланированному FLEX_POD_CIDR диапазону.
  • Открытый ключ WireGuard заполнен.
  • cluster-flex-private-l3 SitePeering ссылается на сайты cluster и flex-site.
  • Каждый возвращенный объект pod Unbounded-Net на узле Running.
  • Для общедоступной топологии WireGuard существует ожидаемый пиринг пула шлюзов.

Проверьте агент flex-узла

Подождите до одной минуты, пока служба станет активной. Если это не так, отобразите состояние службы и последние записи журнала:

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'

Продолжайте, если выходные данные содержат ActiveState=active, SubState=running и Result=success.

Если агент неоднократно перезапускается, поскольку он не может получить список ресурсов MachineOperation, вернитесь к временному шагу настройки RBAC для временного демона flex в разделе Настройка сети и создание пула узлов flex в AKS, убедитесь, что роль и привязка роли существуют, а затем перезапустите агент:

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

Проверка размещения рабочей нагрузки и подключения

Создание рабочей нагрузки проверки

Создайте выделенное пространство имен. Если это пространство имён уже существует, очистите результаты предыдущего запуска проверки, прежде чем повторить попытку.

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

Создайте HTTP-сервер, который планировщик Kubernetes помещает на гибкий узел и предоставляет его через службу 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

Проверка обратного вызова и подключения к локальной службе

Проверьте журналы и выполнение команд с помощью пути обратного вызова сервера 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"'

Получите ClusterIP и отправьте запрос к службе из рабочей нагрузки узла 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"

Ожидаемый ответ:

flex-network-ok

Проверьте перенаправление портов

В текущем терминале перенаправляет локальный порт через сервер API Kubernetes. Эта команда использует среду развертывания и kubeconfig, загруженную ранее:

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

В втором терминале запросите пересылаемую конечную точку:

curl -fsS http://127.0.0.1:18080

Ожидаемый ответ — flex-network-ok. Нажмите клавиши CTRL+C в первом терминале после проверки.

Проверка подключения с управляемого AKS узла

Найдите готовый узел системы, управляемый AKS:

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

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

Запустите модуль pod клиента на этом узле и проверьте ожидаемый ответ:

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

Узел Kubernetes в состоянии Ready указывает на регистрацию узла. Это само по себе не доказывает наличие сетевого взаимодействия рабочих нагрузок, операций обратного вызова или операций жизненного цикла Azure.

Сократите нагрузку при проверке

Удалите только временные ресурсы, созданные в этой статье.

kubectl delete namespace "${VALIDATION_NAMESPACE}"

Следующий шаг

Затем управляйте, обновляйте, модернизируйте или удаляйте подключённый узел Flex.

  • Последнее обновление: