クイックスタート: 既存の Kubernetes クラスターを Azure Arc に接続する
Azure Arc 対応 Kubernetes は、Azure CLI または Azure PowerShell を使用して既存の Kubernetes クラスターを Azure Arc に接続することで開始します。
Azure Arc にクラスターを接続するしくみを概念図で確認するには、「Azure Arc 対応 Kubernetes エージェントの概要」を参照してください。 サンプル/プラクティス エクスペリエンスで試すには、 Azure Arc Jumpstart にアクセスしてください。
前提条件
重要
以下の前提条件に加えて、Azure Arc 対応 Kubernetes のネットワーク要件をすべて満たしていることを確認してください。
アクティブなサブスクリプションが含まれる Azure アカウント。 無料でアカウントを作成できます。
Kubernetes の中心概念に関する基本的な理解。
Azure CLI へのログインと Azure Arc へのクラスターの接続に使用できる ID (ユーザーまたはサービス プリンシパル)。
Azure CLI の最新バージョン。
次のコマンドを実行してインストールされた、connectedk8s Azure CLI 拡張機能の最新バージョン。
az extension add --name connectedk8s稼働している Kubernetes クラスター。 お持ちでない場合は、次のいずれかのオプションを使用してクラスターを作成できます。
Cluster API を使用したセルフマネージド Kubernetes クラスター
注意
クラスターには、オペレーティング システムとアーキテクチャの種類が
linux/amd64および/またはlinux/arm64であるノードが少なくとも 1 つ含まれている必要があります。 ARM64 シナリオの詳細については、クラスターの要件に関するページを参照してください。
クラスターにデプロイされる Arc エージェント用に少なくとも 850 MB の空き容量、および 1 つの CPU の約 7% を使用するための容量。
kubeconfig ファイルと、クラスターを指すコンテキスト。 kubeconfig ファイルの概要と、クラスターを指すコンテキストを設定する方法の詳細については、こちらの記事を参照してください。
Azure Arc 対応 Kubernetes 用のプロバイダーを登録する
次のコマンドを入力します。
az provider register --namespace Microsoft.Kubernetes az provider register --namespace Microsoft.KubernetesConfiguration az provider register --namespace Microsoft.ExtendedLocation登録プロセスを監視します。 登録には最大で 10 分かかる場合があります。
az provider show -n Microsoft.Kubernetes -o table az provider show -n Microsoft.KubernetesConfiguration -o table az provider show -n Microsoft.ExtendedLocation -o table登録すると、これらの名前空間の
RegistrationState状態がRegisteredに変わります。
リソース グループを作成する
次のコマンドを実行します。
az group create --name AzureArcTest --location EastUS --output table
出力:
Location Name
---------- ------------
eastus AzureArcTest
既存の Kubernetes クラスターを接続する
次のコマンドを実行して、クラスターに接続します。 このコマンドを使用して、Azure Arc エージェントをクラスターにデプロイし、Helm v. 3.6.3 をデプロイ マシンの .azure フォルダーにインストールします。 この Helm 3 のインストールは Azure Arc でのみ使用され、マシンにインストール済みの以前のバージョンの Helm が削除されたり変更されたりすることはありません。
この例では、クラスターの名前は AzureArcTest1 です。
az connectedk8s connect --name AzureArcTest1 --resource-group AzureArcTest
出力:
Helm release deployment succeeded
{
"aadProfile": {
"clientAppId": "",
"serverAppId": "",
"tenantId": ""
},
"agentPublicKeyCertificate": "xxxxxxxxxxxxxxxxxxx",
"agentVersion": null,
"connectivityStatus": "Connecting",
"distribution": "gke",
"id": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/AzureArcTest/providers/Microsoft.Kubernetes/connectedClusters/AzureArcTest1",
"identity": {
"principalId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"tenantId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"type": "SystemAssigned"
},
"infrastructure": "gcp",
"kubernetesVersion": null,
"lastConnectivityTime": null,
"location": "eastus",
"managedIdentityCertificateExpirationTime": null,
"name": "AzureArcTest1",
"offering": null,
"provisioningState": "Succeeded",
"resourceGroup": "AzureArcTest",
"tags": {},
"totalCoreCount": null,
"totalNodeCount": null,
"type": "Microsoft.Kubernetes/connectedClusters"
}
ヒント
location パラメーターを指定せずに上記のコマンドを実行すると、リソース グループと同じ場所に Azure Arc 対応 Kubernetes リソースが作成されます。 Azure Arc 対応 Kubernetes リソースを別の場所に作成するには、az connectedk8s connect コマンドの実行時に --location <region> または -l <region> のいずれかを指定します。
重要
タイムアウト エラーが原因でデプロイが失敗する場合は、トラブルシューティング ガイドを参照して、この問題の詳しい解決方法を確認してください。
送信プロキシ サーバーを使用して接続する
クラスターが送信プロキシ サーバーの背後にある場合、送信プロキシ サーバー経由で要求をルーティングする必要があります。
送信プロキシ サーバーを使用するには、デプロイ マシンで Azure CLI に必要な環境変数を設定します。
export HTTP_PROXY=<proxy-server-ip-address>:<port> export HTTPS_PROXY=<proxy-server-ip-address>:<port> export NO_PROXY=<cluster-apiserver-ip-address>:<port>Kubernetes クラスターで、
proxy-httpsパラメーターとproxy-httpパラメーターを指定して connect コマンドを実行します。 プロキシ サーバーが HTTP と HTTPS の両方で設定されている場合は、HTTP プロキシには--proxy-http、HTTPS プロキシには--proxy-httpsを必ず使用してください。 プロキシ サーバーで HTTP のみが使用される場合は、両方のパラメーターにその値を使用できます。az connectedk8s connect --name <cluster-name> --resource-group <resource-group> --proxy-https https://<proxy-server-ip-address>:<port> --proxy-http http://<proxy-server-ip-address>:<port> --proxy-skip-range <excludedIP>,<excludedCIDR> --proxy-cert <path-to-cert-file>
注意
- 一部のネットワーク要求 (たとえばクラスター内のサービス間通信を含むもの) は、送信方向の通信でプロキシ サーバーを介してルーティングされるトラフィックから切り離す必要があります。
--proxy-skip-rangeパラメーターを使用して、CIDR 範囲とエンドポイントをコンマで区切って指定することで、エージェントからこれらのエンドポイントへの通信が送信プロキシ経由で行われないようにすることができます。 少なくとも、クラスター内のサービスの CIDR 範囲は、このパラメーターの値として指定する必要があります。 たとえば、kubectl get svc -Aが返すサービスの一覧で、すべてのサービスの ClusterIP 値が10.0.0.0/16の範囲であるとします。 その場合、--proxy-skip-rangeに指定する値は10.0.0.0/16,kubernetes.default.svc,.svc.cluster.local,.svcです。 --proxy-http、--proxy-https、および--proxy-skip-rangeは、ほとんどの送信プロキシ環境に必要です。--proxy-certは、プロキシが求める信頼された証明書を、エージェント ポッドの信頼された証明書ストアに挿入する必要がある場合に "のみ" 必要となります。- 送信プロキシは、websocket 接続を許可するように構成する必要があります。
プロキシ サーバー エンドポイントの入力なしで、信頼された証明書のみを指定する必要がある送信プロキシ サーバーの場合は、--proxy-cert の入力のみを指定して az connectedk8s connect を実行できます。 複数の信頼された証明書が予期される場合は、--proxy-cert パラメーターを使用して、結合された証明書チェーンを 1 つのファイルに指定できます。
注意
--custom-ca-certは--proxy-certの別名です。 どちらのパラメーターも同じ意味で使用できます。 同じコマンドで両方のパラメーターを渡すと、最後に渡されたパラメーターが有効と認められます。
--proxy-cert パラメーターを指定して connect コマンドを実行します。
az connectedk8s connect --name <cluster-name> --resource-group <resource-group> --proxy-cert <path-to-cert-file>
クラスターの接続を確認する
次のコマンドを実行します。
az connectedk8s list --resource-group AzureArcTest --output table
出力:
Name Location ResourceGroup
------------- ---------- ---------------
AzureArcTest1 eastus AzureArcTest
注意
クラスターをオンボードした後、Azure portal の Azure Arc 対応の Kubernetes リソースの概要ページで、クラスターのメタデータ (クラスターのバージョン、エージェントのバージョン、ノードの数など) が画面に表示されるまでに約 5 ～ 10 分かかります。
ヒント
クラスターの接続時に発生する問題のトラブルシューティングについては、「Azure Arc 対応 Kubernetes クラスターの接続の問題を診断する」を参照してください。
Kubernetes 用 Azure Arc エージェントを表示する
Azure Arc 対応の Kubernetes では、azure-arc 名前空間にいくつかのエージェントがデプロイされます。
これらのデプロイとポッドは、次を使用して表示します。
kubectl get deployments,pods -n azure-arcすべてのポッドが
Running状態であることを確認します。出力:
NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/cluster-metadata-operator 1/1 1 1 13d deployment.apps/clusterconnect-agent 1/1 1 1 13d deployment.apps/clusteridentityoperator 1/1 1 1 13d deployment.apps/config-agent 1/1 1 1 13d deployment.apps/controller-manager 1/1 1 1 13d deployment.apps/extension-manager 1/1 1 1 13d deployment.apps/flux-logs-agent 1/1 1 1 13d deployment.apps/kube-aad-proxy 1/1 1 1 13d deployment.apps/metrics-agent 1/1 1 1 13d deployment.apps/resource-sync-agent 1/1 1 1 13d NAME READY STATUS RESTARTS AGE pod/cluster-metadata-operator-9568b899c-2stjn 2/2 Running 0 13d pod/clusterconnect-agent-576758886d-vggmv 3/3 Running 0 13d pod/clusteridentityoperator-6f59466c87-mm96j 2/2 Running 0 13d pod/config-agent-7cbd6cb89f-9fdnt 2/2 Running 0 13d pod/controller-manager-df6d56db5-kxmfj 2/2 Running 0 13d pod/extension-manager-58c94c5b89-c6q72 2/2 Running 0 13d pod/flux-logs-agent-6db9687fcb-rmxww 1/1 Running 0 13d pod/kube-aad-proxy-67b87b9f55-bthqv 2/2 Running 0 13d pod/metrics-agent-575c565fd9-k5j2t 2/2 Running 0 13d pod/resource-sync-agent-6bbd8bcd86-x5bk5 2/2 Running 0 13d
これらのエージェントの詳細については、「Azure Arc 対応 Kubernetes エージェントの概要」を参照してください。
リソースをクリーンアップする
Azure CLI で次のコマンドを使用して、Azure Arc 対応 Kubernetes リソース、関連付けられているすべての構成リソース、"および" クラスターで実行されているすべてのエージェントを削除できます。
az connectedk8s delete --name AzureArcTest1 --resource-group AzureArcTest
削除プロセスが失敗した場合は、次のコマンドを使用して強制的に削除します (確認プロンプトをバイパスする場合は -y を追加します)。
az connectedk8s delete -n AzureArcTest1 -g AzureArcTest --force
このコマンドは、(以前に作成したリソースが完全には削除されていないため) 新しいクラスター デプロイの作成時に問題が発生した場合にも使用できます。
注意
Azure portal を使用して Azure Arc 対応 Kubernetes リソースを削除すると、関連付けられているすべての構成リソースは削除されますが、クラスターで実行されているエージェントは削除 "されません"。 ベスト プラクティスは、Azure portal 内のリソースを削除するのではなく、az connectedk8s delete を使用して Azure Arc 対応 Kubernetes リソースを削除することです。
次のステップ
- GitOps (Flux v2) を使用して構成をデプロイする方法を確認します。
- Azure Arc 対応 Kubernetes の一般的な問題のトラブルシューティング。
- Azure Arc のジャンプスタートを使用して、Azure Arc 対応 Kubernetes の自動化されたシナリオを体験します。