すべてのプロダクト
Search

このプロダクト

    Container Service for Kubernetes:コンテナの可観測性に関するベストプラクティス

    ドキュメントセンター

    Container Service for Kubernetes:コンテナの可観測性に関するベストプラクティス

    最終更新日:Aug 06, 2025

    Container Service for Kubernetes (ACK) は、デフォルトで Alibaba Cloud 可観測性サービスと統合されており、コンテナシナリオの運用システムを迅速に構築するのに役立つさまざまな可観測性機能を提供します。このトピックで推奨されている基本機能を使用して、コンテナ可観測性システムを迅速にセットアップします。また、各セクションを詳細に調べて、ACK クラスタインフラストラクチャ データプレーン、コントロールプレーン、およびアプリケーションシステムを網羅する完全な監視システムを構築することもできます。これにより、クラスタの安定性が向上します。

    可観測性の概要

    可観測性により、リアルタイムの障害検出、予防、手動または自動リカバリ、およびスケーラブルな修復が可能になることで、環境の変化時のシステムの安定性が確保されます。メトリクス、ログ、トレースを通じてクラスタの状態を可視化することで、トラブルシューティングとパフォーマンスの最適化を促進します。

    コンテナエコシステムでは、可観測性は、インフラストラクチャ、オペレーティングシステム、コンテナ/クラスタ、アプリケーションの 4 つのレイヤーにわたって動作します。

    image

    可観測性の観点から、クラスタの安定性の維持は、次の 3 つの側面に分けることができます。

    • クラスタインフラストラクチャ コントロールプレーン

      • kube-apiserver、etcd、kube-scheduler、kube-controller-manager、cloud-controller-manager などのクラスタコンポーネントのヘルスステータスと容量。

      • Server Load Balancer (SLB) 帯域幅や kube-apiserver の接続数など、コントロールプレーンコンポーネントによって提供されるサービスに関連する主要なリソース。

    • クラスタインフラストラクチャ データプレーン

      • 異常なノード状態、リソースの異常、ノード GPU カードの障害、ノードのメモリ使用率が高いなど、クラスタノードのヘルスステータス。

      • コンテナストレージやコンテナネットワークのコンポーネントや機能など、クラスタユーザー側コンポーネントの安定性。

    • クラスタにデプロイされたユーザー業務システム (アプリケーション)

      • ユーザー業務ポッドとアプリケーションのヘルスステータスなど、アプリケーションのヘルスステータス。一般的な例外状態には、メモリ不足 (OOM Kills) によるポッドの終了またはプロセスの終了、ポッドの準備ができていないことなどが含まれます。

    有効にすることをお勧めする機能

    このセクションでは、コンテナシナリオの運用システムを迅速に構築するために ACK が提供するすぐに使える可観測性機能について説明します。

    一般的な安定性シナリオ

    Service Mesh シナリオ

    Service Mesh シナリオでは、次の機能を有効にします。

    マルチクラウド ハイブリッドクラウド ACK One シナリオ

    ACK One 登録済みクラスタのシナリオ、または ACK One マルチクラスタフリートを使用して構築されたマルチクラウド ハイブリッドクラウドのシナリオでは、次の機能を有効にします。

    以下のセクションでは、クラスタインフラストラクチャ コントロールプレーン、クラスタインフラストラクチャ データプレーン、およびユーザー業務システム (アプリケーション) について、推奨される可観測性ベストプラクティスソリューションを紹介します。

    1. クラスタインフラストラクチャ コントロールプレーン

    image

    Kubernetes クラスタコントロールプレーンは、次のようなコア機能を管理します。

    • API レイヤー操作

    • ワークロードスケジューリング

    • Kubernetes リソースオーケストレーション

    • クラウド リソースのプロビジョニング

    • メタデータストレージ

    コントロールプレーンの主要コンポーネントには、kube-apiserver、kube-scheduler、kube-controller-manager、cloud-controller-manager、etcd が含まれます。

    ACK マネージドクラスターのコントロールプレーンは、サービスレベル契約 (SLA) 保証付きで Alibaba Cloud によって完全に管理されています。コントロールプレーンの可観測性を向上させ、クラスタの管理、構成、最適化を容易にするには、次の機能を使用して、デフォルトで事前構成されたアラートを使用して、コントロールプレーンワークロードの状態をリアルタイムで監視および観察します。これにより、異常を防ぎ、継続的な安定した運用を確保できます。

    コントロールプレーンコンポーネント監視を有効にする

    ACK は、kube-apiserver コンポーネントによって提供される Kubernetes RESTful API インターフェースを拡張および強化します。これにより、外部クライアントとクラスタ内の他のコンポーネント (Prometheus メトリック収集など) が ACK クラスタと対話し、コントロールプレーンコンポーネントの Prometheus メトリックを取得できます。

    コントロールプレーンコンポーネントログを監視する

    ACK クラスタは、アカウントの SLS プロジェクトへの一元化されたロギングをサポートしています。詳細については、「ACK マネージドクラスターのコントロールプレーンコンポーネントログを収集する」をご参照ください。

    アラート管理を構成する

    ACK は、コンテナのコアとなる異常に関するデフォルトのアラートルールを提供します。また、必要に応じてアラートルールを構成することもできます。

    2. クラスタインフラストラクチャ データプレーン

    クラスタノード

    ACK クラスタは、ワーカーノードを使用して、ワークロードデプロイメントのリソース環境を提供します。コンテナ化された環境の安定性を確保するには、各ノードの異常状態とリソース負荷を監視する必要があります。Kubernetes は、システム全体の信頼性のために一時的なノードの異常を許容する スケジューリング、プリエンプション、エビクションメカニズムを提供していますが、包括的な安定性を実現するには、ノードの異常を予防、観察、対応、回復するための予防的な対策が必要です。

    ack-node-problem-detector を使用したイベント監視

    イベント監視のために ACK によって提供される ack-node-problem-detector コンポーネントには、次のものがあります。

    • アップストリーム Kubernetes Node Problem Detector との完全な互換性

    • ACK 固有の環境向けに最適化されたチェック:

      • コンポーネント内の node-problem-detector DaemonSet は、クラスタノード環境、オペレーティングシステムの互換性、コンテナエンジンに合わせて調整および強化されています。

      • 1 分間のチェック間隔で 強化されたノード検査機能がプラグインとして提供されており、日々のほとんどのノード O&M シナリオに対応しています。

      • すべての Kubernetes イベントを SLS イベントセンターにストリーミングする統合 kube-eventer デプロイメントによる 90 日間のイベント監視データの永続化。デフォルトでは、Kubernetes イベントは etcd に保存され、クエリ保持期間は 1 時間のみです。この永続化メカニズムにより、システムは etcd の制限を超えて履歴イベントクエリを実行できます。

    ack-node-problem-detector が異常なノード状態を検出した場合は、kubectl describe node ${NodeName} コマンドを使用して、ノードの異常な Condition を表示するか、[ノード] ページのノードリストで異常なノード状態を表示します。

    ACK イベント監視で アラート管理機能を使用して、重要なポッドの起動失敗や Service エンドポイントが利用できないなどのイベントをサブスクライブします。SLS 監視サービスは、イベントアラートの送信もサポートしています。

    クラスタノードの ECS プロセスレベル監視を有効にする

    ACK クラスタの各ノードは、ECS インスタンスに対応しています。インフラストラクチャを詳細に可視化するには、ECS インスタンスに対して CloudMonitor が提供する プロセス監視機能を有効にします。

    CloudMonitor (ECS 監視) は以下を提供します。

    • 履歴プロセス分析: メモリ消費量、CPU 使用率、開いているファイル記述子別に、リソースを大量に消費する上位 5 つのプロセスの履歴を追跡します。

    • ECS ホストでの OS 監視: ホスト CPU、メモリ、ネットワーク、ディスク使用率、inode 数、ホストネットワークトラフィック、同時ネットワーク接続数など、ホストレベルの基本的なリソースメトリックを監視します。

      展開してホストとノードのリソースメトリックの比較を表示する

      ホストメトリックとノードメトリックはどちらもリソース使用率の監視に使用されますが、範囲と計算方法が異なります。ホストメトリックはホスト全体のリソース使用率を反映しますが、ノードメトリックはコンテナレイヤーでのリソース消費量と割り当てを示します。詳細については、「リソース予約ポリシー」をご参照ください。

      ディメンション

      ホストメトリック

      ノードメトリック

      範囲

      物理マシンまたは仮想マシンのリソース

      コンテナエンジンのリソース

      メモリの計算

      分子

      ホスト上のすべてのプロセスによって使用される合計メモリ (Usage)

      ノード上の作業メモリの合計 (WorkingSet)。割り当て済みメモリ、使用済みメモリ、ページキャッシュを含む

      分母

      ホストのメモリ容量 (Capacity)

      ノード上の合計割り当て可能メモリ (Allocatable)。ノードコンテナエンジン用に予約されているリソースを除く

      使用率の計算式

      Usage / Capacity

      WorkingSet / Allocatable

    重要

    プロセス監視構成は、ノードプールで CloudMonitor を有効にした後に追加されたノードにのみ適用されます。

    アラート管理とシステム監視構成

    アラート管理は、クラスタイベント監視をサポートしています。ノードの異常イベントとリソース使用率のしきい値に対してアラートを構成できます。[ノード例外のアラートルールセット] や [リソース例外のアラートルールセット] など、複数のノード関連アラートルールセットを有効にしてサブスクライブすることをお勧めします。

    ノード OS ジャーナルログの監視と永続化

    systemd は、Linux システムの init システムおよびサービスマネージャーとして機能し、システム起動後のすべてのサービスを担当します。systemd 内のジャーナルコンポーネントは以下を提供します。

    • システムログの収集と保存

    • リアルタイムログクエリと分析

    次のようなシナリオでは、systemd ジャーナルを使用して OS ログを収集および監視することをお勧めします。

    • kubelet や OS カーネルなどのノードの安定性メトリックの収集

    • 特権モードで実行されているコンテナ、頻繁にオーバーコミットされるノードリソース、OS リソースを直接使用するその他のシナリオなど、OS またはコンテナエンジンに依存するワークロードの監視の強化

    ログデータを収集して SLS プロジェクトに保存するには、「ノードの systemd ジャーナルログを収集する」をご参照ください。

    GPU と AI トレーニングシナリオの監視

    ACK クラスタにデプロイされた AI トレーニングタスクと機械学習タスクの場合、ACK は、ノード GPU の状態監視や GPU リソース監視などの機能を提供します。推奨ソリューション:

    クラスタデータプレーンシステムコンポーネント

    コンテナストレージ

    ACK クラスタのコンテナストレージタイプには、ノード上のローカルストレージ、Secret/ConfigMap、Network Attached Storage (NAS) ボリューム、Cloud Parallel File Storage (CPFS) ボリューム、Object Storage Service (OSS) ボリュームなどの外部ストレージが含まれます。

    展開してコンテナストレージタイプの詳細な説明を表示する

    • ノード上のローカルストレージ: ノードにマウントされたシステムディスクとデータディスクが含まれます。ポッドは、HostPath ボリュームまたは EmptyDir ボリュームを宣言することで、これらのストレージリソースを使用できます。

      • HostPath ボリューム: Kubernetes によって監視されないため、手動でストレージを監視する必要があります。

      • EmptyDir ボリューム: ポッドエフェメラルストレージの一部であり、ポッドで Ephemeral Storage Resource Request and Limit を宣言することで管理できます。

      エフェメラルストレージの監視範囲には、次のものが含まれます。

      • ポッドによってマウントされた tmpfs 以外の EmptyDir ボリューム (tmpfs EmptyDir ボリュームはメモリに保存されます)

      • ノードに保存されているポッドログファイル

      • ポッド内のすべてのコンテナの書き込み可能なレイヤー

    • Secret/ConfigMap: これらのタイプは通常、クラスタリソースメタデータを保存するために使用されます。厳密なストレージ監視要件はありません。

    • 外部ストレージ: ポッドは、永続ボリューム (PV) と永続ボリューム要求 (PVC) を介してこれらのストレージリソースを使用できます。ACK は、CSI でプロビジョニングされたストレージタイプをサポートしています。

      • 追加でマウントされたディスクボリューム (ノードプールに事前にマウントされたデータボリュームではありません)

      • NAS ボリュームと CPFS ボリューム

      • OSS ボリューム

    ACK は csi-plugin コンポーネントを使用して、上記のコンテナストレージタイプの監視メトリックを一様に公開します。これらのメトリックは Managed Service for Prometheus によって収集され、すぐに使用できる監視ダッシュボードが提供されます。サポートされているストレージ監視タイプとサポートされていないストレージ監視タイプ、および対応する監視方法の包括的な概要については、「コンテナストレージ監視の概要」をご参照ください。

    コンテナネットワーク

    CoreDNS

    CoreDNS は、クラスタの DNS サービス検出メカニズムの主要コンポーネントです。コンポーネントの安定性を確保するには、以下を監視します。

    • クラスタデータプレーンでの CoreDNS のリソース使用率。

    • 異常な解決応答コード (rcode) などの主要なメトリック。このメトリックは、CoreDNS ダッシュボードの Responses (by rcode) メトリックです。

    • NXDOMAIN、SERVFAIL、FormErr などの DNS 解決の異常。

    推奨プラクティス:

    • CoreDNS 監視

      • Managed Service for Prometheus ユーザーの場合: ACK クラスタの組み込み CoreDNS 監視ダッシュボードを使用します。

      • 自己管理型 Prometheus ユーザーの場合: コミュニティ CoreDNS 監視方法を使用してメトリック収集を構成します。

    • コンテナサービスアラート管理を有効にし、次のようなアラートルールセットをサブスクライブします。

      • CoreDNS 構成の再読み込みの失敗やその他の CoreDNS ステータスの異常アラートなど、[ネットワーク例外のアラートルールセット]。

      • CoreDNS ポッドのステータスとリソースの問題を網羅する [ポッド例外のアラートルールセット]。

    • CoreDNS 解決の遅延や高リスクドメインリクエストなどの問題を解決するには、「CoreDNS ログを分析する」をご参照ください。

    Ingress

    顧客向けトラフィックルーティングに Ingress を使用する場合は、Ingress を介してトラフィック量と呼び出しの詳細を監視し、異常な Ingress ルーティング状態のアラートを設定します。

    推奨プラクティス:

    • 監視

    • トレース

      ACK の Ingress トレース機能を有効にして、NGINX Ingress コントローラーテレメトリを Managed Service for OpenTelemetry に報告します。これにより、トラブルシューティングのためにトレースデータのリアルタイム集約、トポロジーマッピング、永続ストレージが可能になります。たとえば、Albconfig を介して Xtrace を有効にしてトレース追跡を行うことで、ALB Ingress トレースデータを観察できます。

    • アラート管理

      コンテナサービスアラート管理機能を有効にし、[ネットワーク例外のアラートルールセット] などのアラートルールセットをサブスクライブして、異常な Ingress ルーティング状態のアラートを受信します。

    基本的なコンテナネットワークトラフィック監視

    ACK クラスタは、ノード kubelet を介して コミュニティ標準コンテナメトリックを公開します。これには、ポッドのインバウンドトラフィックとアウトバウンドトラフィック、異常なネットワークトラフィックの検出、パケットレベルのネットワーク監視など、基本的なネットワークトラフィック監視要件が含まれます。

    ただし、HostNetwork モードで構成されている場合、ポッドはホストのプロセスネットワーク動作を継承するため、基本的なコンテナ監視メトリックではポッドレベルのネットワークトラフィックが正しく反映されません。推奨プラクティス:

    • kubelet メトリックでの Prometheus ベースの監視

      • オプション 1: Managed Service for Prometheus

        ACK は、すぐに使用できる基本的なネットワークトラフィック監視機能を提供します。ポッド監視ダッシュボードで直接表示できます。

      • オプション 2: 自己管理型 Prometheus

    • ECS レベルのネットワーク監視

      ECS コンソールでホスト ECS ネットワークを監視します。

    3. ユーザーアプリケーション

    ACK は、コンテナポッドとアプリケーションログの監視機能を提供して、クラスタにデプロイされたアプリケーションの安定性を確保します。

    コンテナポッド監視

    クラスタにデプロイされたアプリケーションは、ポッドとして実行されます。ポッドのステータスとリソース負荷は、ポッドで実行されているアプリケーションのパフォーマンスに直接影響します。推奨プラクティス:

    • Prometheus ベースのポッドステータスとリソース監視

      • Managed Service for Prometheus または自己管理型 Prometheus を使用して、ACK クラスタによってノード kubelet を介して公開される コミュニティ標準コンテナメトリックを収集します。

      • kube-state-metrics コンポーネント (Managed Service for Prometheus または ACK 提供の コミュニティ prometheus-operator Helm Chart に含まれる) によって公開される Kubernetes オブジェクトのステータスデータと組み合わせて、CPU、メモリ、ストレージ、基本的なコンテナネットワークトラフィックなど、包括的なポッドメトリックを監視します。

      • Managed Service for Prometheus と統合された ACK クラスタは、すぐに使用できるポッド監視ダッシュボードを提供します。

    • ポッドの異常のイベント監視

      • ポッドのステータスが変更されると、イベントがトリガーされます。ポッドが異常状態になった場合は、イベント監視を有効にして異常を追跡します。

      • コンソールの [イベントセンター] ページでリアルタイム監視を表示し、履歴分析のためにイベントを SLS イベントセンターに永続化します (90 日間保持)。

      • ポッドイベント監視ダッシュボードを使用してポッドライフサイクルタイムラインを分析し、異常状態を特定します。

    • ワークロードとポッドのアラートをサブスクライブする

      コンテナサービスアラート管理と イベント監視を有効にした後、[ワークロード例外のアラートルールセット] や [ポッド例外のアラートルールセット] など、ワークロードとコンテナポッドに関連する重要なアラートルールセットをサブスクライブします。詳細については、「Prometheus でアラートルールを構成するためのベストプラクティス」をご参照ください。

    • カスタム Prometheus アラートルールを作成し、リソースアラートをサブスクライブする

      カスタム Prometheus アラートルールを作成することで、さまざまなリソースしきい値や重要なリソースの優先順位など、さまざまなアプリケーション要件に対応します。

    コンテナアプリケーションログ監視

    クラスタ内のアプリケーションは、重要なプロセスを記録する運用ログを生成します。これらのログを監視することで、異常診断と運用ステータスの評価に役立ちます。

    ACK は、トラブルシューティングのために Kubernetes ロギング機能を提供します。ACK クラスタは、非侵入型のログ管理を提供します。ACK クラスタのアプリケーションログを収集し、SLS が提供するさまざまなログ分析機能を使用できます。

    アプリケーションプロセスのきめ細かいメモリ監視

    Kubernetes では、リアルタイムコンテナメモリ使用量 (ポッドメモリ) は Working Set Size (WSS) によって測定されます。これは、Kubernetes スケジューリングメカニズムがポッドメモリリソースを割り当てるための重要なメトリックです。WSS には以下が含まれます。

    • アクティブな OS カーネルメモリコンポーネント (非アクティブ (匿名) を除く)

    • OS レイヤーメモリコンポーネント

    アプリケーションプロセスが特定のメモリコンポーネント (ファイルシステムへの書き込み時に生成される過剰なページキャッシュなど) を使用する場合、本番システムで綿密な監視が必要になる内部メモリの「ブラックホール」の問題が発生する可能性があります。

    image.png

    コンテナ化された環境での異常なメモリ使用パターンは、WorkingSet の肥大化につながる可能性があり、PodOOMKilling インシデントまたはノードレベルのメモリプレッシャーをトリガーし、ポッドのエビクションが発生する可能性があります。たとえば、ログ処理にデフォルトの新しい I/O (NIO) とメモリマップファイル (mmap) 構成を使用する Log4J や Logback などのログフレームワークを使用する Java アプリケーションでは、多くの場合、以下が発生します。

    • 大量のログを処理する際の頻繁な読み取り/書き込み操作による匿名メモリの急増

    • 高ログスループットシナリオでのメモリの割り当てブラックホール

    コンテナエンジンレイヤーの不透明性によって引き起こされるトラブルシューティングの課題に対処するために、ACK は SysOM に基づくカーネルレベルのコンテナ監視を提供して、SysOM を介してコンテナメモリの問題を観察および解決します。

    アプリケーションメトリックを Prometheus 監視と統合し、カスタムダッシュボードを作成する

    アプリケーション開発機能がある場合は、Prometheus クライアントを使用して、イベントトラッキングを通じてビジネス固有のメトリックを公開することをお勧めします。これらのメトリックは、Prometheus 監視システムを介して収集および可視化して、統合ダッシュボードを作成できます。さまざまなチーム (インフラストラクチャやアプリケーションなど) 向けにカスタマイズされたダッシュボードを作成して、日々の運用監視をサポートし、迅速なインシデント対応シナリオを可能にし、平均復旧時間 (MTTR) を効果的に短縮できます。

    APM とトレース機能を有効にする

    アプリケーションパフォーマンス監視 (APM) は、アプリケーションプロセスのパフォーマンスを監視するための一般的なソリューションです。Alibaba Cloud ARMS は、複数の APM プロダクト機能を提供します。開発言語に基づいて適切な監視方法を選択してください。

    • Java アプリケーションの APM 監視 (非侵入型)

      • 機能: アプリケーショントポロジーを自動的に検出し、3D 依存関係マップを生成し、インターフェース/JVM リソースを監視し、例外/低速トランザクションをキャプチャします。

      • 実装: コードを変更せずに Java アプリケーションを統合する方法については、「Java アプリケーション監視」をご参照ください。

    • Python アプリケーションの APM 監視 (侵入型/コードインストルメント)

      • 範囲: Django/Flask/FastAPI フレームワークを使用する Web アプリケーション、および LlamaIndex/Langchain に基づいて開発された AI/LLM アプリケーション

      • 機能: トポロジーマッピング、トレース分析、API 診断、異常検出、LLM 相互作用追跡などのアプリケーションパフォーマンス監視。

      • 実装: ack-onepilot コンポーネントをインストールし、Dockerfile を調整して Python アプリケーションパフォーマンス監視を実装します。

    • Go アプリケーションの APM 監視 (侵入型/バイナリインストルメント)

      • 機能: アプリケーショントポロジー、データベースクエリ分析、API 呼び出しなどの監視データが ARMS で提供されます。

      • 実装: ack-onepilot コンポーネントをインストールし、コンテナイメージのビルド中に instgo を使用してアプリケーションの Go バイナリファイルをコンパイルします。詳細については、「Go アプリケーション監視」をご参照ください。

    • OpenTelemetry ベースのイベントトラッキング (侵入型)

      • 機能: 分散アプリケーションアーキテクチャのボトルネック識別とマイクロサービスの診断改善のためのエンドツーエンドの分散トレーシング、リクエスト分析、チェーントポロジー、依存関係分析を提供します。

      • 実装: Managed Service for OpenTelemetry は、複数のデータ統合方法を提供します。開発言語とソリューションの安定性/成熟度に基づいて、アプリケーションに適した統合方法を選択するには、「統合ガイド」をご参照ください。

    フロントエンド Web 動作監視

    システムがクラスタ内の外部ユーザーに Web インターフェースを公開する場合、フロントエンドページの安定性と継続性を確実に保証する必要があります。ARMS が提供する リアルユーザー監視 (RUM) 機能は、Web、モバイルアプリ、プログラムにわたるパフォーマンスの可観測性を専門としており、以下によってユーザーエクスペリエンスに重点を置いています。

    • ユーザーインタラクションフローの完全な再構築

    • ページ読み込み速度や API リクエストトレースなどのパフォーマンスメトリック

    • JavaScript エラーやネットワーク障害などの障害分析

    • JavaScript の読み込みエラーやクラッシュ/アプリケーションが応答しない (ANR) エラーなどの安定性監視

    • 根本原因の診断を加速するためのログの関連付け

    詳細については、「アプリケーションを統合する」をご参照ください。

    Service Mesh を介したサービス動作の可観測性

    Alibaba Cloud Service Mesh (ASM) は、オープンソース Istio サービスメッシュと互換性のあるフルマネージドサービスメッシュプラットフォームを提供します。サービス呼び出しでのトラフィックルーティングと分割の管理、認証によるサービス間通信の保護、メッシュ可観測性機能の提供により、サービスガバナンスを簡素化し、開発と O&M のワークロードを大幅に削減します。

    多段階の安定性保証

    ASM の強化された可観測性フレームワークは、以下に詳述するように、ライフサイクル全体の安定性監視をサポートしています。

    1. Day 0 (計画フェーズ)

      システムリリース時のトラフィック構成状態を検証します。

    2. Day 1 (デプロイメントと構成フェーズ)

      マイクロサービス全体のリアルタイムトラフィック分散を監視します。

    3. Day 2 (メンテナンスと最適化フェーズ)

      SLO メトリックに基づいて安定性を確保します。

    可観測性の実装パス

    ASM は、統合されたテレメトリパイプライン構成モデルを提供する、標準化された統合 Service Mesh 可観測性機能を提供し、クラウドネイティブアプリケーションの可観測性サポートを強化します。

    • コントロールプレーントラフィックルーティング監視

    • データプレーンの可観測性

    • マイクロサービスネットワークトポロジー

      データプレーン Prometheus 監視メトリックをデータソースとして、Mesh Topology を介して、マイクロサービス間のトラフィックとレイテンシが期待どおりであるかどうかを可視化および評価します。

    • エラー率とレイテンシパターンの SLO 測定

      SLO は、マイクロサービスのパフォーマンスを記述し、アプリケーションの信頼性を評価し、サービスの状態を継続的に追跡するための定量化された監視メトリックを定義します。これは、サービス品質の評価と継続的な最適化のための測定可能なベンチマークとして機能します。

    • 分散トレーシング

      • 機能: エンドツーエンドの分散トレーシング、リクエスト分析、チェーントポロジー、アプリケーション依存関係分析を提供します。

      • 実装: OpenTelemetry を使用してアプリケーションコードをインストルメントし、ASM で分散トレーシングを有効にします。

    マルチクラウド環境とハイブリッドクラウド環境の統合観測

    Distributed Cloud Container Platform for Kubernetes (ACK One) は、ハイブリッドクラウド、マルチクラスタ管理、分散コンピューティング、ディザスタリカバリなどのシナリオ向けに Alibaba Cloud によって開発されたエンタープライズレベルのクラウドネイティブプラットフォームです。以下が可能になります。

    • クロスインフラストラクチャ管理: リージョンやインフラストラクチャに関係なく、Kubernetes クラスタを接続および管理します。

    • 一貫したガバナンス: コンピューティング、ネットワーク、ストレージ、セキュリティ、監視、ロギング、ジョブ、アプリケーション、トラフィックの統合運用。

    • API 互換性: シームレスな統合のためのコミュニティに準拠した API。

    コアシナリオは次のとおりです。

    • ハイブリッドクラウド: ACK One 登録済みクラスタを使用して、オンプレミスデータセンターの自己管理型 Kubernetes クラスタをクラウドに登録してハイブリッドクラウドを実現し、クラウドベースのコンピューティングリソースの弾力的なスケーリングを可能にします。

    • マルチクラウド: ACK One のフリートインスタンスを使用して、複数の ACK クラスタまたは登録済みクラスタを管理し、マルチクラウド ゾーンディザスタリカバリ、統合アプリケーション構成分散、マルチクラスタオフラインスケジューリングを実装します。

    一般的なマルチクラウドシナリオとハイブリッドクラウドシナリオでは、次の可観測性機能をお勧めします。

    • ACK One 登録済みクラスタの可観測性統合

      ACK One 登録済みクラスタは、SLS、イベントセンター、アラート、ARMS、Managed Service for Prometheus の統合など、ACK と一貫した可観測性を提供します。

      説明

      この機能は、異種ネットワーク環境と権限システムのため、追加のネットワーク構成と承認が必要です。

    • ACK One フリートグローバル監視

      企業が規模を拡大するにつれて、分離、高可用性、ディザスタリカバリなどの要件を満たすために複数の Kubernetes クラスタが必要になります。従来の監視システムは、多くの場合、マルチクラスタの可視性が不足しており、運用の盲点が生じます。ACK One フリートはグローバル監視を提供します。

      • 統合メトリック集約

        グローバル集約インスタンスを介して、複数のクラスタからの Prometheus メトリックを統合監視ダッシュボードに収集します。

      • 運用と診断の効率:

        • クラスタ間の相関分析を実行します。

        • クラスタ間の手動メトリック比較を排除します。

        • 監視システム間のコンテキスト切り替えを削減します。

      ACK One フリートインスタンスが作成され、2 つのクラスタに関連付けられた後、グローバル監視を有効にできます。

    • 統合アラート管理

    • GitOps 可観測性

    Argo Workflows でアプリケーションを監視する

    Argo Workflows は、バッチデータ処理、機械学習パイプライン、インフラストラクチャの自動化、継続的インテグレーションと継続的デリバリー (CI/CD) などのシナリオで広く使用されている堅牢なクラウドネイティブワークフローエンジンです。ACK で Argo Workflows を介してアプリケーションをデプロイする場合、または 分散 Argo ワークフローに Kubernetes クラスタを使用する場合、次の可観測性機能を有効にすることは、安定性と保守性にとって重要です。

    • SLS を使用したログの永続化

      • 課題:

        • ネイティブ Kubernetes ガベージコレクションは、リソースクリーンアップ後にポッド/ワークフローログを消去します。

        • 適切な再利用ポリシーがないと、コントロールプレーンとワークフローコントローラーのリソースが直線的に増加します。

      • ソリューション:

        ワークフロークラスタと SLS を統合して、ワークフローの実行中にポッドによって生成されたログを収集し、SLS プロジェクトに報告します。Argo CLI または Argo UI を介してワークフローログを表示できます。

    • Prometheus 監視

      ワークフローの実行ステータスやクラスタの状態など、包括的な可観測性機能を実現するために、ワークフロークラスタで Managed Service for Prometheus を有効にします。

    Knative ベースのアプリケーションの可観測性

    Knative は、Kubernetes ベースのサーバーレスフレームワークです。以下を提供します。

    • リクエスト駆動型自動スケーリング (スケールツージーロを含む)

    • カナリアロールアウトによるバージョン管理

    コミュニティ Knative および Kubernetes API との完全な互換性に基づいて構築された ACK Knative は、インスタンスを保持することでコールドスタートレイテンシを削減し、Advanced Horizontal Pod Autoscaler (AHPA) に基づいてワークロード予測を実装するなど、複数のディメンションで強化された機能を提供します。詳細については、「Knative 可観測性」をご参照ください。

    実装

    • Knative サービスのログ収集

      ACK クラスタは SLS と互換性があり、非侵入型のログ収集をサポートしています。DaemonSet を介して Knative でログ収集を実装して、各ノードでログエージェントを自動的に実行し、運用効率を向上させます。

    • Prometheus 監視の統合

      Knative にアプリケーションをデプロイした後、Knative Service 監視データを Prometheus と統合します。その後、Grafana ダッシュボードでリアルタイム Knative データを表示できます。これには、ポッドスケーリングトレンド、応答レイテンシ、リクエスト同時実行性、CPU/メモリリソース使用率が含まれます。