コントロールプレーンモニタリングの設定

New Relic は、Kubernetes 統合のためにコントロールプレーンをサポートしており、クラスタのコントロールプレーンコンポーネントからメトリクスを監視・収集することができます。これらのデータは、New Relic で、クエリやチャートの作成に使用することができます。

ヒント

このページでは、特に指定のない限り、 Kubernetes integration v3 を参照しています。v2のコントロールプレーン監視の設定方法の詳細は、以下の特定のセクションに記載されています。

特徴

以下のコントロールプレーンコンポーネントから、メトリクスを監視・収集しています。

etcd: リーダー情報、常駐メモリサイズ、OSスレッド数、コンセンサスプロポーザルデータ、など。サポートされているメトリクスの一覧については、 etcd data を参照してください。
APIサーバー： apiserverリクエストの割合、HTTPメソッドとレスポンスコードによるapiserverリクエストの内訳など。サポートされている指標の完全なリストについては、 APIサーバーデータをご覧ください。
スケジューラ: 要求されたCPU/メモリ対ノードで利用可能なCPU/メモリ、汚染に対する耐性、任意のセットのアフィニティまたはアンチアフィニティなど。サポートされているメトリクスの完全なリストについては、 Scheduler data を参照してください。
コントローラーマネージャー ：常駐メモリサイズ、作成されたOSスレッド数、現在存在するゴルーチンなど。サポートされるメトリクスの完全なリストについては、 Controller Manager data を参照してください。

互換性と要件

AKS、EKS、GKEを含むほとんどのマネージドクラスターは、コントロールプレーンコンポーネントへの外部アクセスを許可していません。そのため、マネージドクラスターでは、New RelicはAPIサーバーのコントロールプレーンメトリックのみを取得でき、etcd、スケジューラー、またはコントローラーマネージャーのコントロールプレーンメトリックは取得できません。
非特権モードでソリューションを展開する場合、コントロールプレーンのセットアップには追加の手順が必要となり、いくつかの注意点が適用されます。
OpenShift 4.xでは、コントロールプレーンコンポーネントのメトリックエンドポイントがデフォルトとは異なるものを使用しています。

コントロールプレーンコンポーネント

Kubernetesコントロールプレーンを監視するタスクは、デフォルトでDaemonSetとしてデプロイされるnrk8s-controlplaneコンポーネントの責任です。このコンポーネントは、 node-role.kubernetes.io/control-planeやnode-role.kubernetes.io/masterなどのマスターノードを識別するために一般的に使用されるラベルを含むnodeSelectorTermsのデフォルトリストを使用して、マスターノードに自動的にデプロイされます。とにかく、このセレクターはvalues.ymlファイルで公開されているため、他の環境に合わせて再構成できます。

これらのセレクターに一致するノードがないクラスターでは、ポッドがスケジュールされないため、リソースを浪費することはなく、ヘルムチャートでcontrolPlane.enabledをfalseに設定することでコントロールプレーンの監視を完全に無効にすることと機能的に同等です。

コントロールプレーンの各コンポーネントには専用のセクションが設けられており、個別に対応することができます。

そのコンポーネントのモニタリングを有効または無効にする
そのコンポーネントを発見するための特定のセレクタと名前空間を定義します。
そのコンポーネントのメトリクスを取得するために使用されるエンドポイントとパスの定義
そのコンポーネントのメトリクスを取得するために使用する必要のある認証メカニズムの定義
オートディスカバリーを完全にスキップするエンドポイントを手動で指定します。

controlPlaneキーの下のnri-kubernetesチャートのvalues.yamlで使用可能なすべての構成オプションを確認できます。

nri-bundle チャートを介して統合をインストールする場合は、対応するサブチャートに値を渡す必要があります。たとえば、 controlPlane コンポーネントで etcd 監視を無効にするには、次のようにします。

newrelic-infrastructure:
  controlPlane:
    config:
      etcd:
        enabled: false

オートディスカバリーとデフォルト設定

デフォルトでは、 Helm Chartは、 Kubeadmやminikubeなど、クラスター内でコントロールプレーンを実行するオンプレミスディストリビューションの一部のコントロールプレーンコンポーネントに対して、すぐに使用できる構成を提供します。

自動検出は検出メカニズムとしてポッドラベルに依存しているため、クラウド環境や、コントロールプレーンコンポーネントがクラスター内で実行されていない場合は機能しないことに注意してください。ただし、これらのシナリオでは、コントロールプレーンコンポーネントに到達できる場合、静的エンドポイントを利用できます。

`hostNetwork` および `privileged`

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

バージョン3以降では、 privilegedフラグはsecurityContextオブジェクトにのみ影響します。つまり、コンテナがホストメトリックにアクセスできるルートとして実行されているかどうかに影響します。ほとんどのディストリビューションでコントロールプレーンのエンドポイントに到達するために必要なhostNetwork: trueを持つコントロールプレーンからメトリックを取得するポッドを除いて、すべての統合コンポーネントはデフォルトでhostNetwork: falseになりました。すべてのコンポーネントのhostNetwork値は、 values.yamlのhostNetworkトグルを使用して、個別にまたはグローバルに変更できます。

クラスタまたはその他のポリシーのために、 hostNetworkでポッドを実行することがまったく受け入れられない場合、コントロールプレーンの監視は不可能であり、 controlPlane.enabledをfalseに設定して無効にする必要があります。

カスタム自動検出または静的エンドポイントを含む高度な構成がある場合は、 hostNetworkなしでコントロールプレーンを監視するために使用できます。プロジェクトのREADMEを確認し、 values.yamlでcontrolPlane.hostNetworkトゥーグルを探します。

カスタムオートディスカバリー

自動検出に使用されるセレクターは、 values.yamlファイルの構成エントリとして完全に公開されます。つまり、コントロールプレーンがクラスターの一部として実行されるほとんどすべての環境に合わせて、セレクターを微調整または置換できます。

オートディスカバリーのセクションは以下のようになります。

autodiscover:
  - selector: "tier=control-plane,component=etcd"
    namespace: kube-system
    # Set to true to consider only pods sharing the node with the scraper pod.
    # This should be set to `true` if Kind is Daemonset, `false` otherwise.
    matchNode: true
    # Try to reach etcd using the following endpoints.
    endpoints:
      - url: https://localhost:4001
        insecureSkipVerify: true
        auth:
          type: bearer
      - url: http://localhost:2381
  - selector: "k8s-app=etcd-manager-main"
    namespace: kube-system
    matchNode: true
    endpoints:
      - url: https://localhost:4001
        insecureSkipVerify: true
        auth:
          type: bearer

autodiscoverセクションには、自動検出エントリのリストが含まれています。各エントリには次のものがあります。

selector：ポッドを検索するために使用される文字列でエンコードされたラベルセレクター。
matchNode：trueに設定すると、検出を実行するDaemonSetの特定のインスタンスと同じノードで実行されているポッドに検出が追加で制限されます。
endpoints：指定されたセレクターのポッドが見つかった場合に試行するエンドポイントのリスト。

さらに、各endpointには次のものがあります。

url：スキームを含む、ターゲットへのURL。 httpまたはhttpsにすることができます。
insecureSkipVerify：trueに設定すると、証明書はhttps URLについてチェックされません。
auth.type：リクエストの認証に使用するメカニズム。現在、次のメソッドがサポートされています。
なし： authが指定されていない場合、リクエストには認証がまったく含まれません。
bearer：KubernetesAPIに対する認証に使用されたものと同じベアラトークンがこのリクエストに送信されます。
mtls：mTLSはリクエストの実行に使用されます。

mTLS

mtlsタイプの場合、以下を指定する必要があります。

endpoints:
  - url: https://localhost:4001
    auth:
      type: mtls
      mtls:
        secretName: secret-name
        secretNamespace: secret-namespace

ここで、 secret-nameは、 secret-namespaceに存在するKubernetes TLSシークレットの名前であり、その特定のエンドポイントに接続するために必要な証明書、キー、およびCAが含まれています。

統合では、このシークレットをマウントするのではなく、実行時にフェッチします。つまり、このシークレットへのアクセスを許可するRBACロールが必要です。ヘルムチャートは、レンダリング時にauth.mtlsエントリを自動的に検出し、 rbac.createがfalseに設定されていない限り、これらの特定のシークレットと名前空間のエントリを自動的に作成します。

私たちの統合は、以下のキーを持つ秘密を受け入れます。

cacert: 署名に使用される PEM エンコードされた CA 証明書。 cert
cert：etcdに提示されるPEMでエンコードされた証明書
key：上記の証明書に対応するPEMでエンコードされた秘密鍵

これらの証明書は、etcdが動作に使用しているのと同じCAによって署名されている必要があります。

これらの証明書を生成する方法は、Kubernetesのディストリビューションによって大きく異なるため、このドキュメントの範囲外です。必要なetcdピア証明書を取得する方法については、ディストリビューションのドキュメントを参照してください。たとえば、Kubeadmでは、マスターノードの/etc/kubernetes/pki/etcd/peer.{crt,key}にあります。

etcdのピア証明書を見つけたり生成したりしたら、シークレットに含まれると思われるキーに合わせてファイル名を変更し、クラスタにシークレットを作成します。

bash

$mv peer.crt cert
$mv peer.key key
$mv ca.crt cacert
$
$kubectl -n newrelic create secret tls newrelic-etcd-tls-secret --cert=./cert --key=./key --certificate-authority=./cacert

最後に、このセクションの冒頭に示されている構成スニペットにシークレット名（ newrelic-etcd-tls-secret ）と名前空間（ newrelic ）を入力できます。 Helm Chartはこの構成を自動的に解析し、RBACロールを作成して、 nrk8s-controlplaneコンポーネントのこの特定のシークレットと名前空間へのアクセスを許可するため、その点で手動のアクションは必要ありません。

静的エンドポイント

オートディスカバリーは、コントロールプレーンがKubernetesクラスター内に存在する場合をカバーする必要がありますが、ディストリビューションや洗練されたKubernetes環境の中には、可用性やリソースの分離など様々な理由から、コントロールプレーンを別の場所で実行するものもあります。

このような場合、コントロールプレーンラベルの付いたポッドがノードで見つかったかどうかに関係なく、任意の固定URLをスクレイプするように統合を構成できます。これは、 staticEndpointエントリを指定することによって行われます。たとえば、外部etcdインスタンスの場合は次のようになります。

controlPlane:
  etcd:
    staticEndpoint:
      url: https://url:port
      insecureSkipVerify: true
      auth: {}

staticEndpoint はautodiscoverエントリのendpointsと同じタイプのエントリであり、そのフィールドは上記で説明されています。ここでは、認証メカニズムとスキーマがサポートされています。

staticEndpointが設定されている場合、 autodiscoverセクションは完全に無視されることに注意してください。

制限

重要

ノード外を指す staticEndpoint を使用している場合 (つまり、 localhostではありません) エンドポイントの場合、 controlPlane.kind DaemonSet から Deploymentに変更する必要があります。

staticEndpointを使用すると、すべての nrk8s-controlplane Pod が上記のエンドポイントに到達してスクレイピングしようとします。これは、 nrk8s-controlplane が DaemonSet (デフォルト) の場合、DaemonSet のすべてのインスタンスがこのエンドポイントをスクレイピングすることを意味します。 localhostを指している場合はこれで問題ありませんが、エンドポイントがノードに対してローカルでない場合、メトリックが重複し、課金対象の使用量が増える可能性があります。 staticEndpoint 使用して非ローカル URL を指している場合は、必ず controlPlane.kind を Deployment に変更してください。

上記と同様の理由により、現在のところ、あるコントロールプレーンコンポーネントにオートディスカバリーを使用し、他のコンポーネントにスタティックエンドポイントを使用することはできません。これは既知の制限事項であり、将来のバージョンでの対応を検討しています。

最後に、 staticEndpointではコンポーネントごとに1つのエンドポイントのみを定義できます。これは、異なるホストに複数のコントロールプレーンシャードがある場合、現在、それらを個別にポイントすることはできないことを意味します。これは、将来のバージョンで対処するために取り組んでいる既知の制限でもあります。当面の回避策は、別の場所にあるさまざまなシャードのメトリックを集約し、集約された出力をstaticEndpoint URLにポイントすることです。

マネージド環境やクラウド環境のためのコントロールプレーン監視

EKSやGKEのような一部のクラウド環境では、Kubernetes API Serverからメトリクスを取得することができます。これは静的なエンドポイントとして簡単に設定できます。

controlPlane:
  affinity: false  # https://github.com/helm/helm/issues/9136
  kind: Deployment
  # `hostNetwork` is not required for monitoring API Server on AKS, EKS
  hostNetwork: false
  config:
    etcd:
      enabled: false
    scheduler:
      enabled: false
    controllerManager:
      enabled: false
    apiServer:
     staticEndpoint:
       url: "https://kubernetes.default:443"
       insecureSkipVerify: true
       auth:
         type: bearer

なお、この機能はAPIサーバーにのみ適用され、クラウド環境ではetcd、スケジューラー、コントローラーマネージャーにはアクセスできませんのでご注意ください。

さらに、特定のマネージド環境またはクラウド環境によっては、KubernetesサービスがAPIサーバーのさまざまなインスタンス間でトラフィックの負荷を分散する可能性があることに注意してください。この場合、ロードバランサーによって選択されている特定のインスタンスに依存するメトリックは信頼できません。

ランチャーRKE1のコントロールプレーンモニタリング

Rancher Kubernetes Engine（RKE1）を利用してデプロイされたクラスターは、コントロールプレーンコンポーネントを、Kubeletによって管理されるポッドとしてではなくDockerコンテナーとして実行します。そのため、統合ではこれらのコンテナーを自動検出できず、統合構成のstaticEndpointセクションですべてのエンドポイントを手動で指定する必要があります。

統合は、直接接続するか、使用可能な認証方法（サービスアカウントトークン、カスタムmTLS証明書、またはなし）を使用するか、プロキシを介して、さまざまなエンドポイントに到達できる必要があります。

たとえば、スケジューラとコントローラマネージャのメトリックを到達可能にするために、 --authorization-always-allow-pathsフラグを追加して、 /metricsまたは--authentication-kubeconfigと--authorization-kubeconfigでトークン認証を有効にする必要がある場合があります。

すべてのコンポーネントが指定されたポートで到達可能であると仮定すると、次の構成はAPIサーバー、スケジューラー、およびコントローラーマネージャーを監視します。

controlPlane:
  kind: DaemonSet
  config:
    scheduler:
      enabled: true
      staticEndpoint:
        url: https://localhost:10259
        insecureSkipVerify: true
        auth:
          type: bearer
    controllerManager:
      enabled: true
      staticEndpoint:
        url: https://localhost:10257
        insecureSkipVerify: true
        auth:
          type: bearer
    apiServer:
      enabled: true
      staticEndpoint:
        url: https://localhost:6443
        insecureSkipVerify: true
        auth:
          type: bearer

この例では、統合は各staticEndpointにローカルに接続しているため、 hostNetworkオプションがtrueに設定されている各コントロールプレーンコンポーネントの同じノードで実行する必要があります。したがって、 controlPlane.kindはDaemonSetとして保持する必要があります。また、DaemonSetには、監視するすべてのコントロールプレーンノードですべてのインスタンスが実行されるように、アフィニティルール、nodeSelector、および許容値を構成する必要があります。

node-role.kubernetes.io/controlplaneラベルを確認すると、コントロールプレーンノードを認識できます。このラベルは、統合のデフォルトのアフィニティルールによってすでに考慮されています。

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

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

これらのバージョンでは、オートディスカバリーオプションの柔軟性が低く、外部エンドポイントをサポートしていないことにご注意ください。お早めにバージョン3 にアップデートされることを強くお勧めします。変更点をご覧ください Kubernetesとの統合の。

マスターノードとコントロールプレーンコンポーネントの発見

Kubernetes統合は、 kubeadmラベル付け規則に依存して、マスターノードとコントロールプレーンコンポーネントを検出します。これは、マスターノードにnode-role.kubernetes.io/master=""またはkubernetes.io/role="master"のラベルを付ける必要があることを意味します。

コントロールプレーンコンポーネントには、 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`

統合は、マスター・ノード内で実行されていることを検出すると、上の表に記載されているラベルに一致するポッドを探して、ノード上でどのコンポーネントが実行されているかを確認しようとします。実行中のコンポーネントごとに、統合はそのメトリクス・エンドポイントにリクエストを行います。

構成

マスターノード内で動作するエージェントは、コントロールプレーンの監視が自動的に行われます。クライアントのリクエストに相互TLS認証（mTLS）を使用しているため、実行に余分な手順が必要なコンポーネントはetdのみです。APIサーバーは、 Secure Port を使って問い合わせを行うように設定することもできます。

重要

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の設定

Kubernetes Integrationのバージョン3には、OpenShiftクラスタ内のコントロールプレーンコンポーネントを自動検出するデフォルト設定が含まれているため、etdを除くすべてのコンポーネントですぐに動作するはずです。

OpenShift 環境ではメトリクスのエンドポイントが mTLS 認証を必要とするように構成されているため、Etcd はすぐにはサポートされません。当社の統合は、この構成でetcdのメトリクスを取得するためのmTLS認証をサポートしていますが、必要なmTLS証明書を手動で作成する必要があります。これは、ユーザーからの明示的な承認なしに当社の統合に広範な権限を与えることを避けるために必要です。

mTLSシークレットを作成するには、以下の本セクションの手順に従ってください。その後、 mtlsセクションで説明されているように、新しく作成されたシークレットを使用するように統合を構成してください。

重要

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

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

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の設定を参照してください。

OpenShift での etcd 用 mTLS の設定

以下の手順で、 OpenShift 4.xでetcdの相互TLS認証を設定してください。

etcdクライアント証明書をクラスターから不透明なシークレットにエクスポートします。デフォルトのマネージドOpenShiftクラスターでは、シークレットの名前はkube-etcd-client-certsで、 openshift-monitoring名前空間に保存されます。

bash

$kubectl get secret etcd-client -n openshift-etcd -o yaml > etcd-secret.yaml

etcd-secret.yaml の内容は次のようになります。

apiVersion: v1
 data:
   tls.crt: <CERT VALUE>
   tls.key: <KEY VALUE>
 kind: Secret
 metadata:
   creationTimestamp: "2023-03-23T23:19:17Z"
   name: etcd-client
   namespace: openshift-etcd
   resourceVersion: 
   uid: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
 type: kubernetes.io/tls

必要に応じて、シークレットの名前と名前空間を意味のあるものに変更します。次の手順では、シークレットの名前と名前空間がそれぞれ mysecret と newrelic に変更されていることを前提としています。
メタデータ部のこれらの不要なキーを削除します。
- creationTimestamp
- resourceVersion
- uid
マニフェストを新しい名前と名前空間でインストールします。
bash
```
$kubectl apply -n newrelic -f etcd-secret.yaml
```

mtls セクションの説明に従って、新しく作成されたシークレットを使用するように統合を構成します。これは、 nri-bundle チャートを介して統合をインストールする場合、 values.yaml に次の構成を追加することで実行できます。

newrelic-infrastructure:
 controlPlane:
   enabled: true
   config:
     etcd:
       enabled: true
       autodiscover:
         - selector: "app=etcd,etcd=true,k8s-app=etcd"
           namespace: openshift-etcd
           matchNode: true
           endpoints:
             - url: https://<ETCD_ENDPOINT>:<PORT>
               insecureSkipVerify: true
               auth:
                 type: mTLS
                 mtls:
                   secretName: mysecret
                   secretNamespace: newrelic

自分のデータを見る

統合が正しく設定されていれば、 Kubernetes cluster explorer には、以下のように、すべてのコントロールプレーンコンポーネントとそのステータスが専用のセクションに表示されます。

one.newrelic.com > All capabilities > Kubernetes Cluster Explorer: Kubernetes Cluster Explorer を使用して、クラスターのコントロールプレーンコンポーネントからメトリクスを監視および収集します。

また、この NRQL クエリでコントロールプレーンデータを確認することもできます。

SELECT latest(timestamp) FROM K8sApiServerSample, K8sEtcdSample, K8sSchedulerSample, K8sControllerManagerSample FACET entityName where clusterName = '_MY_CLUSTER_NAME_'

ヒント

それでもコントロールプレーンのデータが表示されない場合は、 Kubernetesインテグレーションのトラブルシューティングで説明している解決方法を試してみてください。データが見えない。

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

コントロールプレーンモニタリングの設定

ヒント

特徴

互換性と要件

コントロールプレーンコンポーネント

オートディスカバリーとデフォルト設定

`hostNetwork` および `privileged`

カスタムオートディスカバリー

mTLS

静的エンドポイント

制限

重要

マネージド環境やクラウド環境のためのコントロールプレーン監視

ランチャーRKE1のコントロールプレーンモニタリング

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

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

マスターノードとコントロールプレーンコンポーネントの発見

構成

重要

etcd

APIサーバー

重要

OpenShiftの設定

統合バージョン2でのOpenShiftの設定

重要

重要

OpenShift での etcd 用 mTLS の設定

自分のデータを見る

ヒント

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

コントロールプレーンモニタリングの設定

ヒント

特徴 .css-21sua1{background:none;border:none;width:0;padding:0;}

互換性と要件

コントロールプレーンコンポーネント

オートディスカバリーとデフォルト設定

hostNetwork および privileged

カスタムオートディスカバリー

mTLS

静的エンドポイント

制限

重要

マネージド環境やクラウド環境のためのコントロールプレーン監視

ランチャーRKE1のコントロールプレーンモニタリング

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

OpenShiftの設定

統合バージョン2でのOpenShiftの設定

OpenShift での etcd 用 mTLS の設定

自分のデータを見る

ヒント

特徴

`hostNetwork` および `privileged`

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