Kubernetesの監視 - Telegrafを使用するベストな監視方法

目次

• はじめに

• 前提条件

• Telegraf デーモンセットファイル構造の作成

• Telegraf デーモンセットをデプロイ

• メトリックの検索と可視化

• Graphite アラートの設定

• 最後に

はじめに

このチュートリアルでは、Telegrafエージェントを使用して、Kubernetesクラスタを簡単に監視できるようにする方法を解説いたします。

方法としては、ノード/ポッドのメトリクスをデータソースに転送し、カスタムダッシュボードとアラートを作成するためにそのデータを使用するDaemonsetとしてTelegrafエージェントを使用することとなります。ほんの数分で実現できるようになりますので、以下の方法をぜひお試しください。

Kubernetesは、コンテナ化されたアプリケーションのデプロイ、スケーリング、管理を自動化し、分散システム全体で高可用性と一貫したパフォーマンスを確保するために、本番レベルのアプリケーションやソフトウェアサービスにおいて使用されています。

Kubernetesは、ロードバランシング、セルフヒーリング、ローリングアップデートによって信頼性を高め、クラウドネイティブ環境やハイブリッド環境における効率的なリソース利用とオーケストレーションを可能にします。ここ数年で人気が高まっており、世界中のソフトウェアインフラを管理するための貴重なプラットフォームとなっています。

Kubernetesクラスターを監視することは、問題を早期に検出し、迅速な解決を可能にすることで、リソースの使用を最適化し、アプリケーションのパフォーマンスを確保するために極めて重要です。また、異常なアクティビティを可視化することでセキュリティを強化し、規制基準の遵守にも役立ちます。さらに、モニタリングはコスト管理とキャパシティプランニングを支援し、ダイナミックな環境におけるサービスの信頼性と可用性を担保することになります。

前提条件

この記事では、アクティブなKubernetesクラスタにアクセスできることを前提としています。そうでない場合は、Docker Desktop経由でminikubeのようなツールを使用するか、AWS EKSやLinodeのようなマネージドサービスを使用してテストクラスタをスピンアップすることができます。この記事では、Linodeでホストされているクラスタからメトリクスを収集しています。

次に、メトリクスを転送するデータソースも必要です。無料で簡単にデータソースを設定するには、Hosted GraphiteとGrafanaサービスを提供するMetricFireのトライアルにサインアップしてみてください。トライアルアカウントにサインアップすると、APIキーが発行されます。

最後に、TelegrafをDaemonsetとしてクラスタにデプロイします。つまり、コマンドラインにkubectlツールをインストールし、~/.kube/configファイルにクラスタコンテキストと認証情報（certificate-authority-data、token）を適切に設定しておく必要があります。

k8クラスタが実行され、~/.kube/configファイルがCLIアクセスを許可するように設定されたら、コンテキストを設定できます：

• kubectl config get-contexts 

• kubectl config use-context <context-name>

Telegraf デーモンセットファイル構造の作成

デーモンセットのデプロイは一般的にYAMLファイルの構成によって管理され、Helmチャートを使用することで、これらのファイルを自動的に簡単に作成できるため、人気があります - フレームワークのボイラープレートのようなものです。しかし、Helmチャートの複雑さが必要ない場合、Kustomizeツールはkubectlにすでに組み込まれているので、デプロイメントを管理するための優れた選択肢になります。以下では、Kustomizeコマンドラインツールを使ってTelegrafエージェントをデーモンセットとしてデプロイするための基本的なファイル構造を詳しく説明します。ローカルマシンに各ディレクトリ/ファイルを手動で作成するか、MetricFire GitHubからパブリックリポジトリをクローンするだけです。

プロジェクトディレクトリ:

telegraf-daemonset/

├── kustomization.yaml

└── resources/

    ├── config.yaml

    ├── daemonset.yaml

    ├── namespace.yaml

    ├── role.yaml

    ├── role-binding.yaml

    └── service_account.yaml

kustomization.yaml： このファイルはオーケストレーターとして機能し、他のすべてのYAMLファイルを結びつけ、追加の設定やパッチを適用します。このファイルはデプロイが一貫しており、環境間で再現可能であることを保証します。

apiVersion: kustomize.config.k8s.io/v1beta1

kind: Kustomization

namespace: monitoring

resources:

  - resources/config.yaml

  - resources/daemonset.yaml

  - resources/namespace.yaml

  - resources/role-binding.yaml

  - resources/role.yaml

  - resources/service_account.yaml

resources/config.yaml： このファイルには、DaemonSetやKubernetesリソースが必要とする設定データが含まれています。Telegrafの場合、通常、入出力プラグインとその設定が含まれます。KubernetesのConfigMapとして使用され、DaemonSetに設定データを提供します。デフォルトの'パフォーマンスコレクションプラグインに加え、inputs.kubernetesプラグインとoutputs.graphiteプラグインを設定します。これはHosted Graphiteトライアルアカウントにデータを転送します（このファイルにHG APIキーを追加してください）。

apiVersion: v1

kind: ConfigMap

metadata:

  name: telegraf-config

data:

  telegraf.conf: |

    [agent]

      hostname = "$HOSTNAME"

      interval = "10s"

      round_interval = true

    [[inputs.cpu]]

     percpu = false  ## setting to 'false' limits the number of cpu metrics returned

    [[inputs.disk]]

      ignore_fs = ["tmpfs", "devtmpfs", "devfs", "iso9660", "overlay", "aufs", "squashfs"]

   # [[inputs.diskio]]  ## commented out to limit the number of metrics returned

    [[inputs.mem]]

    [[inputs.system]]

    [[outputs.graphite]]

      servers = ["carbon.hostedgraphite.com:2003"]

      prefix = "<YOUR-HG-API-KEY>.telegraf-k8"

    [[inputs.kubernetes]]

      url = "https://$HOSTIP:10250"

      bearer_token = "/var/run/secrets/kubernetes.io/serviceaccount/token"

      insecure_skip_verify = true

resources/daemonset.yaml： このファイルはKubernetesのDaemonSetリソースを定義します。DaemonSetは、クラスタ内のすべての（または一部の）ノードでPodのコピーが実行されるようにします。コンテナイメージ、リソース制限、ボリュームなど、Podテンプレートの仕様が含まれています。

apiVersion: apps/v1

kind: DaemonSet

metadata:

  name: telegraf

spec:

  selector:

    matchLabels:

      name: telegraf

  template:

    metadata:

      labels:

        name: telegraf

    spec:

      serviceAccountName: telegraf-sa

      containers:

      - name: telegraf

        image: telegraf:latest

        resources:

          limits:

            memory: 200Mi

            cpu: 200m

          requests:

            memory: 100Mi

            cpu: 100m

        volumeMounts:

        - name: config

          mountPath: /etc/telegraf/telegraf.conf

          subPath: telegraf.conf

        - name: docker-socket

          mountPath: /var/run/docker.sock

        - name: varlibdockercontainers

          mountPath: /var/lib/docker/containers

          readOnly: true

        - name: hostfsro

          mountPath: /hostfs

          readOnly: true

        env:

        # This pulls HOSTNAME from the node, not the pod.

        - name: HOSTNAME

          valueFrom:

            fieldRef:

              fieldPath: spec.nodeName

        # In test clusters where hostnames are resolved in /etc/hosts on each node,

        # the HOSTNAME is not resolvable from inside containers

        # So inject the host IP as well

        - name: HOSTIP

          valueFrom:

            fieldRef:

              fieldPath: status.hostIP

        # Mount the host filesystem and set the appropriate env variables.

        # ref: https://github.com/influxdata/telegraf/blob/master/docs/FAQ.md

       # HOST_PROC is required by the cpu, disk, mem, input plugins

        - name: "HOST_PROC"

          value: "/hostfs/proc"

        # HOST_SYS is required by the diskio plugin

        - name: "HOST_SYS"

          value: "/hostfs/sys"

        - name: "HOST_MOUNT_PREFIX"

          value: "/hostfs"

      volumes:

      - name: hostfsro

        hostPath:

          path: /

      - name: config

        configMap:

          name: telegraf-config

      - name: docker-socket

        hostPath:

          path: /var/run/docker.sock

      - name: varlibdockercontainers

        hostPath:

          path: /var/lib/docker/containers

resources/namespace.yaml： Namespaceは、クラスタ内のリソースを論理的に分離するために使用されます。このファイルは、DaemonSetのすべてのリソースが指定されたネームスペースに配置されることを保証します。

apiVersion: v1

kind: Namespace

metadata:

  name: monitoring

resources/role.yaml：  Roleは、Namespace内のリソースへのアクセスを許可するために使用されます。このファイルは、DaemonSetによって使用されるサービスアカウントによって、どのリソースに対してどのアクションを実行できるかを指定します。

kind: ClusterRole

apiVersion: rbac.authorization.k8s.io/v1

metadata:

  name: telegraf-cluster-role

rules:

  - apiGroups: ["metrics.k8s.io"]

    resources: ["pods"]

    verbs: ["get", "list", "watch"]

  - apiGroups: [""]

    resources: ["nodes", "nodes/proxy", "nodes/stats", "persistentvolumes"]

    verbs: ["get", "list", "watch"]

resources/role-binding.yaml： このファイルは、Roleをユーザ、グループ、またはサービスアカウントにバインドします。このファイルによって、指定されたNamespace内のRoleで定義されたリソースに対して誰がアクションを実行できるかを指定できます。

apiVersion: rbac.authorization.k8s.io/v1

kind: ClusterRoleBinding

metadata:

  name: telegraf-sa-binding

subjects:

  - kind: ServiceAccount

    name: telegraf-sa

roleRef:

  apiGroup: rbac.authorization.k8s.io

  kind: ClusterRole

  name: telegraf-cluster-role

resources/service_account.yaml： サービスアカウントは、Pod内で実行されるプロセスのIDを提供します。サービスアカウントはKubernetes APIサーバとの認証に使用され、クラスタのリソースとやり取りする必要があるPodに関連付けられます。

apiVersion: v1

kind: ServiceAccount

metadata:

 name: telegraf-sa

Telegraf デーモンセットをデプロイ

この時点で、プロジェクトディレクトリにkustomization.yamlファイルとresourcesディレクトリ（他の6つのyamlファイルを含む）があるはずです。

すでに正しいクラスタコンテキストを使用しているはずなので、ルートプロジェクトディレクトリ内からkustomization.yamlファイルをテスト（ドライラン）してデプロイすることができます：

• kubectl apply -k . --dry-run=client

• kubectl apply -k .

期待される出力

namespace/monitoring created

serviceaccount/telegraf-sa created

clusterrole.rbac.authorization.k8s.io/telegraf-cluster-role created

clusterrolebinding.rbac.authorization.k8s.io/telegraf-sa-binding created

configmap/telegraf-config created

daemonset.apps/telegraf created

これで、クラスタで実行中のデーモンセットの一覧を取得し、Nameをtelegraf、Namespaceをmonitoringを持つデーモンセットを確認できます：

• kubectl get daemonsets --all-namespaces

Telegrafはノードとポッドのコンテナ/ボリューム/ネットワークのメトリクスを収集し、Hosted Graphiteのトライアルアカウントに転送します。これらのメトリクスはGraphiteフォーマットになり、カスタムダッシュボードやアラートを作成するためにHGで使用することができます。inputs.kubernetesプラグインの詳細と設定オプションについては、公式GitHubリポジトリを参照してください。

メトリックの検索と可視化

Hosted Graphiteのトライアルアカウントに移動します。メトリクスにはTelegrafというプレフィックスが付きますので、それを検索パラメータとして使用し、Graphiteメトリクスの完全なリストを探し出すことができるようになります：

次に、Dashboards => Primary Dashboardsに移動し、+ ボタンを選択して新しいパネルを作成します。そして、編集モードでクエリ UI を使用してgraphite metric pathを選択します（HG では、デフォルトのデータソースはHosted Graphiteバックエンドになります）。ダッシュボードの作成および変数、注釈、Graphite 関数などの高度な機能の詳細については、HG ダッシュボードドキュメントを参照してください：

また、Hosted Graphite Dashboard Libraryに移動し、telegraf-k8メトリクスと互換性のある、事前に作成されたKubernetes Overviewダッシュボードを生成することもできます。

Graphite アラートの設定

Hosted Graphite UIで、Alerts => Graphite Alertsに移動し、新しいアラートを作成します。アラートに名前を付け、アラートのメトリックフィールドにクエリを追加し、このアラートがどのようなものなのかの説明を追加します：

次に、アラート基準タブを選択し、しきい値と通知チャネルを定義します。デフォルトの通知チャネルは、Hosted Graphiteアカウントのサインアップに使用したメールです。Slack、PagerDuty、Microsoft Teams、OpsGenie、カスタムWebhooksなどの追加チャネルを簡単に構成できます。通知チャンネルの詳細については、Hosted Graphiteのドキュメントを参照してください：

最後に

Kubernetesインフラストラクチャを可視化することは、最適なパフォーマンス、セキュリティ、効率的なリソース管理を確保するために非常に重要です。これにより、異常を検出し、問題を診断し、情報に基づいたスケーリングとリソース割り当ての決定を行うことができます。Graphiteデータを収集するためにTelegraf DaemonSetを使用することは、各ノードに自動的にTelegrafをデプロイし、手動介入なしで包括的なデータ収集を保証するので便利です。このアプローチは、Telegrafの幅広い入力プラグインを活用して多様なメトリクスをキャプチャし、クラスタ全体で集中化された一貫性のあるモニタリングソリューションを提供します。

ダッシュボードやアラートのようなツールは、堅牢で効率的なインフラストラクチャを維持するために不可欠な、リアルタイムの可視化、問題のプロアクティブな特定、過去の傾向分析、情報に基づいた意思決定の促進を提供することで、データを補完します。

Hosted GraphiteとGrafanaサービスの無料トライアルはこちらからお申し込みください。製品について、またはMetricFireが御社をどのように支援できるかについてご質問がある場合は、デモをご予約の上、直接お問い合わせください。