Azure Kubernetes Fleet Manager の自動デプロイを使用してマルチクラスターリソースの配置を推進する (プレビュー)

2025-06-16

Azure Kubernetes Fleet Manager の自動デプロイを使用して、コードリポジトリからフリート内の 1 つ以上の AKS クラスターにアプリケーションをビルドしてデプロイできます。自動デプロイにより、コードをビルドしてデプロイするための GitHub アクションワークフローを設定するプロセスが簡略化されます。接続されると、新しくコミットするたびにパイプラインが実行されます。

自動デプロイは、draft.sh に基づいて構築されます。新しいデプロイワークフローを作成するときに、既存の Dockerfile を使用したり、Dockerfile を生成したり、既存の Kubernetes マニフェストを使用したり、Kubernetes マニフェストを生成したりできます。生成されたマニフェストは、セキュリティと回復性のベストプラクティスを念頭に置いて作成されます。

Von Bedeutung

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

[前提条件]

デプロイするアプリケーションを含む GitHub アカウント。
Azure アカウントをお持ちでない場合は、開始する前に無料アカウントを作成してください。
自動デプロイとリソース伝達の概念の概要を読み、この記事で使用される概念と用語を理解してください。
ハブクラスターとメンバークラスターを備えた Kubernetes Fleet Manager。お持ちでない場合は、「Azure CLI を使用して Azure Kubernetes Fleet Manager リソースを作成し、メンバークラスターを参加させる」を参照してください。
構成を完了したユーザーには、Fleet Manager ハブクラスター Kubernetes API へのアクセス許可があります。詳細については、 Kubernetes API へのアクセスに関するページを参照してください。
Fleet Manager ハブクラスターに既にデプロイされている Kubernetes 名前空間。
メンバー AKS クラスターに AcrPull 権限が付与された Azure Container Registry (ACR)。

アプリケーションのソースコードを取り込む

Azure Kubernetes Fleet Manager を見つけて、自動デプロイの構成を開始します。

Azure portal で、上部の検索バーで Kubernetes Fleet Manager を検索します。
検索結果で Kubernetes Fleet Manager を選択します。
リソースの一覧から Azure Kubernetes Fleet Manager を選択します。
Fleet Manager サービスメニューの [フリートリソース] で、[ 自動デプロイ] を選択します。
上部のメニューで [ + 作成 ] を選択します。このデプロイが初めての場合は、展開リスト領域で [作成 ] を選択することもできます。

ソースコードリポジトリに接続する

ワークフローを作成し、目的のソースコードリポジトリとブランチに接続することを承認します。 [リポジトリ] タブで次の詳細を完了します。

[ワークフロー名] フィールドに、ワークフローのわかりやすい名前を入力します。
次に、[ アクセスの承認 ] を選択して GitHub に対してユーザーを承認し、リポジトリの一覧を取得します。
リポジトリソースの場合は、次のいずれかを選択します。
1. 現在承認されている GitHub ユーザーが所有しているリポジトリの場合は [My repositories]。または、
2. すべてのリポジトリとは、現在承認されている GitHub ユーザーがアクセスできるリポジトリのことです。リポジトリを所有する組織を選択する必要があります。
リポジトリとブランチを選択します。
[ 次へ ] ボタンを選択します。

アプリケーションイメージとデプロイ構成を指定する

Kubernetes で実行するアプリケーションを準備するには、コンテナーレジストリに格納するコンテナーイメージにアプリケーションをビルドする必要があります。 Dockerfile では、コンテナーイメージをビルドする方法について説明します。ソースコードリポジトリに Dockerfile がまだない場合は、自動デプロイで生成できます。

既存の Dockerfile を使用する
Dockerfile を生成する

コードリポジトリに既に Dockerfile がある場合は、それを使用してアプリケーションイメージをビルドできます。

既存の Dockerfile をコンテナー構成に対して選択します。
リポジトリから Dockerfile を選択します。
Dockerfile ビルドコンテキストを入力して、一連のファイルとディレクトリをビルドプロセス (通常は Dockerfile と同じフォルダー) に渡します。これらのファイルはイメージのビルドに使用され、 .dockerignore ファイルに含めることで無視されない限り、最終的なイメージに含まれます。
既存の Azure Container Registry を選択します。このレジストリは、ビルドされたアプリケーションイメージを格納するために使用されます。アプリケーションを受信できる AKS クラスターには、レジストリに対するアクセス許可 AcrPull 付与する必要があります。
Azure Container Registry イメージ名を設定します。このイメージ名は、Kubernetes 配置マニフェストで使用する必要があります。

Fleet Manager の自動デプロイを使用して、Go、C#、Node.js、Python、Java、Gradle、Clojure、PHP、Ruby、Erlang、Swift、Rust などの多くの言語とフレームワーク用の Dockerfile を生成します。言語サポートは、draft.sh で利用できる内容に基づいて構築されています。

コンテナー構成の自動コンテナー化 (Dockerfile の生成) を選択します。
[ リポジトリの場所にファイルを保存] をソースリポジトリ内のフォルダーに設定します。
サポートされている言語とフレームワークの一覧から アプリケーション環境 を選択します。
アプリケーションポートを入力します。
既存の Azure Container Registry を選択します。このレジストリは、ビルドされたアプリケーションイメージを格納するために使用されます。アプリケーションを受信できる AKS クラスターには、レジストリに対するアクセス許可 AcrPull 付与する必要があります。
Azure Container Registry イメージ名を設定します。このイメージ名は、Kubernetes 配置マニフェストで使用する必要があります。
生成された Dockerfile と .dockerignore ファイルを確認します。

Kubernetes マニフェスト構成を選択する

Kubernetes で実行されているアプリケーションは、多くの Kubernetes プリミティブコンポーネントで構成されます。これらのコンポーネントは、使用するコンテナーイメージ、実行するレプリカの数、アプリケーションを公開するために必要なパブリック IP がある場合などについて説明します。詳細については、 Kubernetes の公式ドキュメントを参照してください。ソースコードリポジトリに Kubernetes マニフェストがまだない場合は、自動デプロイで自動的に生成できます。既存の Helm グラフを選択することもできます。

Warnung

これらの名前空間は Fleet Manager によって使用される内部名前空間であり、アプリケーションの配置に使用できないため、 fleet-system または fleet-member 名前空間を選択しないでください。

コードリポジトリに既に Kubernetes マニフェストがある場合は、それを選択して、クラスターリソース配置によってデプロイおよび構成されるワークロードを制御できます。

配置オプション として [既存の Kubernetes マニフェスト配置ファイルを使用 する] を選択します。
リポジトリから Kubernetes マニフェストファイルまたはフォルダー を選択します。
ワークロードをステージングする既存の Fleet Manager 名前空間 を選択します。
[ 次へ ] ボタンを選択します。

Fleet Manager の自動デプロイを使用して、一連の基本的な Kubernetes マニフェストファイルを生成して、アプリケーションを稼働させます。現在、自動デプロイでは、 Deployment、 Service、および ConfigMapが作成されます。

生成されたマニフェストは、次のような配置セーフガードの推奨事項を適用するように設計されています。

稼働状態、準備、および起動プローブを自動的に生成します。
ポッドのアンチアフィニティとトポロジを優先すると、レプリカを異なるノードに分散させる制約が分散され、回復性が向上します。
悪意のあるアクターによって悪用される一般的なシステム呼び出しの脆弱性に対する保護の追加レイヤーを確立する、 RuntimeDefault安全なコンピューティングプロファイルを適用します。
すべての Linux 機能を削除し、ベースライン Kubernetes ポッドセキュリティ標準に従って制限付きセットのみを許可します。

Kubernetes マニフェストを生成するには:

展開オプションの [ アプリケーション展開ファイルの生成 ] を選択します。
アプリケーションポートを入力します。このポートは、生成された Serviceで使用されます。
ワークロードをステージングする既存の Fleet Manager 名前空間 を選択します。
[ リポジトリの場所にファイルを保存] をソースリポジトリ内のフォルダーに設定します。
[ 次へ ] ボタンを選択します。

構成の確認

リポジトリ、イメージ、およびデプロイ構成の構成を確認します。

[次へ] を選択して、次のアクションを実行するプロセスを開始します。

フェデレーション資格情報を作成して、GitHub アクションで次の操作を行えるようにします。
1. ビルドされたコンテナーイメージを Azure Container Registry にプッシュします。
2. Kubernetes マニフェストを Fleet Manager ハブクラスターで選択した名前空間にステージングします。
生成されたファイルとワークフローを使用して、コードリポジトリに pull request を作成します。

セットアップには数分かかるため、[デプロイ] ページから移動しないでください。

プル要求を確認してマージする

デプロイステージが完了したら、[ プル要求の承認 ] ボタンを選択して、コードリポジトリで生成されたプル要求を開きます。

注

生成されたプル要求の名前には、それがAKSにデプロイされているかのように示されるという、既知の問題があります。この間違った名前にもかかわらず、選択した名前空間の Fleet Manager ハブクラスターでワークロードがステージングされます。

[変更されたファイル] で 変更を確認 し、必要な編集を行います。
変更をコードリポジトリにマージするには、[ プル要求 のマージ] を選択します。

変更をマージすると、アプリケーションをコンテナーイメージにビルドし、選択した Azure Container Registry に格納する GitHub Actions ワークフローが実行されます。

生成されたリソースを確認する

パイプラインが完了したら、構成した Azure Container Registry インスタンスを見つけてイメージリポジトリを開くことで、Azure portal で作成されたコンテナーイメージを確認できます。

Fleet Manager の自動デプロイ構成を表示することもできます。 workflow名を選択すると、GitHub アクションで GitHub が開きます。

最後に、予想される Kubernetes リソースが Fleet Manager ハブクラスターでステージングされていることを確認できます。

az fleet get-credentials \
    --resource-group ${GROUP} \
    --name ${FLEET}

kubectl describe deployments virtual-worker --namespace=contoso-store

出力は次のようになります。 0 のレプリカでは、ワークロードが Fleet Manager ハブクラスターでスケジュールされていないと想定されます。 Image プロパティが Azure Container Registry のビルドイメージに向けられていることを確認してください。

Name:                   virtual-worker
Namespace:              contoso-store
CreationTimestamp:      Thu, 24 Apr 2025 01:56:49 +0000
Labels:                 workflow=actions.github.com-k8s-deploy
                        workflowFriendlyName=contoso-store-deploy
Annotations:            <none>
Selector:               app=virtual-worker
Replicas:               1 desired | 0 updated | 0 total | 0 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:  app=virtual-worker
  Containers:
   virtual-worker:
    Image:      contoso03.azurecr.io/virtual-worker:latest
    Port:       <none>
    Host Port:  <none>
    Limits:
      cpu:     2m
      memory:  20Mi
    Requests:
      cpu:     1m
      memory:  1Mi
    Environment:
      MAKELINE_SERVICE_URL:  http://makeline-service:3001
      ORDERS_PER_HOUR:       100
    Mounts:                  <none>
  Volumes:                   <none>
  Node-Selectors:            kubernetes.io/os=linux
  Tolerations:               <none>
Events:                      <none>

クラスターリソースの配置を定義する

プレビュー期間中に、ステージングされたワークロードのメンバークラスターへの配置を構成するには、次の手順に従います。

アプリケーションのソースコードリポジトリで、 fleet という名前のリポジトリルートにフォルダーを作成します。

deploy-contoso-ns-two-regions.yaml フォルダーに新しいファイルを作成し、表示された内容を追加します。このサンプルでは、2 つの異なる Azure リージョンに存在する必要がある 2 つのクラスターに contoso-store 名前空間をデプロイします。

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: distribute-virtual-worker-two-regions
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      version: v1          
      name: contoso-store
  policy:
    placementType: PickN
    numberOfClusters: 2
    topologySpreadConstraints:
    - maxSkew: 1
      topologyKey: region
      whenUnsatisfiable: DoNotSchedule

GitHub アクションワークフローファイルを変更し、CRP ファイルへの参照を追加します。
```
DEPLOYMENT_MANIFEST_PATH: |
  ./virtual-worker.yaml
  ./fleet/deploy-contoso-ns-two-regions.yaml
```
新しい CRP マニフェストと更新された GitHub アクションワークフローファイルをコミットします。
CRP 定義で定義されているポリシーに従ってワークロードが配置されていることを確認します。 Azure portal を使用するか、コマンドラインで kubectl を確認します。

次の方法で共有

Azure Kubernetes Fleet Manager の自動デプロイを使用してマルチクラスター リソースの配置を推進する (プレビュー)

[前提条件]

アプリケーションのソース コードを取り込む

ソース コード リポジトリに接続する

アプリケーション イメージとデプロイ構成を指定する

Kubernetes マニフェスト構成を選択する

構成の確認

プル要求を確認してマージする

生成されたリソースを確認する

クラスター リソースの配置を定義する

次のステップ

フィードバック

その他のリソース

Azure Kubernetes Fleet Manager の自動デプロイを使用してマルチクラスターリソースの配置を推進する (プレビュー)

アプリケーションのソースコードを取り込む

ソースコードリポジトリに接続する

アプリケーションイメージとデプロイ構成を指定する

クラスターリソースの配置を定義する