次の方法で共有

最新のアプリケーション プラットフォーム ソリューションのガバナンス

  • [アーティクル]

クラウド導入フレームワークの手法を使って、クラウド ポートフォリオのガバナンスを体系的かつ段階的に改善することができます。 この記事では、Azure または他のパブリック/プライベート クラウドにデプロイされた Kubernetes クラスターにガバナンスのアプローチを拡張する方法について説明します。

ガバナンスを始めるための基礎

ガバナンスでは、最初にガバナンス MVP と呼ばれることが多い初期のガバナンス基盤を使用します。 この基盤により、クラウド環境でガバナンスを実現するために必要な、基本的な Azure 製品がデプロイされます。

初期のガバナンス基盤では、ガバナンスの次の側面に重点が置かれています。

  • 基本的なハイブリッド ネットワークと接続。
  • ID とアクセス制御のための Azure のロールベースのアクセス制御 (RBAC)。
  • リソースを一貫して識別するための名前付けとタグ付けの標準。
  • リソース グループ、サブスクリプション、および管理グループを使用したリソースの編成。
  • Azure Policy を使用してガバナンス ポリシーを適用します。

初期のガバナンス基盤のこれらの機能を使用して、最新のアプリケーション プラットフォーム ソリューション インスタンスを管理できます。 ただし、初めに、Azure Policy をコンテナーに適用するためのコンポーネントを初期の基盤にいくつか追加する必要があります。 構成が完了したら、Azure Policy と初期のガバナンス基盤を使用して、次の種類のコンテナーを管理できます。

ガバナンス規範での拡張

初期のガバナンス基盤をガバナンスのさまざまな規範で拡張して、すべての Kubernetes インスタンスで一貫性のある安定したデプロイ アプローチを実現できます。

Kubernetes クラスターのガバナンスは、5 つの異なる観点から見ることができます。

Azure リソースのガバナンス

1 つめは Azure リソースの観点です。 すべてのクラスターが組織の要件に準拠していることを確認します。 この中には、ネットワーク トポロジ、プライベート クラスター、SRE チームの Azure RBAC のロール、診断設定、利用可能なリージョン、ノード プールに関する考慮事項、Azure Container Registry のガバナンス、Azure Load Balancer のオプション、AKS のアドオン、診断設定などの概念が含まれます。 このガバナンスによって、組織内のクラスターの "外観" と "トポロジ" の一貫性が確保されます。 これは、クラスター デプロイ後のブートストラップにも拡張する必要があります。たとえば、インストールする必要があるセキュリティ エージェントやその構成方法などです。

Snowflake のクラスターは、中央の能力では管理が困難です。 ポリシーが一様に適用され、異常なクラスターが使用されず検出可能になるように、クラスター間の不整合を最小限に抑えます。 これには、ARM、Bicep、Terraform といった、クラスターのデプロイに使用されるテクノロジが含まれる場合もあります。

管理グループ/サブスクリプション レベルで適用される Azure Policy では、これらの考慮事項の大部分に対応することができますが、すべてではありません。

Kubernetes ワークロードのガバナンス

Kubernetes はそれ自体がプラットフォームです。このため、2 つめはクラスター内での処理のガバナンスです。 これには、名前空間のガイダンス、ネットワーク ポリシー、Kubernetes RBAC、制限、クォータなどが含まれます。 これは、ワークロードに適用されるガバナンスであり、クラスターにはそれほど適用されません。 すべてのワークロードは一意です。これは、それぞれによって解決されるビジネス上の問題が異なること、およびこれらがさまざまな方法とテクノロジを使用して実装されることによります。 "1 つのサイズであらゆるものに対応可能な" ガバナンス プラクティスは多くないかもしれませんが、OCI 成果物の作成/消費、サプライ チェーンの要件、パブリック コンテナー レジストリの使用、イメージの検疫プロセス、デプロイ パイプラインなどに関するガバナンスを検討する必要があります。

可能な場合は、一般的なツールとパターンについても標準化することを検討します。 Helm、サービス メッシュ、イングレス コントローラー、GitOps のオペレーター、永続ボリュームなどのテクノロジに関する推奨事項を提示します。 これには、ポッドのマネージド ID と Key Vault のソーシング シークレットの使用に関するガバナンスも含まれます。

テレメトリへのアクセスに関する強い期待に応え、ワークロードの所有者が自社製品の品質向上に必要なメトリックとデータに適切にアクセスできるようにします。また、クラスター オペレーターがシステム テレメトリにアクセスしてサービス内容を改善できるようにします。 多くの場合、データを両者の間で相互に関連付け、必要に応じて適切にアクセスできるように、ガバナンス ポリシーを設定する必要があります。

クラスター レベルで適用される AKS の Azure Policy では、これらの一部に対応することができますが、すべてではありません。

クラスター オペレーターのロール (DevOps、SRE)

3 つめは、クラスター オペレーターのロールに関するガバナンスです。 SRE チームはクラスターとどのように対話するのでしょうか? チームとワークロード チームにはどのような関係性があるでしょうか? これらは同じでしょうか? クラスター オペレーターには、クラスター トリアージ アクティビティのプレイブックが明確に定義されている必要があります。たとえば、クラスターへのアクセス方法、クラスターにどこからアクセスするか、クラスターに対してどのようなアクセス許可を持っているか、それらのアクセス許可がいつ割り当てられたか、などです。 ガバナンス ドキュメント、ポリシー、トレーニング資料などで、ワークロード オペレーターとクラスター オペレーターがこの点についてどのように異なるかを確認します。 組織によっては、これらが同じである可能性もあります。

ワークロードにつき 1 つのクラスター、クラスターにつき多数のワークロード

4 つめはマルチテナントに関するガバナンスです。 つまり、本質的にはすべてが同じワークロード チームによって所有されているアプリケーションの "グループのようなもの" がクラスターに含まれ、関連するワークロード コンポーネントが "単一のセット" で示されている場合があります。 また、複数の異なるワークロードとワークロード所有者が含まれている事実上のマルチテナントとしてクラスターを設計している場合があります。これは実行され、組織内の管理サービス内容として管理されます。 それぞれのガバナンス戦略は顕著に異なります。このため、選択した戦略が適用されるように管理する必要があります。 両方のモデルをサポートする必要がある場合は、どの種類のクラスターにどのポリシーを適用するのかについて、ガバナンス計画で明確に定義します。

これは、スタッフの配置、予算、イノベーションなどに大きな影響を与えるため、戦略フェーズ中に選択する必要があります。

現在の取り組みを維持

5 つめは、ノード イメージの鮮度 (修正プログラムの適用) や Kubernetes のバージョン管理などの操作です。 ノード イメージのアップグレード、適用された修正プログラムの追跡、Kubernetes および AKS の一般的な脆弱性とリスクに関する修復プランの追跡とまとめは、誰が担当するのでしょうか? ワークロード チームは、クラスターのアップグレード時にソリューションが機能するかどうかの検証に関与する "必要があります"。クラスターが最新ではない場合は、Azure サポートから除外されます。 AKS では、"最新の状態に維持" の取り組みについて強力なガバナンスを適切に実施することが "重要" ですが、Azure の他のほとんどのプラットフォームではなおさらです。 このため、クラスターを最新の状態に保つには、アプリケーション チームと緊密に連携し、十分な時間 (少なくとも月単位) をかけてワークロードを検証する必要があります。 Kubernetes に依存しているすべてのチームが、このプラットフォームに関わっている間、この継続的な取り組みの要件とコストを理解していることを確認します。

セキュリティ ベースライン

AKS クラスターのセキュリティのために、次のベスト プラクティスをセキュリティ ベースラインに追加することができます。

ID

以下のような多くのベスト プラクティスを ID ベースラインに適用して、Kubernetes クラスター全体で ID とアクセス管理の一貫性を維持できます。

次のステップ: 最新のアプリケーション プラットフォーム ソリューションを管理する

次の記事では、クラウド導入シナリオを成功させるのに役立つ、クラウド導入作業のガイダンスが特定のポイントごとに示されています。