Azure CLI を使用して Kubernetes クラスターを作成する
適用対象: Azure Local バージョン 23H2
この記事では、Azure CLI を使用して Azure Local で Kubernetes クラスターを作成する方法について説明します。 ワークフローは次のとおりです。
- Azure CLI を使用して、Azure Local バージョン 23H2 で Kubernetes クラスターを作成します。 クラスターは、既定で Azure Arc に接続されています。
- クラスターの作成時に、Kubernetes クラスター管理者アクセス権を持つ Microsoft Entra ユーザーの一覧を含む Microsoft Entra グループを提供します。
- kubectl と Microsoft Entra ID を使用してクラスターにアクセスします。
- このクラスターで、Web フロントエンドと Redis インスタンスが含まれているサンプルの複数コンテナー アプリケーションを実行します。
開始する前に
- 開始する前に、オンプレミスのインフラストラクチャ管理者から次の詳細があることを確認してください。
- Azure サブスクリプション ID - デプロイと登録に Azure Local が使用される Azure サブスクリプション ID。
- カスタムの場所 ID - カスタムの場所の Azure Resource Manager ID。 カスタムの場所は、Azure ローカル クラスターのデプロイ中に構成されます。 インフラストラクチャ管理者は、カスタムの場所の Resource Manager ID を指定する必要があります。 Kubernetes クラスターを作成するには、このパラメーターが必要です。 インフラストラクチャ管理者がカスタムの場所名とリソース グループ名を提供する場合は、
az customlocation show --name "<custom location name>" --resource-group <azure resource group> --query "id" -o tsvを使用して Resource Manager ID を取得することもできます。 - ネットワーク ID - 次の手順に従って作成された Azure ローカル論理ネットワークの Azure Resource Manager ID 。 管理者が論理ネットワークの ID を指定する必要があります。 Kubernetes クラスターを作成するには、このパラメーターが必要です。 論理ネットワークが作成されたリソース グループがわかっている場合は、
az stack-hci-vm network lnet show --name "<lnet name>" --resource-group <azure resource group> --query "id" -o tsvを使用して Azure Resource Manager ID を取得することもできます。
- ローカル開発マシンでこの記事の手順を実行して、リモートの Azure ローカル デプロイに Kubernetes クラスターを作成できます。 開発用コンピューターに最新バージョンの Az CLI があることを確認します。
az upgradeを使用して Az CLI バージョンをアップグレードすることもできます。 - どこからでも Kubernetes クラスターに接続するには、Microsoft Entra グループを作成し、それにメンバーを追加します。 Microsoft Entra グループのすべてのメンバーは、クラスター管理者がクラスターにアクセスできます。 Microsoft Entra グループのメンバーとして自分を追加してください。 自分を追加しない場合、kubectl を使用して Kubernetes クラスターにアクセスすることはできません。 Microsoft Entra グループの作成とユーザーの追加の詳細については、「 Manage Microsoft Entra グループとグループ メンバーシップを参照してください。
- 開発用コンピューターに kubectl をダウンロードしてインストールします。 Kubernetes コマンド ライン ツール kubectl を使用すると、Kubernetes クラスターに対してコマンドを実行できます。 kubectl を使用して、アプリケーションのデプロイ、クラスター リソースの検査と管理、ログの表示を行うことができます。
Azure CLI 拡張機能をインストールする
次のコマンドを実行して、必要な Azure CLI 拡張機能をインストールします。
az extension add -n aksarc --upgrade
az extension add -n customlocation --upgrade
az extension add -n stack-hci-vm --upgrade
az extension add -n connectedk8s --upgrade
Kubernetes クラスターを作成する
az aksarc create コマンドを使用して、AKS Arc に Kubernetes クラスターを作成します。このコマンドを実行する前に、必ず Azure にサインインしてください。 Azure サブスクリプションが複数ある場合は、az account set コマンドを使って適切なサブスクリプション ID を選びます。
az aksarc create -n $aksclustername -g $resource_group --custom-location $customlocationID --vnet-ids $logicnetId --aad-admin-group-object-ids $aadgroupID --generate-ssh-keys
数分後、コマンドが完了し、クラスターに関する情報が JSON 形式で返されます。
Note
- SSH キーの値は、プロビジョニングされたクラスター内のノードにアクセスするための公開キーです。 既定では、このキーは
~/.ssh/id_rsa.pubにあります。 クラスターの作成時に--ssh-key-valueパラメーターを使用して、別の場所を指定できます。 - ローカル コンピューターに既存の SSH キーがない場合は、
--generate-ssh-keysパラメーターが必要です。 クラスターの作成時にこのパラメーターを含めず、SSH キーが存在しない場合は、エラー メッセージが表示されます。 - ローカル コンピューターに SSH キーが既にある場合、AKS クラスターはそのキーを再利用します。 この場合、
--generate-ssh-keysを指定するか、そのパラメーターを省略しても効果はありません。
重要
AKS クラスターに Azure RBAC またはワークロード ID を使用するには、Azure CLI を使用してクラスターの作成時に必要なパラメーターを渡す必要があります。 現時点では、ワークロード ID や Azure RBAC を有効にするために既存の AKS クラスターを更新することはサポートされていません。 詳細については、「Azure RBAC for Kubernetes 承認の使用またはクラスターのワークロード ID のデプロイと構成を参照してください。
Kubernetes クラスターに接続する
これで、開発マシンから az connectedk8s proxy コマンドを実行して、Kubernetes クラスターに接続できます。 このコマンドを実行する前に、必ず Azure にサインインしてください。 Azure サブスクリプションが複数ある場合は、az account set コマンドを使って適切なサブスクリプション ID を選びます。
このコマンドは、Kubernetes クラスターの kubeconfig を開発用マシンにダウンロードし、オンプレミスの Kubernetes クラスターへのプロキシ接続チャネルを開きます。 コマンドが実行されている限り、チャネルは開いています。 好きなだけ長くこのコマンドを実行して、クラスターにアクセスしてみましょう。 タイムアウトした場合は、CLI ウィンドウを閉じ、新しいウィンドウを開き、コマンドをもう一度実行します。
次のコマンドを正常に実行するには、Kubernetes クラスターをホストするリソース グループに対する共同作成者アクセス許可が必要です。
az connectedk8s proxy --name $aksclustername --resource-group $resource_group --file .\aks-arc-kube-config
予想される出力:
Proxy is listening on port 47011
Merged "aks-workload" as current context in .\\aks-arc-kube-config
Start sending kubectl requests on 'aks-workload' context using
kubeconfig at .\\aks-arc-kube-config
Press Ctrl+C to close proxy.
このセッションを実行したまま、別のターミナル/コマンド プロンプトから Kubernetes クラスターに接続します。 kubectl get コマンドを実行して、Kubernetes クラスターに接続できることを確認します。 このコマンドは、クラスター ノードの一覧を返します。
kubectl get node -A --kubeconfig .\aks-arc-kube-config
次の出力例は、前の手順で作成したノードを示しています。 ノードの状態が "準備完了" であることを確認します。
NAME STATUS ROLES AGE VERSION
moc-l0ttdmaioew Ready control-plane,master 34m v1.24.11
moc-ls38tngowsl Ready <none> 32m v1.24.11
アプリケーションとロード バランサーをデプロイする
Kubernetes のマニフェスト ファイルでは、どのコンテナー イメージを実行するかなど、クラスターの望ましい状態を定義します。
マニフェストを使用して、 Azure Vote アプリケーションの実行に必要なすべてのオブジェクトを作成できます。 このマニフェストには、次の 2 つの Kubernetes デプロイが含まれています。
- サンプルの Azure Vote Python アプリケーション。
- Redis インスタンス。
2 つの Kubernetes サービス も作成されます。
- Redis インスタンス用の内部サービス。
- インターネットから Azure Vote アプリケーションにアクセスするための外部サービス。
azure-vote.yaml という名前のファイルを作成し、次のマニフェストにコピーします。
apiVersion: apps/v1
kind: Deployment
metadata:
name: azure-vote-back
spec:
replicas: 1
selector:
matchLabels:
app: azure-vote-back
template:
metadata:
labels:
app: azure-vote-back
spec:
nodeSelector:
"kubernetes.io/os": linux
containers:
- name: azure-vote-back
image: <path to image>/oss/bitnami/redis:6.0.8
env:
- name: ALLOW_EMPTY_PASSWORD
value: "yes"
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 250m
memory: 256Mi
ports:
- containerPort: 6379
name: redis
---
apiVersion: v1
kind: Service
metadata:
name: azure-vote-back
spec:
ports:
- port: 6379
selector:
app: azure-vote-back
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: azure-vote-front
spec:
replicas: 1
selector:
matchLabels:
app: azure-vote-front
template:
metadata:
labels:
app: azure-vote-front
spec:
nodeSelector:
"kubernetes.io/os": linux
containers:
- name: azure-vote-front
image: <path to image>/azure-vote-front:v1
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 250m
memory: 256Mi
ports:
- containerPort: 80
env:
- name: REDIS
value: "azure-vote-back"
---
apiVersion: v1
kind: Service
metadata:
name: azure-vote-front
spec:
type: LoadBalancer
ports:
- port: 80
selector:
app: azure-vote-front
kubectl apply コマンドを使用してアプリケーションをデプロイし、YAML の名前を指定します。
kubectl apply -f azure-vote.yaml --kubeconfig .\\aks-arc-kube-config
次の出力例は、正常に作成されたデプロイおよびサービスを示しています。
deployment "azure-vote-back" created
service "azure-vote-back" created
deployment "azure-vote-front" created
service "azure-vote-front" created
アプリケーション フロントエンドの外部 IP を割り当てることができるように、MetalLB ロード バランサーをデプロイします。 次 手順 従って、Azure portal から、または CLI を使用して MetalLB 拡張機能をデプロイできます。
アプリケーションをテストする
アプリケーションが実行されると、Kubernetes サービスによってアプリケーション フロントエンドがインターネットに公開されます。 このプロセスが完了するまでに数分かかることがあります。
kubectl get service コマンドと --watch 引数を使用して進行状況を監視します。
kubectl get service azure-vote-front --watch --kubeconfig .\aks-arc-kube-config
azure-vote-front サービスの EXTERNAL-IP 出力は、最初は 保留中として表示されます。
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
azure-vote-front LoadBalancer 10.0.37.27 <pending> 80:30572/TCP 6s
EXTERNAL-IP アドレスが pending から実際のパブリック IP アドレスに変わったら、Ctrl キーを押しながら C キーを押して kubectl ウォッチ プロセスを停止します。 次の出力例は、サービスに割り当てられている有効なパブリック IP アドレスを示しています。
azure-vote-front LoadBalancer 10.0.37.27 52.179.23.131 80:30572/TCP 2m
Azure Vote アプリが動作していることを確認するには、Web ブラウザーを開いてサービスの外部 IP アドレスにアクセスします。
クラスターを削除する
az aksarc delete コマンドを実行して、作成したクラスターをクリーンアップします。
az aksarc delete --name $aksclustername --resource-group $resource_group