GKE on AWS のロギングとモニタリング

このトピックでは、GKE on AWS のユーザー クラスタから Cloud Logging と Cloud Monitoring にログと指標をエクスポートする方法について説明します。

概要

GKE on AWS でのロギングとモニタリングには、複数のオプションがあります。GKE Enterprise は、Cloud Logging と Cloud Monitoring と統合できます。GKE Enterprise はオープンソースの Kubernetes をベースにしているため、多くのオープンソース ツール、サードパーティ ツールと互換性があります。

ロギングとモニタリングの方法

GKE Enterprise クラスタには、いくつかのロギング オプションとモニタリング オプションがあります。

  1. Cloud Logging エージェントと Cloud Monitoring エージェントをデプロイし、Google Cloud コンソールでワークロード ログのモニタリングと表示を行う。このトピックでは、このソリューションについて説明します。

  2. Prometheus、Grafana、Elasticsearch などのオープンソース ツールを使用する。このトピックでは、このソリューションについては説明しません。

  3. Datadog などのサードパーティ ソリューションを使用する。このトピックでは、このソリューションについては説明しません。

Cloud Logging と Cloud Monitoring

GKE Enterprise、Cloud Logging、Cloud Monitoring を使用すると、クラスタで実行中のワークロードのダッシュボードの作成、アラートの送信、モニタリング、ログの確認ができます。Google Cloud プロジェクトでログと指標を収集するには、Cloud Logging エージェントと Cloud Monitoring エージェントを構成する必要があります。これらのエージェントを構成しないと、GKE on AWS はロギングデータやモニタリング データを収集しません。

収集されるデータの種類

構成すると、エージェントはクラスタとクラスタで実行されているワークロードからログと指標データを収集します。これらのデータは Google Cloud プロジェクトに保存されます。このプロジェクト ID は、Log Forwarder をインストールするときに、構成ファイルの project_id フィールドに構成します。

収集されるデータには次のものが含まれます。

  • 各ワーカーノードのシステム サービス用のログ。
  • クラスタで実行されているすべてのワークロードのアプリケーション ログ。
  • クラスタ サービスとシステム サービスの指標。特定の指標の詳細については、GKE Enterprise の指標をご覧ください。
  • アプリケーションに Prometheus スクレイピング ターゲットが構成され、prometheus.io/scrapeprometheus.io/pathprometheus.io/port などの構成でアノテーションが付けられている場合は、Pod のアプリケーション指標。

エージェントは任意の時点で無効にできます。詳しくは、クリーンアップをご覧ください。エージェントによって収集されたデータは、その他の指標やログデータと同様に管理、削除できます。手順については、Cloud MonitoringCloud Logging のドキュメントをご覧ください。

ログデータは、構成されている保持ルールに従って保存されます。指標データの保持は、指標タイプによって異なります

ロギングとモニタリングのコンポーネント

GKE on AWS から Google Cloud にクラスタレベルのテレメトリーをエクスポートするには、次のコンポーネントをクラスタにデプロイします。

  • Stackdriver Log Forwarder(stackdriver-log-forwarder-*)。各 Kubernetes ノードから Cloud Logging にログを転送する Fluentbit の DaemonSet です。
  • GKE Metrics Agent(gke-metrics-agent-*)。指標データを収集し Cloud Monitoring に転送する OpenTelemetry Collector ベースの DaemonSet です。

これらのコンポーネントのマニフェストは、GitHub の anthos-samples リポジトリにあります。

前提条件

  1. 課金を有効にした Google Cloud プロジェクト。費用の詳細については、Google Cloud Observability の料金をご覧ください。

    また、プロジェクトで Cloud Logging API と Cloud Monitoring API を有効にする必要があります。これらの API を有効にするには、次のコマンドを実行します。

    gcloud services enable logging.googleapis.com
    gcloud services enable monitoring.googleapis.com
    
  2. GKE on AWS 環境(Connect に登録されたユーザー クラスタを含む)。クラスタが登録済みかどうかは、次のコマンドで確認します。

    gcloud container fleet memberships list
    

    クラスタが登録されている場合は、Google Cloud CLI により、クラスタの名前と ID が出力されます。

    NAME       EXTERNAL_ID
    cluster-0  1abcdef-1234-4266-90ab-123456abcdef
    

    クラスタの一覧が表示されない場合は、Connect を使用したクラスタへの接続をご覧ください。

  3. マシンに git コマンドライン ツールをインストールします。

Google Cloud Observability の権限の設定

ロギング エージェントとモニタリング エージェントは、フリート Workload Identity を使用して Cloud Logging と Cloud Monitoring と通信します。ID には、プロジェクトにログと指標を書き込むための権限が必要です。権限を追加するには、次のコマンドを実行します。

gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="serviceAccount:PROJECT_ID.svc.id.goog[kube-system/stackdriver]" \
  --role=roles/logging.logWriter
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="serviceAccount:PROJECT_ID.svc.id.goog[kube-system/stackdriver]" \
  --role=roles/monitoring.metricWriter

PROJECT_ID は、Google Cloud プロジェクトに置き換えます。

踏み台インスタンスに接続する

GKE on AWS リソースに接続するには、次の操作を行います。既存の AWS VPC(または VPC への直接接続)があるか、管理サービスの作成時に専用の VPC を作成したかに基づいて、以下の操作を行います。

既存の VPC

既存の VPC への直接接続または VPN 接続がある場合は、このトピックのコマンドから env HTTP_PROXY=http://localhost:8118 行を省略します。

専用の VPC

専用の VPC で管理サービスを作成すると、GKE on AWS にパブリック サブネットの踏み台インスタンスが含まれます。

管理サービスに接続するには、次の操作を行います。

  1. GKE on AWS 構成のディレクトリに移動します。このディレクトリは、管理サービスをインストールしたときに作成したものです。

    cd anthos-aws

  2. トンネルを開くには、bastion-tunnel.sh スクリプトを実行します。トンネルは localhost:8118 に転送されます。

    踏み台インスタンスへのトンネルを開くには、次のコマンドを実行します。

    ./bastion-tunnel.sh -N
    

    SSH トンネルからのメッセージがこのウィンドウに表示されます。接続を閉じる準備ができたら、Ctrl+C を使用するか、ウィンドウを閉じて処理を停止します。

  3. 新しいターミナルを開き、anthos-aws ディレクトリに移動します。

    cd anthos-aws
  4. kubectl を使用してクラスタに接続できることを確認します。

    env HTTPS_PROXY=http://localhost:8118 \
    kubectl cluster-info
    

    出力には、Management Service API サーバーの URL が含まれます。

コントロール プレーン ノード上の Cloud Logging と Cloud Monitoring

GKE on AWS 1.8.0 以降では、新しいユーザー クラスタを作成するときに、コントロール プレーン ノード用の Cloud Logging と Cloud Monitoring が自動的に構成されます。Cloud Logging や Cloud Monitoring を有効にするには、AWSCluster 構成の controlPlane.cloudOperations セクションに情報を入力します。

cloudOperations:
  projectID: PROJECT_ID
  location: GC_REGION
  enableLogging: ENABLE_LOGGING
  enableMonitoring: ENABLE_MONITORING

次のように置き換えます。

  • PROJECT_ID: プロジェクト ID。
  • GC_REGION: ログを保存する Google Cloud リージョン。AWS リージョンに近接したリージョンを選択します。詳細については、グローバル ロケーション - リージョンとゾーンをご覧ください。例: us-central1
  • ENABLE_LOGGING: true または false。コントロール プレーン ノードで Cloud Logging が有効かどうか。
  • ENABLE_MONITORING: true または false。コントロール プレーン ノードで Cloud Monitoring が有効かどうか。

次に、カスタム ユーザー クラスタの作成の手順に沿って操作します。

ワーカーノード上の Cloud Logging と Cloud Monitoring

前のバージョンの削除

stackdriver-log-aggregator(Fluentd)や stackdriver-prometheus-k8s(Prometheus)など、前のバージョンの Logging エージェントと Monitoring エージェントが設定されている場合は、先に進む前にアンインストールすることをおすすめします。

ロギング フォワーダーのインストール

このセクションでは、クラスタに Stackdriver Log Forwarder をインストールします。

  1. anthos-samples/aws-logging-monitoring/ ディレクトリから、logging/ ディレクトリに移動します。

    cd logging/
    
  2. プロジェクトの構成に合わせて forwarder.yaml ファイルを変更します。

    sed -i "s/PROJECT_ID/PROJECT_ID/g" forwarder.yaml
    sed -i "s/CLUSTER_NAME/CLUSTER_NAME/g" forwarder.yaml
    sed -i "s/CLUSTER_LOCATION/GC_REGION/g" forwarder.yaml
    

    次のように置き換えます。

    • PROJECT_ID: プロジェクト ID。
    • CLUSTER_NAME: クラスタの名前。例: cluster-0
    • GC_REGION: ログを保存する Google Cloud リージョン。AWS リージョンに近接したリージョンを選択します。詳細については、グローバル ロケーション - リージョンとゾーンをご覧ください。例: us-central1
  3. (省略可)ワークロード、クラスタ内のノードの数、ノードあたりの Pod 数に応じて、メモリと CPU のリソース リクエストを設定する必要があります。詳細については、推奨される CPU とメモリ割り当てをご覧ください。

  4. anthos-aws ディレクトリから anthos-gke を使用して、コンテキストをユーザー クラスタに切り替えている。

    cd anthos-aws
    env HTTPS_PROXY=http://localhost:8118 \
      anthos-gke aws clusters get-credentials CLUSTER_NAME
    CLUSTER_NAME は、ユーザー クラスタ名に置き換えます。

  5. stackdriver サービス アカウントが存在しない場合は作成し、クラスタに Log Forwarder をデプロイします。

    env HTTPS_PROXY=http://localhost:8118 \
      kubectl create serviceaccount stackdriver -n kube-system
    env HTTPS_PROXY=http://localhost:8118 \
      kubectl apply -f forwarder.yaml
    
  6. kubectl を使用して、Pod が起動されたことを確認します。

    env HTTPS_PROXY=http://localhost:8118 \
      kubectl get pods -n kube-system | grep stackdriver-log
    

    ノードプールでは、ノードごとに 1 つのフォワーダー Pod が表示されます。たとえば、6 ノードのクラスタでは、6 つのフォワーダー Pod が表示されます。

    stackdriver-log-forwarder-2vlxb              2/2     Running   0          21s
    stackdriver-log-forwarder-dwgb7              2/2     Running   0          21s
    stackdriver-log-forwarder-rfrdk              2/2     Running   0          21s
    stackdriver-log-forwarder-sqz7b              2/2     Running   0          21s
    stackdriver-log-forwarder-w4dhn              2/2     Running   0          21s
    stackdriver-log-forwarder-wrfg4              2/2     Running   0          21s
    

ログ転送のテスト

このセクションでは、負荷生成ツールを使用する基本的な HTTP ウェブサーバーのワークロードをクラスタにデプロイします。次に、Cloud Logging にログが存在することをテストします。

ウェブサーバー負荷生成ツールのマニフェストは、このワークロードをインストールする前に確認できます。

  1. ウェブサーバーと負荷生成ツールをクラスタにデプロイします。

    env HTTPS_PROXY=http://localhost:8118 \
      kubectl apply -f  https://raw.githubusercontent.com/GoogleCloudPlatform/istio-samples/master/sample-apps/helloserver/server/server.yaml
    env HTTPS_PROXY=http://localhost:8118 \
      kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/istio-samples/master/sample-apps/helloserver/loadgen/loadgen.yaml
    
  2. Cloud Logging ダッシュボードでクラスタのログを表示できることを確認するには、Google Cloud コンソールの [ログ エクスプローラ] に移動します。

    [ログ エクスプローラ] に移動

  3. 次のサンプルクエリを [クエリビルダー] フィールドにコピーします。

    resource.type="k8s_container" resource.labels.cluster_name="CLUSTER_NAME"
    

    CLUSTER_NAME はクラスタ名で置き換えます。

  4. [クエリを実行] をクリックします。最近のクラスタログが [クエリ結果] に表示されます。

    Google Cloud Observability のクラスタログ

  5. ログがクエリ結果に表示されることを確認したら、負荷生成ツールとウェブサーバーを削除します。

    env HTTPS_PROXY=http://localhost:8118 \
      kubectl delete -f https://raw.githubusercontent.com/GoogleCloudPlatform/istio-samples/master/sample-apps/helloserver/loadgen/loadgen.yaml
    
    env HTTPS_PROXY=http://localhost:8118 \
      kubectl delete -f https://raw.githubusercontent.com/GoogleCloudPlatform/istio-samples/master/sample-apps/helloserver/server/server.yaml
    

指標コレクタのインストール

このセクションでは、Cloud Monitoring にデータを送信するエージェントをインストールします。

  1. anthos-samples/aws-logging-monitoring/logging/ ディレクトリから、anthos-samples/aws-logging-monitoring/monitoring/ ディレクトリに移動します。

    cd ../monitoring
    
  2. プロジェクトの構成に合わせて gke-metrics-agent.yaml ファイルを変更します。

    sed -i "s/PROJECT_ID/PROJECT_ID/g" gke-metrics-agent.yaml
    sed -i "s/CLUSTER_NAME/CLUSTER_NAME/g" gke-metrics-agent.yaml
    sed -i "s/CLUSTER_LOCATION/GC_REGION/g" gke-metrics-agent.yaml
    

    次のように置き換えます。

    • PROJECT_ID: プロジェクト ID。
    • CLUSTER_NAME: クラスタの名前。例: cluster-0
    • GC_REGION: ログを保存する Google Cloud リージョン。AWS リージョンに近接したリージョンを選択します。詳細については、グローバル ロケーション - リージョンとゾーンをご覧ください。例: us-central1
  3. (省略可)ワークロード、クラスタ内のノードの数、ノードあたりの Pod 数に応じて、メモリと CPU のリソース リクエストを設定する必要があります。詳細については、推奨される CPU とメモリ割り当てをご覧ください。

  4. stackdriver サービス アカウントが存在しない場合は作成し、クラスタに指標エージェントをデプロイします。

    env HTTPS_PROXY=http://localhost:8118 \
      kubectl create serviceaccount stackdriver -n kube-system
    env HTTPS_PROXY=http://localhost:8118 \
      kubectl apply -f gke-metrics-agent.yaml
    
  5. kubectl ツールを使用して、gke-metrics-agent Pod が動作していることを確認します。

    env HTTPS_PROXY=http://localhost:8118 \
      kubectl get pods -n kube-system | grep gke-metrics-agent
    

    ノードプールでは、ノードごとに 1 つのエージェント Pod が表示されます。たとえば、3 ノードクラスタでは、3 つのエージェント Pod が表示されます。

    gke-metrics-agent-gjxdj                    2/2     Running   0          102s
    gke-metrics-agent-lrnzl                    2/2     Running   0          102s
    gke-metrics-agent-s6p47                    2/2     Running   0          102s
    
  6. クラスタの指標が Cloud Monitoring にエクスポートされていることを確認するには、Google Cloud コンソールの Metrics Explorer に移動します。

    Metrics Explorer に移動

  7. Metrics Explorer で、[クエリエディタ] をクリックし、次のコマンドをコピーします。

    fetch k8s_container
    | metric 'kubernetes.io/anthos/otelcol_exporter_sent_metric_points'
    | filter
        resource.project_id == 'PROJECT_ID'
        && (resource.cluster_name =='CLUSTER_NAME')
    | align rate(1m)
    | every 1m
    

    次のように置き換えます。

  8. [クエリを実行] をクリックします。クラスタ内の各 gke-metrics-agent Pod から Cloud Monitoring に送信される指標ポイントのレートが表示されます。

    クラスタのモニタリング

    他にも試してみるのにふさわしい指標を以下に示します。これらはあくまでも例です。

    • kubernetes.io/anthos/container_memory_working_set_bytes: コンテナのメモリ使用量。
    • kubernetes.io/anthos/container_cpu_usage_seconds_total: コンテナの CPU 使用率。
    • kubernetes.io/anthos/apiserver_aggregated_request_total: kube-apiserver リクエスト数。コントロール プレーンで Cloud Monitoring が有効な場合にのみ使用できます。

    使用可能な指標の完全なリストについては、Anthos 指標をご覧ください。ユーザー インターフェースの使用方法については、Metrics Explorer をご覧ください。

Cloud Monitoring のダッシュボードの作成

このセクションでは、クラスタ内のコンテナのステータスをモニタリングする Cloud Monitoring ダッシュボードを作成します。

  1. anthos-samples/aws-logging-monitoring/monitoring/ ディレクトリから、anthos-samples/aws-logging-monitoring/monitoring/dashboards ディレクトリに移動します。

    cd dashboards
    
  2. pod-status.jsonCLUSTER_NAME 文字列の箇所は、クラスタ名に置き換えます。

    sed -i "s/CLUSTER_NAME/CLUSTER_NAME/g" pod-status.json
    

    CLUSTER_NAME はクラスタ名で置き換えます。

  3. 次のコマンドを実行して、構成ファイルを含むカスタム ダッシュボードを作成します。

    gcloud monitoring dashboards create --config-from-file=pod-status.json
    
  4. ダッシュボードが作成されたことを確認するには、Google Cloud コンソールで Cloud Monitoring ダッシュボードに移動します。

    ダッシュボードに移動する

    新しく作成し、CLUSTER_NAME (Anthos cluster on AWS) pod status 形式の名前を持つダッシュボードを開きます。

クリーンアップ

このセクションでは、クラスタからロギング コンポーネントとモニタリング コンポーネントを削除します。

  1. Google Cloud コンソールのダッシュボード一覧ビューで、ダッシュボード名に関連付けられている削除ボタンをクリックし、モニタリング ダッシュボードを削除します。

  2. anthos-samples/aws-logging-monitoring/ ディレクトリに移動します。

    cd anthos-samples/aws-logging-monitoring
    
  3. このガイドで作成したリソースをすべて削除するには、次のコマンドを実行します。

    env HTTPS_PROXY=http://localhost:8118 \
      kubectl delete -f logging/
    env HTTPS_PROXY=http://localhost:8118 \
      kubectl delete -f monitoring/
    

推奨される CPU / メモリの割り当て

このセクションでは、ロギングとモニタリングに使用される個別のコンポーネントに対する推奨の CPU と割り当てについて説明します。次の各表は、ノードサイズ範囲のあるクラスタの CPU リクエストとメモリ リクエストの一覧です。表に含まれているファイルでコンポーネントのリソース リクエストを設定します。

詳細については、Kubernetes のベスト プラクティス: リソースのリクエストと上限およびコンテナのリソースの管理をご覧ください。

1~10 ノード

ファイル リソース CPU リクエスト CPU 上限 メモリ リクエスト メモリ上限
monitoring/gke-metrics-agent.yaml gke-metrics-agent 30m 100m 50Mi 500Mi
logging/forwarder.yaml stackdriver-log-forwarder 50m 100m 100Mi 600Mi

10~100 ノード

ファイル リソース CPU リクエスト CPU 上限 メモリ リクエスト メモリ上限
monitoring/gke-metrics-agent.yaml gke-metrics-agent 50m 100m 50Mi 500Mi
logging/forwarder.yaml stackdriver-log-forwarder 60m 100m 100Mi 600Mi

100 ノード超

ファイル リソース CPU リクエスト CPU 上限 メモリ リクエスト メモリ上限
monitoring/gke-metrics-agent.yaml gke-metrics-agent 50m 100m 100Mi なし
logging/forwarder.yaml stackdriver-log-forwarder 60m 100m 100Mi 600Mi

次のステップ

Cloud Logging について学習する

Cloud Monitoring について学習する