Kubernetes クラスターを専門的に監視するにはどうすればよいでしょうか?

導入

Kubernetes が実稼働環境でますます普及し複雑になるにつれて、安定性を確保するための課題も増加しています。

包括的かつ詳細な可観測性アーキテクチャとシステムを構築する方法は、システムの安定性を向上させる重要な要素の 1 つです。 ACK は、可観測性のベストプラクティスを統合し、Alibaba Cloud 製品機能を通じてユーザーに提供します。可観測性ツールとサービスがインフラストラクチャとなり、ユーザーが製品機能を使用できるように支援し、ユーザーの Kubernetes クラスターの安定性とユーザー エクスペリエンスを向上させます。

この記事では、Kubernetes 可観測性システムの構築と、Alibaba Cloud 製品をベースにした Kubernetes 可観測性システムを実装するためのベストプラクティスを紹介します。

Kubernetesシステムの可観測性アーキテクチャ

Kubernetes システムの可観測性の課題は次のとおりです。

K8s システム アーキテクチャの複雑さ。システムにはコントロール プレーンとデータ プレーンが含まれており、それぞれに相互に通信する複数のコンポーネントが含まれています。コントロール プレーンとデータ プレーンは、kube-apiserver を介してブリッジされ、集約されます。
ダイナミックさ。 Pod、Service、およびその他のリソースは動的に作成され、IP が割り当てられます。 Pod が再構築された後には、新しいリソースと IP も割り当てられます。これには、動的サービス検出に基づいて監視オブジェクトを取得する必要があります。
マイクロサービス アーキテクチャ。アプリケーションはマイクロサービス アーキテクチャに従って複数のコンポーネントに分解され、各コンポーネントのレプリカの数は弾力性に基づいて自動または手動で制御できます。
特にクラスターの規模が急速に拡大している場合の Kubernetes システムの可観測性の課題に対応するには、効率的で信頼性の高い Kubernetes システムの可観測性がシステムの安定性保証の基盤となります。

では、本番環境で Kubernetes システムの可観測性を向上させるにはどうすればよいでしょうか?

Kubernetes システムの可観測性ソリューションには、インジケーター、ログ、リンク トレース、K8s イベント イベント、NPD フレームワーク、その他の方法が含まれます。それぞれの方法では、Kubernetes システムの状態とデータについて異なる視点を提供できます。実稼働環境では、通常は複数の方法を組み合わせて使用​​する必要があり、場合によっては複数の方法を使用して観測をリンクし、完全で 3 次元の可観測性システムを形成し、さまざまなシナリオのカバレッジを改善して、Kubernetes システム全体の安定性を向上させる必要があります。以下は、本番環境における K8s システムの可観測性ソリューションの概要です。

メトリクス

Prometheus は、指標データ収集ソリューションの業界デファクト スタンダードです。これは、Google の Borgmon 監視システムにヒントを得たオープンソースのシステム監視およびアラーム フレームワークです。 Prometheus は、2012 年に SoundCloud の元 Google 社員によって作成され、コミュニティ オープン ソース プロジェクトとして開発されました。 2015年にプロジェクトが正式に開始されました。 2016 年、Prometheus は CNCF Cloud Native Computing Foundation に参加しました。

Prometheus には次の機能があります。

多次元データモデル（時系列に基づくキーと値のペア）
柔軟なクエリと集計言語 PromQL
ローカルストレージと分散ストレージを提供します。 HTTP ベースのプル モデルを通じて時系列データを収集します。プッシュ モードは、Pushgateway (Prometheus のオプションのミドルウェア) を使用して実装できます。ターゲット マシンは、動的サービス検出または静的構成を通じて検出できます。さまざまなグラフとデータ ダッシュボードをサポートします。
Prometheus は、/metrics HTTP(s) エンドポイントの下のコンポーネントによって公開されるインジケーター データを定期的に収集し、TSDB に保存して、PromQL ベースのクエリおよび集計機能を実装できます。

Kubernetes シナリオのインジケーターは、次の観点から分類できます。

コンテナの基本リソースインジケーター

収集ソースは kubelet に組み込まれた cAdvisor で、コンテナ メモリ、CPU、ネットワーク、ファイル システムなどに関連するインジケーターを提供します。インジケーターのサンプルには次のものがあります。

コンテナの現在のメモリ使用量バイト: container_memory_usage_bytes;

コンテナ ネットワーク受信バイト数: container_network_receive_bytes_total;

コンテナ ネットワークによって送信されたバイト数: container_network_transmit_bytes_total など。

Kubernetes ノード リソース メトリック

収集ソースは node_exporter であり、ノード システムとハードウェアに関連するインジケーターを提供します。インジケーターの例には、ノード合計メモリ node_memory_MemTotal_bytes、ノード ファイル システム領域 node_filesystem_size_bytes、ノード ネットワーク インターフェイス ID node_network_iface_id などがあります。このタイプのインジケーターに基づいて、ノードの CPU/メモリ/ディスク使用量などのノードレベルのインジケーターをカウントできます。

Kubernetes リソース メトリック

収集ソースは kube-state-metrics で、Kubernetes API オブジェクトに基づいてインジケーターを生成し、Node、ConfigMap、Deployment、DaemonSet などの K8s クラスター リソース インジケーターを提供します。ノード タイプ インジケーターを例にとると、ノードの準備完了ステータス インジケーター kube_node_status_condition、ノード情報 kube_node_info などが含まれます。

Kubernetes コンポーネント メトリクス

Kubernetes システム コンポーネント メトリック。たとえば、kube-controller-manager、kube-apiserver、kube-scheduler、kubelet、kube-proxy、coredns などです。

Kubernetes 運用コンポーネント メトリック。監視可能なクラスには、ユーザー定義の検出ルールの定義を実装する blackbox_operator が含まれます。 gpu_exporter は、GPU リソースをエクスポートする機能を実装します。

Kubernetes ビジネス アプリケーション メトリック。外部クエリと集計のために、/metrics パス内の特定のビジネス ポッドによって公開されるメトリックが含まれます。

上記の指標に加えて、K8s は、リソース メトリック、カスタム メトリック、外部メトリックの 3 つのカテゴリを含む、API を通じて外部に指標を公開するための監視インターフェース標準を提供します。

Resource Metricsクラスは、インターフェース metrics.k8s.io に対応します。主な実装は、リソース監視を提供する metrics-server です。より一般的なものは、ノード レベル、ポッド レベル、名前空間レベルです。これらのメトリックには、kubectl top から直接アクセスすることも、HPA (Horizo​​ntal Pod Autoscaler) などの K8s コントローラーを介してアクセスすることもできます。システムアーキテクチャとアクセスリンクは次のとおりです。

Custom Metricsに対応するAPIはcustom.metrics.k8s.ioで、主な実装はPrometheusです。リソース監視とカスタム監視を提供します。リソース監視と上記のリソース監視は実際には重複しており、このカスタム監視とは、たとえば、アプリケーションがオンライン ユーザーの数のようなものを公開したり、背後のデータベースで MySQL の遅いクエリを呼び出したりしたい場合などです。これらは実際にはアプリケーション層で定義でき、対応するメトリックは標準の Prometheus クライアントを通じて公開され、Prometheus によって収集されます。

このタイプのインターフェースが収集されると、custom.metrics.k8s.io などの標準インターフェースを通じてデータを使用できるようになります。つまり、このように Prometheus を接続すると、custom.metrics.k8s.io インターフェースを使用して HPA を実行し、データを消費することができます。システムアーキテクチャとアクセスリンクは次のとおりです。

外部メトリック。 K8s がクラウド ネイティブ インターフェースの実装標準になったことがわかっているからです。多くの場合、私たちはクラウド上でクラウド サービスを扱います。たとえば、アプリケーションでは、最初に使用されるのはメッセージ キューであり、2 番目に使用されるのは RBS データベースです。場合によっては、データを消費するときに、メッセージ キュー内のメッセージ数、アクセス層 SLB の接続数、SLB の上位層での 200 リクエストの数など、クラウド製品の監視指標も消費する必要があります。

では、どのように消費するのでしょうか? K8s にも標準が実装されており、それは external.metrics.k8s.io です。主な実装ベンダーは各クラウドベンダーのプロバイダーであり、これを通じてクラウド リソースの監視指標を取得できます。 Alibaba Cloud は、この標準 external.metrics.k8s.io の実装を提供するために、Alibaba Cloud メトリック アダプターも実装しています。

ログ記録

要約すると、次の内容が含まれます。

ホストカーネルのログ。ホスト カーネル ログは、ネットワーク スタックの異常、ドライバーの異常、ファイル システムの異常、ノード (カーネル) の安定性に影響する異常などの診断を開発者が行うのに役立ちます。
ランタイムログ。最も一般的なランタイムは Docker であり、Docker ログを使用して Pod Hang の削除などの問題をトラブルシューティングできます。
K8s コンポーネント ログ。 APIServer ログは監査に使用でき、Scheduler ログはスケジュールの診断に使用でき、etcd ログはストレージ ステータスの表示に使用でき、Ingress ログはアクセス レイヤー トラフィックの分析に使用できます。
アプリケーション ログ。アプリケーション ログ分析を通じて、ビジネス レイヤーの状態を表示し、異常を診断できます。
ログ収集は、パッシブ収集とアクティブプッシュの 2 つの方法に分かれています。 K8s では、パッシブコレクションは一般的に Sidecar と DaemonSet に分けられます。アクティブ プッシュには、DockerEngine プッシュとビジネス直接書き込みが含まれます。

DockerEngine 自体に LogDriver 機能があります。さまざまな LogDriver を構成することで、コンテナの stdout を DockerEngine を介してリモート ストレージに書き込むことができ、ログ収集の目的を達成できます。このアプローチはカスタマイズ性、柔軟性、リソースの分離性が低いため、通常、運用環境での使用は推奨されません。
ビジネスダイレクトライティングとは、ログ収集 SDK をアプリケーションに統合し、SDK を通じてログをサーバーに直接送信することです。この方法では、ディスク収集ロジックが不要になり、追加のエージェントの展開も必要ありません。システム リソースの消費は最小限ですが、ビジネスとログ SDK 間の結合が強いため、全体的な柔軟性は非常に低くなります。通常、ログが大量にあるシナリオでのみ使用されます。
DaemonSet メソッドは、各ノードで 1 つのログ エージェントのみを実行して、そのノード上のすべてのログを収集します。 DaemonSet はリソースをはるかに少なく占有しますが、スケーラビリティとテナントの分離には制限があります。単一の機能を持つクラスターや、ビジネスがあまり多くないクラスターに適しています。
サイドカー方式では、各 POD に個別のログ エージェントがデプロイされます。このエージェントは、1 つのビジネス アプリケーションのログ収集のみを担当します。 Sidecar は比較的多くのリソースを消費しますが、柔軟性とマルチテナント分離性が優れています。大規模な K8s クラスターや、PaaS プラットフォームとして複数のビジネス パーティにサービスを提供するクラスターに推奨されます。
ホスト コレクション、標準入出力コレクション、およびサイドカー コレクションをマウントします。

総括する：

DockerEngine の直接書き込みは一般的には推奨されません。
ログが大量にあるシナリオでは、ビジネス直接書き込みが推奨されます。
DaemonSet は通常、小規模から中規模のクラスターで使用されます。
Sidecar は、非常に大規模なクラスターで使用することをお勧めします。

イベント

イベント モニタリングは、Kubernetes シナリオに適したモニタリング方法です。イベントには、時間、コンポーネント、レベル (正常、警告)、タイプ、詳細情報が含まれます。イベントを通じて、デプロイメント、スケジュール、操作、停止など、アプリケーションのライフサイクル全体を把握できます。イベントを使用して、システム内で発生する例外を把握することもできます。

K8s の設計概念の 1 つは、ステート マシンに基づく状態遷移です。正常状態が別の正常状態に変換されると正常イベントが発生し、正常状態が異常状態に変換されると警告イベントが発生します。通常、私たちは警告イベントについてより懸念します。イベント監視は、データセンターに正常イベントまたは警告イベントを集約し、データセンターの分析とアラームを通じて、DingTalk、SMS、電子メールなどの方法を通じていくつかの対応する異常を明らかにし、他の監視を補完および改善します。

Kubernetes のイベントは etcd に保存され、デフォルトでは 1 時間のみ保存されるため、より長い期間にわたる分析を実行することはできません。イベントの長期保存とカスタマイズされた開発により、より多様な分析とアラートを実現できます。

システム内の異常なイベント (Failed、Evicted、FailedMount、FailedScheduling など) に対してリアルタイム アラートを提供します。
多くの場合、トラブルシューティングでは履歴データの検索が必要になるため、より長い期間 (数日または数か月) にわたってイベントをクエリする必要があります。
イベントは、統計指標に基づいて判断や意思決定を行えるように、イベント発生の傾向を計算し、前の期間（昨日/先週/リリース前）と比較するなど、分類統計をサポートします。
さまざまな次元に応じてフィルタリングおよびスクリーニングを行うために、さまざまな担当者をサポートします。
カスタマイズされた監視のためにこれらのイベントへのカスタマイズされたサブスクリプションをサポートし、企業の内部展開および運用プラットフォームと統合します。

NPD (ノード問題検出) フレームワーク

Kubernetes クラスターと実行中のコンテナの安定性は、ノードの安定性に大きく依存します。 Kubernetes の関連コンポーネントは、コンテナ管理に関連する問題にのみ焦点を当てており、ハードウェア、オペレーティング システム、コンテナ ランタイム、および依存システム (ネットワーク、ストレージなど) の検出機能は提供していません。 NPD (Node Problem Detector) は、ノードの安定性を診断するための検査フレームワークを提供します。デフォルトの検査戦略をベースに、柔軟に検査戦略を拡張できます。ノードの異常はノード イベントに変換され、APIServer にプッシュされ、同じ APIServer によって管理されます。

NPD は次のようなさまざまな例外チェックをサポートしています。

基本的なサービスの問題: NTP サービスが開始されていません ハードウェアの問題: CPU、メモリ、ディスク、ネットワーク カードが破損しています
カーネルの問題: カーネルのハング、ファイル システムの損傷、コンテナー ランタイムの問題: Docker がハング、Docker が起動できない、リソースの問題: OOM など。

要約すると、このセクションでは、一般的な Kubernetes 可観測性ソリューションについてまとめます。実稼働環境では、通常、さまざまなソリューションを組み合わせて使用​​し、3 次元、多次元、相互に補完的な可観測性システムを形成する必要があります。可観測性ソリューションを導入した後は、上記ソリューションの出力結果に基づいて異常やエラーを迅速に診断し、誤報率を効果的に低減し、履歴データを保存、確認、分析する機能が必要です。さらに拡張すると、データを機械学習や AI フレームワークに提供して、弾力的な予測、異常の診断と分析、インテリジェントな運用と保守の AIOps などの高度なアプリケーション シナリオを実現できます。

これには、前述のさまざまな可観測性ソリューション アーキテクチャをプラグイン方式で設計、展開、構成、アップグレードする方法、出力結果に基づいて原因を迅速かつ正確に診断および分析する方法など、可観測性のベスト プラクティスが基盤として必要です。 Alibaba Cloud Container Service ACK および関連するクラウド製品 (監視サービス ARMS、ログサービス SLS など) は、製品機能を通じてクラウドベンダーのベストプラクティスを実装し、ユーザーに力を与え、ユーザーが Alibaba Cloud の可観測性ソリューションを迅速に導入、構成、アップグレード、習得できるようにする完全かつ包括的なソリューションを提供し、企業のクラウド移行とクラウドネイティブ化の効率と安定性を大幅に向上させ、技術的な障壁と全体的なコストを削減します。

以下では、ACK の最新製品である ACK Pro を例に、関連するクラウド製品と組み合わせて、ACK の可観測性ソリューションとベスト プラクティスを紹介します。

ACK 観測機能

メトリクス観測ソリューション

インジケーターベースの可観測性については、ACK はオープンソースの Prometheus モニタリングと Alibaba Cloud Prometheus モニタリング (Alibaba Cloud Prometheus モニタリングは ARMS のサブ製品です) という 2 つの可観測性ソリューションをサポートできます。

オープンソースの Prometheus モニタリングは、helm パッケージの形式で提供され、Alibaba Cloud 環境に適応し、DingTalk アラーム、ストレージなどの機能と統合されています。デプロイメント エントリは、コンソールのアプリケーション ディレクトリ内の ack-prometheus-operator です。ユーザー設定後、ACK コンソールでワンクリックで展開できます。ユーザーは、Alibaba Cloud ACK コンソールで helm パッケージ パラメータを設定するだけで、デプロイメントをカスタマイズできます。

Alibaba Cloud Prometheus モニタリングは、ARMS のサブ製品です。アプリケーション リアルタイム モニタリング サービス (ARMS) は、フロントエンド モニタリング、アプリケーション モニタリング、および Prometheus モニタリングの 3 つのサブ製品を含むアプリケーション パフォーマンス管理製品です。

2021年のガートナー社のAPMマジッククアドラント評価では、Alibaba Cloud APMの中核製品であるAlibaba Cloud Application Real-Time Monitoring Service（ARMS）が、Cloud Monitoring and Log Serviceとともに評価されました。 Gartner による Alibaba Cloud APM の評価:

中国で最も強い影響力: Alibaba Cloud は中国最大のクラウド サービス プロバイダーであり、Alibaba Cloud ユーザーはクラウド監視ツールを使用して監視ニーズを満たすことができます。
オープンソースの統合: Alibaba Cloud は、オープンソースの標準と製品 (Prometheus など) をプラットフォームに統合することを非常に重視しています。
コスト上の利点: Alibaba Cloud でサードパーティの APM 製品を使用する場合と比較して、Alibaba Cloud APM 製品はコスト効率に優れています。
次の図は、オープンソースの Prometheus と Alibaba Cloud Prometheus のモジュール区分とデータリンクを簡単に比較したものです。

ACK は、CoreDNS、クラスター ノード、クラスターの概要などの K8s の可観測性機能をサポートします。さらに、ACK Pro は、マネージド管理および制御コンポーネントである Kube API Server、Kube Scheduler、Etcd の可観測性機能もサポートしており、継続的に進化しています。ユーザーは、Alibaba Cloud Prometheus の豊富な監視ダッシュボードとアラーム機能を組み合わせて使用​​することで、K8s クラスター内のシステムの問題や潜在的なリスクを迅速に発見し、クラスターの安定性を確保するためにタイムリーに対応する対策を講じることができます。監視ダッシュボードには ACK のベスト プラクティスが統合されており、ユーザーが複数の側面から問題を分析して特定するのに役立ちます。以下では、ベスト プラクティスに基づいて可観測性ダッシュボードを設計する方法について説明し、監視ダッシュボードを使用して問題を特定する具体的なケースをリストして、可観測性機能の使用方法を理解しやすくします。

まず、ACK Pro の可観測性機能を見てみましょう。市場を監視するための入口は次のとおりです。

APIServer は K8s のコア コンポーネントの 1 つであり、K8s コンポーネントが相互作用するためのハブです。 ACK Pro APIServer の監視ダッシュボードの設計により、ユーザーは監視する必要がある APIServer Pod を選択して、単一の指標、集計指標、リクエスト ソースなどを分析できます。同時に、1 つ以上の API リソースにドリルダウンして、APIServer の指標を連動して観察できます。これの利点は、すべての APIServer Pod のグローバル ビューをグローバルに監視でき、ドリルダウンして特定の APIServer Pod と特定の API リソースの監視を監視できることです。全体的および局所的な観察機能は、問題を特定するのに非常に効果的です。したがって、ACK のベスト プラクティスに従って、実装には次の 5 つのモジュールが含まれます。

APIServer Pod、API リソース (Pod、ノード、ConfigMap など)、分位数 (0.99、0.9、0.5)、および統計時間間隔のフィルター ボックスを提供します。ユーザーはフィルター ボックスを制御して監視ダッシュボードをリンクおよび制御し、リンクを実現して主要な指標を強調表示し、システムの主要なステータスを識別できます。 APIServer RT や QPS などの単一指標の監視ダッシュボードを表示し、単一次元指標の観測と表示を実現します。 APIServer RT や QPS などの集約された指標の監視ダッシュボードを監視し、多次元指標の観察と表示を実現します。 APIServer へのクライアント アクセスのソースを分析して、アクセス ソースの分析を実現します。以下はモジュールの実装の概要です。

主要な指標

APIServer の合計 QPS、読み取り要求の成功率、書き込み要求の成功率、読み取りインフライト要求、変更インフライト要求、およびドロップされた要求率 (単位時間あたりのドロップされた要求の数) を含むコア指標が表示されます。

これらのインジケーターは、システムの状態が正常かどうかの概要を提供します。たとえば、ドロップされたリクエスト率が NA でない場合は、APIServer の処理能力がリクエストに対応するのに不十分なためリクエストがドロップされていることを意味し、すぐに対処する必要があります。

クラスターレベルの概要

非 LIST 読み取り要求 RT、LIST 読み取り要求 RT、書き込み要求 RT、読み取り要求 Inflight Request、変更要求 Inflight Request、および単位時間あたりの破棄された要求の数を含みます。ディスクのこの部分の実装では、ACK のベスト プラクティス エクスペリエンスが組み合わされています。

応答時間の観測可能性により、さまざまな時点と間隔で、さまざまなリソース、さまざまな操作、さまざまな範囲の応答時間を直感的に観察できます。フィルタリングする異なる分位数を選択できます。さらに重要な検査ポイントが 2 つあります。

曲線は連続していますか?
RT 時間はまず曲線の連続性を説明します。曲線の連続性により、リクエストが連続リクエストなのか単一のリクエストなのかを直感的に確認できます。

次の図は、サンプリング期間中に APIServer が PUT リース要求を受信し、各サンプリング期間中の P90 RT が 45 ミリ秒であることを示しています。

図の曲線は連続しているため、リクエストはすべてのサンプリング期間に存在することを意味し、連続したリクエストです。

次の図は、サンプリング期間中に APIServer が LIST デーモンセットのリクエストを受信することを示しています。サンプル値によるサンプリング期間中、P90 RT は 45 ミリ秒です。

図には 1 回しか発生していないため、リクエストは 1 つのサンプリング サイクルにのみ存在することを意味します。このシナリオは、ユーザーが kubectl get ds --all-namespaces を実行して生成されたリクエスト レコードから発生します。

I0215 23:32:19.226433 1 trace.go:116] Trace[1528486772]: "Create" url:/api/v1/namespaces/default/configmaps、user-agent:kubectl/v1.18.8 (linux/amd64) kubernetes/d2f5a0f、client:39.xx10、request_id:a1724f0b-39f1-40da-b36c-e447933ef37e (開始: 2021-02-15 23:32:09.485986411 +0800 CST m=+114176.845042584) (合計時間: 9.740403082s):Trace[1528486772]: [9.647465583s] [9.647465583s] 期待されるバージョンに変換しようとしていますTrace[1528486772]: [9.660554709s] [13.089126ms] 変換が完了しましたTrace[1528486772]: [9.660561026s] [6.317s] オブジェクトをデータベースに保存しようとしていますTrace[1528486772]: [9.687076754s] [26.515728ms] オブジェクトをデータベースに保存しましたTrace[1528486772]: [9.740403082s] [53.326328ms] ENDI0215 23:32:19.226568 1 httplog.go:102] requestID=a1724f0b-39f1-40da-b36c-e447933ef37e verb=POST URI=/api/v1/namespaces/default/configmaps レイテンシ=9.740961791s resp=201 UserAgent=kubectl/v1.18.8 (linux/amd64) kubernetes/d2f5a0f srcIP="10.xx10:59256" ContentType=application/json:

以下では、RT がリクエストの具体的な内容とクラスターのサイズに直接関係していることを説明します。

上記の configmap 作成の例では、1MB の configmap も作成されました。パブリック ネットワーク リンクはネットワーク帯域幅と遅延の影響を受け、9 秒に達しました。一方、イントラネット リンクのテストでは、わずか 145 ミリ秒しかかかりませんでした。ネットワーク要因の影響は大きいです。

したがって、RT は、要求された操作のリソース オブジェクト、バイト サイズ、ネットワークなどに関連します。ネットワークが遅くなり、バイト サイズが大きくなるほど、RT は大きくなります。

大規模な K8s クラスターの場合、完全な LIST (ポッド、ノード、その他のリソースなど) のデータ量が非常に大きくなることがあり、送信されるデータの量が増加し、RT も増加します。したがって、RT インジケーターには絶対的な健康閾値は存在しません。特定のリクエスト操作、クラスターのサイズ、ネットワーク帯域幅に基づいて総合的に評価する必要があります。業務に影響がなければ問題ありません。

小規模な K8s クラスターの場合、平均 RT は 45 ミリ秒から 100 ミリ秒であれば許容されます。 100 ノードのクラスターの場合、平均 RT は 100 ミリ秒から 200 ミリ秒であれば許容されます。

ただし、RT が引き続き第 2 レベルに達した場合、または RT が 60 秒に達して要求タイムアウトになった場合は、ほとんどの場合例外が発生しており、状況が期待どおりであるかどうかを判断するために、さらに位置決めと処理が必要になります。

これら 2 つのインジケーターは、APIServer /metrics を通じて外部に公開されます。次のコマンドを実行すると、APIServer の同時リクエスト処理能力を測定する指標である実行中のリクエストを表示できます。同時リクエスト数が APIServer パラメータ max-requests-inflight および max-mutating-requests-inflight で指定されたしきい値に達すると、APIServer の現在の制限がトリガーされます。これは通常、すぐに特定して対処する必要がある異常な状況です。

QPS とレイテンシー

このセクションでは、集計分析のために、Verb と API リソース別に分類されたリクエスト QPS と RT を直感的に表示できます。また、読み取りおよび書き込み要求のエラー コード分類も表示できるため、さまざまな時点での要求によって返されるエラー コードの種類を直感的に見つけることができます。

クライアント概要

このセクションでは、クライアントと、要求されている操作およびリソースを視覚的に表示します。

QPS By Client では、クライアントディメンションごとに異なるクライアントの QPS 値をカウントできます。

QPS By Verb + Resource + Client は、クライアント、Verb、およびリソースのディメンションごとに、単位時間 (1 秒) 内のリクエスト分布をカウントできます。

ARMS Prometheus をベースにした ACK Pro は、APIServer ダッシュボードに加えて、Etcd および Kube Scheduler の監視ダッシュボードも提供します。 ACK と ACK Pro は、CoreDNS、K8s クラスター、K8s ノード、Ingress などのダッシュボードも提供します。ここでは一つ一つ紹介することはしません。ユーザーはARMSダッシュボードを確認できます。これらのダッシュボードは、実稼働環境における ACK と ARMS のベスト プラクティスを組み合わせたもので、ユーザーが最短パスでシステムを観察し、問題の根本原因を見つけ、運用と保守の効率を向上させるのに役立ちます。

ログ可観測性ソリューション

SLS Alibaba Cloud Log Service は、さまざまな種類のログ ストレージに接続できる Alibaba Cloud の標準ログ ソリューションです。

管理対象コンポーネントのログについては、ACK は管理対象クラスターのコントロール プレーン コンポーネント (kube-apiserver/kube-controller-manager/kube-scheduler) のログ送信をサポートし、ACK コントロール レイヤーからユーザーの SLS ログ サービスのログ プロジェクトにログを収集します。

ユーザー側のログについては、ユーザーは Alibaba Cloud の logtail および log-pilot 技術ソリューションを使用して、必要なコンテナ、システム、ノードのログを SLS ログストアに収集し、SLS で簡単にログを表示できます。

イベント観測ソリューション + NPD観測ソリューション

Kubernetes のアーキテクチャ設計は、ステートマシンに基づいています。異なる状態間の遷移により、対応するイベントが生成されます。正常状態間の遷移では正常レベルのイベントが生成され、正常状態と異常状態間の遷移では警告レベルのイベントが生成されます。

ACK は、ACK によって管理される NPD (ノード問題検出器) と NPD に含まれる kube-eventer を通じてコン​​テナ イベント監視機能を提供する、すぐに使用できるコンテナ シナリオ イベント監視ソリューションを提供します。

NPD (node-problem-detector) は、Kubernetes ノード診断用のツールです。 Docker エンジンのハング、Linux カーネルのハング、ネットワーク送信異常、ファイル記述子異常などのノード異常をノード イベントに変換できます。 kube-eventer と組み合わせることで、ノード イベント アラームのクローズド ループを実装できます。
kube-eventer は、ACK が管理するオープンソースの Kubernetes イベント オフライン ツールです。 DingTalk、SLS、EventBridge などのシステムにイベントをオフラインでクラスター化し、さまざまなレベルのフィルタリング条件を提供して、リアルタイムのイベント収集、対象を絞ったアラーム、非同期アーカイブを実現します。
NPD は、構成とサードパーティのプラグインに基づいてノードの問題または障害を検出し、対応するクラスター イベントを生成します。 Kubernetes クラスター自体も、クラスターのステータスの切り替えによりさまざまなイベントを生成します。たとえば、Pod の削除、イメージのプルの失敗、その他の異常な状況などです。ログ サービス (SLS) の Kubernetes イベント センターは、Kubernetes 内のすべてのイベントをリアルタイムで集約し、ストレージ、クエリ、分析、視覚化、アラーム機能を提供します。

ACK 可観測性の展望

ACK および関連クラウド製品は、メトリック、ログ、リンク トラッキング、イベントなど、Kubernetes クラスターの包括的な監視機能を実現しています。今後の開発の方向性は次のとおりです。

より多くのアプリケーション シナリオを調査し、アプリケーション シナリオを可観測性と関連付け、ユーザーが K8s をより適切に使用できるように支援します。たとえば、一定期間にわたって Pod 内のコンテナのメモリ/CPU およびその他のリソース レベルを監視し、履歴データを使用してユーザーの Kubernetes コンテナ リソース要求/制限が妥当かどうかを分析し、妥当でない場合は推奨されるコンテナ リソース要求/制限を提供します。クラスター APIServer RT の過剰なリクエストを監視し、異常なリクエストの原因を自動的に分析して、処理の提案を提供します。
K8s イベントやインジケーターのモニタリングなど、複数の可観測性テクノロジー ソリューションをリンクすると、より豊富で多次元的な可観測性が実現します。
ACK オブザーバビリティの今後の開発方向はますます広がり、お客様にますます優れた技術的価値と社会的価値をもたらすと信じています。