フレックスノードを AKS クラスターにアタッチする (プレビュー)

Important

AKS のプレビュー機能は、セルフサービスのオプトイン単位で利用できます。プレビューは、"現状有姿のまま" および "利用可能な限度" で提供され、サービスレベルアグリーメントおよび限定保証から除外されるものとします。 AKS プレビューは、ベストエフォートベースでカスタマーサポートによって部分的にカバーされます。そのため、これらの機能は運用環境での使用を目的としていません。詳細については、次のサポート記事を参照してください。

Azure Kubernetes Service (AKS) クラスター、ネットワーク、フレックスノードプール、ホスト、ID を準備したら、ホストをブートストラップしてターゲットプールにアタッチします。

この記事では、あなたが次のことを行います。

Flex ノードリリースをダウンロードして確認します。
選択したAzure ID を使用してホストをブートストラップし、新しいプールデータを取得します。
Kubernetes ノード、Azure マシン、ネットワーク状態、エージェントサービスを確認します。
ワークロードの配置、Kubernetes コールバック、およびクロスノード接続を検証します。

必要なツールとネットワークアクセスを備える Linux 互換の Bash 環境で、この記事の管理コマンドを実行します。この記事では、その環境を Bash 環境と呼びます。クラスターに参加する別個のマシンは 、フレックスノードホストです。は、ステップによって明示的に指示された場合にのみ、そこでコマンドを実行します。

プライベート AKS クラスターの場合は、プライベート API サーバーを解決して到達できる Bash 環境からすべての kubectl コマンドを実行します。必要なAzureとホストアクセスがある場合は、Bash 環境からAzure CLI、成果物のダウンロード、SSH、SCP コマンドを実行できます。 Flex ノードホストネットワークも解決し、プライベート API エンドポイントに到達する必要があります。

始める前の準備

ネットワークの構成を完了し、AKS にフレックスノードプールを作成します。
Flex ノードのホストと ID の準備を完了します。
Azure CLI、aks-preview拡張機能、AKS_VERSION、jq、curl、sha256sum、OpenSSH クライアント、およびscpの 1 つのマイナーバージョン内のkubectl バージョンを Bash 環境にインストールします。
マネージド ID またはサービスプリンシパルの場合は、選択した flex ノードプールのブートストラップデータを取得できるAzure アカウントを使用します。
承認された SSH 管理パスを使用して、Bash 環境が Flex ノードホストに到達できることを確認します。
Flex ノードホストが、プールブートストラップデータ、Azure Resource Manager、Microsoft Entra ID、および選択した AKS API エンドポイントで返されるリリースおよびブートストラップ成果物エンドポイントに HTTPS 経由で到達できることを確認します。

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>です。この記事では、必要なその他の変数を派生させます。環境ファイルをまだ作成していない場合は、最初に「Flex ノードのデプロイを計画する」を完了してください。シェルがエラーを報告する場合は、この手順を続行しないでください。

アクティブなサブスクリプションを設定し、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 ノードリリースをダウンロードして確認する

ホストアーキテクチャを特定し、一致するリリースアーカイブを選択します。

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

選択したリリースからアーカイブマニフェストとチェックサムマニフェストをダウンロードします。

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"

アーカイブのチェックサムエントリを 1 つだけ選択し、ファイルを確認します。

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されていることを報告しない限り、続行しないでください。

同じリリースタグからブートストラップスクリプトをダウンロードし、その 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"
```
現在、このリリースでは、このスクリプトの個別のチェックサムは発行されていません。シェルにパイプせずにダウンロードし、検証済みのエージェントアーカイブとバージョンが一致した状態に保ち、構文チェックが失敗した場合は停止します。

現在のプールのブートストラップデータを取得

マネージド ID とサービスプリンシパルパスでは、Bash 環境で取得したブートストラップデータが使用されます。マネージド ID Azure Arc選択した場合は、このセクションをスキップします。 Arc ブートストラップコマンドは、Arc マシン ID を介して新しいデータを取得します。

マネージド ID またはサービスプリンシパルを使用する場合は、ホストにファイルを転送する直前にデータを取得します。応答には、1 時間後に期限切れになるブートストラップトークンが含まれています。返信を印刷したり、メモに保存したりしないでください。

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"

検証済みのリリースファイルとハンドオフファイルをホストにコピーします。

scp -i "${SSH_PRIVATE_KEY_PATH}" \
    "${WORK_DIR}/${AGENT_ARCHIVE}" \
    "${WORK_DIR}/bootstrap.sh" \
    "${WORK_DIR}/host-bootstrap.env" \
    "${FLEX_HOST_SSH_TARGET}:/tmp/"

マネージド ID またはサービスプリンシパルの場合は、保護されたブートストラップデータもコピーします。
```
scp -i "${SSH_PRIVATE_KEY_PATH}" \
    "${WORK_DIR}/base-config.json" \
    "${FLEX_HOST_SSH_TARGET}:/tmp/"
```

ホストに接続し、ルートシェルを開始します。

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

非安全ハンドオフ値を読み込み、転送されたファイルを検証します。
```
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されたことを報告したら続行します。チェックサムまたはスクリプト構文のチェックが失敗した場合は停止します。

マネージド ID またはサービスプリンシパルの場合は、ブートストラップデータをインストールします。

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

ホストをブートストラップ

前の記事で構成した ID と一致するセクションのみを完了します。

このセクションは、Arc マシンリソースが SSH ホストと一致し、 himdsd がアクティブであり、HIMDS 検証が正確な AKS リソースに対して HTTP 200 を返し、前の記事で確認したように AKS スコープのロールの割り当てが存在する場合にのみ使用します。このパスは、Arc マシン ID を介して新しいブートストラップデータを取得し、Bash 環境から base-config.json ファイルを使用しません。

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 と表示され、マシンの登録が完了し、ブートストラップスクリプトで flex ノードエージェントサービスが開始されたことが報告されたら、続行してください。ブートストラップがデータを取得できない場合は、Arc 接続、himdsd、AKS スコープロールの割り当て、Azure Resource Managerへのホストアクセスを確認します。

続行する前に、承認された資格情報管理プロセスを通じて、 /etc/aks-flex-node/credentials/sp-client-certificate ホストで PEM 証明書と秘密キーを組み合わせて使用できるようにします。資格情報ディレクトリは、 700アクセス許可を持つルート所有である必要があります。資格情報またはそのパスを共有環境ファイルに格納しないでください。

ホストルートシェルで、証明書のパスを設定し、その所有者とアクセス許可を確認します。

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

ファイルが存在し、 root rootが所有し、 600アクセス許可を持っている場合にのみ続行します。実行中のエージェントが Azure Machine の照合に使用するため、ブートストラップ後もそれを利用可能な状態にしておいてください。

Bash 環境で取得した保護された base-config.json ファイルを使用してブートストラップを実行します。

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

マシンの登録が完了し、ブートストラップスクリプトによって flex ノードエージェントサービスが開始されたことを報告したら続行します。ブートストラップが失敗した場合、ホストがまだアタッチされたままであるか、エージェントがまだそれを使用している間は、サービスプリンシパル資格情報を削除しないでください。

レンダリングされたサービスプリンシパルの構成を調べる

ブートストラッププロセスが成功した後、ホストルートシェルでコマンドを実行します。

サービスプリンシパル識別子と証明書ファイルは、ブートストラッププロセスへの入力です。スクリプトは、それらをプールのブートストラップデータとマージして、エージェントの構成を生成します。

File	Purpose	取り扱い
`/etc/aks-flex-node/base-config.json`	有効期間の短いブートストラップトークンを含め、添付ファイルの前に取得されたプールブートストラップデータ。	保護された状態にし、その内容を印刷したり共有したりしないでください。
`/etc/aks-flex-node/config.json`	ターゲットクラスターとプール、ノード設定、成果物ソース、Azure認証設定を含む、レンダリングされた flex ノード構成。	モード `0600`でルート所有。完全なファイルを印刷したり共有したりしないでください。
`/etc/aks-flex-node/credentials/sp-client-certificate`	実行中のエージェントによって使用される PEM 証明書と秘密キーの組み合わせ。	保護された資格情報ディレクトリ内で、モード `0600` のルート所有権を持ち、接続されている間は保持されます。

デプロイでbootstrap.shに固定しているエージェントバージョン用のAKS_FLEX_NODE_VERSIONスクリプトでは、--sp-client-certificate-fileが証明書のパスをazure.servicePrincipal.clientSecretFileに書き込みます。名前にもかかわらず、このフィールドはクライアントシークレット値ではなく、このワークフロー内の証明書ファイルを参照します。名前を clientCertificateFile に変更しないでください。スクリプトは azure.managedIdentity を削除し、サービスプリンシパル認証を選択するときに azure.arc.enabled を false に設定します。

次の編集された例は、証明書ベースのサービスプリンシパル構成の形状を示しています。ホストにコピーする完全な構成スキーマやファイルではありません。バージョンに一致するブートストラップスクリプトを使用して構成を生成し続けます。

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

Kubernetes ブートストラップトークンと Azure サービスプリンシパルは、さまざまな目的で機能します。トークンは、最初の Kubernetes 信頼を確立します。サービスプリンシパルは永続的なAzure認証を提供します。 Azure ロールの割り当てに使用されるサービスプリンシパルオブジェクト ID は、この構成に格納されているアプリケーションクライアント ID ではありません。

許可リストに含まれる一連の非セキュリティターゲットフィールドと ID フィールドのみを検査します。このプロジェクションは、完全な構成で cat または jq . に置き換えないでください。
```
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
```
予想されるクラスター、プール、ホスト名、テナント ID、アプリケーションクライアント ID、証明書パスを確認します。これらのフィールドは資格情報ではありませんが、診断出力を共有する前にリソース識別子を確認してください。

生成された構成で、目的のサービスプリンシパルと証明書が選択され、その他のAzure ID モードが無効であることを確認します。

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

チェックが失敗した場合は停止します。 ID の不一致を回避するために、生成されたファイルを手動で編集しないでください。

構成と証明書ファイルのアクセス許可を確認します。
```
stat -c '%U %G %a %n' \
    /etc/aks-flex-node/config.json \
    "${FLEX_SP_CLIENT_CERTIFICATE_FILE}"
```
両方のファイルは、アクセス許可600を持つroot rootによって所有されている必要があります。この検査では、選択した構成が確認されます。次のノード、マシン、ワークロードのチェックでは、ランタイムの動作が検証されます。

システム割り当てマネージド ID の場合、 HOST_IDENTITY_CLIENT_ID は空のままです。ユーザー割り当てマネージド ID は、共有環境に記録されたクライアント ID を使用します。どちらのオプションでも、Bash 環境で取得した保護された base-config.json ファイルが使用されます。

システム割り当てマネージド ID の場合は、次を実行します。

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

ユーザー割り当てマネージド ID の場合は、そのクライアント ID を追加します。

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

マシンの登録が完了し、ブートストラップスクリプトによって flex ノードエージェントサービスが開始されたことを報告したら続行します。

一時リリースファイルを削除する

ブートストラップが成功したら、ホストから一時的なスクリプト、アーカイブ、ハンドオフファイルを削除します。

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

最初の exit はルートシェルから離れる。 2 つ目は 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されたら続行します。ノードが作成されていない場合、または準備が整っていない場合は、ブートストラップを再試行する前に、ブートストラップ出力、API 接続、およびエージェントサービスを確認してください。

Azure マシンリソースを確認する

ターゲット 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

準備された 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}"

コマンドが返したマシン名がちょうど 1 つだけの場合に続行します。

そのマシンを表示します。

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

Flex ノードネットワークを確認する

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

サイトと関連する Unbounded-Net ネットワークリソースを確認します。

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

flex ノードにスケジュールされた Unbounded-Net ポッドを表示します。

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

次の場合を除き、ワークロードの検証を続行しないでください。

ノードが Ready。
サイトは、ネットワークに関する記事で設定した Unbounded-Net Flex サイトです。
ポッド CIDR は、計画された FLEX_POD_CIDR 範囲に属しています。
WireGuard 公開キーが設定されます。
cluster-flex-private-l3 SitePeering は、clusterサイトと flex-site サイトを参照します。
ノード上で返された Unbounded-Net ポッドはすべて Running。
パブリック WireGuard トポロジの場合、予想されるゲートウェイプールピアリングが存在します。

フレックスノードエージェントを確認する

サービスがアクティブになるまで最大 1 分待ちます。表示されない場合は、サービスの状態と最新のログを表示します。

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リソースを一覧表示できないためにエージェントが繰り返し再起動する場合は、「ネットワークの構成」の一時的な flex デーモン RBAC ステップに戻り、AKS に Flex ノードプールを作成し、ロールとバインドが存在することを確認してから、エージェントを再起動します。

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

Kubernetes スケジューラが Flex ノードに配置する HTTP サーバーを作成し、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

コールバックとローカルサービス接続を確認する

Kubernetes API サーバーのコールバックパスを使用して、ログとコマンドの実行を確認します。

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

ポート転送を確認する

現在のターミナルで、Kubernetes API サーバーを介してローカルポートを転送します。このコマンドでは、前に読み込んだデプロイ環境と kubeconfig を使用します。

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

2 番目のターミナルで、転送されたエンドポイントを要求します。

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

そのノードでクライアントポッドを実行し、予想される応答を確認します。

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

Ready状態の Kubernetes ノードには、ノードの登録が表示されます。ワークロードネットワーク、コールバック操作、またはAzureライフサイクル操作は、それ自体では証明されません。

検証ワークロードをクリーンアップする

この記事で作成した一時的なリソースのみを削除します。

kubectl delete namespace "${VALIDATION_NAMESPACE}"

次のステップ

次に、接続されている Flex ノードを管理、更新、アップグレード、または削除します。

フィードバック

このページはお役に立ちましたか?

最終更新: 2026-09-22