はじめに
皆様、こんにちは！
運用エンジニア（SRE、ITマネージャー、DevOps）であれば、テクノロジーやデータのスプロール(注：都市の急速な発展により、市街地が無秩序、無計画に広がっていくことをいいます。 スプロールが公共施設=インフラストラクチャーの不備などの弊害を伴いながら現れたありさまをスプロール現象といい、このような状況になった地域をスプロール地域といいます）をどのように管理するか、常に頭を悩ませていることでしょう。Kubernetes はますます普及しつつあり、これらのデプロイの大部分は Amazon Elastic Kubernetes Service（EKS）、Google Kubernetes Engine（GKE）、または Azure Kubernetes Service（AKS） であることでしょう。単一のクラウドを利用している人もいれば、複数の Kubernetes クラウドサービス上でクラスタを管理する負担が増える人もいるでしょう。クラウドプロバイダーの複雑さに加えて、より多くの観測可能データと遠隔測定データを生成する何百ものデプロイ済みサービスを管理する必要があります。
Kubernetes クラスタとその上で動作するアプリケーションの状態と健全性を、それらが生成するログ、メトリクス、トレースを通じて理解する日々の運用は、おそらくあなたの最大の課題となるでしょう。しかし、運用エンジニアとして、問題の予防、予測、是正に役立つ重要なデータをすべて必要とします。また、トラブルシューティングやサポートのために Kubernetes のテレメトリデータを可視化し分析する必要がある場合、複数のツールにまたがる大量のメトリクス、ログ、トレースは絶対に必要ではありません。
Elastic Observability は、Kubernetes のメトリックスとログの膨大な量を管理するために、ロギングだけでなく、広範囲で集中的な観測能力を提供します。Elastic Observability は、OpenTelemetry と APM エージェントを通じてすべてのメトリクス、ログ、トレースデータを統合することで、Kubernetes クラスタとその上で動作するアプリケーションの動作に関する詳細な洞察とコンテキストを提供します。
クラスタの場所（EKS、GKE、AKS、自己管理）やアプリケーションに関係なく、Kubernetes のモニタリングは Elastic Observability で簡単に行うことができます。ノード、ポッド、コンテナ、アプリケーション、インフラ（AWS、GCP、Azure）のメトリクス、インフラとアプリケーションのログ、アプリケーションのトレースなど、すべてが Elastic Observability で利用可能です。
このブログでは、次の内容をご紹介します。
• Elastic Cloud は、Elastic Agent（DaemonSetとしてクラスタに簡単にデプロイ可能）を通じてメトリクスやログデータを集約、取り込み、ホストからのログやメトリクス（システムメトリクス、コンテナ統計情報）、Kubernetes 上で動作するすべてのサービスからのログを取得することが可能です。
• Elastic Observability は、Kubernetes クラスタコンポーネント（Pod、ノード、サービス、ネームスペースなど）すべてにおいて、どのように統一された遠隔測定（ログ、メトリクス、トレース）体験をもたらすことができるのでしょうか
図：Kubernetes と統合された Elastic Agent
前提条件と構成
このブログを見て実際にやってみる予定の方には、このデモをセットアップするために使用したコンポーネントと詳細をご紹介します。
• Elastic Cloudのアカウントと、デプロイ済みのスタックがあることを確認します (手順はこちら) 。
• GKE を使用しましたが、Kubernetes クラスタの場所はどこでもかまいません。
• 私たちは、非常に人気のあるHipsterShop デモ・アプリケーションの一部を使用しました。これはもともとGoogleによって書かれたもので、OpenTelemetryデモアプリ のような、多数のバリエーションが利用できるKubernetesを紹介するためのものです。このアプリを使用するには、ここ に行き、指示に従ってデプロイしてください。Kubernetes のメトリクスを流すために otelcollector をデプロイする必要はありません - これについては後述します。
• Elastic は Prometheus や FluentD からのネイティブインジェストをサポートしていますが、このブログでは Elastic Agent を経由して Kubernetes クラスタから直接インジェストする方法を紹介しています。Elastic が Prometheus や FluentD/bit からテレメトリを取り込む方法については、追ってブログで紹介する予定です。
Elasticで何を観察・分析できるのか？
Kubernetes クラスタのメトリクスとログを取り込み、可視化するために Elastic をセットアップする手順を説明する前に、Elastic の便利なダッシュボードを覗いてみましょう。
前述の通り、私たちは GKE 上で HipsterShop の亜種を実行し、Kubernetes を統合した Elastic Agents を GKE クラスタ上のDaemonSet としてデプロイしています。エージェントをデプロイすると、Elastic は Kubernetes クラスタからメトリクスを取り込み始め（具体的にはkube-state-metricsから）、さらに Elastic はクラスタからすべてのログ情報を取り込みます。
Elastic Observability で Kubernetes のメトリクスを可視化する
Elastic Observability ですぐに使えるようになる Kubernetes のダッシュボードをいくつかご紹介します（OOTB）。
Elastic Kubernetes の概要ダッシュボードに HipsterShop のクラスタメトリクスが表示されます。
図：Elastic Observability 上の HipsterShop デフォルトネームスペースポッドダッシュボード
Elastic にはクラスタ概要ダッシュボードや、ポッドダッシュボードに加え、便利な OOTB ダッシュボードがいくつかあります。
• Kubernetes 概要ダッシュボード（上図参照）
• Kubernetes ポッドダッシュボード(上記参照)
• Kubernetes ノードダッシュボード
• Kubernetes デプロイメントダッシュボード
• Kubernetes DaemonSets ダッシュボード
• Kubernetes StatefulSets ダッシュボード
• Kubernetes CronJob & Jobs ダッシュボード
• Kubernetes サービスダッシュボード
• 定期的に追加予定
さらに、これらのダッシュボードをカスタマイズしたり、独自のダッシュボードを構築することも可能です。
Elastic Observability でのログの扱いについて
図：Kubernetes コンテナのログと Elastic Agent のログ
上記の画面からもわかるように、Kubernetes クラスタのメトリクスだけでなく、Kubernetes クラスタで Elastic Agent を使用するだけで、すべての Kubernetes ログを取得することができます。
問題の予防、予測、修正
Elastic はメトリックスやログの管理だけでなく、クラスタのテレメトリ全体における異常の検出や予測もサポートします。データに対して Elastic の機械学習をオンにするだけで、分析作業を強化することができます。以下に示すように、Elastic は Kubernetes クラスタのログとメトリクスのための統一された観測可能な場所であるだけでなく、分析と管理を強化するための広範な真の機械学習機能を提供します。
Elastic Observability 上のログを横断して異常検知を行う。
図：Elastic Observability による Kubernetes ポッド上の問題分析
上のグラフでは、ログ全体で異常検知を行い、9月21日から23日の期間に何か問題がある可能性があることを示しています。下のグラフでは、単一の kubernetes.pod.cpu.usage.node メトリックを分析することで、9 月の初期と月の後半に CPU の問題があることを示し、詳細を掘り下げています。クラスタのテレメトリーについては、マルチメトリック分析（上記で示したシングルメトリックの問題とは異なります）と母集団分析を使って、機械学習でより複雑な分析を行うことができます。
Elastic は、Kubernetes クラスターテレメトリーの分析を強化するために、より優れた機械学習機能を提供します。次のセクションでは、テレメトリーデータを Elastic に取り込むのがいかに簡単かを説明します。
GKE 上にデプロイされた HipsterShop アプリケーションから Elastic にメトリクス、ログ、トレースを取得する方法
詳しく説明します。まず、Hipstershop の好きなバージョンを選びます。上に書いたように、私たちはOpenTelemetry-Demo の変形版を使いましたが、これはすでに OTel があるからです。
しかし、このブログのためにスリム化しました（サービスの数が少なく、言語も多様です）。
ステップ 0：Elastic Cloud のアカウントを取得する
指示に従って、Elastic Cloud の利用を開始 します。
ステップ 1：Kubernetes クラスターを取得し、Kubernetes アプリをクラスターにロードする
選択したクラウドサービスまたはローカルの Kubernetes プラットフォームの Kubernetes クラスター上にアプリを取得します。Kubernetes 上にアプリを立ち上げたら、デフォルトの名前空間上で以下の Pod（またはその亜種） が稼働しているはずです。
NAME READY STATUS RESTARTS AGE
adservice-8694798b7b-jbfxt 1/1 Running 0 4d3h
cartservice-67b598697c-hfsxv 1/1 Running 0 4d3h
checkoutservice-994ddc4c4-p9p2s 1/1 Running 0 4d3h
currencyservice-574f65d7f8-zc4bn 1/1 Running 0 4d3h
emailservice-6db78645b5-ppmdk 1/1 Running 0 4d3h
frontend-5778bfc56d-jjfxg 1/1 Running 0 4d3h
jaeger-686c775fbd-7d45d 1/1 Running 0 4d3h
loadgenerator-c8f76d8db-gvrp7 1/1 Running 0 4d3h
otelcollector-5b87f4f484-4wbwn 1/1 Running 0 4d3h
paymentservice-6888bb469c-nblqj 1/1 Running 0 4d3h
productcatalogservice-66478c4b4-ff5qm 1/1 Running 0 4d3h
recommendationservice-648978746-8bzxc 1/1 Running 0 4d3h
redis-cart-96d48485f-gpgxd 1/1 Running 0 4d3h
shippingservice-67fddb767f-cq97d 1/1 Running 0 4d3h
ステップ 2：kube-state-metrics をオンにする
まずは
git clone https://github.com/kubernetes/kube-state-metrics.git
次に、examples ディレクトリの下にある kube-state-metrics ディレクトリで、標準の config を適用するだけです。
kubectl apply -f ./standard
これでkube-state-metricsがオンになり、kube-system名前空間でこのようなPodが動作しているのが確認できるはずです。
kube-state-metrics-5f9dc77c66-qjprz 1/1 Running 0 4d4h
ステップ3： Kubernetes 統合による Elastic Agent のインストール
Add Kubernetes Integration:
- Elastic の「integrations」から「Kubernetes Integration」を選択し、「Add Kubernetes」を選択します。
- Kubernetes 統合の名前を選択します。
- 設定画面で kube-state-metrics をONにする。
- new-agent-policy-name テキストボックスで、設定に名前をつけます。
- 設定を保存します。これで、ポリシーとの統合が作成されました。
エージェントポリシーと Elastic Agent での使用方法については、こちらをご覧ください。
- Kubernetes 統合を追加します。
- 2で作成したばかりのポリシーを選択します。
- エージェント追加の手順の3つ目で、マニフェストをコピー＆ペーストするかダウンロードします。
- マニフェストを kubectl を実行しているシェルに追加し、elastic-agent-managed-kubernetes.yaml として保存し、以下のコマンドを実行します。
kubectl apply -f elastic-agent-managed-kubernetes.yaml
kube-system ネームスペースの DaemonSet の一部として、いくつかのエージェントが表示されるはずです。
NAME READY STATUS RESTARTS AGE
elastic-agent-qr6hj 1/1 Running 0 4d7h
elastic-agent-sctmz 1/1 Running 0 4d7h
elastic-agent-x6zkw 1/1 Running 0 4d7h
elastic-agent-zc64h 1/1 Running 0 4d7h
私のクラスタでは、4つのノードと4つの elastic-agent が DaemonSet の一部として起動されています。
ステップ 4: Kubernetes メトリクスのための Elastic out of box ダッシュボード（OOTB）を見て、Kubernetes ログの発見を開始
これで完了です。すべてのダッシュボードにメトリクスが流れ込んでいるのがわかるはずです。特定のポッドのログを表示するには、Kibana の Discover に入り、特定のポッド名を検索するだけです。
Elastic Kubernetes の概要ダッシュボードに HipsterShop のクラスタメトリクスが表示されます。
図：Elastic Observability 上の Hipstershop デフォルトネームスペースポッドダッシュボード
さらに、Elastic で直接すべての Pod ログを参照することができます。
図：frontendService と cartService のログ
上記の例では、frontendService と cartService のログを検索してみました。
ステップ 5: ボーナス!
OTel ベースのアプリケーションを使用していたため、Elastic はアプリケーションのトレースも引き込むことができます。これについては別のブログで説明します。
Hipster Shop のフロントエンドトランザクションのトレースが Elastic Observability でどのように見えるか、簡単に見てみましょう。
図：HipsterShop のチェックアウトトランザクションのトレース
結論: Kubernetes モニタリングのための Elastic Observability ロック
Elastic Observability が Kubernetes クラスタの管理にどのように役立つのか、また簡単なデプロイでも生成されるメトリクス、ログ、トレースデータの複雑さについて理解していただけたと思います。
具体的に学んだことを簡単に振り返ります。
• Elastic Cloud は、DaemonSet としてお客様のクラスタに簡単にデプロイでき、システムメトリクス、コンテナ統計、Kubernetes 上で動作するすべてのサービスからのメトリクスなど、ホストからのメトリクスを取得する Elastic Agent を通じて、どのように遠隔測定データを集約し取り込むことができるのか。
• お客様の Kubernetes クラスタコンポーネント（ポッド、ノード、サービス、任意のネームスペースなど）にまたがる統一された遠隔測定（Kubernenetes ログ、メトリクス、トレース）から、Elastic がもたらすものをご覧ください。
• MTTHH (mean time to happy hour)を短縮する Elastic の ML 機能にご注目ください。
さっそく始めてみませんか？登録 をして、このブログでご紹介した機能や性能を試してみてください。
Elastic テクニカルプロダクトマーケティングマネージャー/エバンジェリスト
鈴木章太郎