次の方法で共有

Azure Kubernetes Service の運用管理に関する考慮事項

  • [アーティクル]

Kubernetes は比較的新しいテクノロジで、急速に進化しており、優れたエコシステムを備えています。 そのため、管理し保護することが困難な場合があります。

AKS の運用ベースライン

管理と監視を念頭に置いて Azure Kubernetes Service (AKS) ソリューションを適切に設計することで、オペレーショナル エクセレンスと顧客の成功に向けて作業を行うことができます。

設計上の考慮事項

次の要因について検討します。

  • AKS の制限に注意します。 複数の AKS インスタンスを使用して、これらの制限を超えてスケーリングします。
  • ワークロードをクラスター内で論理的に分離する方法、別々のクラスターに物理的に分離する方法に注意します。
  • ワークロードのリソース消費を制御する方法に注意します。
  • Kubernetes がワークロードの正常性を理解するために役立つ方法に注意します。
  • さまざまな仮想マシンのサイズと、それぞれを使用した場合の影響に注意します。 より大きな VM では、より多くの負荷を処理できます。 より小さな VM は、計画済みおよび計画外のメンテナンスで使用できなくても、より簡単に他の VM に置き換えることができます。 さらに、同じクラスター内で異なるサイズの仮想マシンを可能にする、スケール セットのノード プールと VM にも注意します。 より大きな VM の方がより最適です。これは、AKS がそのリソースを予約する割合が小さくなり、より多くのリソースをワークロードで使用できるためです。
  • AKS を監視してログに記録する方法に注意します。 Kubernetes はさまざまなコンポーネントで構成されており、監視とログ記録によって、その正常性、傾向、および潜在的な問題に関する分析情報を得られます。
  • 監視とログ記録に基づいて構築すると、Kubernetes やそこで実行されるアプリケーションで生成されるイベントが多くなる場合があります。 アラートを使用すると、履歴目的のログ エントリと、早急に対処する必要があるログ エントリを区別できます。
  • 必要な更新プログラムやアップグレードに注意します。 Kubernetes レベルでは、メジャー バージョン、マイナー バージョン、およびパッチ バージョンがあります。 アップストリーム Kubernetes のポリシーに従って、サポートされている状態を維持するために、顧客はこれらの更新プログラムを適用する必要があります。 ワーカー ホスト レベルでは、OS カーネル修正プログラムで、再起動や新しい OS バージョンへのアップグレードが必要になる場合があります。再起動は顧客が行う必要があります。 クラスターの手動アップグレードに加え、クラスターに自動アップグレード チャネルを設定できます。
  • クラスターのリソースの制限と個々のワークロードに留意してください。
  • 水平ポッド オートスケーラーとクラスター オートスケーラーの違いに注意します。
  • ネットワーク ポリシーと Azure ポリシーのプラグインを使用してポッド間のトラフィックをセキュリティで保護することを検討します。
  • AKS で実行中のアプリケーションやサービスのトラブルシューティングに役立てるために、コントロール プレーン コンポーネントによって生成されたログを表示する必要がある場合があります。 ログ記録は既定では有効になっていないため、AKS のリソース ログを有効にすることが望ましい場合があります。

Recommendations

  • AKS の制限について理解します。

  • 名前空間レベルで論理的な分離を使用して、アプリケーション、チーム、環境、事業単位を分離します。 マルチテナントとクラスター分離。 ノード プールは、ノードの仕様が異なるノードでも Kubernetes が複数のノード プールをアップグレードするなどのメンテナンスでも役立ちます。

  • 名前空間レベルでリソース クォータを計画して適用します。 ポッドでリソースの要求と制限が定義されていない場合は、ポリシーなどを使用してデプロイを拒否します。 すべての kube-system ポッドに要求と制限があるわけではないため、これは kube-system ポッドには適用されません。 リソースの使用状況を監視し、必要に応じてクォータを調整します。 スケジューラの基本的な機能

  • 正常性プローブをサービスに追加します。 ポッドに、livenessProbe、readinessProbe および startupProbe AKS 正常性プローブが含まれていることを確認します。

  • 密度向上による利点が得られるように、複数のコンテナー インスタンスを格納するのに十分な数の VM サイズを使用します。ただし、障害が発生しているノードのワークロードをクラスターで処理できなくなるほど大きくしないようにします。

  • 監視ソリューションを使用します。 Azure Monitor のコンテナー分析情報は既定で設定され、多くの分析情報に簡単にアクセスできます。 より深く掘り下げたい場合や、Prometheus を使用した経験がある場合は、Prometheus 統合を使用できます。 AKS で監視アプリケーションも実行したい場合は、Azure Monitor を使用してそのアプリケーションを監視する必要もあります。

  • Azure Monitor コンテナー分析情報のメトリック アラートを使用して、直接アクションが必要な場合に通知を提供します。

  • アプリケーションの需要を満たし、ピーク時の負荷を軽減するために、ノード プールの自動スケーリング機能をポッドの水平オートスケーラーと共に使用します。

  • Azure Advisor を使用して、コスト、セキュリティ、信頼性、オペレーショナル エクセレンス、パフォーマンスに関するベスト プラクティスの推奨事項を取得します。 また、Microsoft Defender for Cloud を使用して、イメージの脆弱性などの脅威を防止および検出します。

  • Azure Arc 対応 Kubernetes を使用すると、Azure Policy、Defender for Cloud、GitOps などを使用して Azure 内の非 AKS Kubernetes クラスターを管理できます。

  • ポッドの要求と制限を使用して、AKS クラスター内のコンピューティング リソースを管理します。 ポッドの要求と制限によって、Kubernetes スケジューラに、どのコンピュート リソースをポッドに割り当てるかが通知されます。

AKS を保護および復旧するためのビジネス継続性とディザスター リカバリー

組織は、その特定要件を満たすために、適切な Azure Kubernetes Service (AKS) プラットフォームレベルの機能を設計する必要があります。 これらのアプリケーション サービスには、目標復旧時間 (RTO) と回復ポイントの目標 (RPO) に関連する要件があります。 AKS ディザスター リカバリーには、対処すべき複数の考慮事項があります。 最初の手順で、インフラストラクチャとアプリケーションのサービス レベル アグリーメント (SLA) を定義します。 Azure Kubernetes Service (AKS) の SLA について学習します。 月間稼働率の計算の詳細については、SLA の詳細セクションを参照してください。

設計上の考慮事項

次の要因について検討します。

  • AKS クラスターからノード プール内の複数のノードを使用して、アプリケーションの最小レベルの可用性を提供する必要があります。

  • ポッドの要求と制限を設定します。 これらの制限を設定すると、Kubernetes から次のことができます。

    • ポッドに CPU およびメモリ リソースを効率的に提供します。
    • ノードのコンテナー密度を高くします。

    また、制限を設定することで、ハードウェアをうまく利用できるようになるため、コストを削減しながら信頼性を高めることができます。

  • AKS の Availability Zones または可用性セットに対する適合性。

    • 可用性ゾーンをサポートしているリージョンを選択します。
    • Availability Zones は、ノード プールの作成時にのみ設定でき、後で変更することはできません。 複数ゾーンのサポートは、ノード プールにのみ適用されます。
    • ゾーンを完全に活用するには、すべてのサービス依存関係でもゾーンがサポートされている必要があります。 依存サービスでゾーンがサポートされていない場合、ゾーンの障害によってそのサービスがエラーになる可能性があります。
    • Availability Zones が達成できる以上の高可用性を実現するには、複数の AKS クラスターを異なるペアのリージョンで実行します。 Azure リソースで geo 冗長がサポートされている場合は、冗長サービスのセカンダリ リージョンがある場所を指定します。

  • AKS のディザスター リカバリーに関するガイドラインを把握しておく必要があります。 次に、それらが Azure Dev Spaces に使用する AKS クラスターに適用されるかどうかを検討します。

  • アプリケーションとデータのバックアップを一貫して作成します。

    • ステートフルでないサービスは、効率的にレプリケートできます。
    • クラスター内に "状態" を格納する必要がある場合は、ペアになっているリージョンで頻繁にデータをバックアップしてください。 考慮事項の 1 つは、クラスターに "状態" を適切に格納することは、複雑になる場合があるということです。

  • クラスターの更新とメンテナンス。

    • クラスターを常に最新の状態に保ちます。
    • リリースと非推奨化プロセスに注意します。
    • 更新とメンテナンスを計画します。

  • フェールオーバーが発生した場合のネットワーク接続。

    • 要件に応じて、ゾーンまたはリージョン間でトラフィックを分散できるトラフィック ルーターを選択します。 Web 以外のトラフィックをゾーン間で分散できるため、このアーキテクチャを使用して Azure Load Balancer をデプロイします。
    • リージョン間でトラフィックを分散する必要がある場合は、Azure Front Door の使用を検討してください。

  • 計画的および計画外のフェールオーバー。

    • 各 Azure サービスを設定するときに、ディザスター リカバリーをサポートする機能を選択します。 たとえば、このアーキテクチャでは、geo レプリケーションのために Azure Container Registry を有効にしています。 リージョンがダウンした場合でも、レプリケートされたリージョンから引き続きイメージをプルできます。

  • サービスレベル目標を達成するためにエンジニアリング DevOps 機能を保守します。

  • Kubernetes API サーバー エンドポイントに対して、利用料金に基づく SLA が必要かどうかを判断します。

設計の推奨事項

設計のベスト プラクティスを次に示します。

  • システム ノード プールに 3 つのノードを使用します。 ユーザー ノード プールの場合、2 つ以上のノードから開始します。 より高い可用性が必要な場合は、さらに多くのノードを設定します。

  • アプリケーションを別のノード プールに配置してシステム サービスから分離します。 このように、Kubernetes サービスは専用ノードで実行され、他のサービスと競合しません。 ワークロードをスケジューリングするノード プールを識別するために、タグ、ラベル、テイントを使用します。

  • 信頼性を確保するには、クラスターの定期的な保守 (タイムリーな更新を行うなど) が不可欠です。 AKS 上の Kubernetes バージョンのサポート期間に注意し、更新を計画します。 また、ポッドの正常性をプローブを介して監視することをお勧めします。

  • 可能な限り、サービスの状態をコンテナー内から削除します。 代わりに、マルチリージョン レプリケーションをサポートする Azure のサービスとしてのプラットフォーム (PaaS) を使用します。

  • ポッド リソースを確保する。 デプロイにポッド リソースの要件を指定することを強くお勧めします。 そうすることで、スケジューラでポッドを適切にスケジューリングできます。 ポッドがスケジュールされていない場合、信頼性が低下します。

  • ハードウェア障害などの中断に対処するために、デプロイに複数のレプリカを設定します。 更新やアップグレードなどの計画されたイベントに備えて、中断バジェットを使用して、予想されるアプリケーション負荷を処理するために必要な数のポッド レプリカを確保できます。

  • お使いのアプリケーションのデータに Azure Storage が使用されている場合があります。 アプリケーションは異なるリージョンの複数の AKS クラスターに分散しているため、ストレージの同期を保つ必要があります。 ストレージをレプリケートする 2 つの一般的な方法は次のとおりです。

    • インフラストラクチャベースの非同期レプリケーション
    • アプリケーションベースの非同期レプリケーション

  • ポッドの制限を見積もります。 ベースラインをテストして確定します。 要求と制限に等しい値を使用して開始します。 次に、それらの値を徐々に調整しながら、クラスターを不安定にするおそれがあるしきい値を確定します。 ポッドの制限は、配置マニフェストに指定できます。

    組み込み機能として、サービス アーキテクチャの障害や中断を処理する複雑なタスクに対するソリューションが提供されています。 これらの構成は、設計とデプロイ自動化の両方を簡略化するのに役立ちます。 SLA、RTO、および RPO の標準を定義しておくことで、組織は Kubernetes と Azure への組み込みサービスを使用して、ビジネス目標を達成できます。

  • ポッド中断バジェットを設定します。 この設定により、デプロイ内で、更新またはアップグレード イベント中に削除できるレプリカの数がチェックされます。

  • サービス名前空間でリソース クォータを適用します。 名前空間のリソース クォータによって、ポッドの要求と制限がデプロイに適切に設定されます。

    • クラスター レベルでリソース クォータを設定すると、適切な要求と制限のないパートナー サービスをデプロイするときに問題が発生するおそれがあります。

  • コンテナー イメージを Azure Container Registry に格納し、レジストリを各 AKS リージョンに geo レプリケーションします。

  • アップタイム SLA を使用すると、運用ワークロードをホストするすべてのクラスターに対して利用料金に基づく高い SLA を実現することができます。 アップタイム SLA は、可用性ゾーンを使用するクラスターに対しては Kubernetes API サーバー エンドポイントの 99.95% の可用性を保証し、可用性ゾーンを使用しないクラスターに対しては 99.9% の可用性を保証します。 ノード、ノード プールとその他のリソースは、それぞれの SLA の対象になっています。 AKS では、コントロール プレーン コンポーネントのサービス レベル目標 (SLO) が 99.5% の Free レベルが提供されています。 アップタイム SLA が有効になっていないクラスターは、運用ワークロードに使用しないでください。

  • Azure ExpressRoute 接続には、複数のリージョンとピアリングの場所を使用します。

    Azure リージョンまたはピアリング プロバイダーの場所に影響する停止が発生した場合に、ハイブリッド ネットワーク アーキテクチャが冗長になっていると、中断のないクロスプレミス接続を確保できます。

  • グローバル仮想ネットワーク ピアリングを使用してリージョンを相互接続します。 クラスターが相互に通信する必要がある場合、両方の仮想ネットワークを相互に接続するには、仮想ネットワーク ピアリングを使用して実現できます。 このテクノロジは、異なる地理的リージョンにまたがっていても、Microsoft のバックボーン ネットワーク全体で高帯域幅を提供して仮想ネットワークを相互に接続します。

  • Azure Front Door からスプリット TCP ベースのエニーキャスト プロトコルを使用して、エンド ユーザーが Front Door の最も近いポイント オブ プレゼンスにすぐに接続されるように保証します。 Azure Front Door のその他の機能は次のとおりです。

    • TLS 終了
    • カスタム ドメイン
    • Web アプリケーション ファイアウォール
    • URL 書き換え
    • セッション アフィニティ

    アプリケーション トラフィックのニーズを確認して、どのソリューションが最も適切かを検討してください。