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