クラウドネイティブシナリオにおける高可用性アーキテクチャのベストプラクティス

[Yuan Chuang Conference プレビュー] 1024 プログラマーズデー (2 日前)、オープンソース中国オフィスに集合、AI について話しましょう! >>>

著者: Liu Jiaxu (ニックネーム: Jiaxu)、Alibaba Cloud コンテナサービス技術専門家

導入

クラウドネイティブテクノロジの急速な発展と、エンタープライズ IT 分野でのその応用の深化に伴い、エンタープライズサービスの可用性、安定性、セキュリティにとって、クラウドネイティブシナリオにおける高可用性アーキテクチャの重要性がますます高まっています。合理的なアーキテクチャ設計とクラウドプラットフォームの技術サポートを通じて、クラウドネイティブの高可用性アーキテクチャは、高可用性、柔軟な拡張性、簡素化された運用および保守管理、信頼性とセキュリティの向上、その他の利点を提供し、企業により信頼性が高く効率的なサービスを提供します。動作環境。

Kubernetes は、クラウドネイティブのコアテクノロジの 1 つです。インフラストラクチャの自動化、柔軟なスケーラビリティ、マイクロサービスアーキテクチャ、自動化された運用とメンテナンスなどのコンテナオーケストレーションおよび管理機能を提供します。そのため、Kubernetes のアプリケーション高可用性アーキテクチャはクラウドネイティブであり、可用性が高くなります。礎石。この記事では、Alibaba Cloud Container Service for Kubernetes (ACK) を例として、ACK に基づく高可用性アーキテクチャとアプリケーションのガバナンスのベストプラクティスを紹介します。

アプリケーションの高可用性アーキテクチャの設計

クラウドネイティブアプリケーションの高可用性アーキテクチャ設計は、アプリケーションの高可用性開発、展開、ガバナンスにとって重要な前提条件であり、次の側面から検討できます。

1. クラスター設計:クラスターのコントロールプレーンとデータプレーンのコンポーネントとノードは、マルチノードおよびマルチコピーの高可用性を備えて展開され、K8s クラスターの高可用性を確保します。ACK を例に挙げると、コントロールプレーンとデータプレーンをカバーするクラスターの高可用性機能が提供されます。コントロールプレーンでは、ACK Pro マネージドバージョンクラスタのコントロールプレーンコンポーネントは、複数のコピーを使用してアベイラビリティゾーン全体に展開され、コントロールプレーンの負荷圧力に基づいて自動的に伸縮します。ACK 独自バージョンは 3 つまたは 5 つのマスターで構成できます。ノード。データ側では、ACK はユーザーがアベイラビリティゾーンおよび ECS デプロイメントセット全体にノードをデプロイおよび追加することを選択できるようにサポートします。

2. コンテナ設計:アプリケーションはクラスタ内に複数のコピーを使用してデプロイされ、アプリケーションのコピーはデプロイメント、Statefulset、OpenKruise CRD に基づいて管理され、アプリケーションの高可用性を実現します。アプリケーションが負荷の動的な変化に対処できるように自動エラスティックポリシーが構成されます。。マルチコピー Pod のシナリオでは、プライマリロールとセカンダリロールにコピーがあるかどうかに応じて、プライマリとセカンダリの高可用性とマルチアクティブな高可用性に分けることができます。

3. リソースのスケジューリング: K8s スケジューラを使用して、アプリケーションの負荷分散とフェイルオーバーを実現します。ラベルとセレクターを使用してアプリケーションのデプロイメントノード範囲を指定し、アフィニティ、アンチアフィニティ、およびトポロジスケジューリング制約ルールを使用してアプリケーションのスケジューリング戦略を制御し、ノード、アベイラビリティゾーン、デプロイメントセット、トポロジドメインなどごとにポッドを実装します。さまざまなカテゴリ高可用性を実現します。

4. ストレージ設計:データ損失を避けるために、ストレージをマウントするための K8s 永続ボリュームなど、アプリケーションデータを保存するために永続ストレージを使用します。ステートフルアプリケーションの場合は、StatefulSet を使用して、ステートフルアプリケーションのレプリカとストレージボリュームを管理します。

5. 障害回復: K8s の自動回復メカニズムを使用して、アプリケーション障害を処理します。ヘルスチェックと自動再起動を使用して、アプリケーションの健全性を監視し、アプリケーションに障害が発生した場合にはアプリケーションを自動的に再起動または移行することができます。

6. ネットワーク設計: K8s のサービス検出機能と負荷分散機能を使用してアプリケーションネットワークアクセスを実装し、Service と Ingress を使用してアプリケーションサービスを公開します。

7. 監視と警報: K8s 監視および警報システム (Prometheus、Thanos、AlertManager など) を使用して、アプリケーションの実行ステータスを監視し、タイムリーに障害を検出して処理します。

8. フルリンク高可用性設計:フルリンク高可用性とは、クラウドネイティブアプリケーションシステムおよびサービスに含まれるすべてのコンポーネント、モジュール、サービス、ネットワーク、およびその他のリンクの高可用性を指します。フルリンクの高可用性は、システム全体のアーキテクチャ設計、コンポーネントの選択と構成、サービスの導入、運用と保守に至るまで、包括的な検討と実装が必要となる総合的な考慮事項です。同時に、特定のビジネスニーズと技術要件に基づいて、適切な妥協とトレードオフを行う必要があります。

つまり、K8s アプリケーションの高可用性アーキテクチャを設計するには、信頼性が高く安定したアプリケーションの高可用性アーキテクチャと機能を実現するために、クラスタ、コンテナ、リソースのスケジューリング、ストレージ、障害回復、ネットワーク、アラームの監視などの要素を包括的に考慮する必要があります。上記の原則を参照することで、既存システムの高可用性変革も実装できます。

以下では、上記の設計原則に基づいて Kubernetes が提供するさまざまな高可用性テクノロジと、ACK に基づいた関連製品の実装を紹介します。

K8s 高可用性テクノロジーと ACK でのその応用

Kubernetes は、クラスターとアプリケーションの高可用性を確保するためのさまざまな高可用性テクノロジーとメカニズムを提供します。トポロジー分散制約、PodAntiAffinity、コンテナーのヘルスチェックと自動再起動、ストレージの冗長性と永続性、サービスの検出とロードバランシングなどが含まれます。これらのテクノロジーとメカニズムは、可用性の高い Kubernetes クラスターとアプリケーションを構築し、安定した信頼性の高いサービスを提供するのに役立ちます。これについては、以下で紹介します。

3.1 コントロールプレーン/データプレーンは複数のアベイラビリティゾーンで高可用性を備えています

クラスタリングは、コントロールプレーンとデータプレーンのノード/コンポーネントを異なる可用性ゾーンに展開することで高可用性を実現し、重要な高可用性アーキテクチャ設計手法です。アベイラビリティーゾーンは、地理的エリア内のクラウドプロバイダーによって提供される、論理的に独立したデータセンターです。ノードを異なるアベイラビリティーゾーンにデプロイすることで、1 つのアベイラビリティーゾーンに障害が発生したり利用できなくなった場合でも、クラスターがサービスを提供し続けることができます。

アベイラビリティゾーンに基づく K8s クラスタノードの高可用性設計のキーポイントは次のとおりです。これを使用して、Kubernetes のアベイラビリティゾーンに基づいてコントロールプレーン/データプレーンノードの高可用性構成を実装できます。

複数のアベイラビリティーゾーンのオプション

単一障害点のリスクを軽減するには、クラスターに対してクラウドベンダーがサポートする複数のアベイラビリティゾーンを選択します。
コントロールプレーンノード/コンポーネントのデプロイ

コントロールプレーンノードとコンポーネント (etcd、kube-apiserver、kube-controller-manager、kube-scheduler など) をさまざまなアベイラビリティゾーンにデプロイし、クラウドベンダーのロードバランサーまたは DNS 解決を使用してトラフィックをバックエンドに分散します。複数の etcd ノードを使用して高可用性 etcd クラスターを構成し、それらを異なるアベイラビリティーゾーンに分散します。これにより、etcd ノードの 1 つに障害が発生した場合でも、クラスターは引き続き動作できることが保証されます。
データプレーンノードを展開する

データプレーンノードを複数のアベイラビリティゾーンに分散して、ポッドを異なるアベイラビリティゾーンにスケジュールして、クロスアベイラビリティゾーンの高可用性を実現します。
監視と自動回復監視システムを構成してクラスターの健全性を監視し、ノードまたはアベイラビリティーゾーンに障害が発生した場合の自動フェイルオーバーと回復のための自動回復メカニズムを設定します。

コントロールプレーンノード/コンポーネントとデータプレーンノードを複数のアベイラビリティゾーンにデプロイすることで、Kubernetes クラスターの可用性とフォールトトレランスが向上し、単一のアベイラビリティゾーンまたはノードに障害が発生した場合でもクラスターがサービスを提供し続けることができます。

ACK は、コントロールプレーンとデータプレーンをカバーするクラスターの高可用性機能を提供します。ACK コンテナサービスは、Kubernetes on Kubernetes アーキテクチャを使用して、etcd、API サーバー、スケジューラなどのユーザーの Kubernetes クラスタコントロールプレーンコンポーネントをホストします。各コントロールプレーンコンポーネントの複数のインスタンスは、高可用性アーキテクチャを使用してデプロイおよび管理されます。ACK Pro クラスターが配置されているリージョンのアベイラビリティーゾーンの数が 3 以上の場合、ACK Pro 管理対象クラスターのコントロールプレーンの SLA は 99.95% です。ACK Pro クラスターが配置されているリージョンのアベイラビリティーゾーンの数は 99.95% です。見つかった値が 2 以下の場合、ACK Pro が管理するクラスターコントロールプレーンの SLA は 99.50% です。

ACK コンテナサービスは、ホスティングコンポーネントの高可用性、セキュリティ、柔軟な拡張と縮小を担当します。ACK Pro クラスターは、管理対象コンポーネントに完全な可観測性機能を提供し、ユーザーがクラスターのステータスを監視および警告できるようにします。

以下では、アベイラビリティゾーンによる高可用性のフラグメンテーションを制御するための一般的なテクノロジと、ACK シナリオでのその使用方法を紹介します。これらのテクノロジは、データプレーンの高可用性シナリオで広く使用されています。

3.1.1 トポロジースプレッドの制約

Topology Spread Constraints は、Kubernetes クラスター内の Pod の分散を管理する機能です。これにより、Pod がさまざまなノードおよび可用性ゾーンに均等に分散され、アプリケーションの高可用性と安定性が向上します。このテクノロジーは、Deployment、StatefulSet、DaemonSet、および Job/CronJob のワークロードに適用されます。

トポロジー分散制約を使用すると、次の構成を設定して Pod の分散を制御できます。

マックススキュー

各トポロジドメイン内のPodの最大偏差値を指定します。トポロジドメインには、ノード、可用性ゾーン、またはその他のカスタムトポロジドメインを指定できます。最大偏差値は、クラスターの任意の 2 つのトポロジドメイン内のポッド間の最大差を表す整数です。たとえば、MaxSkew が 2 に設定されている場合、2 つのトポロジドメイン内のポッド数の差は 2 を超えてはなりません。
トポロジーキー

トポロジー・ドメインのラベルまたはアノテーションを識別するために使用されるキーを指定します。ノードラベル (node.kubernetes.io/zone など)、またはカスタムラベルやアノテーションを使用できます。
満足できない場合

トポロジー分布の制約を満たせない場合に実行するアクションを指定します。選択できる操作は、DoNotSchedule (Pod をスケジュールしない)、ScheduleAnyway (Pod を強制的にスケジュールする)、および RequireDuringSchedulingIgnoredDuringExecution (トポロジ分散制約を要求するが、強制しない) です。

これらの構成を使用すると、トポロジー分散制約を含むポリシーを作成し、目的のトポロジー分散に従ってポッドがクラスターにデプロイされるようにすることができます。これは、信頼性と可用性を向上させるために、異なるアベイラビリティーゾーンまたはノード間で負荷を均等に分散する必要があるアプリケーションに役立ちます。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-run-per-zone
spec:
  replicas: 3
  selector:
    matchLabels:
      app: app-run-per-zone
  template:
    metadata:
      labels:
        app: app-run-per-zone
    spec:
      containers:
        - name: app-container
          image: app-image
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: "topology.kubernetes.io/zone"
          whenUnsatisfiable: DoNotSchedule

上記の例では、maxSkew を 1 に設定し、topologyKey を「topology.kubernetes.io/zone」に設定し、whenUnsatisfiable を DoNotSchedule に設定して、トポロジ分散制約が作成されます。これは、ノードのラベル「topology.kubernetes.io/zone」（クラウドベンダーの可用性ゾーンに対応）で定義されたトポロジドメインと、トポロジ間のポッド数の最大差に従って、ポッドが可用性ゾーンごとに強制的に分散されることを意味します。ドメインは1です。このようにして、可能な限り可用性ゾーンに従って Workload Pod を分散し、スケジュールすることができます。

ACK K8s クラスターコントロールプレーンは、デフォルトでマルチアベイラビリティゾーンの高可用性アーキテクチャを採用していますが、さらにデータプレーンに対してマルチアベイラビリティゾーンアーキテクチャを実装する必要があります。ACK クラスターのデータプレーンは、ノードプールと仮想ノードで構成されます。各ノードプールは ECS インスタンスのグループであり、ユーザーはノードプールを通じてノードの管理、拡張、縮小、日常の運用とメンテナンスを行うことができます。仮想ノードは、エラスティックコンテナインスタンス ECI を通じてサーバーレスコンテナ実行環境を提供できます。

各ノードプールの背後には Elastic Scaling Group (ESS) があり、ノードの手動拡張と自動拡張をサポートします。ACK ノードプールはデプロイメントセットをサポートしており、異なる物理サーバー上の同じデプロイメントセットに ECS インスタンスを分散してデプロイできるため、1 台の物理マシンの障害による複数の ECS インスタンスのダウンタイムを回避できます。ACK はマルチ AZ ノードプールもサポートしています。作成および運用中に、異なる AZ にまたがる複数の vSwitch をノードプールに対して選択できます。そして、スケーリンググループによって指定された (つまり、複数の VPC スイッチを指定して) ECS インスタンスが複数のアベイラビリティゾーン間で均等に分散できるように、バランスの取れた分散戦略を選択します。在庫不足などの理由で可用性ゾーンのバランスが崩れた場合は、バランシング操作を実行して、可用性ゾーンのリソース配分のバランスを調整できます。

ノード、デプロイメントセット、AZ などのさまざまな障害ドメインのメタ情報に基づいて、K8s スケジューリングのトポロジー分散制約 (トポロジー分散制約) と組み合わせることで、さまざまなレベルの障害ドメイン分離機能を実現できます。まず、ACK ノードプール内のすべてのノードは、「kubernetes.io/hostname」、「topology.kubernetes.io/zone」、「topology.kubernetes.io/region」などのトポロジ関連のラベルを自動的に追加します。開発者は、トポロジー分散制約を使用して、さまざまな障害ドメイン間での Pod の分散を制御し、基盤となるインフラストラクチャ障害に対する耐性を向上させることができます。

3.1.2 トポロジ分布制約と NodeAffinity/NodeSelector の関係

トポロジ分散制約と NodeAffinity/NodeSelector の関係は、ノードアフィニティとノードセレクタは主に特定範囲のノードへの Pod のスケジューリングを制御するために使用され、トポロジ分散制約は異なるトポロジドメイン間の Pod の分散を制御することに重点を置いています。。これらのメカニズムを組み合わせて、Pod のスケジューリングと分散をより詳細に制御できます。

NodeAffinity および NodeSelector は、トポロジ分散制約とともに使用できます。まず NodeAffinity と NodeSelector を使用して特定の条件を満たすノードを選択し、次にトポロジ分散制約を使用して、これらのノード上の Pod の分散が予想されるトポロジ分散要件を満たしていることを確認できます。

詳細については [1]を参照してください。

トポロジー分散制約を伴うノードアフィニティとノードセレクターの混合使用については、 [2]を参照してください。

3.1.3 トポロジカル分布制約の欠点

トポロジー分散制約にはいくつかの制限と欠点があるため、注意する必要があります。

アベイラビリティーゾーンの数の制限: アベイラビリティーゾーンの数が非常に限られている場合、または使用可能なアベイラビリティーゾーンが 1 つだけの場合、トポロジー分散制約を使用しても利点が得られない可能性があります。この場合、真の可用性ゾーンの障害分離と高可用性は実現できません。
ポッドが削除された場合、制約がまだ満たされているという保証はありません。たとえば、デプロイメントをスケールダウンすると、ポッドの分散が不均一になる可能性があります。
スケジューラは、クラスタ内のすべての領域または他のトポロジドメインについての事前知識を持っていません。これらは、クラスター内の既存のノードに基づいて決定されます。これにより、ノードプール (またはノードグループ) がノード 0 に削減され、ユーザーがクラスターがスケーリングできることを期待している場合、自動スケーリングクラスターで問題が発生する可能性があります。その時点では、これらのトポロジドメインは少なくとも考慮されません。その中にノードが入っています。

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

3.1.4 複数のアベイラビリティゾーンにより、同時かつ迅速な弾性拡張を実現

ACK ノードの自動スケーリングコンポーネントは、事前スケジュールを通じてサービスを特定のスケーリンググループにデプロイできるかどうかを判断し、指定されたスケーリンググループにインスタンスの数を拡張するリクエストを送信し、最後に ESS スケーリンググループがインスタンスを生成します。。ただし、スケーリンググループ上で複数のアベイラビリティゾーン vSwtich を構成するこのモデル機能では、次の問題が発生します。

クラスターリソースが不十分なためにマルチ AZ ビジネスポッドをスケジュールできない場合、ノード自動スケーリングサービスはスケーリンググループの拡張をトリガーしますが、アベイラビリティーゾーンと拡張する必要があるインスタンスの間の関係をアベイラビリティーゾーンに渡すことはできません。同時に複数の vSwtich にポップアップするのではなく、特定のリージョンに複数のインスタンスがあると、複数のアベイラビリティゾーンでの同時拡張のニーズを満たすことができません。

マルチアベイラビリティゾーンバランシングは、データ型の高可用性シナリオにおける一般的な展開方法です。ビジネスのプレッシャーが高まると、マルチアベイラビリティーゾーンのバランスの取れたスケジューリング戦略を適用することで、クラスターのスケジューリングレベルを満たすために複数のアベイラビリティーゾーンのインスタンスを自動的に拡張することが期待されます。

複数のアベイラビリティゾーンでノードを同時に拡張する問題を解決するために、Container Service ACK には ack-autoscaling-placeholder コンポーネントが導入されています。このコンポーネントは、少量のリソース冗長性を使用して、複数のアベイラビリティゾーンの柔軟なスケーリング問題を方向性のあるスケーリング問題に変換します。同時ノードプールの数。

具体的な原則は次のとおりです。

まず、各アベイラビリティゾーンのノードプールを作成し、各ノードプールにアベイラビリティゾーンのラベルを付けます。
アベイラビリティゾーンラベルの nodeSelector を設定することで、ack-autoscaling-placeholder を使用して、各アベイラビリティゾーンのプレースホルダーポッドを作成します。デフォルトのプレースホルダーポッドには比較的低重みの PriorityClass があり、アプリケーションポッドの優先順位はプレースホルダーポッドよりも高くなります。
このようにして、ビジネスがポッド保留を適用した後、各アベイラビリティーゾーンのポッドをプリエンプトします。可用性ゾーンのノードノードセレクターを持つマルチアベイラビリティーゾーンのポッドが保留中になると、ノード自動スケーリングコンポーネントによって認識されるスケジューリングポリシーは次のようになります。アンチアフィニティはアベイラビリティーゾーンのノードセレクターになり、拡張ゾーンを発行するノードからのリクエストの処理が容易になります。

下図の 2 つのアベイラビリティゾーンを例に、既存のアーキテクチャを利用して複数のアベイラビリティゾーンの同時拡張に対応する方法を紹介します。

詳細については [4]を参照してください。

3.1.5 アベイラビリティゾーンの容量が損傷した後の自動回復

マルチゾーンの高可用性クラスターで AZ 障害が発生した場合、アプリケーションの容量が損傷していることが多く、K8s はアプリケーションのコピー数または HPA (水平ポッドスケーリング) 構成に基づいて容量を自動的に拡張します。これには、クラスターリソースの自動拡張を実現するために、クラスターをクラスター AutoScaler または仮想ノードで構成する必要があります。Cluster AutoScaler を使用すると、過剰割り当てを通じてリソースを予約できるため、コンテナアプリケーションを迅速に起動し、基盤となる拡張の遅さや失敗によるビジネスの中断を回避できます。詳細については [5]を参照してください。

3.2 ノードごとに Pod アンチアフィニティを適用する (PodAntiAffinity)

ポッドアンチアフィニティは、ポッドをスケジュールするときに同じノードにスケジュールされないようにするために使用される Kubernetes のスケジューリング戦略です。これを使用して Pod ノードを分散し、アプリケーションの高可用性と障害分離機能を向上させることができます。

ポッドのアンチアフィニティポリシーを使用すると、次の方法を設定してポッドのノード分散を制御できます。

1.スケジューリング中に必須、実行中に無視

これは、スケジューリング時にポッド間の非アフィニティ関係が満たされることを要求する強制ポリシーです。これは、Kubernetes スケジューラが、ポッドをスケジュールするときに、それらが同じノード上でスケジュールされないよう最善を尽くすことを意味します。ただし、スケジュール設定後、ノードのリソースが不十分な場合、またはその他の理由によりこれらのポッドを同じノードで実行する必要がある場合、Kubernetes はこの反アフィニティポリシーを無視します。

2.スケジュール中は優先、実行中は無視

これは、Pod 間の非アフィニティ関係を維持することを推奨する推奨戦略ですが、必須ではありません。スケジューラに複数の選択肢がある場合、同じノード上でこれらの Pod をスケジュールすることを回避しようとします。ただし、他に利用可能なオプションがない場合でも、スケジューラは同じノード上でこれらの Pod をスケジュールできます。

ポッドのアンチアフィニティポリシーを使用すると、クラスター内のポッドの分散を制御し、同じノード上でポッドをスケジュールすることを回避し、ノードの分散を実現できます。これは、可用性と障害分離を向上させるために、別のノードでポッドを実行する必要があるアプリケーションに役立ちます。

以下は Pod アンチアフィニティの例です。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-run-per-node
spec:
  replicas: 3
  selector:
    matchLabels:
      app: app-run-per-node
  template:
    metadata:
      labels:
        app: app-run-per-node
    spec:
      containers:
        - name: app-container
          image: app-image
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchExpressions:
                  - key: app
                    operator: In
                    values:
                      - app-run-per-node
              topologyKey: "kubernetes.io/hostname"

上記の例では、Pod に非アフィニティ設定が設定されており、スケジューラは、スケジューリング時にこれらの Pod が同じノードにスケジュールされないようにする必要があります。トポロジキーは「kubernetes.io/hostname」に設定されており、スケジューラーが異なるノード間で分散できるようになります。

ポッドのアンチアフィニティとノードアフィニティ (Node Affinity) は異なる概念であることに注意してください。ノードアフィニティは、Pod が特定のラベルを持つノード上でスケジュールされることを優先するように指定するために使用され、Pod アンチアフィニティは、Pod が同じノードにスケジュールされないようにするために使用されます。これら 2 つのスケジューリング戦略を組み合わせることで、より柔軟でフォールトトレラントなスケジューリングとノード分散が可能になります。

TopologySpreadConstraints に基づいて、ノードごとに Pod の高可用性スケジューリング効果を実現することもできます。topologyKey: "kubernetes.io/hostname" を指定することは、各ノードがトポロジドメインであることに相当し、ノード間のスキュー比較を実現します。次に、トポロジ分散制約の例を示します。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: my-app-container
          image: my-app-image
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: "kubernetes.io/hostname"
          whenUnsatisfiable: DoNotSchedule

上記の例では、maxSkew を 1 に設定し、topologyKey を「kubernetes.io/hostname」に設定し、whenUnsatisfiable を DoNotSchedule に設定して、トポロジ分散制約が作成されます。これは、高可用性を実現するためにノードごとにポッドを強制的に分散させるために、各ノードで実行できるポッドは 1 つだけであることを意味します。

3.3 アプリケーションのマルチコピーの高可用性

Kubernetes では、デプロイメント、Statefulset、OpenKruise などの CRD 高度なリソースなど、さまざまなワークロードに基づいてアプリケーションのマルチコピー高可用性を実現できます。Deployment を例にとると、Deployment リソースは Pod のコピー数を定義するために使用されるコントローラーであり、指定された数のコピーが常に実行されていることを確認し、コピーが失敗した場合には自動的に新しいコピーを作成する役割を果たします。

3.3.1 アプリケーションのマルチアクティビティと高可用性

アプリケーションのマルチアクティビティと高可用性とは、アプリケーションの複数のコピーがトラフィックを受信してサービスを個別に処理できることを意味します。コピーの数は HPA を通じて構成でき、負荷圧力によってトリガーされる自動弾力性を使用して、動的トラフィックに適応できます。 API サーバーおよび Nginx Ingress コントローラーとして。この形式の高可用性設計では、データの一貫性や複数のコピーのパフォーマンスなどの問題を考慮する必要があります。

3.3.2 アプリケーションのアクティブおよびバックアップの高可用性

アプリケーションのマスターとバックアップの高可用性とは、アプリケーションの複数のコピーにマスターコピーとバックアップコピーが存在することを意味します。最も一般的なのは、1 つのマスターと 1 つのバックアップです。1 つのマスターと複数のスレーブなど、より複雑な形式もありますマスターはロック取得などの方法に基づいて選択され、コントローラーの形式で適用可能なコンポーネントです。たとえば、Etcd、KubeControllerManager、および KubeScheduler はすべて、アクティブモードとバックアップモードの高可用性アプリケーションです。

ユーザーは、自社のビジネス形態やシナリオに合わせて、マルチアクティブまたはアクティブスタンバイを使用するようにコントローラーを設計できます。

3.3.3 PDB によりアプリケーションの高可用性が向上

アプリケーションの可用性をさらに向上させるために、Kubernetes では Pod Disruption Budget (PDB) 構成を使用することもできます。PDB を使用すると、ユーザーは使用可能なレプリカの最小数を定義でき、ノードのメンテナンスや障害が発生した場合、Kubernetes は少なくとも指定された数のレプリカが実行されたままであることを保証します。PDB は、同時に終了されるレプリカが多すぎるのを防ぐことができます。これは、MessageQueue 製品など、複数のライブレプリカがトラフィックを処理するシナリオに特に適しており、それによってサービスの中断を回避できます。

PDB を使用するには、PDB リソースを Deployment または StatefulSet の構成に追加し、使用可能なレプリカの最小数を指定します。たとえば、次は PDB を使用したデプロイメント構成の例です。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-with-pdb
spec:
  replicas: 3
  selector:
    matchLabels:
      app: app-with-pdb
  template:
    metadata:
      labels:
        app: app-with-pdb
    spec:
      containers:
        - name: app-container
          image: app-container-image
          ports:
            - containerPort: 80
  ---
  apiVersion: policy/v1beta1
  kind: PodDisruptionBudget
  metadata:
    name: pdb-for-app
  spec:
    minAvailable: 2
    selector:
      matchLabels:
        app: app-with-pdb

上記の例では、デプロイメント構成は 3 つのレプリカを定義し、PDB 構成は少なくとも 2 つのレプリカを使用可能な状態に保つように指定しています。つまり、ノードのメンテナンス中や障害中であっても、Kubernetes は少なくとも 2 つのレプリカが常に実行されていることを保証し、Kubernetes クラスター内のアプリケーションの可用性を向上させ、サービス中断の可能性を減らします。

3.4 健全性の検出と自己修復

Kubernetes では、さまざまな種類のプローブを構成することで、コンテナーのステータスと可用性を監視および管理できます。Kubernetes で一般的に使用されるプローブ構成と戦略は次のとおりです。

Liveness プローブLiveness プローブは、コンテナーがまだ正常に実行されているかどうかを監視するために使用されます。liveness プローブが失敗した場合 (200 以外のステータスコードを返した場合)、Kubernetes はコンテナを再起動します。Survival Probe を構成すると、問題が発生したときにコンテナーが自動的に再起動できるようになります。Liveness プローブは、HTTP リクエスト、TCP ソケット、またはコマンド実行を使用して検出できます。
Readiness プローブReadiness プローブは、コンテナーがトラフィックを受信する準備ができているかどうかを監視するために使用されます。Kubernetes は、readiness プローブが成功した場合 (ステータスコード 200 を返した場合) にのみ、トラフィックをコンテナに転送します。readiness プローブを構成すると、コンテナーが完全に開始され、リクエストを受信する準備ができた場合にのみ、サービスのロードバランサーにコンテナーが追加されるようにすることができます。
起動プローブ起動プローブは、コンテナが起動しているかどうかを監視するために使用されます。liveness プローブや readiness プローブとは異なり、起動プローブはコンテナーの起動中に実行され、コンテナーはプローブが成功した後にのみ準備完了としてマークされます。プローブの開始が失敗した場合、Kubernetes はコンテナーを失敗としてマークし、コンテナーを再起動します。
再起動ポリシー再起動ポリシーは、コンテナが終了したときに実行する必要があるアクションを定義します。Kubernetes は、次の 3 つの再起動戦略をサポートしています。

- Always: Kubernetes は、コンテナーがどのように終了したかに関係なく、コンテナーを自動的に再起動します。
- OnFailure: Kubernetes は、コンテナーがゼロ以外のステータスで終了した場合にのみ、コンテナーを自動的に再起動します。
- Never: Kubernetes は、コンテナがどのように終了しても、コンテナを自動的に再起動しません。

これは、ポッドまたはデプロイメントの構成に対応するプローブと再起動ポリシーを追加することで構成できます。次に例を示します。

apiVersion: v1
kind: Pod
metadata:
  name: app-with-probe
spec:
  containers:
    - name: app-container
      image: app-image
      livenessProbe:
        httpGet:
          path: /health
          port: 80
        initialDelaySeconds: 10
        periodSeconds: 5
      readinessProbe:
        tcpSocket:
          port: 8080
        initialDelaySeconds: 15
        periodSeconds: 10
      startupProbe:
        exec:
          command:
            - cat
            - /tmp/ready
        initialDelaySeconds: 20
        periodSeconds: 15
      restartPolicy: Always

上記の例では、liveness プローブ (HTTP GET リクエストを通じてパス /health を持つポート 80 を検出)、readiness プローブ (TCP ソケットを通じてポート 8080 を検出)、および起動プローブ (コマンド cat /tmp/ready を使用)コンテナが開始されているかどうかを検出します)、再起動ポリシーは常にです。実際のニーズに応じて、コンテナの特性とヘルスチェック要件に基づいて適切な構成を行うことができます。

3.5 アプリケーションとデータの分離

Kubernetes では、Persistent Volume (PV) と Persistent Volume Claims (PVC) を使用してアプリケーションとデータの分離を実現することも、適切なバックエンドデータベースサービスストレージを選択することもできます。

PV と PVC は、アプリケーションが基礎となるストレージテクノロジとは独立して使用できる抽象化レイヤーを提供します。永続ボリュームはクラスター内のストレージリソースであり、ポッドやノードから独立しています。Persistent Volume Claim は、ストレージリソースをアプリケーションのポッドにバインドするために使用される Persistent Volume に対するリクエストです。

適切な Persistent Volume Claims と Persistent Volume を選択するには、考慮すべき要素がいくつかあります。

ストレージタイプ

アプリケーションのニーズに基づいて、適切なストレージタイプを選択してください。Kubernetes は、ローカルストレージ、ネットワークストレージ (NFS、iSCSI など)、クラウドプロバイダーの永続ストレージ (Alibaba Cloud OSS など)、外部ストレージプラグイン (Ceph など) を含むさまざまなストレージタイプをサポートします。、GlusterFS など）。アプリケーションの読み取りおよび書き込みパフォーマンス、データ保護、可用性の要件に基づいて、適切なストレージタイプを選択してください。
ストレージ

アプリケーションのストレージのニーズに基づいて、適切なストレージ容量を選択してください。永続ボリュームを作成するときに、ストレージ容量のサイズ範囲を指定できます。Persistent Volume Claim を作成するときに、必要なストレージ容量を指定できます。データストレージのニーズを満たすのに十分なストレージ領域をアプリケーションに提供するようにしてください。
アクセスモード

アプリケーションのアクセスモードに基づいて、適切なアクセスモードを選択します。Kubernetes は、一貫した読み取りと書き込み (ReadWriteOnce)、複数回の読み取りと書き込み (ReadWriteMany)、読み取り専用 (ReadOnlyMany) などの複数のアクセスモードをサポートします。アプリケーションのマルチノードアクセスのニーズに基づいて、適切なアクセスモードを選択します。

RDS などの適切なバックエンドデータサービスを選択する場合は、次の要素を考慮する必要があります。

データベースの種類と機能

アプリケーションのニーズに基づいて、適切なデータベースの種類を選択してください。リレーショナルデータベース (MySQL、PostgreSQL など)、NoSQL データベース (MongoDB、Cassandra など) などのデータベースの種類が異なると、異なる機能と適応性が提供されます。アプリケーションのデータモデルとクエリのニーズに基づいて、適切なデータベースタイプを選択します。
パフォーマンスとスケーラビリティ

アプリケーションのパフォーマンス要件に基づいてバックエンドデータサービスを選択します。データベースのパフォーマンス指標 (スループット、レイテンシーなど) とそのスケーリング能力を考慮してください。
可用性と信頼性

バックエンドデータサービスを選択するときは、可用性と信頼性を考慮してください。クラウドプロバイダーのマネージドデータベースサービスは通常、高可用性と自動バックアップ機能を提供します。アプリケーションの可用性とデータ保護のニーズを満たすバックエンドデータサービスを必ず選択してください。

3.6 負荷分散の高可用性構成

従来の負荷分散 CLB は、ほとんどのリージョンに複数のアベイラビリティゾーンをデプロイして、同じリージョン内でマシンルーム間のディザスタリカバリを実現していました。サービスアノテーションを使用して、SLB/CLB のアクティブアベイラビリティゾーンとバックアップアベイラビリティゾーンを指定できます。アクティブアベイラビリティゾーンとバックアップアベイラビリティゾーンは、ノードプール内の ECS アベイラビリティゾーンと一致している必要があります。これにより、アベイラビリティゾーン間のデータ転送が削減され、ネットワークアクセスが向上します。パフォーマンス。

apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-master-zoneid: "cn-hangzhou-a"
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-slave-zoneid: "cn-hangzhou-b"
  name: nginx
  namespace: default
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    run: nginx
  type: LoadBalancer

クロスアベイラビリティゾーンのネットワークトラフィックを削減し、ネットワークパフォーマンスを向上させるため。Kubernetes 1.23 で導入された Topology Aware Hints を使用して、トポロジーを認識した最近接ルーティング機能を実装できます。

3.7 クラウドディスクの高可用性構成

現在、Alibaba Cloud クラウドディスクは単一のアベイラビリティゾーンでのみ作成およびマウントできます。マルチアベイラビリティゾーンクラスタ内の永続アプリケーションのデータストレージとしてクラウドディスクを使用するには、トポロジ対応のクラウドディスクストレージタイプ alicloud- を選択する必要があります。 ACK によって提供されるディスクトポロジ [6]を使用して、Persistent VolumeClaim を作成します。このストレージクラスのボリュームバインディングモードは、デフォルトで WaitForFirstConsumer に設定されており、対応するアベイラビリティゾーンで Persistent VolumeClaim が作成されるまで遅延バインディングをサポートします。マルチアベイラビリティゾーントポロジ認識を指定してストレージボリュームを生成する、より洗練された ESSD クラウドディスクストレージクラスを作成できます。ストレージ宣言と永続化アプリケーションは次のとおりです。詳細については、ドキュメント [7] を参照して ください。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: alicloud-disk-topology-essd
provisioner: diskplugin.csi.alibabacloud.com
parameters:
  type: cloud_essd
  fstype: ext4
  diskTags: "a:b,b:c"
  zoneId: “cn-hangzhou-a,cn-hangzhou-b,cn-hangzhou-c” #指定可用区范围来生成云盘
  encrypted: "false"
  performanceLevel: PL1 #指定性能类型
  volumeExpandAutoSnapshot: "forced" #指定扩容编配的自动备份开关，该设置仅在type为"cloud_essd"时生效。
volumeBindingMode: WaitForFirstConsumer
reclaimPolicy: Retain
allowVolumeExpansion: true
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: topology-disk-pvc
spec:
  accessModes:
  - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 100Gi
  storageClassName: alicloud-disk-topology-essd
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
spec:
  serviceName: "mysql"
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - image: mysql:5.6
        name: mysql
        env:
        - name: MYSQL_ROOT_PASSWORD
          value: "mysql"
        volumeMounts:
        - name: data
          mountPath: /var/lib/mysql
      volumes:
        - name: data
          persistentVolumeClaim:
            claimName: topology-disk-pvc

3.8 仮想ノードの高可用性構成

仮想ノードは、エラスティックコンテナインスタンス ECI にデプロイされる Kubernetes アプリケーションをサポートしているため、ノードの運用とメンテナンスの必要性がなくなり、オンデマンドでノードを作成できるため、予約されたリソースの無駄が削減されます。突発的なトラフィックに対応するためにビジネスを急速に水平展開する場合や、ジョブタスクを処理するために多数のインスタンスを起動する場合、アベイラビリティゾーン内で対応する仕様のインスタンスの在庫が不足したり、指定されたスイッチ IP が枯渇したりする状況が発生する可能性があります。 ECI インスタンスの作成に失敗しました。ACK サーバーレスのマルチアベイラビリティーゾーン機能を使用すると、ECI インスタンスの作成の成功率を向上させることができます。

ECI プロファイルを通じて異なる AZ 間で vSwitch を構成することで、複数の AZ アプリケーション間で仮想ノードをデプロイできます。

ECI は、圧力を分散する効果を得るために、Pod を作成するリクエストをすべての vSwitch に分散します。
ポッド作成リクエストで vSwitch にインベントリがない状況が発生した場合、自動的に次の vSwitch に切り替えて作成を試行し続けます。

実際のニーズに応じて、kube-system/eci-profile configmap の vswitch フィールドを変更すると、変更はすぐに有効になります。

kubectl -n kube-system edit cm eci-profile

apiVersion: v1
data:
  kube-proxy: "true"
  privatezone: "true"
  quota-cpu: "192000"
  quota-memory: 640Ti
  quota-pods: "4000"
  regionId: cn-hangzhou
  resourcegroup: ""
  securitygroupId: sg-xxx
  vpcId: vpc-xxx
  vswitchIds: vsw-xxx,vsw-yyy,vsw-zzz
kind: ConfigMap

関連するコンテンツは [8] にあります。

3.9 アラーム設定の監視

K8s 自体や kube-state-metrics などのコンポーネントによって明らかにされる指標を通じて、ポッドやノードなどのリソースの高可用性と利用可能なゾーンの分布を効果的に監視できます。これは、問題を迅速に発見して特定するために非常に重要です。本番環境では、監視・警報システムは継続的に構築され、K8sのバージョンアップやコンポーネントのバージョンアップに合わせて更新が繰り返されるため、常に新しい指標に注目し、ビジネスシナリオに応じて監視・警報システムに導入することをお勧めします。以下に、リソースの高可用性のための 2 つのアラーム設定を参考として示します。

3.9.1 アプリケーションのロードコピーが利用できないというアラームの監視

K8s の kube-state-metrics は、アプリケーション負荷の Deployment/Statefulset/Daemonset の使用できないコピーの数、コピーの総数などを集計して分析することができ、この種の指標に基づいて、アプリケーション内に使用できないコピーがあるかどうかを確認できます。コピーの合計数に占める使用できないコピーの割合部分的または完全に影響を受けるサービスの監視と警告を実現します。

Deployment を例として、AlertManager/Thanos Ruler のアラームの例は次のとおりです。

# kube-system或者monitoring中的Deployment存在不可用副本，持续1m，则触发告警，告警serverity配置为L1
- alert: SystemPodReplicasUnavailable
  expr: kube_deployment_status_replicas_unavailable{namespace=~"kube-system|monitoring",deployment!~"ack-stub|kubernetes-kdm"} > 0
  labels:
    severity: L1
  annotations:
    summary: "namespace={{$labels.namespace}}, deployment={{$labels.deployment}}: Deployment存在不可用Replica"
  for: 1m
# kube-system或者monitoring中的Deployment副本总数>0，且全部副本不可用，持续1m，则触发告警，告警serverity配置为L1
- alert: SystemAllPodReplicasUnavailable
  expr: kube_deployment_status_replicas_unavailable{namespace=~"kube-system|monitoring"} == kube_deployment_status_replicas{namespace=~"kube-system|monitoring"} and kube_deployment_status_replicas{namespace=~"kube-system|monitoring"} > 0
  labels:
    severity: L1
  annotations:
    summary: "namespace={{$labels.namespace}}, deployment={{$labels.deployment}}: Deployment全部Replicas不可用"
  for: 1m

3.9.2 クラスター可用性ゾーン内の異常なノードの割合に関するアラームの監視

K8s の kube-controller-manager コンポーネントは、異常なノードの数、正常なノードの割合、およびアベイラビリティゾーン内のノードの総数をカウントし、関連するアラームを構成できます。

# HELP node_collector_unhealthy_nodes_in_zone [ALPHA] Gauge measuring number of not Ready Nodes per zones.
# TYPE node_collector_unhealthy_nodes_in_zone gauge
node_collector_unhealthy_nodes_in_zone{zone="cn-shanghai::cn-shanghai-e"} 0
node_collector_unhealthy_nodes_in_zone{zone="cn-shanghai::cn-shanghai-g"} 0
node_collector_unhealthy_nodes_in_zone{zone="cn-shanghai::cn-shanghai-l"} 0
node_collector_unhealthy_nodes_in_zone{zone="cn-shanghai::cn-shanghai-m"} 0
node_collector_unhealthy_nodes_in_zone{zone="cn-shanghai::cn-shanghai-n"} 0
# HELP node_collector_zone_health [ALPHA] Gauge measuring percentage of healthy nodes per zone.
# TYPE node_collector_zone_health gauge
node_collector_zone_health{zone="cn-shanghai::cn-shanghai-e"} 100
node_collector_zone_health{zone="cn-shanghai::cn-shanghai-g"} 100
node_collector_zone_health{zone="cn-shanghai::cn-shanghai-l"} 100
node_collector_zone_health{zone="cn-shanghai::cn-shanghai-m"} 100
node_collector_zone_health{zone="cn-shanghai::cn-shanghai-n"} 100
# HELP node_collector_zone_size [ALPHA] Gauge measuring number of registered Nodes per zones.
# TYPE node_collector_zone_size gauge
node_collector_zone_size{zone="cn-shanghai::cn-shanghai-e"} 21
node_collector_zone_size{zone="cn-shanghai::cn-shanghai-g"} 21
node_collector_zone_size{zone="cn-shanghai::cn-shanghai-l"} 21
node_collector_zone_size{zone="cn-shanghai::cn-shanghai-m"} 21
node_collector_zone_size{zone="cn-shanghai::cn-shanghai-n"} 21

AlertManager/Thanos Rulerのアラーム例は以下のとおりです。

# node_collector_zone_health <= 80 如果可用区内健康节点比例小于80%，就触发告警。
- alert: HealthyNodePercentagePerZoneLessThan80
  expr: node_collector_zone_health <= 80
  labels:
    severity: L1
  annotations:
    summary: "zone={{$labels.zone}}: 可用区内健康节点与节点总数百分比 <= 80%"
  for: 5m

アプリケーション向けの単一/マルチクラスター高可用性アーキテクチャ

上記の第 3 章で紹介した高可用性テクノロジーと、Alibaba Cloud の製品機能によって提供される製品機能に基づいて、単一クラスター内の高可用性アーキテクチャを完全に実現できます。マルチクラスター高可用性アーキテクチャは、単一クラスター高可用性アーキテクチャをさらにアップグレードした高可用性アーキテクチャであり、クラスター/リージョン全体で高可用性サービス機能を提供します。

マルチリージョン、マルチクラスターの展開とユニット化されたアプリケーションアーキテクチャを通じて、高可用性を確保しながら、クロスリージョンのネットワーク伝送遅延、コスト、障害率の課題を克服できます。これにより、ビジネスの安定性と信頼性を確保しながら、ユーザーに優れたユーザーエクスペリエンスを提供できます。

4.1 単一リージョン、マルチアベイラビリティゾーンの高可用性クラスター

上記の第 3 章で紹介した高可用性テクノロジーと Alibaba Cloud 製品によって提供される機能に基づいて、単一クラスターディメンション内の高可用性アーキテクチャを実現できますが、ここでは再度説明しません。

4.2 単一リージョンのマルチクラスターの高可用性 + マルチリージョンのマルチクラスターの高可用性

まず、各 ACK クラスターはマルチアベイラビリティゾーンの高可用性アーキテクチャを採用し、ビジネスアプリケーションはマルチアベイラビリティゾーン展開モードを採用して、SLB を通じて外部サービスを提供します。

マルチリージョンデプロイメントとマルチ AZ デプロイメントは本質的に似ていますが、リージョン間のネットワーク伝送遅延、コスト、障害率の違いにより、適応するには異なるデプロイメントとアプリケーションアーキテクチャが必要になります。プラットフォーム層については、クロスリージョンの Kubernetes クラスターを実装することは推奨されません。代わりに、マルチリージョンのマルチクラスターアプローチを採用し、それをユニット化されたアプリケーションアーキテクチャと組み合わせて、マルチリージョンの高可用性アーキテクチャを実現することをお勧めします。。複数の独立した Kubernetes クラスターを異なるリージョンにデプロイし、各クラスターが独自のノードとアプリケーションを管理します。各リージョンのクラスターは独立しており、独自のマスターノードとワーカーノードを持ちます。これにより、地域間のネットワーク遅延と障害率が軽減され、アプリケーションの可用性とパフォーマンスが向上します。

同時に、ユニット化されたアプリケーションアーキテクチャを採用してアプリケーションを独立したユニットに分割し、各ユニットが複数のリージョンのクラスターにコピーをデプロイします。ロードバランシングと DNS 解決テクノロジを通じて、ユーザーのリクエストを最も近い場所にルーティングし、トラフィックを最も近いリージョンに分散し、ネットワーク遅延を短縮し、高可用性と災害復旧機能を提供できます。

クロスリージョン ACK クラスターがネットワーク相互接続を必要とする場合、マルチリージョン VPC 間の相互接続はクラウドエンタープライズネットワーク (CEN) を通じて実現できます。地域間のビジネストラフィックスケジューリングは、グローバルトラフィック管理 GTM およびクラウド分析サービスを通じて実装されます。

可観測性、セキュリティポリシー、クラスタ間でのアプリケーションの統合配信など、複数のリージョンにある複数のクラスタの統合管理を実行したい場合。ACK One を使用してこれを実現できます。分散クラウドコンテナプラットフォーム ACK One (Kubernetes 用分散クラウドコンテナプラットフォーム) は、ハイブリッドクラウド、マルチクラスター、分散コンピューティング、災害復旧などのシナリオ向けに Alibaba Cloud によって開始されたエンタープライズレベルのクラウドネイティブプラットフォームです。ACK One は、任意のリージョンおよび任意のインフラストラクチャ上のユーザーの Kubernetes クラスターに接続して管理でき、コンピューティング、ネットワーク、ストレージ、セキュリティ、モニタリング、ログ、ジョブ、アプリケーション、トラフィックなどをサポートする一貫した管理およびコミュニティ互換 API を提供します。運用保守管理・制御を一元的に行うことができます。ACK One についてさらに詳しく知りたい場合は、DingTalk 検索グループ番号: 35688562 を使用してグループに参加してください。

ACK One は、アプリケーションシステムのディザスタリカバリソリューションを 2 か所 3 センターで構築しています (関連コンテンツは [9] を参照してください)。

リンクの概要

クラウドネイティブシナリオにおけるアプリケーションの高可用性アーキテクチャと設計は、エンタープライズサービスの可用性、安定性、セキュリティにとって非常に重要であり、アプリケーションの可用性とユーザーエクスペリエンスを効果的に向上させ、障害の分離と耐障害性を実現します。この記事では、クラウドネイティブアプリケーションの高可用性アーキテクチャ設計の重要な原則、K8s 高可用性テクノロジ、ACK シナリオでのその使用と実装、および単一クラスタとマルチクラスタの高可用性アーキテクチャの使用について紹介します。関連するニーズを持つ企業にリファレンスとヘルプを提供するために、ACK は安全で安定したパフォーマンスとコストが最適化され、継続的にアップグレードされるクラウドネイティブの製品とサービスを顧客に提供し続けます。

この記事では、Alibaba Cloud Container Service の責任者である Yi Li 氏が ACK 高可用性アーキテクチャの分析について素晴らしい情報を共有してくれたことに言及し、心より感謝の意を表します。

[2] https://kubernetes.io/blog/2020/05/introducing-podtopologyspread/

[3] https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/#known-limitations

[4] https://help.aliyun.com/zh/ack/ack-managed-and-ack-dicate/user-guide/configure-auto-scaling-for-cross-zone-deployment

[5] https://help.aliyun.com/document_detail/184995.html

[6] https://help.aliyun.com/zh/ack/ack-managed-and-ack-dicate/user-guide/dynamically-provision-a-disk-volume-by-using-the-cli-1 #セクション-dh5-bd8-x0q

[7] https://help.aliyun.com/zh/ack/ack-managed-and-ack-dicate/user-guide/use-dynamically-provisioned-disk-volumes

[8] https://help.aliyun.com/zh/ack/serverless-kubernetes/user-guide/create-ecis-across-zones

[9] https://developer.aliyun.com/article/913027