Kubernetes統合コンポーネント

New Relic Kubernetes の統合により、Kubernetes をオンプレミスで実行しているかクラウドで実行しているかにかかわらず、クラスターの正常性とパフォーマンスを完全に監視できます。これにより、Kubernetes の名前空間、デプロイ、レプリカセット、ノード、ポッド、コンテナーを可視化できます。

newrelic-infrastructure グラフは 統合の主要コンポーネントです。そのアーキテクチャについては 、こちらをご覧ください。

nri-bundle チャートは、 newrelic-infrastructureを含む統合用の個々のチャートをグループ化します。これにより、1 つのチャートだけを使用して統合を簡単にインストールおよびアップグレードできます。この表でインストールできるデフォルトおよびオプションのコンポーネントについては 、こちらをご覧ください。

アーキテクチャー

newrelic-infrastructureチャートには、 nrk8s-ksm 、 nrk8s-kubelet 、 nrk8s-controlplaneの 3 つのコンポーネントがあります。 最初のものはデプロイメントであり、次の 2 つは DaemonSet です。

各コンポーネントには 2 つのコンテナーがあります。

1. インテグレーションのコンテナで、メトリクスの収集を担当します。
2. メトリクスを New Relic に送信するために使用される、New Relic インフラストラクチャ エージェントを含むコンテナー。

Kub-State-Metricsコンポーネント

Kubernetes 組織自体の下に格納されている OSS プロジェクトkube-state-metricsの上にクラスター状態メトリックを構築します。

特定のデプロイメントnrk8s-ksmが KSM の検出とスクレイピングを処理します。このポッドは存続期間が長く単一であるため、エンドポイント インフォーマーを安全に使用して KSM ポッドの IP を特定し、スクレイピングできます。インフォーマーは、クラスター内のインフォーマーのリストを自動的にローカルにキャッシュし、新しいものを監視して、ポッドの場所を特定するためのリクエストで API サーバーを攻撃することを回避します。

ターゲット メトリックがデフォルトで有効になっていない場合、顧客は KSM でモニターできるようにターゲット メトリックを有効にする必要があります。 たとえば、KSM v2+ では、ラベルと注釈メトリクスがデフォルトで無効になっています。 顧客は、metric-labels-allowlist metric-annotations-allowlistKubernetesクラスタで、 ここで 説明する または オプションを使用して、ターゲット ラベルとアノテーション メトリックをモニターできるようにすることができます。

KSM がサポートするバージョンの詳細については、Bring your own KSMを参照してください。

Kubeletコンポーネント

Kubelet は「Kubernetes エージェント」であり、すべての Kubernetes ノードで実行され、コントロール プレーンの指示に従ってコンテナーを作成する役割を担うサービスです。コンテナ ランタイムと密接に連携しているのは Kubelet であるため、CPU、メモリ、ディスク、ネットワークなどの使用など、統合のためのインフラストラクチャ メトリックの主なソースです。完全に文書化されていませんが、Kubelet API はほとんどの Kubernetes メトリクスの事実上のソースです。

Kubeletのスクレイピングは、通常、リソースの少ない操作です。これと、可能な限りノード間のトラフィックを最小限に抑えるという意図を踏まえて、 nrk8s-kubeletはDaemonSetとして実行され、各インスタンスは、同じノードで実行されているKubeletからメトリックを収集します。

nrk8s-kubelet ノード IP を使用して Kubelet に接続します。このプロセスが失敗した場合、 nrk8s-kubeletはフォールバックして API サーバー プロキシ経由でノードに到達します。多数の kubelet をプロキシすると API サーバーの負荷が増加する可能性があるため、このフォールバック メカニズムは非常に大規模なクラスターの場合に役立ちます。ログで次のようなメッセージを探すことで、API サーバーがプロキシとして使用されているかどうかを確認できます。

Trying to connect to kubelet through API proxy

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

主要な Kubernetes ディストリビューションとして、 nrk8s-controlplaneをhostNetwork: trueで DaemonSet としてデプロイします。構成は、自動検出と静的エンドポイントをサポートするように構成されています。すぐに使用できる幅広いディストリビューションとの互換性を保つために、構成エントリとして幅広い既知のデフォルトを提供しています。コードではなく構成でこれを行うと、必要に応じて自動検出を微調整できます。

セレクタごとに複数のエンドポイントを持ち、正しいエンドポイントを自動的に検出するプローブ メカニズムを追加する可能性があります。これにより、同じセレクターを使用して、ポートやプロトコルなどのさまざまな構成を試すことができます。

etcd CPコンポーネントのスクレイピング構成は以下のようになっており、すべてのコンポーネントに同じ構造と機能が適用されています。

config:
  etcd:
    enabled: true
    autodiscover:
      - selector: "tier=control-plane,component=etcd"
        namespace: kube-system
        matchNode: true
        endpoints:
          - url: https://localhost:4001
            insecureSkipVerify: true
            auth:
              type: bearer
          - url: http://localhost:2381
    staticEndpoint:
      url: https://url:port
      insecureSkipVerify: true
      auth: {}

staticEndpointが設定されている場合、コンポーネントはそれを取得しようとします。エンドポイントに到達できない場合、統合は失敗するため、手動エンドポイントが構成されている場合にサイレント エラーは発生しません。

staticEndpointが設定されていない場合、コンポーネントは自動検出エントリを反復処理して、指定されたnamespaceのselectorに一致する最初のポッドを探し、オプションでDaemonSetの同じノードで実行されます（ matchNodeの場合） trueに設定されます）。ポッドが検出された後、コンポーネントはプローブし、http HEADリクエストを発行し、リストされたエンドポイントを順番に、選択した認証タイプを使用して最初に成功したプローブされたエンドポイントをスクレイプします。

上記では、 etcdコンポーネントの構成の抜粋を示していますが、スクレイピングロジックは他のコンポーネントでも同じです。

コントロールプレーンモニタリングの設定方法の詳細については、 コントロールプレーンモニタリング のページをご確認ください。

ヘルムチャート

Helm は、ソリューションをクラスターにデプロイするために提供する主要な手段です。Helm チャートは、1 つのデプロイメントと、それぞれがわずかに異なる構成を持つ 2 つの DaemonSet を管理します。これにより、チャートや生成されたマニフェストに手動でパッチを適用する必要なく、ニーズに合わせてソリューションを柔軟に適応させることができます。

新しい Helm チャートが公開する新機能の一部は次のとおりです。

• すべてのポッドのsecurityContextを完全に制御
• すべてのポッドのポッドlabelsおよびannotationsのフルコントロール
• 追加の環境変数、 volumes 、およびを追加する機能 volumeMounts
• どのエンドポイントに到達するか、オートディスカバリーの動作、スクレイピングの間隔など、統合の設定を完全にコントロールすることが可能
• Helmのイディオムやスタンダードとの連携強化

切り替え可能なすべてのスイッチの詳細は、 README.mdチャートで確認できます。

コンポーネント

nri-bundle を使用してKubernetesインテグレーションをインストールすると、次の 2 つのコンポーネントがデフォルトでインストールされます。

これらは、 nri-bundle を使用して、または個別にインストールできるオプションのコンポーネントです。