Cloud Network Well-architected Design Guidelines:ACK のアプリケーション配信ネットワーク設計

概要

このトピックでは、Kubernetes クラスタのネットワークイングレスの設計方法、特に Service コンポーネントと Ingress コンポーネントの設計方法について説明します。ネットワーク構成では、Kubernetes クラスタ内のサービス間のアクセスと Kubernetes クラスタ内のサービスへのアクセスの効率とセキュリティが非常に重要です。Service コンポーネントと Ingress コンポーネントの設計原則を正しく理解し実装することで、アプリケーションの可用性を高めるだけでなく、システム全体のパフォーマンスと安定性も大幅に向上します。

用語

Kubernetes: Kubernetes は、コンテナ化されたアプリケーションのデプロイ、スケーリング、および管理を自動化するオープンソースのコンテナオーケストレーションエンジンです。このオープンソースプロジェクトは、Cloud Native Computing Foundation ( CNCF ) によってホストされています。

Container Service for Kubernetes ( ACK ): ACK は、世界で初めて Certified Kubernetes Conformance Program に参加したサービスの 1 つです。ACK は、高性能なコンテナ化アプリケーション管理サービスを提供し、企業がコンテナ化アプリケーションのライフサイクルを管理し、クラウドにコンテナ化アプリケーションを効率的にデプロイできるようにします。

Service: Kubernetes では、Service は Pod または Pod のグループをネットワーク経由で公開するのに役立つ抽象化です。Service は、ラベルセレクターに基づいて Pod のグループを識別し、ClusterIP、NodePort、LoadBalancer、ExternalName などの Service タイプに基づいて Pod 間のトラフィック分散を管理します。Service は、Pod への直接アクセスによって発生する問題を効果的に修正し、アプリケーションの高可用性と効率性を確保します。デフォルトでは、Service は TCP プロトコルを使用します。その他のサポートされているプロトコルを使用することもできます。Service は主に東西トラフィックの処理に使用されます。

Ingress: Ingress は、URI、ホスト名、パスなどの Web の概念を理解するプロトコル対応の構成メカニズムを使用して、HTTP または HTTPS サービスを利用できるようにします。Ingress の概念を使用すると、Kubernetes API を使用して定義したルールに基づいて、トラフィックを異なるバックエンドにマッピングできます。Ingress は、負荷分散、SSL 終端、および名前ベースの仮想ホスティングを提供できます。通常、Ingress コントローラーはロードバランサーを使用して Ingress を実行しますが、Ingress コントローラーはエッジルーターまたは追加のフロントエンドを構成してトラフィックの処理を支援することもできます。Ingress は主に南北トラフィックの処理に使用されます。

Container Network Interface ( CNI ) プラグイン: CNI プラグインは、コンテナネットワークの実装を担当します。使用する CNI プラグインによって、Pod への IP アドレスの割り当て方法、オーバーレイネットワークを使用するかどうか、クラスタ内でのトラフィックの転送方法、および Pod へのアクセスの管理方法が決まります。よく知られているオープンソースの CNI プラグインには、Calico、Flannel、Cilium などがあります。ACK は、Terway と Flannel という CNI プラグインを提供しています。Terway と Flannel は異なる機能を提供します。次のセクションでは、Terway と Flannel が提供する機能について説明します。ACK クラスタを作成するときに Terway と Flannel のどちらを選択するかについては、「Terway コンテナネットワークプラグインと Flannel コンテナネットワークプラグインの比較」をご参照ください。

Terway: Terway は Alibaba Cloud によって開発された CNI プラグインです。ACK クラスタの Elastic Compute Service ( ECS ) インスタンスは、Elastic Network Interface ( ENI ) を使用してネットワーク通信を有効にします。Terway は、ノード上の ENI を Pod に割り当てて、Pod 間のネットワーク接続を確立します。したがって、Terway プラグインを使用するクラスタ内の Pod は、クラスタが存在する仮想プライベートクラウド ( VPC ) に接続されます。Terway モードでは、Virtual Extensible Local Area Network ( VXLAN ) などのトンネリング技術でパケットをカプセル化する必要がないため、通信効率が向上します。Terway は、ネットワークパフォーマンスとアクセス制御に高い要件を持つ大規模クラスタに適しています。

Flannel: Flannel はオープンソースの CNI プラグインです。Flannel は、VXLAN などのネットワーク仮想化技術を使用して、Pod 用のオーバーレイネットワークを構築します。Flannel は構成と使用が簡単です。Flannel は NAT ゲートウェイを必要としないため、Terway と比較して、ネットワークパフォーマンスとアクセス制御機能が劣ります。また、Flannel は大規模クラスタをサポートしていません。Flannel は、1,000 ノード以下のクラスタに適しています。ネットワークパフォーマンスとアクセス制御の要件が低いか、クラスタをすばやく作成して使用したい場合は、Flannel プラグインを使用することをお勧めします。

Network Load Balancer ( NLB ): NLB は、Internet of Everything ( IoE ) 時代向けのレイヤー 4 負荷分散サービスです。NLB は超高性能を提供し、オンデマンドで自動的にスケーリングできます。NLB インスタンスは最大 1 億の同時接続をサポートしており、高い同時実行性を必要とするサービスに最適です。

Application Load Balancer ( ALB ): ALB はアプリケーションレイヤーで実行される Alibaba Cloud サービスであり、HTTP、HTTPS、および Quick UDP Internet Connections ( QUIC ) でのトラフィックの分散を最適化するように設計されています。ALB は非常に柔軟性が高く、オンデマンドで大量のレイヤー 7 トラフィックを処理できます。ALB は複雑なルーティングをサポートしています。ALB は他のクラウドネイティブサービスと緊密に統合されており、Alibaba Cloud のクラウドネイティブ Ingress ゲートウェイとして機能するように設計されています。

Elastic IP Address ( EIP ): EIP は、独立したリソースとして購入して保持できるパブリック IP アドレスです。EIP は、仮想プライベートクラウド ( VPC ) 内の ECS インスタンス、セカンダリ ENI、Server Load Balancer ( SLB ) インスタンス、NAT ゲートウェイ、および高可用性仮想 IP アドレス ( HaVip ) に関連付けることができます。

高信頼性

• マルチリージョン/マルチゾーンデプロイ:

  • Service: 単一ゾーンの障害が全体的な可用性に影響を与えないように、複数のゾーンに Service をデプロイします。

  • Ingress: マルチリージョンまたはマルチゾーンデプロイをサポートするように Ingress コントローラーを構成します。いずれかのゾーンに障害が発生した場合でも、サービスの継続性と高可用性を維持できます。

• ヘルスチェックとフェールオーバー:

  • Service: Kubernetes の組み込みヘルスチェック機能を使用して Pod のステータスを監視し、異常な Pod を自動的に削除します。

  • Ingress: Ingress コントローラーのヘルスチェック機能を使用して、バックエンドサービスのヘルスステータスを定期的にチェックし、異常なノードから正常なノードにトラフィックを自動的に切り替えます。

スケーラビリティ

• きめ細かい水平スケーリング:

  • Service: Service は、ゾーンごとのきめ細かい水平スケーリングをサポートしています。

  • Ingress: パスやホスト名など、ビジネス要件に基づいてトラフィックを分散するように Ingress の複雑なルーティングポリシーを構成します。

パフォーマンスと弾力性

• 動的トラフィック管理と自動スケーリング:

  • Service と Ingress: セッション管理や重み付きラウンドロビンなどのインテリジェントトラフィック管理ポリシーと Service と Ingress を統合して、システムパフォーマンスを最適化し、ユーザーエクスペリエンスを向上させます。また、Ingress コントローラーと service の自動スケーリングポリシーを構成して、さまざまな時間帯のトラフィック変動に効率的に対応します。

• ピーク時のパフォーマンス:

  • Service と Ingress: 自動スケーリング機能と Service と Ingress を統合して、リアルタイムのトラフィック量に基づいて容量を動的に調整します。これにより、ピーク時のサービスパフォーマンスが確保され、オフピーク時のコストが削減されます。

可観測性

• メトリックの収集と表示:

  • Service と Ingress: 包括的なサービスステータスを示すパフォーマンスメトリックを収集して表示します。

• 異常検出とアラート:

  • Service と Ingress: 自動異常検出およびアラートシステムは、潜在的な問題に迅速に対応し、サービスのダウンタイムを最小限に抑えることができます。

セルフサービス機能

• ネイティブ互換性と自動デプロイ:

  • Service と Ingress: Kubernetes YAML 定義、管理サービス、および Ingress と互換性があります。Terraform や Resource Orchestration Service ( ROS ) などの Infrastructure as Code ( IaC ) ツールを使用してデプロイを自動化し、O&M 効率を高めることができます。

セキュリティ

• アクセス制御と暗号化:

  • Service と Ingress: セキュリティグループを使用して、デフォルトで TLS 終端を有効にしてデータ転送を保護し、中間者攻撃 ( MITM ) 攻撃を防ぐことができます。

高信頼性

• マルチリージョン/マルチゾーンデプロイ:

  • Service: NLB は複数レベルのディザスタリカバリをサポートしています。ネットワークトラフィックはバックエンドサーバーのグループに分散され、ディザスタリカバリが可能になります。NLB は、セッション維持とマルチゾーンデプロイもサポートしており、サービスの可用性を確保します。

  • Ingress: ALB インスタンスは、少なくとも 2 つのゾーンにデプロイできます。ゾーン間で障害分離を有効にすることができます。1 つのゾーンがダウンしても、リージョン内の他のゾーンは影響を受けません。

• ヘルスチェックとフェールオーバー:

  • Service: NLB はヘルスチェックを使用してバックエンドサーバーの可用性をテストします。ヘルスチェックを有効にした後、バックエンドサーバーがヘルスチェックに失敗した場合、NLB はそのバックエンドサーバー宛てのリクエストを他の正常なバックエンドサーバーに自動的に転送します。バックエンドサーバーが再び正常であると宣言されると、NLB はリクエストをそのバックエンドサーバーに自動的に転送します。ヘルスチェックは、サービスの高可用性を確保するための重要な手段です。ヘルスチェックは、ビジネスの全体的な可用性を向上させ、異常なサーバーによって引き起こされる単一障害点 ( SPOF ) を排除します。

  • Ingress: ALB バックエンドサーバーの可用性を監視するために、ALB のサーバーグループのヘルスチェックを構成できます。ヘルスチェックは、異常なバックエンドサーバーをできるだけ早く検出することにより、サービスの可用性を確保します。ヘルスチェックが有効になっている場合、ALB はリクエストを正常なバックエンドサーバーに自動的にルーティングし、指定された間隔ですべてのバックエンドサーバーの可用性をプローブします。バックエンドサーバーは、正常であると宣言される前に、特定の回数 ( N 回 ) ヘルスチェックに合格する必要があります。N はビジネス要件に基づいて指定できます。これにより、ネットワークジッターによって引き起こされるヘルスチェックエラーを防ぎます。

スケーラビリティ

• きめ細かい水平スケーリング:

  • Service と Ingress: NLB と ALB は手動でスケールアウトできます。NLB と ALB を有効にして、トラフィックを異なるゾーンに分散し、システムの信頼性とパフォーマンスを向上させることができます。

パフォーマンスと弾力性

• 動的トラフィック管理と自動スケーリング:

  • Service と Ingress: NLB と ALB はドメイン名と仮想 IP アドレス ( VIP ) を使用して、トラフィックを複数のレイヤーのサーバーに分散します。ALB と NLB は、ネットワークトラフィックをサーバーグループに分散してアプリケーションの可用性を向上させ、SPOF によるサービス中断を防ぎます。ALB と NLB は、カスタマイズされたマルチゾーンデプロイとゾーン間の弾力的なスケーリングもサポートしており、個々のゾーンのリソースボトルネックを解消します。

可観測性

• メトリックの収集と表示:

  • Service と Ingress: CloudMonitor を使用して、ALB と NLB のステータスとメトリックを監視および表示できます。これにより、エラーをすばやく特定できます。コンソール、API、または SDK を使用して、ALB と NLB リソースに関する監視情報を表示できます。ALB と NLB はどちらも Prometheus モニタリングをサポートしています。

• 異常検出とアラート:

  • Service と Ingress: CloudMonitor をアクティブにした後、CloudMonitor コンソールを使用するか、API 操作を呼び出すか、SDK を使用して、ALB インスタンスと NLB インスタンスのアラートルールを構成できます。

セルフサービス機能

• ネイティブ互換性と自動デプロイ:

  • Service: Terraform や ROS などの IaC ツールを使用して NLB デプロイを自動化できます。アノテーションを使用して NLB を Service として構成することもできます。

    apiVersion: v1
    kind: Service
    metadata:
      annotations:
        service.beta.kubernetes.io/alibaba-cloud-loadbalancer-zone-maps: "${zone-A}:${vsw-A},${zone-B}:${vsw-B}" # 例: cn-hangzhou-k:vsw-i123456,cn-hangzhou-j:vsw-j654321。
      name: nginx
      namespace: default
    spec:
      externalTrafficPolicy: Local
      ports:
      - name: tcp
        port: 80
        protocol: TCP
        targetPort: 80
      - name: https
        port: 443
        protocol: TCP
        targetPort: 443
      selector:
        app: nginx
      loadBalancerClass: "alibabacloud.com/nlb"
      type: LoadBalancer

  • Ingress: Terraform や ROS などの IaC ツールを使用して ALB デプロイを自動化できます。ALB Ingress をデプロイすることで、API サーバー上の AlbConfig、Ingress、および Service の変更を監視し、既存の AlbConfig を動的に更新できます。Kubernetes クラスタは NGINX Ingress と互換性があります。

セキュリティ

• アクセス制御と暗号化:

  • Service と Ingress: デフォルトでは、ALB と NLB をセキュリティグループに追加でき、プロトコル、ポート、および IP アドレスに基づくアクセス制御をサポートしています。

  • Ingress: ALB は、HTTP、HTTPS、WebSocket、TLS などのさまざまなプロトコルをサポートしています。

Service 設計

シナリオ

ACK クラスタ内の Pod を Web サーバーとして使用する: ACK クラスタの Pod にアプリケーションをデプロイし、IP アドレスとポートを使用して Service を公開します。

Service タイプの選択

LoadBalancer Service は、ロードバランサーで構成された NodePort Service に似ています。このタイプの Service は、トラフィックを複数の Pod に均等に分散できます。LoadBalancer Service は、パブリック IP アドレスを自動的に提供して、バックエンド Pod を外部アクセスに公開します。LoadBalancer Service は、レイヤー 4 で TCP および UDP リクエストを処理し、レイヤー 7 で HTTP および HTTPS リクエストを管理できます。

NLB の作成または関連付け

• 既存の NLB インスタンスを選択するか、NLB インスタンスを作成し、その NLB インスタンスを LoadBalancer Service として使用できます。

• ACK コンソールまたは kubectl ( YAML スクリプト ) を使用して NLB インスタンスを作成または関連付けし、service の関連付け ( NLB へのサーバーグループの追加と同様 ) とポートマッピング ( NLB へのリスナーの追加と同様 ) を構成できます。

• Service の YAML ファイルにアノテーションを追加して、NLB を構成できます。

NLB クォータ

詳細については、「制限」をご参照ください。

Ingress 設計

ALB Ingress と NGINX Ingress の比較