Kubernetes基礎 #8 - モニタリング

DevOps

Last Edited: 6/9/2025

このブログ記事では、Kubernetesにおけるモニタリングツールについて紹介します。

DevOps

前回の記事では、サービスアカウントが主にビルドツールやモニタリングサービスに適切な権限を割り当てるために使用されることを簡単に説明しました。 適切なクラスター管理のためには、クラスターパフォーマンスの複数の側面を測定するモニタリングサービスを設定することが不可欠です。 そこで、この記事ではKubernetesにおけるモニタリングの主要なツールをいくつか取り上げます。

ヘルスプローブ

ヘルスプローブは、kubeletがポッドに対して行うHTTPリクエスト、TCPリクエスト、またはコマンド実行であり、 コンテナ内のプロセスはカスタムに定義します。これらのプローブは、ポッドが起動しているか、ポッドがリクエストを受信する準備ができているか、 ポッドが生きていて再起動が必要かどうかをチェックするために使用される応答を取得します。ポッドが起動していない、 準備ができていない、または生きていない場合、ヘルスプローブはポッドを再起動して問題の修正を試みます。

# http-liveness.yaml
apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - name: liveness
    image: registry.k8s.io/e2e-test-images/agnhost:2.40
    args:
    - liveness
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
        httpHeaders:
        - name: Custom-Header
          value: Awesome
      initialDelaySeconds: 3
      periodSeconds: 3
---
# tcp-readiness.yaml
apiVersion: v1
kind: Pod
metadata:
  name: goproxy
  labels:
    app: goproxy
spec:
  containers:
  - name: goproxy
    image: registry.k8s.io/goproxy:0.1
    ports:
    - containerPort: 8080
    readinessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 10

上記の例では、ライブネスプローブ（HTTP）とレディネスプローブ（TCP）の設定を示しています。ポッドが動作しているネットワーキング層に応じて、 HTTPエンドポイントを設定するか、ポートを解放するかを選択できます。（ヘルスチェックのためにkubeletにポッド内でコマンドを実行させることも可能です。） initialDelaySecondsフィールドは最初のヘルスチェック呼び出しまでの遅延を指定し、periodSecondsは次のヘルスチェックまで何秒待つかを指定します。 ポッドが準備できるまで、サービスロードバランサーから除外されkubeletによって再起動され、ポッドの生存が確認されるまで、kubeletはコンテナを再起動します。

メトリックサーバー

メトリックサーバーは、CPUとメモリ使用率をモニタリングするkube-system名前空間内のポッドです。 記事Kubernetes基礎 #6 - スケジューリング & オートスケーリングで説明したHorizontal Pod Autoscaler（HPA）は、 メトリックサーバーに依存しており、メトリックサーバーが適切に設定されていない場合はエラーを返します。 メトリックサーバーをインストールするには、こちらの手順に従ってください。 （メトリックサーバーのYAMLファイル内のコマンドに--kubelet-insecure-tlsフラグを追加する必要がある可能性があります。 これはkubectl get deployでYAMLファイルを取得し、変更を適用することで実行できます。）

メトリックサーバーが正しく設定されていることを確認するには、kubectl top podsを実行して、 すべてのポッドとそのCPUおよびメモリ使用率を降順でリストできます。メトリックサーバーはHPA（およびVPA）に不可欠であり、 クラスターのモニタリングに有用ですが、数百のリソースを持つ本番クラスターには適していません。 また、HTTPレスポンス時間などの詳細なメトリックを取得したり、潜在的な障害について通知を受けたり、 分析のためにメトリックを集約・保存したりすることもできません。そのため、通常はより洗練されたサードパーティのモニタリングツールに頼ることになります。

Prometheus

Prometheusは最も人気のあるモニタリングツールの一つで、特にコンテナ化されたマイクロサービスアーキテクチャのプロジェクトにおいて、 DockerやKubernetesとの高い互換性により広く使用されています。本番環境に適しており、そのスタックにはアラート機能、 時系列データベース、クエリ言語、ユーザーインターフェース（Grafana）、そしてさまざまなメトリクスをPrometheusにエクスポートできる多数の事前構築されたエクスポーターとクライアントライブラリが含まれています。 以下は、Prometheusのシステムアーキテクチャを表しています。

Prometheus

PrometheusはKubernetes APIサーバーと互換性があり、メトリクスを収集する必要があるサービスを発見できます。 エクスポーターとクライアントライブラリによって公開されたサービスからメトリクスを取得します。 Alertmanagerは、クラスターから潜在的な問題が検出された際に管理者にアラートを送信するよう設定できます （CPU使用率が90%を超えた場合にアラートを送信するなど、任意に定義されたルールに基づいて）。 保存されたデータはGrafanaで表示でき、データモデルに基づいてPromQLを使用してクエリも実行できます。

時系列データベース（ローカルまたはリモートストレージ）、HTTPサーバー、リトリーバー、エクスポーター、 アラートマネージャーを含むシステムアーキテクチャの各コンポーネントを手動で設定し、 Kubernetes上でサービスディスカバリーとPrometheusの設定を適用することも可能ですが、 これには相当な労力が必要です（複数のシークレット、ConfigMap、StatefulSet、DaemonSet、Ingress、クラスターロールなどの設定が含まれます）。 そのため、Prometheusが提供するPrometheus Operatorを使用できます。 これは基本的な使用に必要なリソースを自動的に設定・管理します。Prometheus Operatorはこちらの手順に従ってインストールできます。

Prometheusは広く使用されているモニタリングツールですが、Prometheus Operatorを使用しても設定が困難な場合があり、 そのデータモデル、クエリ言語、クライアントライブラリも習得が困難な場合があります。 将来的に（必要性が生じた時に）Prometheusに関する別の記事シリーズを執筆するかもしれませんが、 現時点では、本番レベルのモニタリングシステムがどのようなものかの紹介に留めておきます。

結論

この記事では、ポッドのヘルスチェックと復旧のためのヘルスプローブ、ポッドのリソース使用率監視とオートスケーリングのためのMetrics Server、 そして本番環境に適した最も人気のあるモニタリングツールの一つであるPrometheusについて説明しました。 Prometheusの複雑さのため、その設定方法や全体的な使用方法については詳しく説明しませんでしたが、 基本的なシステムアーキテクチャについては説明しており、これは今後のさらなる探究に役立つはずです。

リソース

TOPに戻る↑