• English日本語한국어
  • ログイン今すぐ開始

Kubernetesインテグレーションのインストール

New Relic Kubernetesインテグレーションにより、New Relic Infrastructureエージェントを活用して、環境の健全性とパフォーマンスのフルオブザーバビリティを実現します。このエージェントは、KubernetesイベントインテグレーションPrometheusエージェントNew RelicログKubernetesプラグインなど、いくつかのNew Relicインテグレーションを使用してクラスタからテレメトリーデータを収集します。

インストールオプション

Kubernetesインテグレーションをインストールするには、こちらのガイド付きインストールの手順に従うことをお勧めします。サーバー、VM、特権のない環境には、このインタラクティブなインストールツールをお勧めします。

ガイド付きインストールエクスペリエンスでは、New Relic Kubernetesインテグレーションのインストールプロセスが簡素化され、有効にする機能や収集対象データの制御を行えるようになります。また、Kubernetesインテグレーションと並行して、事前に構築されたオプションのリソース(ダッシュボードやアラートなど)を含むクイックスタートオプションも用意しており、Kubernetesクラスタを即座に可視化できます。

次の3つのオプションから1つを選択できます。

  1. New Relic CLI

  2. 必要な値が事前に入力されたHelmコマンド

  3. プレーンなマニフェスト

    Kubernetesインテグレーションガイド付きインストールのナビゲーション

    ガイド付きインストールを開始したら、以下の情報を使用して設定に関する意思決定を行います。

    ヒント

    以降の手順では、クイックスタートの準備手順をスキップします。クイックスタートによるガイド付きインストールを選択した場合は、Kubernetesのクイックスタートインストレーションの確認ページとインストレーションの計画ページをクリックするだけで、以下に説明するメインのガイド付きインストールページにアクセスできます。

    インストールの準備

    ガイド付きインストール用にKubernetesシステムを準備します。

    • カスタムマニフェストがHelmの代わりに使用されている場合、まずkubectl delete -f previous-manifest-file.ymlを使用して古いインストレーションを削除してから、ガイド付きインストーラを再度実行する必要があります。これにより、kubectl apply -f manifest-file.ymlを使用してデプロイできる一連のマニフェストが更新されます。

    • 対応のKubernetesバージョンを使用していること、当社の互換性と要件のページに記載されたマネージドサービスまたはプラットフォームに関する事前の注意事項を必ず確認してください。

    • New Relic を持っていることを確認してください。無料のアカウントを設定できます。クレジットカードは不要です。

    • newrelic dockerhub(https://hub.docker.com/u/newrelic)とGoogleのレジストリ(registry.k8s.io)ドメインが許可リストに追加されていることを確認してください。ここは、インストール時にコンテナイメージをプルする場所です。通常、registry.k8s.ioはリージョンに応じてローカルレジストリドメイン(asia-northeast1-docker.pkg.devなど)にリダイレクトされるため、ホワイトリストに追加されるさらなるGoogleレジストリドメインを特定するには、コマンドに従う必要があります。

      マネージドクラウドにインテグレーションをインストールする場合は、先に進む前に、これらの予備ノートを参照してください。

    ガイド付きインストールの開始

    以下のオプションのいずれかをクリックして、ガイド付きインストールを開始します。

    ガイド付きインストールオプション

    説明

    ガイド付きインストール

    EUデータセンターを使用していないNew Relic組織で、クイックスタートのボーナスダッシュボードやアラートを必要としない場合に使用します。

    ガイド付きインストール(EU)

    EUデータセンターを使用しているNew Relic組織で、クイックスタートのボーナスダッシュボードやアラートを必要としない場合に使用します。

    クイックスタートによるガイド付きインストール

    EUデータセンターを使用していないNew Relic組織で、クイックスタートのボーナスダッシュボードやアラートのインストールが必要な場合は、このオプションを使用します。

    インストールの設定

    Kubernetesインテグレーションの設定ページで、次のフィールドに入力します。

    フィールド

    説明

    お客様のデータをこのアカウントに送信します

    Kubernetesデータを書き込むNew Relicアカウントを選択します。

    クラスタ名

    クラスタ名は、Kubernetesデータのタグ付けに使用する名前です。これにより、このインテグレーションをインストールするクラスタに固有のデータをフィルタリングできます。これは、複数のクラスタをNew Relicアカウントに接続する場合に重要なので、わかりやすい名前を選択してください。

    インテグレーションのネームスペース

    インテグレーションのネームスペースは、クラスタ内にKubernetesインテグレーションを格納するために使用するネームスペースです。newrelicのデフォルトのネームスペースを使用することをお勧めします。

    追加データの選択

    このページで、収集する追加データを選択し、適切なオプションを選択します。

    Prometheusエンドポイントをスクレイピング

    このオプションを選択すると、Prometheusをエージェントモードでインストールし、クラスタで公開されているPrometheusエンドポイントからメトリクスを収集します。各オプションの詳細を表示するには、コラプサーを展開します。

    ログデータの収集

    インストールUI内でログデータの詳細をカスタマイズできます。

    Pixieを通じてサービスレベルの洞察、フルボディのリクエスト、アプリケーションプロファイルを実現

    Pixieは、eBPFを使用してテレメトリーデータを自動的に収集する、Kubernetesアプリケーション用のオープンソースオブザーバビリティツールです。クラスタにはPixieがインストールされていないものの、 New RelicプラットフォームでPixieの強力なテレメトリーデータ収集と可視化を活用したい場合は、Pixieを通じてサービスレベルの洞察、フルボディのリクエスト、アプリケーションプロファイルを有効にするをチェックしてください。

    すでにCommunity Cloudを使用している場合は、Community CloudでホストされているPixieはこのクラスタですでに実行されていますを選択します。Pixieでのさまざまなホスティング方法については、以下の点に留意してください。New Relicは、Pixieホスティングオプションごとに異なるレベルのインテグレーションをサポートします。

    インストールの完了

    ガイド付きインストールの最終手順で、次のインストール方法のいずれかを選択して、Kubernetesのインストール設定を確定します。

    • ガイド付きインストール(推奨):このオプションは、newrelic-cli CLIを自動的にダウンロードして使用し、Kubernetesインテグレーションをインストールして設定します。

    • Helm 3Helmを使用してKubernetesインテグレーションをインストールして設定する場合は、このオプションを使用します。このオプションはnri-bundleHelmチャートをインストールします。ここで説明するオプションを使用すると、さらに設定できます。

    • マニフェスト :YAML形式でKubernetesマニフェストを生成し、kubectlを使用して手動でインストールする場合は、このオプションを選択します。

      ヒント

      データが表示されませんか?上記の手順を完了してもデータが表示されない場合は、このトラブルシューティングページを確認してください。

WindowsベースのKubernetesシステムを使用している場合は、このオプションを使用してください。Windowsインテグレーションにはさまざまな制限があります。

プレビュー

この機能は現在プレビュー段階です。

互換性および要件

Kubernetesインテグレーションをインストールする前に、互換性と要件を確認してください。

重要

Windowsでコンテナを使用する場合、コンテナホストのバージョンとコンテナイメージのバージョンが同じである必要があります。Kubernetesインテグレーションは、WindowsバージョンLTSC 2019(1809)、20H2、LTSC 2022で実行できます。

Windowsのバージョンを確認するには:

  1. コマンドウィンドウを開きます。

  2. 次のコマンドを実行します。

    bash
    $
    Reg Query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion" /v
    $
    ReleaseIdcmd.exe

    例:BusyBoxコンテナからWindows用Kubernetesを取得する

    以下のコマンドを実行します。

    bash
    $
    kubectl exec -it busybox1-766bb4d6cc-rmsnj -- Reg Query
    $
    "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion" /v ReleaseId

    次のように表示されます。

    bash
    $
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion
    $
    ReleaseId REG_SZ 1809

    リリースIDとOSバージョン間の有用なマッピングについては、こちらを参照してください。

    インストール

    Helmを使用して、Windows用のKubernetesインテグレーションをインストールできます。Windowsの異なるビルドバージョン(1809と2004)を持つノードを含むクラスタに、インテグレーションをインストールする方法の例を参照してください。

  3. New Relic Helmチャートリポジトリを追加します。

    bash
    $
    helm repo add newrelic https://helm-charts.newrelic.com
  4. newrelicの名前空間の作成:

    bash
    $
    kubectl create namespace newrelic
  5. kube-state-metricsをインストールします。

    bash
    $
    helm repo add ksm https://kubernetes.github.io/kube-state-metrics
    $
    helm install ksm ksm/kube-state-metrics --version 2.13.2

    重要

    このコマンドは、インテグレーションの必須の依存関係であるkube-state-metricsを、Linuxノードにインストールするためのものです。Linux以外のノードにインストールすることはサポートされていないため、Linux以外のノードにインストールすると、デプロイメントが失敗するおそれがあります。nodeSelectorを使用して、Linuxノードを選択することをお勧めします。kube-state-metricsデプロイメントを編集することで、これを実行できます。

  6. Helmで使用する次のデータを含むvalues-newrelic.yamlファイルを作成します。

    global:
    licenseKey: _YOUR_NEW_RELIC_LICENSE_KEY_
    cluster: _K8S_CLUSTER_NAME_
    enableLinux: true # Set to true if your cluster also has linux nodes
    enableWindows: true
    windowsOsList:
  • version: 2019 # Human-readable version identifier imageTag: 2-windows-1809-alpha # Tag to be used for nodes running the windows version above buildNumber: 10.0.17763 # Build number for your nodes running the version above. Used as a selector.
  • version: 20h2 imageTag: 2-windows-20H2-alpha buildNumber: 10.0.19042
  • version: 2022 imageTag: 2-windows-ltsc2022-alpha buildNumber: 10.0.20348 nodeSelector: kubernetes.io/os: linux # Selector for Linux installation. windowsNodeSelector: kubernetes.io/os: windows # Selector for Windows installation.
  1. 以下を使用してインテグレーションをインストールします。

    bash
    $
    helm upgrade --install newrelic newrelic/newrelic-infrastructure \
    >
    --namespace newrelic --create-namespace \
    >
    --version 2.7.2 \
    >
    -f values-newrelic.yaml
  2. ポッドがデプロイされ、安定した状態になっていることを確認します。

    bash
    $
    kubectl -n newrelic get pods -w

    Helmチャートは、リストにあるWindowsの各バージョンに1つのDaemonSetを作成し、NodeSelectorを使用して各ノードに対応するポッドをデプロイします。

    制限

    Windows用Kubernetesインテグレーションには次の制限が適用されます。

  • WindowsエージェントはKubernetesサンプルK8sNodeSampleK8sPodSampleなど)のみを送信します。

    • SystemSampleStorageSampleNetworkSample、およびProcessSampleは生成されません。
    • Windows kubeletにはKubernetesメトリクスがないため、一部のKubernetesメトリクスが欠落しています。
  • ノード:

    • fsInodes: 送信されません
    • fsInodesFree: 送信されません
    • fsInodesUsed: 送信されません
    • memoryMajorPageFaultsPerSecond: 値として常にゼロを返します
    • memoryPageFaults: 値として常にゼロを返します
    • memoryRssBytes: 値として常にゼロを返します
    • runtimeInodes: 送信されません
    • runtimeInodesFree: 送信されません
    • runtimeInodesUsed: 送信されません
  • ポッド:

    • net.errorsPerSecond: 送信されません
    • net.rxBytesPerSecond: 送信されません
    • net.txBytesPerSecond: 送信されません
  • コンテナ:

    • containerID: 送信されません
    • containerImageID: 送信されません
    • memoryUsedBytes:UIでは、これはポッドをクリックすると表示されるポッドカードに表示され、データは表示されません。代わりにmemoryWorkingSetBytesを使用するようにチャートを更新することで、この問題はまもなく修正される予定です。
  • ボリューム:

    • fsUsedBytes: ゼロ、よってfsUsedPercentはゼロです

    Windows Kubeletでの既知の問題

    KubeletのWindowsバージョンには、インテグレーションによるデータの取得を妨げる可能性がある問題がいくつかあります。

  • 問題 90554:この問題により、インテグレーションが/stats/summaryエンドポイントにリクエストを行うと、Kubeletが500エラーを返します。この問題はKubernetes 1.19リリースに含まれる予定で、リリース1.16.11、1.17.7、1.18.4にバックポートされています。この問題に対するインテグレーション側の解決策はありません。できるだけ早くいずれかのパッチバージョンに更新することをお勧めします。詳細ログを有効にし、次のタイプのメッセージを検索すると、この問題の影響を受けているかどうかを確認できます。

    bash
    $
    error querying Kubelet. Get "https://<KUBELET_IP>/stats/summary": error calling kubelet endpoint. Got status code: 500
  • 問題 87730:この問題により、最小限の負荷で実行すると、Kubeletメトリクスが非常に遅くなります。タイムアウトエラーが発生して、インテグレーションが失敗します。この問題に対するパッチがKubernetes 1.18に追加され、1.15.12、1.16.9、1.17.5にバックポートされました。できるだけ早くいずれかのパッチバージョンに更新することをお勧めします。この問題を軽減するには、TIMEOUT設定オプションを使用して、インテグレーションタイムアウトを増やすことができます。詳細ログを有効にし、次のタイプのメッセージを検索すると、この問題の影響を受けているかどうかを確認できます。

    bash
    $
    error querying Kubelet. Get "https://<KUBELET_IP>/stats/summary": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

EKS FargateでKubernetesワークロードをモニタリングする場合は、このオプションを使用します。このインテグレーションでは、モニタリングが必要な各ポッドにInfrastructureエージェントとnri-kubernetesインテグレーションを含むサイドカーが自動的に挿入されます。

プレビュー

この機能は現在プレビュー段階です。

New Relicは、モニタリングが必要な各ポッドにインフラストラクチャエージェントと、nri-kubernetesインテグレーションを含むサイドカーを自動挿入することで、EKS FargateでのKubernetesワークロードのモニタリングをサポートします。

同じKubernetesクラスタにEC2ノードも含まれている場合、ソリューションがすべてのノードにDaemonSetとしてデプロイされます。EC2ノードでスケジュールされたポッドにサイドカーが挿入されることはなく、 DaemonSetがFargateノードにデプロイされることもありません。以下に、FargateノードとEC2ノードの両方を含むハイブリッドインスタンスの例を示します。

混合環境のインテグレーションでは、Fargateノードのサイドカーのみが使用されます。

スケジュールされている場所やFargateノード、EC2ノードかに関係なく、New RelicはすべてのKubernetesオブジェクトでサポートされているすべてのメトリクスを収集します。Fargateによって課された制限により、New RelicインテグレーションはFargateノード上の非特権モードでの実行に限定されます。つまり、実行中のプロセスなど、通常はホストから直接取得されるメトリクスがFargateノードでは利用できません。

どちらのシナリオでも、エージェントはKube State Metrics(KSM)、Kubelet、cAdvisorからデータを収集し、データを同じ形式で送信します。

重要

他のKubernetesクラスタと同様に、このソリューションでもKube State Metrics(KSM)インスタンスをデプロイして監視する必要があります。Helmチャートやインストーラーはデフォルトで自動的にこれを行いますが、クラスタにKSMの動作インスタンスがすでにある場合は、この動作を無効にすることができます。このKSMインスタンスは、他のワークロードと同様に監視されます。Fargateノードでスケジュールされた場合はサイドカーを挿入し、EC2ノードでスケジュールされた場合はDaemonSetのローカルインスタンスを挿入します。

Kubernetes用New Relicソリューションの他のコンポーネント(nri-prometheusnri-metadata-injectionnri-kube-eventsなど)には特別な特徴はなく、Fargate以外の環境と同様に、Helmチャートによって通常どおりデプロイされます。

インストレーション

EKS FargateクラスタにNew Relicの完全なオブザーバビリティをインストールするには、次の2つの選択肢から選択できます。

  • 自動インジェクション(推奨)

  • 手動インジェクション

    どちらのアプローチを選択しても、インストール後のエクスペリエンスはまったく同じです。唯一の違いは、コンテナの注入方法です。New Relicのインフラストラクチャモニタリングオペレーターを使用して、自動インジェクションを設定することをお勧めします。これにより、監視する各デプロイメントを手動で編集する必要がなくなります。

    自動インジェクション(推奨)

    デフォルトでは、Fargateサポートが有効になっている場合、New Relicはオペレーターをクラスタ(newrelic-infra-operator)にデプロイします。デプロイが完了すると、このオペレーターはFargateノードにスケジュールされているポッドにモニタリングサイドカーを自動挿入し、同時にSecretsClusterRoleBindings、およびその他の関連リソースの作成と更新も管理します。

    このオペレーターは、ポッドと名前空間の両方のラベルセレクターを使用して、インジェクションの範囲を狭めたり広げたりできる、多数の高度な設定オプションを受け入れます。

    オペレーターが行うこと

    オペレーターはバックグラウンドでMutatingWebhookConfigurationを設定し、クラスタ内に作成されるポッドオブジェクトを変更できるようにします。このイベントで、作成中のポッドがユーザーの設定と一致する場合、オペレーターは次のことを行います。

  1. New Relic Kubernetesインテグレーションを含むポッドにサイドカーコンテナを追加します。

  2. シークレットが存在しない場合は、サイドカーがデータを報告するために必要なNew Relic

    を含む、ポッドと同じ名前空間にシークレットを作成します。

  3. ポッドのサービスアカウントを、オペレーターチャートが以前作成したClusterRoleBindingに追加します。これにより、このサイドカーにKubernetesメトリクスエンドポイントにアクセスするために必要な権限が付与されます。

    ClusterRoleBindingは、挿入されるポッドに次の権限を付与します。

    rules:
  • apiGroups: [""] resources:

    • "nodes"
    • "nodes/metrics"
    • "nodes/stats"
    • "nodes/proxy"
    • "pods"
    • "services"
    • "namespaces" verbs: ["get", "list"]
  • nonResourceURLs: ["/metrics"] verbs: ["get"]

    <Callout variant="tip">
    サイドカーを挿入し、オペレーターがインストールされる前にデプロイされたポッドからメトリクスを取得するには、影響を受けるデプロイメントのロールアウト(再起動)を手動で実行する必要があります。こうすることで、ポッドの作成時に、オペレーターはモニタリングサイドカーを注入できるようになります。New Relicは、予期しないサービスの中断やリソース使用量の急増を防ぐために、これを自動的に行いません。
    </Callout>
    <Callout variant="important">
    `newrelic`名前空間(またはインストール用に選択した名前空間)を宣言するセレクターを使用して、Fargateプロファイルを作成してください。
    </Callout>
    以下に、インジェクションワークフローを示します。
    <img
    title="Diagram showing the workflow of sidecar injection"
    alt="Diagram showing the workflow of sidecar injection"
    src={kubernetesFargateWorkflow}
    />
    #### 自動インジェクションインストール [#auto-injection-install]
    <Callout variant="tip">
    次の手順はデフォルト設定の場合です。これらを完了する前に、以下の[設定](#config-auto)セクションを参照して、自動インジェクションの側面を変更するかどうかを確認してください。
    </Callout>
    まず、New Relic Helmリポジトリをまだ追加していない場合は追加します。
    ```shell
    helm repo add newrelic https://helm-charts.newrelic.com

    次に、インフラストラクチャサイドカーの注入を担当するオペレーターをインストールするために、設定の定義に使用するvalues.yamlという名前のファイルを作成してください。

    ## Global values
    global:
    # -- The cluster name for the Kubernetes cluster.
    cluster: "_YOUR_K8S_CLUSTER_NAME_"
    # -- The license key for your New Relic Account. This will be preferred configuration option if both `licenseKey` and `customSecret` are specified.
    licenseKey: "_YOUR_NEW_RELIC_LICENSE_KEY_"
    # -- (bool) In each integration it has different behavior. Enables operating system metric collection on each EC2 K8s node. Not applicable to Fargate nodes.
    # @default -- false
    privileged: true
    # -- (bool) Must be set to `true` when deploying in an EKS Fargate environment
    # @default -- false
    fargate: true
    ## Enable nri-bundle sub-charts
    newrelic-infra-operator:
    # Deploys the infrastructure operator, which injects the monitoring sidecar into Fargate pods
    enabled: true
    tolerations:
    - key: "eks.amazonaws.com/compute-type"
    operator: "Equal"
    value: "fargate"
    effect: "NoSchedule"
    config:
    ignoreMutationErrors: true
    infraAgentInjection:
    # Injection policies can be defined here. See [values file](https://github.com/newrelic/newrelic-infra-operator/blob/main/charts/newrelic-infra-operator/values.yaml#L114-L125) for more detail.
    policies:
    - namespaceName: namespace-a
    - namespaceName: namespace-b
    newrelic-infrastructure:
    # Deploys the Infrastructure Daemonset to EC2 nodes. Disable for Fargate-only clusters.
    enabled: true
    nri-metadata-injection:
    # Deploy our mutating admission webhook to link APM and Kubernetes entities
    enabled: true
    kube-state-metrics:
    # Deploys Kube State Metrics. Disable if you are already running KSM in your cluster.
    enabled: true
    nri-kube-events:
    # Deploy the Kubernetes events integration.
    enabled: true
    newrelic-logging:
    # Deploys the New Relic's Fluent Bit daemonset to EC2 nodes. Disable for Fargate-only clusters.
    enabled: true
    newrelic-prometheus-agent:
    # Deploys the Prometheus agent for scraping Prometheus endpoints.
    enabled: true
    config:
    kubernetes:
    integrations_filter:
    enabled: true
    source_labels: ["app.kubernetes.io/name", "app.newrelic.io/name", "k8s-app"]
    app_values: ["redis", "traefik", "calico", "nginx", "coredns", "kube-dns", "etcd", "cockroachdb", "velero", "harbor", "argocd", "istio"]

    最後に、ファイルを作成して調整した後、次のHelmコマンドを使用してソリューションをデプロイできます。

    bash
    $
    helm upgrade --install newrelic-bundle newrelic/nri-bundle -n newrelic --create-namespace -f values.yaml

    重要

    ハイブリッドクラスタ(EC2ノードとFargateノードの両方を含む)にソリューションをデプロイする場合は、ソリューションがFargateプロファイルにより選択されていないことを確認してください。選択されていると、DaemonSetインスタンスは保留状態のままになります。Fargateのみの環境の場合、DaemonSetインスタンスは作成されないため問題ありません。

    設定

    自動インジェクションのさまざまな側面を設定できます。デフォルトでは、オペレーターはJob、またはBatchJobの一部ではないFargateノードにデプロイされたすべてのポッドにモニタリングサイドカーを注入します。

    この動作は設定オプションから変更できます。たとえば、セレクターを定義して、注入されるポッドの選択を狭めたり広げたり、オペレーターにリソースを割り当てたり、サイドカーを調整したりできます。また、他の属性、ラベル、環境変数を追加することもできます。チャートのREADME.mdおよびvalues.yamlを参照してください。

    重要

    独自のカスタムインジェクションルールを指定すると、Fargateでスケジュールされていないポッドへのサイドカーインジェクションを防止するデフォルトのルールセットが破棄されます。カスタムルールでも同じように機能することを確認してください。DaemonSetもデプロイされているハイブリッドクラスタ上で、EC2でスケジュールされたポッドが2回監視されることになり、データが不正確だったり重複したりします。

    最新バージョンまたは新しい設定への更新

    EKS Fargateインテグレーションの最新バージョンに更新するには、helm repo update newrelicを使用してHelmリポジトリをアップグレードし、上記のコマンドを再度実行するだけでバンドルを再インストールします。

    挿入されたインフラストラクチャエージェントまたはオペレーター自体の設定を更新するには、values-newrelic.yamlを変更し、新しい設定でHelmリリースをアップグレードします。オペレーターはすぐに更新され、次回の再起動時にワークロードに新しいバージョンが組み込まれます。直ちにアップグレードしたい場合は、以下を実行してワークロードを強制的に再起動できます。

    bash
    $
    kubectl rollout restart deployment YOUR_APP

    Fargateインテグレーションのアンインストール

    自動インジェクションを実行しているサイドカーをアンインストールし、残りのNew Relicソリューションを保持するには、Helmを使用して、values.yamlファイル、またはコマンドラインでinfra-operator.enabledfalseに設定して、インフラオペレーターを無効にします。(--set)を指定し、上記のインストールコマンドを再実行します。

    --set global.fargate=trueフラグを保持することを強く推奨します。これを行うと、自動インジェクションは有効になりませんが、他のインストールコンポーネントがFargateを認識し、不要な動作が防止されます。

    ソリューション全体をアンインストールするには:

  1. Helmリリースを完全にアンインストールします。

  2. サイドカーを削除するには、ポッドをロールアウトします。

    bash
    $
    kubectl rollout restart deployment YOUR_APP
  3. ガベージコレクションのシークレット:

    bash
    $
    kubectl delete secrets -n YOUR_NAMESPACE -l newrelic/infra-operator-created=true

    既知の制限:自動インジェクション

    自動インジェクションを使用する際に注意すべき問題がいくつかあります。

  4. 現在、クラスタ全体を監視して、不要になったシークレットがガベージコレクションの対象になっていることを確認するコントローラーはありません。ただし、すべてのオブジェクトは、必要に応じてすべてのリソースの削除に使用できる同じラベルを共有します。ラベルnewrelic/infra-operator-created: trueを挿入します。これを使用すると、1 つのコマンドでリソースを削除できます。

  5. 現時点では、注入されたサイドカーを使用してポッド内で実行されているサービスを監視することはできません。サイドカーはKubernetes自体のみを監視します。ただし、上級ユーザーは、これらのポッドを自動インジェクションから除外し、サイドカーを設定し適切な場所にその設定をマウントすることで、オンホストインテグレーションが有効になっている、カスタマイズバージョンのサイドカーを手動で注入することもできます。ヘルプについては、このチュートリアルを参照してください。

    手動インジェクション

    自動インジェクションについて懸念がある場合は、Fargateノード上でスケジュールされるワークロードのマニフェストを変更すると、サイドカーを手動で直接注入できます。EC2ノードにスケジュールされたデプロイメントにサイドカーを追加すると、特にDaemonSetでそれらのノードがすでに監視されている場合、データが不正確だったり重複したりすることがあります。

    サイドカーがデータを正常に報告するには、次のオブジェクトが必要です。

  • ClusterRoleは、 nri-kubernetesインテグレーションに必要な権限を提供します。

  • ClusterRoleとポッドのサービスアカウントをリンクするClusterRoleBinding

  • Fargateの各名前空間に New Relic licenseKeyを保存するシークレット

  • 監視対象のワークロードの仕様テンプレート内のサイドカーコンテナ

    手動インジェクションインストール

    ヒント

    これらの手動設定手順は、一般的なインストール用です。これらを完了する前に、以下の設定セクションを参照して、自動インジェクションの側面を変更するかどうかを確認してください。

    手動インジェクションの場合は、次の手順を実行します。

  1. ClusterRoleが存在しない場合は、を作成し、メトリックエンドポイントに到達するために必要な権限を付与します。 同じクラスター内の複数のアプリケーションを監視する場合でも、これは1回だけ実行する必要があります。

  2. 監視するワークロードごとに、newrelic/infrastructure-k8sイメージのサイドカーコンテナを追加します。以下は、注入されたサイドカーの例です。

  3. ClusterRoleBindingを作成するか、以前に作成したものに監視対象アプリケーションのServiceAccountを追加します。すべてのワークロードは同じClusterRoleBindingを共有できますが、各ワークロードのServiceAccountをそれに追加する必要があります。

  4. New Relic

    を含むシークレットを作成します。各名前空間には独自のシークレットが必要です。

    設定

    サイドカーエージェントのマニフェストを手動で追加する場合、任意のエージェント設定オプションを使用すると、エージェントの動作を設定できます。ヘルプについては、インフラストラクチャエージェントの構成設定を参照してください。

    最新バージョンにアップデート

    いずれかのコンポーネントを更新するには、デプロイされたyamlを変更するだけです。

    注入されたコンテナのいずれかのフィールドを更新すると、ポッドが再作成されます。

    重要

    エージェントはNew Relic をホットロードできません。シークレットを更新した後、デプロイメントを再度ロールアウトする必要があります。

    Fargateインテグレーションのアンインストール

    挿入されたコンテナと関連リソースを削除するには、以下を削除するだけです。

  • 監視が不要なワークロードのサイドカー。

  • newrelicライセンスを含むすべてのシークレット。

  • ClusterRole ClusterRoleBinding個のオブジェクト。

    サイドカーコンテナを削除すると、ポッドが再作成されることに注意してください。

    ロギング

    New Relicのログ記録は、AWSによって課されたセキュリティ制約のため、Fargateノードでは利用できませんが、以下にいくつかのログ記録オプションを示します。

  • ログ記録にFluentbitを使用している場合は、ログ転送用のKubernetesプラグインを参照してください。

  • ログデータがすでにAWS FireLensによって監視されている場合は、ログ転送用のAWS FireLensプラグインを参照してください。

  • ログデータがすでにAmazon CloudWatch Logsによって監視されている場合は、Kinesis Data Firehoseを使用したログのストリーミングを参照してください。

  • CloudWatchログ送信用のAWS Lambdaを参照してください。

  • Amazon ECSからNew Relicにログを転送する3つの方法を参照してください。

    トラブルシューティング

    DaemonSetレプリカがFargateノードにデプロイされている

    インフラDaemonSetレプリカがFargateノードでスケジュールされている場合は、nodeAffinityルールが適切に設定されていないことが原因である可能性があります。

    コマンドライン(--set global.fargate=true)またはvalues.yamlファイルのいずれかで、ソリューションがtrueglobal.fargateオプションを指定してインストールされていることを再確認します。インストール方法がHelmではなかった場合は、Fargateノードを除外するnodeAffinityルールを手動で追加する必要があります。

    許容できない感染によるイベントFailedScheduling

    ポッドの作成中に次のイベントが発生した場合は、自動インジェクションのインストールで説明されているtolerationsを、values.yamlファイルに必ず追加してください。

    LAST SEEN | TYPE | REASON | OBJECT | MESSAGE
    :--|:--|:--|:--|:--
    3m9s (x2 over 8m10s) | Warning | FailedScheduling | Pod/no-fargate-deploy-cbddd6ccf-8f9x4 | 0/2 nodes are available: 2 node(s) had untolerated taint {eks.amazonaws.com/compute-type: fargate}. preemption: 0/2 nodes are available: 2 Preemption is not helpful for scheduling..

    ポッドが多すぎることによるイベントFailedScheduling

    ポッドの作成中に次のイベントが発生した場合は、インストールが行われる名前空間を指定するセレクターを含む、Fargateプロファイルがあるかどうかを確認してください。

    LAST SEEN | TYPE | REASON | OBJECT | MESSAGE
    :--|:--|:--|:--|:--
    61s | Warning | FailedScheduling | Pod/newrelic-bundle-newrelic-infra-operator-admission-create-d8ggt | 0/2 nodes are available: 2 Too many pods. preemption: 0/2 nodes are available: 2 No preemption victims found for incoming pod..

    EKSデータの表示

    以下に、New Relic UIでのFargateノードの外観の例を示します。

    AWSデータを表示するには:

  1. one.newrelic.com > All capabilities > Infrastructure > Kubernetes に移動し、次のいずれかを実行します。
  • インテグレーション名を選択してデータを表示します。
  • [データを探索]アイコンを選択して、AWSデータを表示します。
  1. 2つのFargateタグを使用してデータをフィルタリングします。
  • computeType=serverless
  • fargateProfile=[name of the Fargate profile to which the workload belongs]

Helmを使用してインテグレーションをインストールする場合は、2つのオプションがあります。

  1. ガイド付きインストールエクスペリエンス。これは、必要なフィールドが事前に入力されたHelmコマンドを提供します。このオプションでは、Helmリリースではなく、プレーンマニフェストとしてインテグレーションをインストールすることもできます。

  2. values.yamlファイルによる手動設定。このタブでは、その方法について説明します。

    Helmは、Kubernetes上のパッケージマネージャーです。これにより、インストール、アップグレード、リビジョン追跡が容易になり、Kubernetesにインストールするサービスの依存関係が管理されます。まだ作成されていない場合は、無料のNew Relicアカウントを以下で作成し、今すぐデータの監視を開始してください。

    インストーラの起動

    互換性および要件

    Helmがマシンにインストールされていることを確認してください。Kubernetesインテグレーションのバージョン3には、Helmバージョン3が必要です。

    Helmを使用してKubernetesインテグレーションをインストールするには、New Relic とKubernetesクラスタの名前が必要です。

  3. を見つけてコピーします。

  4. クラスタの表示名を選択します。たとえば、次の出力を使用できます。

    bash
    $
    kubectl config current-context

    重要

    これらの値は、後でインストールプロセス中に必要になるため、安全な場所に保管してください。

    Helmを使用したKubernetesインテグレーションのインストール

    New Relicでは、プラットフォームにさまざまな機能を提供する、さまざまなコンポーネント用のHelmチャートをいくつか用意しています。

  • newrelic-infrastructure:メインの Kubernetesインテグレーションとインフラストラクチャエージェントが含まれます。これはNew Relic Kubernetesエクスペリエンスのコアコンポーネントで、Kubernetesダッシュボードと、Kubernetesクラスタエクスプローラーに表示されるほとんどのデータをレポートする役割を果たします。

  • newrelic-logging:New RelicのFluent Bit出力プラグインを備えたDaemonSetを提供し、ログをNew Relicに簡単に転送します。

  • nri-kube-events:クラスタイベント(kubectl get eventsなど)を収集して、New Relicに報告します。

  • newrelic-prometheus-agent:New RelicのPrometheus Configuratorは、エージェントモードでPrometheusを設定し、リモート書き込みエンドポイントを使用してメトリクスをNew Relic に報告します

  • nri-metadata-injection:コンテナにいくつかの環境変数を挿入する、最小限のMutatingAdmissionWebhookを設定します。これらにはクラスタとNew Relicのインストールに関するメタデータが含まれており、後でAPMを使用してインストゥルメントされたアプリケーションにより取得され、APMとインフラストラクチャデータを関連付けることができます。

  • nri-statsd:New Relic StatsDインテグレーション。

    これらのコンポーネントは個別にインストールできますが、nri-bundleチャートを使用することを強くお勧めします。New Relicでは、上記の個別チャートのラッパーやメタパッケージとして機能するこのチャートを用意してします。このチャートを使用すると、次のような利点が得られます。

  • インストールされるコンポーネントを完全に制御できます。各コンポーネントは、個別のHelm依存関係としてインストールされます。ここで説明するパラメーターを使用して、それらを個別に設定できます。

  • インストールされているバージョンが相互に互換性があることが保証されます。

  • インストールされているチャート間で設定値に矛盾がないことが保証されます。

    nri-bundleチャートは、Kubernetesガイド付きインストールでインストールおよび設定されるチャートです。

    Helmを使用したnri-bundleのインストールと設定

  1. Helmとkubectlを実行するマシンで適切なコンテキストを使用していることを確認してください。

    利用可能なコンテキストは次のようにして確認できます。

    bash
    $
    kubectl config get-contexts

    次を使用して、目的のコンテキストに切り替えます。

    bash
    $
    kubectl config use-context _CONTEXT_NAME_
  2. New Relic Helmチャートリポジトリを追加します。

    bash
    $
    helm repo add newrelic https://helm-charts.newrelic.com
  3. values-newrelic.yamlという名前のファイルを作成します。これは設定の定義に使用します。

    global:
    licenseKey: _YOUR_NEW_RELIC_LICENSE_KEY_
    cluster: _K8S_CLUSTER_NAME_
    newrelic-prometheus-agent:
    # Automatically scrape prometheus metrics for annotated services in the cluster
    # Collecting prometheus metrics for large clusters might impact data usage significantly
    enabled: true
    nri-metadata-injection:
    # Deploy our webhook to link APM and Kubernetes entities
    enabled: true
    nri-kube-events:
    # Report Kubernetes events
    enabled: true
    newrelic-logging:
    # Report logs for containers running in the cluster
    enabled: true
    kube-state-metrics:
    # Deploy kube-state-metrics in the cluster.
    # Set this to true unless it is already deployed.
    enabled: true
  4. 次のコマンドを実行して、チャート内のすべてが正しく設定されていることを確認します。--dry-run--debugを指定しているため、この手順では何もインストールされません。

    bash
    $
    helm upgrade --install newrelic-bundle newrelic/nri-bundle \
    >
    --namespace newrelic --create-namespace \
    >
    -f values-newrelic.yaml \
    >
    --dry-run \
    >
    --debug

    次のフラグに注意して調整してください。

  • global.licenseKey=YOUR_NEW_RELIC_LICENSE_KEY:お使いのアカウントの有効な

    に設定する必要があります。

  • global.cluster=K8S_CLUSTER_NAME:New Relic UIでクラスタの識別に使用するため、New Relicアカウントで設定されている、他のKubernetesクラスタでは使用されていないわかりやすい値にする必要があります。

  • kube-state-metrics.enabled=true: これをtrueに設定すると、インテグレーションの実行に必要なKube State Metrics(KSM)が自動的にインストールされます。KSMがクラスタ内にすでに存在する場合は、別の名前空間にある場合でも、これをfalseに設定できます。

  • newrelic-prometheus-agent.enabled=true: クラスタ内に存在するPrometheusエンドポイントからデータを自動収集する、Prometheusエージェントをデプロイします。

  • nri-metadata-injection.enabled=true: 最小限のWebhookをインストールします。これにより環境変数が追加され、New Relic APMでインストゥルメントされたアプリケーションを、Kubernetesにリンクできるようになります。

    Kubernetesチャートには、特定のニーズに合わせて編集できるフラグと調整パラメーターの包括的なセットが含まれています。変更できる内容については、以下のインテグレーションの設定セクションを確認してください。

  1. --debug--dry-runを指定せずにコマンドを実行して、Kubernetesインテグレーションをインストールします。

    bash
    $
    helm upgrade --install newrelic-bundle newrelic/nri-bundle \
    >
    --namespace newrelic --create-namespace \
    >
    -f values-newrelic.yaml

    重要

    Kubernetesバージョン1.27.xまたはそれ以前の対応バージョンを使用していることを確認してください。

  2. ポッドがデプロイされ、安定した状態になっていることを確認します。

    bash
    $
    kubectl -n newrelic get pods -w

    以下が表示されます。

  • newrelic-nrk8s-ksm ポッド。

  • newrelic-nrk8s-kubelet クラスタ内の各ノードのポッド。

  • newrelic-nrk8s-control-plane クラスタ内の各マスターノードのポッド(存在する場合)。

  • newrelic-kube-state-metrics ポッド(インストールにKSMを含めた場合)。

  • newrelic-nri-kube-events ポッド(Kubernetesイベントレポートを有効にしている場合)。

  • prometheus-agent ポッド(Prometheusエージェントインテグレーションを有効にしている場合)。

  • newrelic-newrelic-logging クラスタ内の各ノードのポッド(ロギングインテグレーションを有効にしている場合)。

    このドキュメントはインストールで役立ちましたか。

    インテグレーションの設定

    nri-bundleチャート。そのインストール手順は上記に記載されており、ソリューションのコンポーネントを含む、他のいくつかのチャートのラッパーやメタパッケージとして機能します。このようなラッパーを提供することで、コンポーネントのチャートを比較的単純に保ちながら、相互に互換性があるバージョンを使用して、制御されたコンポーネントのセットを提供できます。

    nri-bundleチャートは、複数の個別チャートをラップし、さまざまなテレメトリーデータを収集して、New Relicに送信します。このバンドルを使用すると、ニーズに応じて必要な子チャートを選択的に有効にすることができます。個別のコンポーネントを設定するには、Helmの依存関係システムを使用する必要があります。つまり、各子チャートの設定を、values-newrelic.ymlファイル内の別個のセクション(各子チャートにちなんだ名前)に配置する必要があります。たとえば、newrelic-infrastructureチャートを設定するには、次のコードをvalues-newrelic.yamlに追加します。

    # General settings that apply to all the child charts
    global:
    licenseKey: _YOUR_NEW_RELIC_LICENSE_KEY_
    cluster: _K8S_CLUSTER_NAME_
    # ... Other settings as shown above
    # Specific configuration for the newrelic-infrastructure child chart
    newrelic-infrastructure:
    verboseLog: true # Enable debug logs
    privileged: false # Install with minimal privileges
    # Other options from https://github.com/newrelic/helm-charts/tree/master/charts/newrelic-infrastructure-v3
    # Specific configuration for the newrelic-logging child chart
    newrelic-logging:
    fluentBit:
    retryLimit: 10

    子チャートのオプションに子チャート名をプレフィックスとして付け、ネストをドットで置き換えることで、コマンドラインから子チャートオプションを渡すこともできます。

    helm upgrade --install newrelic-bundle newrelic/nri-bundle \
    --namespace=newrelic \
    --set global.licenseKey=_YOUR_NEW_RELIC_LICENSE_KEY_ \
    --set global.cluster=_K8S_CLUSTER_NAME_ \
    --set newrelic-infrastructure.privileged=false \
    --set newrelic-infrastructure.verboseLog=true \
    --set newrelic-logging.fluentBit.retryLimit=10

    各子チャートで調整できるフラグ(scrape-intervalなど)の完全なリストは、それぞれのリポジトリにあります。

  • newrelic-infrastructure

  • デバッグログ、特権モード、コントロールプレーンモニタリングなどを設定します。

  • nri-kube-events

  • nri-metadata-injection

  • APMリンク用のWebhookのデプロイ方法を設定します。

  • スクレイピングするPrometheusエンドポイントを設定します。

  • newrelic-logging

  • New Relicに送信するログまたはログ属性を設定します。

    ヒント

    子チャートの設定オプションを指定する場合は、それらをvalues-newrelic.yaml内のチャート名にちなんで名付けられたセクションの下に配置する必要があります。

    ヒント

    コマンドラインから子チャートのオプションを渡すには、子チャートの名前をプレフィックスとして付け、ネストをドットで置き換える必要があります。

GKE AutopilotクラスタにKubernetesインテグレーションをインストールするには3つの方法があります。

Kubernetesデータの使用

詳細:

このドキュメントはインストールで役立ちましたか。

Copyright © 2024 New Relic株式会社。

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.