次の方法で共有

クラスターの設計と操作

  • [アーティクル]

この記事ではクラスター構成とネットワーク設計について取り上げます。 インフラストラクチャのプロビジョニングを自動化することで、将来のスケーラビリティに対応する方法を学習します。 プロビジョニングは、必要な IT インフラストラクチャを設定するプロセスです。 インフラストラクチャの自動プロビジョニングでは、リモート インストールがサポートされ、仮想環境が設定されます。 また、事業継続とディザスター リカバリーを計画することで、高可用性を維持するのにも役立ちます。

計画、トレーニング、および証明

開始時に、下のチェックリストと Kubernetes リソースを使用するとクラスターの設計の計画に役立ちます。 このセクションを終了すると、こちらの質問に答えることができます。

  • クラスターのネットワーク設計要件を特定しましたか?
  • さまざまな要件を持つサービスはありますか? 使用予定のノード プールの数はいくつですか?

チェックリスト:

  • ネットワーク設計に関する考慮事項を特定する。 クラスター ネットワークの設計上の考慮事項を理解して、ネットワーク モデルを比較し、ニーズに合った Kubernetes ネットワーク プラグインを選択します。 Azure Container Networking Interface (CNI) ネットワークについては、ノードあたりの最大ポッド数 (既定値は 30) とノード数の倍数として、必要な IP アドレスの数を検討してください。 アップグレード中に必要なノードを 1 つ追加します。 ロード バランサー サービスを選択する場合に、公開されるエンドポイントの数を減らすためのサービスが多すぎる場合は、イングレス コントローラーの使用を検討してください。 Azure CNI で適切なルーティングを確保するには、サービス CIDR が仮想ネットワークと接続されているすべての仮想ネットワークで一意である必要があります。

    詳細については、次を参照してください。

  • 複数のノード プールを作成する。 コンピューティングまたはストレージのさまざまな要件があるアプリケーションをサポートするには、必要に応じて複数のノード プールでクラスターを構成します。 たとえば、より多くのノード プールを使用して、コンピューティング集中型アプリケーションに GPU を提供したり、高パフォーマンスな SSD ストレージへのアクセスを提供したりします。 詳細については、Azure Kubernetes Service のクラスターでの複数のノード プールの作成と管理に関する記事を参照してください。

  • 可用性の要件を決定する。 Azure Kubernetes Service の背後に少なくとも 2 つのポッドがあれば、ポッドのエラーや再起動があった場合のアプリケーションの高可用性が確保されます。 ポッドのエラーや再起動時の負荷を処理するには、3 つ以上のポッドを使用してください。 クラスター構成では、99.95% のサービス レベル アグリーメントを満たすために、可用性セットまたは仮想マシン スケール セット内に少なくとも 2 つのノードが必要です。 ノードのエラー時と再起動時のポッドのスケジューリングを保証するには、少なくとも 3 つのポッドを使用します。

    アプリケーションにより高いレベルの可用性を提供するために、クラスターは可用性ゾーンにまたがって分散させることができます。 これらのゾーンは、特定のリージョン内の物理的に分離されたデータセンターです。 クラスター コンポーネントが複数のゾーンに分散されている場合、クラスターは、それらのゾーンのいずれかで障害が発生しても許容できます。 アプリケーションと管理操作は、1 つのデータセンター全体で障害が発生した場合でも継続して利用できます。 詳細については、「可用性ゾーンを使用する Azure Kubernetes Service (AKS) クラスターを作成する」を参照してください。

運用環境へ移行してインフラストラクチャのベスト プラクティスを適用する

運用環境向けにアプリケーションを準備するときには、ベスト プラクティスの最小セットを実装します。 この段階で、こちらのチェックリストを使用します。 このセクションを終了すると、こちらの質問に答えることができます。

  • クラスター インフラストラクチャを自信を持って再デプロイできますか?
  • リソース クォータを適用していますか?

チェックリスト:

  • クラスターのプロビジョニングを自動化する。 コードとしてのインフラストラクチャを使用することで、インフラストラクチャのプロビジョニングを自動化して災害時の回復性を高め、必要に応じて迅速にインフラストラクチャを再デプロイする機敏性を得ることができます。 詳細については、「Terraform を使用して Azure Kubernetes Service で Kubernetes クラスターを作成する」を参照してください。

  • ポッド中断バジェットを使用して可用性を計画する。 アプリケーションの可用性を維持するには、ポッド中断バジェット (PDB) を定義して、ハードウェア障害またはクラスターのアップグレード中に最小限の数のポッドがクラスターで使用できるようにします。 詳細については、「ポッド中断バジェットを使用して可用性を計画する」を参照してください。

  • 名前空間にリソース クォータを適用する。 名前空間レベルでリソース クォータを計画して適用します。 クォータは、コンピューティング リソース、ストレージ リソース、およびオブジェクト数に設定できます。 詳細については、「リソース クォータを適用する」を参照してください。

最適化とスケーリング

アプリケーションの運用開始後、ワークフローの最適化と、アプリケーションとチームでのスケーリングの準備はどのようにして行うことができますか? 最適化とスケーリングのチェックリストを使用して準備してください。 このセクションを終了すると、こちらの質問に答えることができます。

  • 事業継続とディザスター リカバリーの計画はありますか?
  • クラスターでアプリケーションの需要に合わせてスケーリングできますか?
  • クラスターとアプリケーションの正常性を監視し、アラートを受け取ることができますか?

チェックリスト: