Azure Arc 対応 Kubernetes で Container Apps のデプロイを計画する

本番クラスタにコンテナアプリ拡張機能をインストールする前にこの記事をご利用ください。 Azure Arc上のコンテナアプリは、Kubernetesクラスターが提供する容量およびプラットフォームサービスを利用します。 ノード、負荷分散、DNS、アウトバウンド接続、ストレージ、アイデンティティ、ログ、アップグレードに関する決定はアプリケーションの可用性に影響を与えます。

この記事のセクションを使って、導入要件を特定し、インストール前に前提条件を検証してください。

計画範囲

Azure Arc上のコンテナアプリは、Azureリソース、既存のKubernetesクラスター、そしてデプロイされたアプリケーションにまたがっています。 以下のエリアを計画しましょう:

対応トポロジーとバージョンマトリックス

Azure Arc対応のKubernetesもサポートする最新のベンダー対応パッチリリースを使用してください。 Container Appsのドキュメントでは、各ディストリビューションごとに別々のKubernetesバージョン範囲が公開されていません。 本番環境のインストールやアップグレード前に、Microsoftのサポートで正確なディストリビューションとKubernetesのバージョンを検証してください。

以下のマトリックスは、現在公開されている配布サポートを示しています。 インストールのたびに、事前にAzure Arc 対応 Kubernetes クラスターで使用可能な拡張機能およびAzure Arc 上の Azure Container Apps の制限事項を参照して再確認してください。

この拡張機能はWindowsノードやArm64クラスタではサポートされていません。 Arc拡張フレームワークは少なくとも1つの適切な linux/amd64 ノードを必要としますが、本番環境での展開には拡張、ワークロード、アップグレード、障害に対応する十分なノードが必要です。

クラスタ上で動作できるのはサポートされたKEDAのインストールが1つだけです。 KEDAがコンテナアプリ拡張機能でインストールされるのか、それともクラスタ上に既に存在しているのかを確認しましょう。 KEDAがすでに存在する場合は、停止してサポートされた共存構成を確認してから続けてください。 既存のKEDAインストールを削除したり、非公開の拡張機能設定を適用したりしないでください。他のワークロードがそれを必要とするかもしれません。

容量の要件

計画容量は以下の通りです:

• Container Apps 拡張機能によって作成されたリソースに一覧表示されている、固定コンポーネントおよびノードごとの Container Apps 拡張機能コンポーネント。
• すべてのコンテナアプリの最大期待レプリカ数。
• 同時ジョブ実行と再試行バースト。
• DAPRサイドカーとアプリケーションサイドカー。
• Kubernetesシステムのワークロードやその他のクラスタテナントについて。
• ノードと拡張機能のローリング アップグレード。
• 高可用性のデプロイメントで少なくとも1つのノード障害が発生しました。

アプリケーションの最大レプリカ数を設定してもクラスタ容量は確保されません。

最小設置能力

拡張配置、有効コンポーネント、ノード数、デーモンワークロード、KEDAインストール、Log Analytics、DAPR使用、ワークロードリクエストなどが異なるため、普遍的な本番最小限は存在しません。 公表されている拡張コンポーネントの要求値をベースラインとして使用し、ノードの総リソースではなく、割り当て可能なリソースを測定してください。 評価クラスターサイズは生産サイズの推奨ではありません。

設置前に、以下を録音してください:

• 適格な linux/amd64 ノードに割り当て可能なCPUとメモリ。
• ノード数と故障領域の配置。
• 無料のポッドとサービスのIP容量。
• 現在のシステムおよびテナントの要求と制限。
• 汚染、アフィニティ、クオータ、またはディスラプション バジェットの影響により、容量が利用できません。

作業負荷能力の推定

各アプリケーションごとに計算します:

peak capacity = maximum replicas x (application requests + sidecar requests)

ピーク時の同時ジョブ容量、拡張容量、システム予備容量、アップグレード時の増加分、障害対応用の予備容量を追加します。 ノードラベル、汚染、アフィニティルール、リソース断片化が、名目上空き容量を設定不可能にしないようにしてください。

代表的なワークロードをスケジューリングし、ノードドレインをシミュレートすることで計画を検証します。 拡張ポッドと必要なワークロードレプリカが準備完了しているか確認してください。

ネットワークの要件

Azure Arc上のコンテナアプリは、いくつかの異なるネットワークパスを必要とします:

Azure Arcで対応されたKubernetesネットワーク要件を標準的なエンドポイントリストとして使用してください。 正しいAzureクラウドを選択し、Arcの機能を有効にせずにエンドポイントリストをファイアウォールのルールセットにコピーしないでください。 クラスタネットワークから必要なすべての完全認証ドメイン名(FQDN)をテストしてください。 Arcの要件では、HTTPSエンドポイントは公式に署名され検証可能な証明書を使用することが定められています。 非本番クラスタでのプロキシおよびTLS検査動作を確認する;サポートされていない傍受や信頼できない交換証明書は、エージェントや拡張コンポーネントの接続を妨げることがあります。

選択された LoadBalancer 実装によって、アドレスプール、ヘルスプローブ、ルーティング、必要な容量が決定されます。 カスタムロードバランサーが予約アドレスを必要とする場合は、まずそのアドレスを予約し、インストール時に拡張機能 loadBalancerIp 設定に通してください。 ヘルスプローブのポートとソース範囲は実装ごとに異なります。Azure Load Balancerのデフォルトを前提にせず、選択したロードバランサーから取得してください。

基盤となるArc対応のKubernetesクラスターは、接続環境のネットワーク制限を制御します。 アプリケーション依存関係がプライベートエンドポイントを使用している場合、アプリケーションポッドからクラスタがDNS名を解析し、プライベートIPにルーティングできるか確認します。 クライアントIP情報を必要とするアプリケーションは、選択したロードバランサーおよびプロキシチェーンによって生成される転送ヘッダーを検証し、どのプロキシが信頼されるかを定義すべきです。

ネットワークの検証

1. Kubernetes LoadBalancer テストサービスを展開し、すべてのクライアントネットワークから到達可能なアドレスを受け取っているか確認してください。
2. 対象となるクラスターノードや診断ポッドから、必要なすべてのAzure Arcエンドポイントおよびワークロード依存関係に解決・接続します。
3. プロキシが必要なHTTPSおよびWebSocketのトラフィックを許可し、信頼できない発行者で証明書を置き換えていないかを確認してください。
4. クラスタDNS、ポッド間トラフィック、サービス、アドミッションウェブフック、ロードバランサーヘルスプローブが意図されたネットワークポリシーと連携していることを確認しましょう。
5. 拡張機能のインストール後、本番DNSレコードを作成する前に、イングレスサービスが予定されたIPを受け取り、到達可能であることを確認してください。

DNS の要件

拡張インストール後、テストアプリケーションを展開し、生成されたFQDNを取得します。 FQDNがすべての意図されたクライアントネットワークから解決し、拡張入力に到達しているかを確認します。 接続環境名は生成されたアプリケーションドメインの一部なので、意図的に選択してください。

内部アプリケーションでは、内部クライアントと外部クライアントが異なる回答を必要とする場合はスプリットホライゾンDNSを使いましょう。 権威あるDNSゾーン、記録的な生存時間、復旧要件を特定しましょう。 アプリケーションが生成されたドメイン、カスタムドメイン、またはその両方を使用するかを判断し、展開前に証明書の発行と更新を計画してください。

想定される各クライアントネットワークからの DNS とイングレスを検証します:

nslookup <APPLICATION_FQDN>
curl --verbose https://<APPLICATION_FQDN>

アプリケーションFQDNはイングレスIPに解決し、期待されるアプリケーション応答を返さなければなりません。 冗長な出力を共有する前に、認可ヘッダー、クッキー、機密クエリ文字列を削除してください。

身元、秘密、そして登録

管理型IDはAzure Arcのコンテナアプリではサポートされていません。管理型IDを使ってAzure Container Registryからイメージを取得することもサポートされていません。

Azureリソースへのアクセスには、ターゲットサービスが対応している場合にのみ専用のアプリケーション登録とサービスプリンシパルを使いましょう。 必要なデータプレーンの役割だけを、最も狭い実用範囲で与えましょう。 テナントIDとクライアントIDは認証情報とは別にし、アプリケーションやターゲットサービスがサポートしている場合は証明書を使用し、認証情報の有効期限とローテーションを計画しましょう。 アプリケーションアクセスのためにArcの接続クラスタIDやクラスタ管理者IDを再利用しないでください。

プライベートレジストリの場合は、レジストリがサポートしている場所でプルのみアクセスできるレジストリスコープ認証情報を使いましょう。 本番ワークロードには AC R 管理者の資格情報を使用しないでください。 レジストリやアプリケーションの認証情報をコンテナアプリの秘密として保存し、アプリケーション設定から名前で参照します。

コンテナアプリのシークレットはアプリケーションスコープで、シークレットを変更しても既存のリビジョンが自動的に更新されるわけではありません。 Azureのコントロールプレーンアクセスと特権Kubernetesアクセスの両方をセキュリティ境界として扱いましょう。 展開のKubernetesセキュリティ要件に従い、拡張機能およびアプリケーション名前空間へのアクセスを制限してください。

次の回転シーケンスを使ってください:

1. IDプロバイダーやレジストリで2つ目の有効な認証情報を作成します。
2. コンテナアプリの秘密を更新し、必要に応じて影響を受けたリビジョンをデプロイまたは再起動します。
3. 新しい認証情報を使用して、イメージの取得とアプリケーションの認証を確認してください。
4. 古い資格を取り消せ。
5. アクティブなリビジョンやジョブがまだ古い値を参照していないか確認してください。

コマンド履歴、ソース制御、診断バンドル、ポッド記述、アプリケーションログに秘密値を置いてはいけません。 拡張で保護された設定やKubernetesの秘密を読む人を制限しましょう。

Storage

ワークロードに必要な永続性に応じてストレージを計画します:

Arc上のコンテナアプリの制限は現在Azure Files SMBを文書化しており、SMB CSIドライバーが必要です。 AzureホストのContainer AppsでサポートされているボリュームタイプがArcでもサポートされていると仮定しないでください。Azure ArcでAzure Container AppsからリンクされたSMBインストールコマンドを使い、ここで別のコピーを管理しないでください。

マウントに使われるストレージアカウントの認証情報をシークレットとして扱う。 管理型アイデンティティはArcのコンテナアプリにはサポートされていません。選択したマウントオプション、ファイル権限、同時アクセス、障害挙動、認証情報のローテーションを、本番で使われている正確なCSIドライバーおよびストレージサービスのバージョンでテストしてください。

永続データバックアップ、復元テスト、保持、災害復旧を計画しましょう。 リビジョンやジョブでマウントの失敗がどのように報告されるかを確認し、診断手順に Pod のイベントと CSI ドライバーのログを含めてください。 Linux は、この拡張機能でサポートされる唯一のノード OS です。

計画の観測可能性

Log Analyticsの統合は任意です。 もし使う予定があるなら、拡張機能をインストールするときに設定してください。後でその拡張機能インスタンスに追加できないからです。

Log Analyticsを設定すると、ContainerAppConsoleLogs_CLでアプリケーションログを確認できます。 「Create a container app on Azure Arc」チュートリアルでは、TimeGenerated、ContainerAppName_s、Log_sを実演し、クエリやアラートを作成する前にライブテーブルを確認してください。 初回摂取の確認時は10〜15分を空けてください。

ワークスペースへのアクセス、保持、アラート、エクスポート、取り込みコストを計画します。 収集を有効にする前に、認証情報、個人情報、機密URLの登録履歴を確認しましょう。

Log Analyticsを設定していなかったり、インジェスションインシデント時に使わない場合は、Kubernetesログを使用してください:

kubectl get pods -n <APPS_NAMESPACE> -o wide
kubectl logs -n <APPS_NAMESPACE> <POD_NAME> --all-containers=true --tail=200
kubectl get events -n <APPS_NAMESPACE> --sort-by=.lastTimestamp

システムコンポーネントは標準出力にログを書き込みます。 デフォルトでは、システムコンポーネントのテレメトリはMicrosoftに送信され、アプリケーションログはLog Analyticsを設定しない限り送信されません。 logProcessor.enabled=false設定はログ処理やワークスペースへの転送を無効にし、サポート側が手動で収集するよう求める診断証拠を増やすことができます。

本番環境に入る前に、ユニークなアプリケーションログメッセージをエンドツーエンドでテストし、拡張機能の健康状態やアプリケーション障害のアラートを作成し、AzureとKubernetesの両方の診断が利用可能か確認してください。

アップグレード、バックアップ、復旧

拡張リリースのトレインおよびアップグレードポリシーを選択してドキュメント化してください。 コンテナアプリのセットアップチュートリアルでは、 stable リリーストレインと自動的なマイナーバージョンアップグレードを組み合わせています。 Azure Arcのクラスタ拡張機能は、リリーストレインに自動アップグレードで対応するか、手動でピン留めしてアップグレードすることができます。 バージョンを変更する前に Container Apps拡張機能のリリースノート を確認し、余裕容量、互換性のあるKubernetesバージョン、メンテナンスウィンドウ、アプリケーション検証を提供してください。

拡張機能やKubernetesのアップグレード前:

1. 接続されたクラスタと拡張機能のプロビジョニング状態が Succeeded であることを確認しましょう。
2. ターゲットとなるKubernetesと拡張機能の組み合わせがサポートされているか確認してください。
3. リリースノートや現在の構成(リリーストレイン、自動アップグレード設定、KEDAインストール、ネームスペース、Log Analytics、loadBalancerIpなど)を確認しましょう。
4. 段階的な入れ替えに必要な予備容量を確認し、業務中断予算の範囲内で作業を進めることが可能であることを確認してください。
5. 対象画像の画像レジストリ接続性とアクセスポリシーを確認しましょう。
6. アプリケーションのソース設定とすべての永続的なアプリケーションデータをバックアップしてください。
7. 変更の前後で、アプリケーション、Ingress、スケーリング、ジョブ、ストレージ、ロギングのスモークテストを実行してください。

KubernetesのネームスペースバックアップをAzureリソースのバックアップとして扱わないでください。 接続されたクラスタ、拡張、カスタムロケーション、接続環境、コンテナアプリ、ジョブはAzure Resource Managerで表現され、クラスタ内のリソースに依存しています。 宣言型アプリケーションの設定は別途バックアップしてください。 Microsoftサポートがその回復手順を提供しない限り、新たにインストールした拡張機能上で拡張管理のデプロイメント、カスタムリソース、シークレットを手動で復元しないでください。

拡張のダウングレードやロールバックは、Arcのコンテナアプリに関する一般的な復旧メカニズムとして文書化されていません。リリーストレインを変更したり、古いバージョンにピン留めしたり、拡張管理ワークロードをインシデント対応として変更したりする際、Microsoftのサポートパスを確認しずに行ってください。

Kubernetesインフラストラクチャ、ネットワーク、DNS、ロードバランシング、ストレージ、Azure Arcエージェント、コンテナアプリ拡張、カスタムロケーション、接続環境、アプリケーション設定、認証情報、永続的なアプリケーションデータを考慮したリカバリーランブックを作成・テストします。 回復後に入力、リビジョン、スケーリング、ジョブ、ストレージ、ログを検証します。 展開時にはKubernetesトポロジーおよびバックアップ製品でサポートされている回復手順を使用してください。

Azure の切断を計画する。 アークエージェントは拡張変更を検出し、望ましい状態を伝播させるために接続性を必要とします。 新たに作成された拡張リソースの保護設定は最大48時間保持されます。その期間中にクラスターが切断されたままであれば、拡張は Pending から Failedに移動します。 継続保証を前提とするのではなく、Azure接続が途絶えた際のワークロードの挙動をテストしてください。

関連するコンテンツ

• Azure Arc 上の Azure Container Apps
• Azure Container Apps を実行するための Azure Arc 対応 Kubernetes クラスターを設定する
• Azure Arc でコンテナー アプリを作成する
• Azure Arc 対応 Kubernetes 上の Azure Container Apps のトラブルシューティング
• Azure Arc 対応 Kubernetes ネットワーク要件
• Azure Arcで有効なKubernetesのカスタムロケーション
• Azure Arc-enabled Kubernetes のクラスタ拡張