New Relic Kubernetes コンポーネント

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

アーキテクチャー

newrelic-infrastructureグラフは統合の主要コンポーネントです。nrk8s-ksm 、 nrk8s-kubelet 、 nrk8s-controlplaneの 3 つの異なるコンポーネントに分かれています。最初はデプロイメントで、次の 2 つは DaemonSet です。

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

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

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

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

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

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

重要

customAttributesを使用して、特定のノードに厳密には関連付けられていないエンティティに関連するアンプルに属性を追加します: K8sNamespaceSample 、 K8sDeploymentSample 、 K8sReplicasetSample 、 K8sDaemonsetSample 、 K8sStatefulsetSample 、 K8sServiceSample 、およびK8sHpaSample .

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で切り替えることができるすべてのスイッチの詳細を確認できます。