概要 | New Relic Documentation

Kubernetesインテグレーションバージョン 2 には、バージョン 3 とは異なる設定と要件がいくつかあります。このドキュメントでは、バージョン 3 とは異なる設定と、バージョン 2 に必要な設定について説明します。特に指定がない場合は、バージョン 3 の設定を使用できます。

注意

New Relic ではバージョン 2 が非推奨となっており、使用は推奨されていません。バージョン 2 のサポートは終了していますが、引き続きバージョン 2 を使用しているユーザーのためにこのドキュメントを維持しています。

現在のバージョンのの使用を開始するには、インテグレーションの概要」KubernetesKubernetes を参照してください。

バージョン 3 の変更点を理解するには、 Kubernetesインテグレーションバージョン 3 のドキュメントに導入された変更点を参照してください。

統合されたコントロールプレーンの監視バージョン2

ここでは、バージョン2以前のインテグレーションでコントロールプレーンモニタリングを設定する方法について説明します。

これらのバージョンでは自動検出オプションの柔軟性が低く、外部エンドポイントをサポートしていないことに注意してください。できるだけ早くバージョン 3にアップデートすることを強くお勧めします。

自動検出とデフォルト設定: `hostNetwork`および `privileged`

v3より前のバージョンでは、統合がprivileged: falseを使用してデプロイされると、コントロールプレーンコンポーネントのhostNetwork設定もfalseに設定されます。

コントロールプレーンノードとコントロールプレーンコンポーネントの検出

Kubernetesインテグレーションは、 kubeadmラベル付け規則に依存して、コントロールプレーンノードとコントロールプレーンコンポーネントを検出します。つまり、コントロールプレーンノードにはnode-role.kubernetes.io/control-plane=""というラベルを付ける必要があるということです。

コントロールプレーンコンポーネントには、 k8s-appまたはtierとcomponentラベルのいずれかが必要です。許容されるラベルの組み合わせと値については、次の表を参照してください。

コンポーネント	ラベル	終点
APIサーバー	Kubeadm / Kops / ClusterAPI `k8s-app=kube-apiserver` `tier=control-plane component=kube-apiserver` OpenShift `app=openshift-kube-apiserver apiserver=true`	`localhost:443/metrics` デフォルトでは（構成可能）、要求が失敗した場合はにフォールバックします `localhost:8080/metrics`
etcd	Kubeadm / Kops / ClusterAPI `k8s-app=etcd-manager-main` `tier=control-plane component=etcd` OpenShift `k8s-app=etcd`	`localhost:4001/metrics`
スケジューラー	Kubeadm / Kops / ClusterAPI `k8s-app=kube-scheduler` `tier=control-plane component=kube-scheduler` OpenShift `app=openshift-kube-scheduler scheduler=true`	`localhost:10251/metrics`
コントローラーマネージャー	Kubeadm / Kops / ClusterAPI `k8s-app=kube-controller-manager` `tier=control-plane component=kube-controller-manager` OpenShift `app=kube-controller-manager kube-controller-manager=true`	`localhost:10252/metrics`

インテグレーションは、コントロールプレーンノード内で実行されていることを検出すると、上記の表にリストされているラベルと一致するポッドを探して、ノード上で実行されているコンポーネントを見つけようとします。実行中のコンポーネントごとに、統合はメトリクスエンドポイントにリクエストを送信します。

構成

コントロールプレーンノード内で実行されているエージェントのコントロールプレーン監視は自動的に行われます。実行に追加の手順が必要な唯一のコンポーネントは etcd です。これは、クライアント要求に相互 TLS 認証 (mTLS) を使用するためです。 API サーバーは、セキュアポートを使用してクエリを実行するように構成することもできます。

重要

OpenShift 4.x のコントロールプレーン監視には、追加の設定が必要です。詳細については、 OpenShift 4.x Configuration のセクションを参照してください。

etcd

etcd をクエリするために mTLS を設定するには、次の 2 つの構成オプションを設定する必要があります。

オプション	価値
`ETCD_TLS_SECRET_NAME`	mTLSの設定を含むKubernetesのシークレットの名前。シークレットには以下のキーを入れてください。 `cert`：要求を行っているクライアントを識別する証明書。 etcdの信頼できるCAによって署名されている必要があります。 `key`：クライアント証明書の生成に使用される秘密鍵。 `cacert`：etcdサーバー証明書の識別に使用されるルートCA。 `ETCD_TLS_SECRET_NAME`オプションが設定されていない場合、etcdメトリックはフェッチされません。
`ETCD_TLS_SECRET_NAMESPACE`	`ETCD_TLS_SECRET_NAME`で指定されたシークレットが作成されたネームスペース。設定されていない場合、 `default`名前空間が使用されます。

オプション

価値

ETCD_TLS_SECRET_NAME

mTLSの設定を含むKubernetesのシークレットの名前。

シークレットには以下のキーを入れてください。

cert：要求を行っているクライアントを識別する証明書。 etcdの信頼できるCAによって署名されている必要があります。
key：クライアント証明書の生成に使用される秘密鍵。
cacert：etcdサーバー証明書の識別に使用されるルートCA。
ETCD_TLS_SECRET_NAMEオプションが設定されていない場合、etcdメトリックはフェッチされません。

ETCD_TLS_SECRET_NAMESPACE

ETCD_TLS_SECRET_NAMEで指定されたシークレットが作成されたネームスペース。設定されていない場合、 default名前空間が使用されます。

APIサーバー

デフォルトでは、APIサーバーの指標はlocalhost:8080のセキュリティで保護されていないエンドポイントを使用してクエリされます。このポートが無効になっている場合は、セキュアポートを介してこれらのメトリックを照会することもできます。これを有効にするには、Kubernetes統合マニフェストファイルで次の設定オプションを設定します。

オプション	価値
`API_SERVER_ENDPOINT_URL`	メトリックをクエリするための（安全な）URL。 APIサーバーはデフォルトで`localhost:443`を使用します `ClusterRole`がマニフェストにある最新バージョンに更新されていることを確認してくださいバージョン1.15.0で追加

オプション

価値

API_SERVER_ENDPOINT_URL

メトリックをクエリするための（安全な）URL。 APIサーバーはデフォルトでlocalhost:443を使用します

ClusterRoleがマニフェストにある最新バージョンに更新されていることを確認してください

バージョン1.15.0で追加

重要

なお、このポートは、APIサーバーが使用するセキュアポートに応じて異なる場合があります。

たとえば、MinikubeではAPIサーバーのセキュアポートは8443であるため、 API_SERVER_ENDPOINT_URLは次のように設定する必要があります。 https://localhost:8443

OpenShiftの設定

OpenShift 4.x のコントロールプレーンコンポーネントは、SSL とサービスアカウントベースの認証を必要とするエンドポイント URL を使用します。したがって、デフォルトのエンドポイント URL は使用できません。

重要

Helmを介してopenshiftをインストールする場合は、これらのエンドポイントを自動的に含めるように構成を指定してください。 openshift.enabled=trueとopenshift.version="4.x"を設定すると、セキュアエンドポイントが含まれ、 /var/run/crio.sockランタイムが有効になります。

OpenShift でコントロールプレーンの監視を構成するには、カスタマイズされたマニフェストで次の環境変数のコメントを解除します。 URL 値は、 OpenShift 4.x のコントロールプレーン監視メトリクスエンドポイントのデフォルトのベース URL に事前設定されています。

- name: "SCHEDULER_ENDPOINT_URL"
        value: "https://localhost:10259
        - name: "ETCD_ENDPOINT_URL"
        value: "https://localhost:9979"
        - name: "CONTROLLER_MANAGER_ENDPOINT_URL"
        value: "https://localhost:10257"
        - name: "API_SERVER_ENDPOINT_URL"
        value: "https://localhost:6443"

重要

カスタムETCD_ENDPOINT_URLが定義されている場合でも、etcd では HTTPS および mTLS 認証を構成する必要があります。 OpenShift で etcd 用に mTLS を構成する方法の詳細については、「OpenShift で etcd 用に mTLS を設定する」を参照してください。

Kubernetesのログ

詳細なログを生成し、バージョンと設定情報を取得したい場合は、以下の情報を確認してください。

Kubernetesの場合、インフラストラクチャエージェントはエラーのイベントにログエントリを追加するだけです。最も一般的なエラーは、標準の (詳細ではない) ログに表示されます。独自に、または New Relic サポートと協力してより詳細な調査を行う場合は、詳細モードを有効にすることができます。

注意

詳細モードでは、ログファイルに送信される情報の量が大幅に増加します。このモードはトラブルシューティングの目的で一時的にのみ有効にし、終了したらログレベルをリセットしてください。

マニフェストファイルを使用して詳細ログを有効にするには:

詳細ログを有効にする: デプロイメントファイルで、 NRIA_VERBOSE の値を 1に設定します。
変更したコンフィグレーションを実行して適用する。
bash
```
$kubectl apply -f your_newrelic_k8s.yaml
```
数分間、あるいは十分なアクティビティが発生するまで、冗長モードのままにしておきます。
詳細モードを無効にする： NRIA_VERBOSEの値を0に戻します。
復元したコンフィグレーションを実行して適用します。
bash
```
$kubectl apply -f your_newrelic_k8s.yaml
```
環境内のノードのリストを取得します。
bash
```
$kubectl get nodes --all-namespaces
```
infrastructureおよびkube-state-metricsポッドのリストを取得します。
bash
```
$kubectl get pods --all-namespaces -o wide | egrep 'newrelic|kube-state-metrics'
```
kube-state-metricsに接続しているポッドからログを取得します。
kube-state-metricsサービスの設定を取得します。

Kubernetes 統合の場合、インフラストラクチャエージェントはエラーが発生した場合にのみログエントリを追加します。最も一般的なエラーは、標準 (詳細ではない) ログに表示されます。独自で、または New Relic サポートと協力してより詳細な調査を行っている場合は、冗長モードを有効にすることができます。

注意

Helm を使用して詳細ログを有効にするには:

以下のコマンドを実行します。

bash

$helm upgrade -n <namespace> --reuse-values newrelic-bundle --set newrelic-infrastructure.verboseLog=true newrelic/nri-bundle

数分間、あるいは十分なアクティビティが発生するまで、冗長モードのままにしておきます。

必要な情報が得られたら、詳細なログを無効にします。

bash

$helm upgrade --reuse-values newrelic-bundle --set newrelic-infrastructure.verboseLog=false newrelic/nri-bundle

復元したコンフィグレーションを実行して適用します。
bash
```
$kubectl apply -f your_newrelic_k8s.yaml
```
環境内のノードのリストを取得します。
bash
```
$kubectl get nodes --all-namespaces
```
infrastructureおよびkube-state-metricsポッドのリストを取得します。
bash
```
$kubectl get pods --all-namespaces -o wide | egrep 'newrelic|kube-state-metrics'
```
kube-state-metricsに接続しているポッドからログを取得します。
kube-state-metricsサービスの設定を取得します。

kube-state-metricsに接続しているポッドからログを取得するには:

以下のコマンドを実行します。

bash

$kubectl get pods --all-namespaces -o wide | grep kube-state-metrics

このような出力を探してください。

bash

$kube-system   kube-state-metrics-5c6f5cb9b5-pclhh     2/2
$    Running   4          4d        172.17.0.3   minikube

kube-state-metricsと同じノードで実行されている New Relic ポッドを取得します。

bash

$kubectl describe node minikube | grep newrelic-infra

このような出力を探してください。

bash

$default                    newrelic-infra-5wcv6                     100m (5%)
$0 (0%)      100Mi (5%)       100Mi (5%)

を実行して、ノードのログを取得します。
bash
```
$kubectl logs newrelic-infra-5wcv6
```

コントロールプレーンノードで実行されているポッドからログを取得するには:

コントロールプレーンとしてラベル付けされたノードを取得します。

bash

$kubectl get nodes -l node-role.kubernetes.io/control-plane=""

このような出力を探してください。

bash

$NAME                         STATUS  ROLES          AGE   VERSION
$ip-10-42-24-4.ec2.internal   Ready   control-plane  42d   v1.14.8

前のステップで返されたノードのいずれかで稼働しているNew Relicポッドを取得します。
bash
```
$kubectl get pods --field-selector spec.nodeName=ip-10-42-24-4.ec2.internal -l name=newrelic-infra --all-namespaces
```
このような出力を探してください。
bash
```
$newrelic-infra-whvzt
```
次のコマンドを実行して、ノードのログを取得します。
bash
```
$kubectl logs newrelic-infra-whvzt
```

Kubernetesで実行されているサービスを監視する

Kubernetes のモニタリングサービスは、インフラストラクチャエージェントとオンホスト統合、および自動検出メカニズムを活用して、指定されたセレクターを持つポッドをポイントすることで機能します。

方法については、「Helm Chart を使用してサービスの監視を有効にする」ドキュメントを参照してください。バージョン 2 のこの例を確認してください。これは、 Redisインテグレーションの yaml 構成が nri-bundle チャートの values.yml ファイルに追加されたことを示しています。

newrelic-infrastructure:
    integrations_config:
    - name: nri-redis.yaml
    data:
    discovery:
    command:
    # Run NRI Discovery for Kubernetes
    # https://github.com/newrelic/nri-discovery-kubernetes
    exec: /var/db/newrelic-infra/nri-discovery-kubernetes --tls --port 10250
    match:
    label.app: redis
    integrations:
    - name: nri-redis
    env:
    # using the discovered IP as the hostname address
    HOSTNAME: ${discovery.ip}
    PORT: 6379
    labels:
    env: test

サービスYAMLをKubernetes統合構成に追加します

Kubernetesインテグレーションバージョン 2 を使用している場合は、ConfigMap 内のすべてのファイルが /etc/newrelic-infra/integrations.d/ にマウントされるように、DaemonSet の spec の volumes および volumeMounts セクションにこの ConfigMap のエントリを追加する必要があります。

この機械翻訳は、参考として提供されています。

概要

注意

統合されたコントロールプレーンの監視バージョン2

自動検出とデフォルト設定: `hostNetwork`および `privileged`

コントロールプレーンノードとコントロールプレーンコンポーネントの検出

構成

重要

etcd

APIサーバー

重要

OpenShiftの設定

重要

重要

Kubernetesのログ

マニフェストファイルを使用して詳細ログを有効にする

注意

Helm を使用して詳細ログを有効にする

注意

kube-state-metricsに接続しているポッドのログを取得する。

コントロールプレーンノードで実行されているポッドからログを取得する

Kubernetesで実行されているサービスを監視する

サービスYAMLをKubernetes統合構成に追加します

この機械翻訳は、参考として提供されています。

概要

注意

統合されたコントロールプレーンの監視 バージョン2 .css-21sua1{background:none;border:none;width:0;padding:0;}

自動検出とデフォルト設定: hostNetworkおよび privileged

コントロール プレーン ノードとコントロール プレーン コンポーネントの検出

構成

重要

etcd

APIサーバー

重要

OpenShiftの設定

重要

重要

Kubernetesのログ

Helm を使用して詳細ログを有効にする

kube-state-metricsに接続しているポッドのログを取得する。

コントロールプレーンノードで実行されているポッドからログを取得する

Kubernetesで実行されているサービスを監視する

サービスYAMLをKubernetes統合構成に追加します

統合されたコントロールプレーンの監視バージョン2

自動検出とデフォルト設定: `hostNetwork`および `privileged`

コントロールプレーンノードとコントロールプレーンコンポーネントの検出