このリファレンス実装は、一般的な AKS クラスター の 推奨される開始 (ベースライン) インフラストラクチャ アーキテクチャ を示します。この実装とドキュメントは、ネットワーキング、セキュリティ、および開発のような複数の異なるチームを通して、この一般的なベースラインインフラストラクチャを展開し、そのコンポーネントを理解するためのプロセスを導くことを目的としています。
ここでは、各コンポーネントを理解するために、 冗長な 方法で展開を行います。理想的には、各レイヤーについて理解し、それを自分のワークロードに適用するために必要な知識を提供します。
このプロジェクトには、セキュアな AKS クラスターの課題、デザイン パターン、およびベスト プラクティスのコンパニオン セットの記事があります。Azure Architecture Center の Azure Kubernetes Service (AKS) ベースラインクラスター で見つけることができます。まだ読んでいない場合は、この実装に適用された考慮事項を追加するコンテキストを提供するために、それを読むことをお勧めします。最終的に、これは、その特定のアーキテクチャ ガイダンスの直接の実装です。
このアーキテクチャはインフラストラクチャに焦点を当てています。より多くのワークロードに焦点を当てています。AKS クラスター自体に焦点を当てています。これには、アイデンティティ、デプロイ後の構成、シークレット管理、およびネットワークトポロジーに関する懸念が含まれます。
この実装は、Azure サービスとの統合を通じて、観測性を提供し、複数のリージョンでの成長をサポートするネットワークトポロジーを提供し、クラスター内のトラフィックを安全に保つようにします。このアーキテクチャは、プレプロダクションとプロダクションのステージの開始点として考慮する必要があります。
ここの資料は、比較的密集しています。これらの手順を理解するために時間を割くことを強くお勧めします。ここでは、"一発クリック" デプロイは提供していません。ただし、コンポーネントを理解し、チームと組織の間の共有の責任を特定した後は、最終的なインフラストラクチャに対して適切で監査可能なデプロイメント プロセスを構築することをお勧めします。
リファレンス実装を通じて、Contoso Bicycle への参照が表示されます。これは、北米西海岸にある顧客にオンライン Web サービスを提供する小さくて急成長している仮想のスタートアップです。彼らはオンプレミスのデータ センターを持っていません。すべてのコンテナ化されたビジネス アプリケーションは、安全で企業向けの AKS クラスターによってオーケストレートされるようになりました。彼らの要件と IT チームの構成 について詳しく読むことができます。このネタは、いくつかの実装の詳細、命名規則などの基盤を提供します。必要に応じて適応してください。
最後に、この実装では、ASP.NET Core Docker サンプル Web アプリを例のワークロードとして使用します。このワークロードは、基本的なインフラストラクチャを体験するのに役立つために、無関心にしています。
- AKS v1.25
- システムとユーザー ノード プールの分離
- AKS 管理の Azure AD
- Azure AD ベースの Kubernetes RBAC (ローカルユーザーアカウントは無効になっています)
- Managed ID
- Azure CNI
- Azure Monitor for containers
- Azure Virtual Networks (hub-spoke)
- Azure Firewall managed egress
- Azure Application Gateway (WAF)
- AKS 管理の内部ロード バランサー
- Azure Workload Identity [AKS-managed add-on]
- Flux GitOps Operator [AKS-managed extension]
- ImageCleaner (Eraser) [AKS-managed add-on]
- Kubernetes Reboot Daemon
- Secrets Store CSI Driver for Kubernetes [AKS-managed add-on]
- Traefik Ingress Controller
AKS ホステッド ワークロードのデプロイでは、通常、前提条件、ホスト ネットワーク、クラスター インフラストラクチャ、最後にワークロード自体のエリアで責任の分離とライフサイクル管理が発生します。このリファレンス実装も同様です。また、ベースライン クラスターのトポロジーと決定を示すことを主な目的としていることに注意してください。私たちは、"ステップ バイ ステップ" フローがソリューションの一部を学び、それらの関係性について洞察を得るのに役立つと考えています。最終的には、クラスターとその依存関係のライフサイクル/SDLC 管理は、状況に応じて (チームの役割、組織の標準など) 、必要に応じて実装されます。
** この学習の旅を Preparing for the cluster セクションから開始してください。 ** これを最後まで実行すると、推奨されるベースライン クラスターがインストールされ、終端から終端までのサンプル ワークロードが実行され、自分の Azure サブスクリプションで参照できるようになります。
クラスターをデプロイする前に、考慮すべき点があります。このサイズのデプロイを行うには、サブスクリプションと AD テナントで十分な権限があるかどうか？これは、自分のチームが直接対応するのか、別のチームが責任を負うのか、といった点でどの程度対応するのか？などです。
- 事前準備に進み、必要なものをインストールします。
- クライアント向けおよび AKS Ingress コントローラーの TLS 証明書を取得します
- Azure AD 統合を計画します
Microsoft は、AKS を計画的に構築することをお勧めします。必要なサイズに適切にサイズされ、適切なネットワークの監視が可能である必要があります。組織では通常、従来のハブ-スポーク モデルが好まれます。この実装では、このモデルが反映されています。このモデルは標準のハブ-スポーク モデルですが、理解すべき基本的なサイジングと分割の考慮事項が含まれています。
リファレンス実装の中心となるガイダンスです。これは、前のネットワーク トポロジ ガイダンスとペアリングされています。ここでは、クラスターの Azure リソースと、Azure Application Gateway WAF、Azure Monitor、Azure Container Registry、Azure Key Vault などの隣接サービスをデプロイします。ここで、クラスターがブートストラップされていることを検証します。
前段のステップは、ここで手動で実行することで、関連するコンポーネントを理解できますが、私たちは自動化された DevOps プロセスを推奨します。したがって、IaC と同様に、CI/CD パイプラインに前段のステップを組み込んでください。詳細については、専用の AKS ベースライン自動化ガイダンス を参照してください。
クラスターへのワークロードのデプロイは、この基盤がビジネスの信頼できるアプリケーション プラットフォームとして機能する方法を理解するためには、困難です。このワークロードのデプロイは、通常、CI/CD パターンに従い、さらに高度なデプロイ戦略（ブルー/グリーンなど）を含む可能性があります。次のステップは、この基盤の説明のために適した手動デプロイを表します。
クラスターとサンプル ワークロードがデプロイされたら、クラスターがどのように機能しているかを確認します。
前段のステップでデプロイされた Azure リソースのほとんどは、削除されない限り、継続的な課金が発生します。
Kubernetes と AKS は、急速に進化する製品です。AKS ロードマップ には、製品の変化がどのように速いかが示されています。このリファレンス実装では、AKS チームが「Shipped & Improving」として説明するプレビュー機能のいくつかに依存しています。その背景にある理由は、多くのプレビュー機能が数ヶ月しか続かないためです。GA に入る前に、今日クラスターをアーキテクチャリングしている場合、多くのプレビュー機能が近づいているか、すでに GA に入っている可能性があります。
以下の実装は、すべてのプレビュー機能を含みませんが、一般的なクラスターに大きな価値を追加するもののみを含みます。セキュリティ、管理可能性などのポスチャーを強化するために、プレプロダクションクラスターで評価することをお勧めします。これらの機能がプレビューから出てくると、このリファレンス実装はそれらを組み込むように更新される可能性があります。以下の機能を試してフィードバックを提供してください。
- BYO Kubelet Identity
- Planned maintenance window
- BYO CNI (
--network-plugin none) - Simplified application autoscaling with Kubernetes Event-driven Autoscaling (KEDA) add-on
AKS ベースラインは、次の追加のリファレンス実装の基礎として使用されました。これらは、AKS ベースラインの学習を基にしており、特定のトポロジー、要件、および/またはワークロード タイプに合わせてクラスターに特定のレンズを適用します。
- AKS baseline for multi-region clusters
- AKS baseline for regulated workloads
- AKS baseline for microservices
- Azure landing zones, enterprise-scale reference implementation using Terraform
このリファレンス実装では、より高度なシナリオをカバーすることは意図的に行っていません。以下のようなトピックは対象外となっています。
- クラスターのライフサイクル管理に関する SDLC と GitOps
- ワークロード SDLC 統合（Bridge to Kubernetes などの概念、高度なデプロイメント テクニック、Draft など）
- コンテナー セキュリティ
- 複数の（関連しているかどうか）ワークロードを所有する同じチーム
- 複数ワークロードを所有する異なるチーム（組織内で共有プラットフォームとしての AKS）
- クラスター内に含まれる状態（PVC など）
- Windows ノード プール
- スケール ゼロ ノード プールとイベント ベースのスケーリング（KEDA）
- Terraform
- dapr
このスペースを維持するために、これらのようなトピックに関するリファレンス実装ガイダンスを構築しています。さらにガイダンスが提供されると、このベースライン AKS 実装が開始点として使用されます。このベースラインを使用して構築されたパターンを提案したい場合は、お問い合わせください。
Kubernetes は、とても柔軟なプラットフォームであり、インフラストラクチャおよびアプリケーション オペレーターには、ビジネスとテクノロジの目標を達成するための多くの選択肢を提供します。旅の途中で、Azure プラットフォーム機能、OSS ソリューション、サポート チャネル、規制遵守、および運用プロセスに依存するタイミングを検討する必要があります。このリファレンス実装を、自分のチーム内でアーキテクチャの会話を始める場所として使用することをお勧めします。特定の要件に適応し、最終的にお客様を喜ばせるソリューションを提供します。
- Azure Kubernetes Service Documentation
- Microsoft Azure Well-Architected Framework
- Microservices architecture on AKS
コントリビューターガイドをご覧ください。
このプロジェクトは、Microsoft Open Source Code of Conductを採用しています。詳細については、Code of Conduct FAQを参照するか、追加の質問やコメントがある場合は、opencode@microsoft.comにご連絡ください。
With ❤️ from Microsoft Patterns & Practices, Azure Architecture Center.