Splunk Infrastructure MonitoringでAmazon EKS Distro (EKS-D)を監視する

Splunkは、Amazon Kubernetesの公式ディストリビューションであるAmazon EKS Distro (EKS-D)の提供においてアマゾン ウェブ サービス (AWS)とパートナーを組んでいます。EKS-Dには、Amazon EKSと同じ検証およびテスト済みのセキュアなコンポーネントが含まれます。Splunk Infrastructure Monitoringは、Kubernetesを監視するためのエンタープライズクラスのターンキーソリューションで、Amazon EKSに対応しています。Splunk Infrastructure Monitoringでは、特別な設定をせずにKubernetesコントロールプレーンを監視することもできます。SplunkのEKS-Dのサポートにより、両社のお客様は、クラウドネイティブのAmazon EKSからAmazon Outpostsとのハイブリッド、オンプレミスの自己管理型環境まで、あらゆる環境でKubernetesを確実に運用できます。

コンテナ環境のリアルタイム監視

Kubernetes Navigatorでは、Kubernetesワーカーノードやデプロイされたアプリケーションのパフォーマンスを簡単かつ直感的に把握および管理できます。以前のブログでは、以下の機能を活用することで、DevOpsチームとSREチームがKubernetes環境のパフォーマンスの問題を迅速に検出、トリアージ、解決する方法をご紹介しました。

• ダイナミックなクラスターマップ：Kubernetesクラスターの状況を総合的に表示して健全性を即座に把握できます
• ドリルダウン：詳細をドリルダウンしてトラブルシューティングを短時間かつ効果的に行えます
• コンテキストを維持したログ管理：コンテキストログへのディープリンク機能によって詳細なインサイトを取得し、コンテキストの切り替えをなくして根本原因分析の時間を短縮できます
• Kubernetes Analyzer：AIドリブンの分析でトラブルシューティングを効率良く行えます
   

さらに、自己管理型のEKS-D環境の場合、DevOpsチームは、Kubernetesコントロールプレーンの主要なパフォーマンスメトリクスをリアルタイムで表示し、正確なアラートを受け取る必要があります。

このブログでは、Splunk Infrastructure MonitoringでAmazon EKS-Dのコントロールプレーンを監視する方法について詳しく説明します。  

EKS-Dの内部コンポーネントの監視

Kubernetesクラスターは、コンテナ化したアプリケーションをデプロイする1つ以上のワーカーノードと、それらのワーカーノードを管理するコントロールプレーンで構成されます。コントロールプレーンは、どのPodをどのワーカーノードにデプロイするかなど、スケジューリングに関する決定を行い、クラスターを監視して、Kubernetesクラスターが適切な状態になるように管理します。

Splunkは、コントロールプレーンを構成するコンポーネント、ワーカーノードで実行されるコンポーネント、主要なアドオンなど、Kubernetes内部コンポーネントに関する設定済みのテレメトリを提供します。これらのコンポーネントを監視すれば、Kubernetesクラスターのスケジューリング、オーケストレーション、ネットワークに関する問題を迅速に解決できます。

• コントロールプレーンのコンポーネント：APIサーバー、etcd分散永続ストレージ、スケジューラー、コントローラーマネージャー
• データプレーンのコンポーネント：Kubernetesサービスプロキシ、Kubelet、コンテナランタイム、ネットワークインターフェイス、ストレージインターフェイス
• アドオン：Kubernetes DNSサーバー
   

^{図：Amazon EKS Distro (EKS-D)のコンポーネント}

Kubernetesは分散システムであり、上記のコンポーネントはすべてAPIサーバーのみと通信します。APIサーバーは、デプロイしたアプリケーションのさまざまなライフサイクルイベントを調整します。  Kubernetesは、Kubernetesクラスターの状態を表すKubernetesオブジェクトと呼ばれる永続エンティティで構成されます。Kubernetesオブジェクトには以下のものがあります。

• コンテナ化してクラスターにデプロイしたアプリケーションとその関連ノード
• これらのアプリケーションが利用できるリソース
• アプリケーションの動作に関するポリシー(再起動、アップグレード、フォールトトレランスなど)
• サービス検出のアドオン
   

EKS-Dコントロールプレーンのコンポーネント

APIサーバー 

APIサーバーは、クラスターを操作するためのkubectlや自動化タスクなど、すべてのKubernetesコンポーネントとクライアントの中央ハブとして機能します。HTTP経由のRESTful APIを実装することにより、クラスターを照会および変更するためのCRUD(作成、読み取り、更新、削除)インターフェイスを提供します。CRUDリクエストの検証を行った後、etcd分散ストレージシステムにクラスターの状態を保存し、クライアントが不適切な構成のオブジェクトを保存できないようにします。検証と同時に、認証、認可、排他制御を実行することで、オブジェクトに対して許可された変更が同時に複数行われた場合でも、他のクライアントにオーバーライドされないようにします。APIサーバーでは、これらのタスクを実行するためにさまざまなプラグインが使用されます。

^{図：Kubernetes APIサーバーの健全性とパフォーマンスを表示する設定済みのダッシュボード}

監視対象となる主要メトリクス

クラスターとのやりとりはすべてAPIサーバーを通じて行われるため、APIサーバーの健全性とパフォーマンスを監視することは特に重要です。Splunkでは、メトリクスを自動的に収集し、設定済みのダッシュボードに同時スレッド数、goroutine、RPCレートなどの内部コンポーネントの状態を表示できます。また、登録キューの深さを監視し、キューに追加されたリクエストを追跡して、APIサーバーでリクエストの処理が遅れている場合に通知することもできます。  Splunkでは「4つのゴールデンシグナル」アプローチを取り入れてAPIサーバーの健全性とパフォーマンスを監視できます。

1. リクエスト数：metric apiserver_request_totalを使用して、サービスに対するリクエスト数を、verbs、リソース、成否を示すステータスコードごとに監視できます。
2. レイテンシー：apiserver_request_duration_secondsまたはapiserver_request_duration_seconds_bucketを使用して、操作またはアクションごとに各種サービスでのレイテンシーを追跡できます。
3. サチュレーション：ワークキュー関連のメトリクスは、APIサーバーリソースのサチュレーション状態を示します。workqueue_adds_total、workqueue_deapth、workqueue_queue_duration_secondsはそれぞれ、コントローラーによる新しいアクションの実行スケジュール速度、キューで待機中のアクション数、コントローラーマネージャーでのこれらのタスクの実行速度を表します。
4. エラー数：metric apiserver_request_totalでは、リクエスト数がステータスコードとともに返されます。ステータスコードが400または500の場合、リクエストでエラーが返されことを示します。
    

コントローラーマネージャー

コントローラーマネージャーは、クラスターが適切な状態になるようにコントローラーを運用します。DevOpsチームは、リソース仕様ファイルを通じて「適切な状態」をAPIサーバーに指定します。たとえばノードコントローラーは、クラスター内の各ノードの健全性を監視し、到達不能なノードがあった場合はPodを適切に退避させることによって、ノードリソースを管理します。また、レプリケーションコントローラーは、クラスターで実行されている実際のPod数と必要なPod数の差を調整します。コントローラーマネージャーの健全性は、クラスターのパフォーマンスを示します。

^{図：コントローラーマネージャーのパフォーマンスを表示する設定済みダッシュボード}

監視対象となる主要メトリクス

コントローラーマネージャーのダッシュボードでは、Podのレプリケーションなどのリクエストが処理前に入るワークキューを確認できます。また、リクエスト処理のレイテンシーを監視したり、マネージャーからAPIサーバーへのHTTPリクエスト数を追跡してこれらのコンポーネント間の通信状態を把握したりすることもできます。さらに、コントローラーマネージャーを実行しているコンテナのサチュレーション状態を監視して、CPU、メモリ、ディスクリソースが十分に確保されていることを確認することも重要です。コントローラーマネージャーのパフォーマンスメトリクスの全リストは、こちらのドキュメントで確認できます。

etcd — 分散ストレージ

etcdは、クラスターの状態を永続化するための分散キーバリューストアです。クラスターの状態を保持し、Kubernetesオブジェクトの実行に関する情報を提供します。etcdでは、分散合意アルゴリズムのRaftが使用されます。etcdサービスが利用できなくなった場合、既存のPodの実行は続けられますが、クラスターの状態は変更できなくなります。また、Kubernetes APIサーバーがetcdに再接続すると、不整合が発生します。  

^{図：etcdのパフォーマンスに関するインサイトを表示する設定済みダッシュボード}

監視対象となる主要メトリクス

etcdクラスターリーダーを監視することが重要です。リーダーを実行しているノードに障害が発生した場合、Raftによって新しいノードが選出され、リーダーシップ変更イベントが発生します。一般的に、リーダーシップの変更が頻繁に発生する場合は、構造的な問題を示している可能性があります。また、各種のプロポーザルのレイテンシーを監視して、プロポーザルの失敗(proposals_failed_total)についてアラートを通知することもできます。プロポーザルの失敗は、クラスター全体の問題を示します。さらに、Kubernetesがクラスター内の変更をサブスクライブしてAPIサーバーからの状態リクエストを実行するために使用するウォッチャーの数(etcd_debugging_mvcc_watcher_total)も監視します。

Kubernetesスケジューラー

DevOpsチームは通常、Podを実行するノードを指定しません。ノードの指定はスケジューラーに任され、スケジューラーは、ノードが決まっていない新しいPodにノードを割り当てます。この機能は一見シンプルです。しかし、スケジューラーはノードをランダムに選んでいるわけではありません。高度なアルゴリズムに基づいて、特定のPodを実行するために利用できる最適なノードを判断しています。また、利用可能なすべてのノードのリストを管理し、以下のようなさまざまなチェックを実行します。

• このノードで実行されている他のPodとのノードアフィニティまたは非アフィニティがPodの仕様に指定されているか
• このノードのTaintがPodの仕様に指定されているか
• このノードは、Podのハードウェアリソース要求を満たせるか
• PodにhostPortが必要か、また、このノードでそのポートを利用できるか
• Podに特定のタイプのボリュームが必要か、また、そのボリュームをこのノードのこのPodにマウントできるか
  
  

^{図：Kubernetesスケジューラーのパフォーマンスに関するインサイトを表示する設定済みダッシュボード}

監視対象となる主要メトリクス

設定済みのKubernetesスケジューラーダッシュボードには、スケジューラーに対して行われたクライアントリクエストが、操作のタイプ(verbs)とステータスコードとともに表示されます。200以外のHTTP応答コードが返されたときや、総スケジューリング時間(scheduler_binding_duration_seconds)の値が履歴ベースラインと比べて高い場合(Kubernetesスケジューラーのパフォーマンスに問題があることを示します)に、アラートを通知できます。

CoreDNS

CoreDNSは、柔軟性と拡張性に優れたDNSサーバーであり、Kubernetesクラスターにデプロイされたマイクロサービスベースアプリケーションのサービス検出機能も提供します。CoreDNSは一連のプラグインで構成されます。各プラグインがKubernetesサービスの検出やPrometheusメトリクスなどのDNS機能を実行します。ほとんどのプラグインはPrometheusプラグインを介してテレメトリデータを送信します。カスタムプラグインを作成して、exampleプラグインの説明に従って監視を有効にすることもできます。Splunkスマートエージェントでは、CoreDNSモニターを設定することによってパフォーマンスメトリクスを透過的に収集できます。

^{図：CoreDNSのパフォーマンスメトリクスを表示する設定済みダッシュボード}

監視対象となる主要メトリクス

設定済みのダッシュボードでは、CoreDNSインフラとその機能の健全性を確認できます。DNSリクエストをレコードタイプ(coredns_dns_request_type_count_total)ごとに監視すると、CoreDNSの処理量を把握できます。上の図のように、キャッシュサイズとキャッシュのヒット率を監視し、Corefileを介してConfigMapの有効期間(TTL)値を増やして、レコードをキャッシュに保持する期間を長くすることもできます。エラーを監視するには、リターンコード(rcodes)を追跡します。たとえばNXDomainはDNSリクエストの問題を表し、ドメインが見つからない場合にエラーを通知します。ServFailやRefusedは、DNSサーバー(この場合はCoreDNS)に問題があることを示します。

Amazon EKS Distro (EKS-D)の監視を始めるには

Splunk Infrastructure Monitoringなら、AWSのマネージドKubernetesであるAmazon EKS、オンプレミスやハイブリッドの自己管理型EKS-D環境を含むあらゆる環境で、Kubernetesを包括的に監視できます。

Splunk Infrastructure Monitoringの無料トライアル版を入手して、エンドツーエンドのKubernetes監視をぜひお試しください。