Kubernetes の統合は、GKE、EKS、AKS、OpenShift など、さまざまなプラットフォームと互換性があります。それぞれに、当社の統合との互換性が異なります。詳細については、このページを参照してください。
要件
New Relic Kubernetes 統合には、New Relic アカウントが必要です。まだお持ちでない場合は、以下で無料の New Relic アカウントを作成して、今すぐデータの監視を開始してください。
また、 New Relic Infrastructureと互換性のあるLinux ディストリビューションも必要です。
重要
kube-state-metricsインテグレーションバージョン3.6.0以降ではv2以上がサポートされています 以上。Kubernetesインテグレーションをバージョン3.5.0までインストールします
kube-state-metrics1.9.8 以下を使用している場合。kube-state-metricsを v1.9.8 から v2 以上に更新する場合は、いくつかの変数が変更されている可能性があるため、values.yamlファイルを確認してください。
Helm の互換性と要件
Helmがインストールされており、サポートされている最小バージョンが v3 であることを確認してください。 Kubernetesインテグレーションのバージョン 3 には、Helm バージョン 3 が必要です。
クラスターの表示名を選択します。 たとえば、次の出力を使用できます。
bash$kubectl config current-context
マニフェストの互換性と要件
カスタムマニフェストがHelmの代わりに使用されている場合、まずkubectl delete -f previous-manifest-file.ymlを使用して古いインストレーションを削除してから、ガイド付きインストーラを再度実行する必要があります。これにより、kubectl apply -f manifest-file.ymlを使用してデプロイできる一連のマニフェストが更新されます。
コンテナ ランタイム
Kubernetes の統合は CRIに依存しません。Containerd との互換性が特にテストされています。Dockershim はリリース 1.24 の時点で Kubernetes プロジェクトから削除されていることに注意してください。詳細については 、Dockershim の削除に関する FAQ を 参照してください。
互換性
重要
Openshiftを使用している場合は、ほとんどの場合kubectlを使用することもできますが、 kubectlにはoc loginやoc admなどのコマンドがないことに注意してください。 kubectlの代わりにocを使用する必要があるかもしれません。
私たちの統合には互換性があり、次の Kubernetes バージョンで継続的にテストされています。
バージョン | |
|---|---|
Kubernetesクラスタ | 1.27から1.31 |
重要
Kubernetes バージョン 1.26 以降では、 @autoscaling/v2beta2 API が@autoscaling/v2に置き換えられました。 引き続き HorizontalPodAutoscaling メトリックス レポートを実行するには、 Kubernetesバージョン 1.26 以降のクラスタに kube-state-metrics バージョン 2.7 以降をインストールする必要があります。これは、kube-state-metrics v2.7 以降のみが @autoscaling/v2 APIをサポートできるためです。
Kubernetesフレーバー
Kubernetes 統合は、さまざまなフレーバーと互換性があります。次のものとの統合をテストしました。
フレーバー | メモ |
|---|---|
ミニクベ | |
親切 | |
K3s | |
クベアドム | |
Amazon Elastic Kubernetes Service（EKS） | |
Amazon Elastic Kubernetes Service Anywhere（EKS-Anywhere） | |
Fargate上のAmazonElasticKubernetesサービス（EKS-Fargate） | |
Rancher Kubernetesエンジン（RKE1） | コントロール プレーン コンポーネントをインストルメント化するには、 追加の構成が必要です |
Azure Kubernetes Service（AKS） | |
Google Kubernetes Engine（GKE） | 標準および自動操縦モードと互換性があります。 |
OpenShift | バージョン4.14でテスト済み |
VMwareタンズ | VMware Tanzu（Pivotal Platform）のバージョン2.5～2.11、Ops Managerのバージョン2.5～2.10に対応 |
インストール方法によっては、コントロールプレーンの監視が利用できないか、追加の構成が必要になる場合があります。
例えば：
- etcd、スケジューラー、およびコントローラー マネージャーに必要なメトリックを公開するエンドポイントがないため、API サーバー メトリックのみがスクレイピング可能であり、マネージド クラスター (GKE、EKS、AKS) コントロール プレーンをインストルメント化するために使用できます。
- ランチャーコントロールプレーンをインストルメント化するには、コンポーネント
/metricsがデフォルトで常に到達可能であるとは限らず、自動検出できないため、 追加の構成が必要です。
リソース要件
New Relic Kubernetesインテグレーションを導入する場合、監視コンポーネントが効率的に動作するように適切なリソースを割り当てることが重要です。
以下は、 インフラストラクチャチャートによる各コンポーネントのデプロイに対する推奨される最小リソース要求と制限です。
Kubeletコンポーネント
各ノードにデプロイされた Kubelet コンポーネント ポッドには、次のコンテナが含まれます。
Kubelet コンテナ
CPU ：
- リクエスト：
100m
- リクエスト：
メモリ：
- リクエスト：
150M - 制限:
300M
- リクエスト：
エージェントコンテナ
CPU ：
- リクエスト：
100m
- リクエスト：
メモリ：
- リクエスト：
150M - 制限:
300M
- リクエスト：
Kube State メトリクス コンポーネント
KSM コンテナ
CPU ：
- リクエスト：
100m
- リクエスト：
メモリ：
- リクエスト：
150M - 制限:
850M
- リクエスト：
フォワーダーコンテナ
CPU ：
- リクエスト：
100m
- リクエスト：
メモリ：
- リクエスト：
150M - 制限:
850M
- リクエスト：
コントロールプレーンコンポーネント
CPU ：
- リクエスト：
100m
- リクエスト：
メモリ：
- リクエスト：
150M - 制限:
300M
- リクエスト：
エージェントコンテナ
CPU ：
- リクエスト：
100m
- リクエスト：
メモリ：
- リクエスト：
150M - 制限:
300M
- リクエスト：
以下は、 nri-bundleの一部としてデプロイされる他のコンポーネントに必要な推奨リソース要求と制限です。
メタデータインジェクション
CPU ：
- リクエスト：
100m
- リクエスト：
メモリ：
- リクエスト：
30M - 制限:
80M
- リクエスト：
ロギング
各ノードにデプロイされた New Relic ログ ポッドには、次のコンテナが含まれます。
CPU ：
- リクエスト：
250m - 制限:
500m
- リクエスト：
メモリ：
- リクエスト：
64M - 制限:
128M
- リクエスト：
考察
クラスタ サイズ: これらのリソースの推奨事項は、一般的なクラスタ サイズに対するものです。 より多くのノードとポッドを持つ大規模なクラスターでは、追加のデータ量を処理するためにリソースの割り当てを増やす必要がある場合があります。
カスタム設定: 追加機能またはカスタム設定を有効にする場合は、それに応じてリソースを調整することを検討してください。
監視と調整: デプロイメント後、これらのポッドのリソース使用状況を監視し、実際の使用量に基づいてリクエストと制限を調整して、パフォーマンスとコストを最適化します。
これらのリソース仕様は、New Relic Kubernetesインテグレーションのデプロイに使用される Helm チャートの values.yaml ファイルで調整できます。 これらのリソース要件が満たされていることを確認することで、New Relic を使用してKubernetesクラスタの効率的かつ効果的な監視を維持できます。