Azure Kubernetes Fleet Manager を使用したインテリジェントなクラスター間 Kubernetes リソース配置
アプリケーション開発者は、多くの場合、Kubernetes リソースを複数のクラスターにデプロイする必要があります。 Fleet オペレーターは多くの場合、ワークロードのための最適なクラスターをヒューリスティック (たとえばコンピューティングのコストや、メモリと CPU などの使用可能リソース) に基づいて選ぶ必要があります。 複数のクラスターでこれらの Kubernetes リソースを手動で作成、更新、追跡するのは手間がかかります。 この記事では、Azure Kubernetes Fleet Manager (Fleet) によって、インテリジェントな Kubernetes リソース配置機能を使用してこれらのシナリオに対処する方法について説明します。
概要
Fleet のリソース配置機能では、次のクラスター プロパティに基づいてスケジュールの決定を行うことができます。
- ノード数
- ターゲット メンバー クラスターのコンピューティング/メモリのコスト
- ターゲット メンバー クラスターでのリソース (CPU またはメモリ) の可用性
このガイドで使用されている概念の説明については、リソース伝達の概念の概要に関するページを参照してください。
前提条件
アクティブなサブスクリプションが含まれる Azure アカウント。 無料でアカウントを作成できます。
1 つ以上のメンバー クラスターを含む Fleet リソースが必要です。 このとおりでない場合は、クイックスタートに従って Fleet リソースをハブ クラスターありで作成してから、Azure Kubernetes Service (AKS) クラスターをメンバーとして参加させてください。
推奨事項: 関心のあるクラスター プロパティ (場所、ノード数、リソース、またはコスト) を使用して配置をテストできるように、AKS メンバー クラスターを構成してください。
以下の環境変数を設定します。
export GROUP=<resource-group> export FLEET=<fleet-name> export MEMBERCLUSTER01=<cluster01> export MEMBERCLUSTER02=<cluster02>このガイドの手順を完了するには、Azure CLI バージョン 2.58.0 以降がインストールされている必要があります。 インストールとアップグレードについては、「Azure CLI のインストール」を参照してください。
Kubernetes CLI (kubectl) がまだインストールされていない場合は、次のコマンドを使用してインストールしてください。
az aks install-cli次のコマンドを実行してインストールできる
fleetAzure CLI 拡張機能も必要です。az extension add --name fleetリリースされている最新バージョンの拡張機能に更新するには、
az extension updateコマンドを実行します。az extension update --name fleetkubectl からフリート ハブ クラスターへの接続を認可します。
az fleet get-credentials --resource-group $GROUP --name $FLEET
メンバー クラスターのプロパティを検査する
追加するメンバー クラスターごとに、これらのステップを繰り返します。
ハブ クラスターに対するクエリを実行してメンバー クラスターのラベル、プロパティ、リソースを取得します。 結果を読むことができるように、YAML として出力します。
kubectl get membercluster $MEMBERCLUSTER01 –o yaml生成された YAML ファイルには、配置ポリシーの構築に使用できる詳細情報 (ラベルとプロパティ) が記録されています。
apiVersion: cluster.kubernetes-fleet.io/v1 kind: MemberCluster metadata: annotations: ... labels: fleet.azure.com/location: eastus2 fleet.azure.com/resource-group: resource-group fleet.azure.com/subscription-id: 8xxxxxxx-dxxx-4xxx-bxxx-xxxxxxxxxxx8 name: cluster01 resourceVersion: "123456" uid: 7xxxxxxx-5xxx-4xxx-bxxx-xxxxxxxxxxx4 spec: ... status: ... properties: kubernetes-fleet.io/node-count: observationTime: "2024-09-19T01:33:54Z" value: "2" kubernetes.azure.com/per-cpu-core-cost: observationTime: "2024-09-19T01:33:54Z" value: "0.073" kubernetes.azure.com/per-gb-memory-cost: observationTime: "2024-09-19T01:33:54Z" value: "0.022" resourceUsage: allocatable: cpu: 3800m memory: 10320392Ki available: cpu: 2740m memory: 8821256Ki capacity: cpu: "4" memory: 14195208Ki各メンバー クラスターに対してこのステップを繰り返すと、ポリシーで使用できるラベルとプロパティが明らかになります。
ワークロードを配置できるように準備する
次に、ワークロードをメンバー クラスターに配置できるようにするためにハブ クラスターにパブリッシュします。
このワークロード用の名前空間をハブ クラスター上に作成します。
kubectl create namespace test-appサンプル ワークロードを、ハブ クラスター上の新しい名前空間にデプロイできます。 これらの Kubernetes リソースの種類ではカプセル化が必要ないため、変更なしでデプロイできます。
次の YAML を
sample-workload.yamlという名前のファイルに保存します。apiVersion: v1 kind: Service metadata: name: nginx-service namespace: test-app spec: selector: app: nginx ports: - protocol: TCP port: 80 targetPort: 80 type: LoadBalancer --- apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment namespace: test-app spec: selector: matchLabels: app: nginx replicas: 2 template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.16.1 ports: - containerPort: 80コマンドを使用してワークロード定義をハブ クラスターにデプロイします。
kubectl apply -f sample-workload.yamlワークロード定義がデプロイされたので、フリートのインテリジェント配置機能をテストできるようになりました。
ワークロード配置ポリシーをテストする
次に示すサンプルは、概念ドキュメントと併せて、独自の ClusterResourcePlacement をプログラミングするためのガイドとして使用できます。
Note
各サンプル ポリシーを試す場合は、必ず前の ClusterResourcePlacement を削除してください。
クラスター ノード数に基づく配置
この例に示すプロパティ並べ替えでは、Descending という順序を使用します。つまり、フリートのクラスターのうちノード数が多いものが優先されます。
ノード数が最も多いクラスターは重み 20 を受け取り、最も低いクラスターは 0 を受け取ります。 他のクラスターには、重みの計算式を使用して計算された比例重みが与えられます。
apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
name: crp-demo
spec:
resourceSelectors:
- group: ""
kind: Namespace
name: test-app
version: v1
policy:
placementType: PickN
numberOfClusters: 10
affinity:
clusterAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 20
preference:
metricSorter:
name: kubernetes-fleet.io/node-count
sortOrder: Descending
ラベル セレクターとプロパティ並べ替えを使用する配置
この例では、クラスターに重みが与えられるのはラベル env=prod がある場合のみとなります。 そのラベル制約を満たすクラスターには、そのメンバー クラスター内の CPU の合計量に基づいて比例重みが与えられます。
この例では、ラベル セレクターとプロパティ並べ替えの両方を preferredDuringSchedulingIgnoredDuringExecution アフィニティに使用する方法を示します。 ラベル セレクターに失敗したメンバー クラスターは重みを受け取りません。 ラベル セレクターを満たすメンバー クラスターは、プロパティ ソーターで指定された比例重みを受け取ります。
apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
name: crp-demo
spec:
resourceSelectors:
- group: ""
kind: Namespace
name: test-app
version: v1
policy:
placementType: PickN
numberOfClusters: 10
affinity:
clusterAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 20
preference:
labelSelector:
matchLabels:
env: prod
metricSorter:
name: resources.kubernetes-fleet.io/total-cpu
sortOrder: Descending
メモリと CPU コアのコストに基づく配置
この例での並べ替えの順序は Ascending であるため、フリートのクラスターのうち、メモリと CPU コアのコストが低いものが優先されます。 メモリと CPU コアのコストが最も低いクラスターに与えられる重みは 20 で、最も高いクラスターには 0 が与えられます。 他のクラスターは、重みの計算式を使用して計算された比例重みを受け取ります。
apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
name: crp-demo
spec:
resourceSelectors:
- group: ""
kind: Namespace
name: test-app
version: v1
policy:
placementType: PickN
numberOfClusters: 2
affinity:
clusterAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 20
preference:
propertySorter:
name: kubernetes.azure.com/per-gb-memory-core-cost
sortOrder: Ascending
- weight: 20
preference:
propertySorter:
name: kubernetes.azure.com/per-cpu-core-cost
sortOrder: Ascending
配置の状態を確認する
配置の状態を確認するには、Azure portal と kubectl コマンドのどちらも使用できます。
配置の進行状況を確認する方法の詳細については、リソースの伝達に関するクイック スタートを参照してください。
リソースをクリーンアップする
クラスター リソース配置の削除を Azure portal または kubectl コマンドを使用して行う方法の詳細については、リソースの伝達に関するクイックスタートのリソースのクリーンアップのセクションを参照してください。
次のステップ
リソース伝達の詳細について確認するには、以下のリソースを参照してください。
Azure Kubernetes Service