EKSファーゲート

ベータ機能

この機能はまだ開発中ですが、ぜひお試しください。

New Relicは、インフラストラクチャエージェントと監視が必要な各ポッドのnri-kubernetes統合を含むサイドカーを自動的に挿入することで、EKSFargateでのKubernetesワークロードの監視をサポートします。

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

混合環境では、統合はFargateノードにサイドカーのみを使用します。

New Relicは、FargateノードかEC2ノードかに関係なく、スケジュールされている場所に関係なく、すべてのKubernetesオブジェクトでサポートされているすべてのメトリックを収集します。Fargateによって課せられた制限により、NewRelic統合はFargateノードで非特権モードで実行するように制限されていることに注意してください。つまり、実行中のプロセスのように、通常はホストから直接フェッチされるメトリックは、Fargateノードでは使用できません。

両方のシナリオのエージェントは、Kube State Metrics（KSM）、Kubelet、およびcAdvisorからデータを取得し、同じ形式でデータを送信します。

重要

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

nri-prometheus 、 nri-metadata-injection 、 nri-kube-eventsなどのKubernetes用のNew Relicソリューションの他のコンポーネントには特別なものはなく、Fargate以外の環境の場合と同様に、HelmChartによって通常どおりデプロイされます。

重要

FargateノードではNewRelicLoggingはまだサポートされていません。

インストール

EKS FargateクラスターにNewRelicの完全な可観測性をインストールするには、次の2つの方法から選択できます。

自動注入（推奨）
手動注射

選択したアプローチに関係なく、インストール後のエクスペリエンスはまったく同じです。唯一の違いは、コンテナの注入方法です。監視する各デプロイメントを手動で編集する必要がなくなるため、New RelicInfrastructureOperatorを使用して自動インジェクションを設定することをお勧めします。

自動注入（推奨）

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

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

オペレーターが行うこと

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

NewRelicKubernetes統合を含むポッドにサイドカーコンテナを追加します。
シークレットが存在しない場合は、サイドカーがデータを報告するために必要なNewRelicライセンスキーを含むポッドと同じ名前空間にシークレットを作成します。
ポッドのサービスアカウントを、以前にオペレーターチャートによって作成されたClusterRoleBindingに追加します。これにより、このサイドカーに、Kubernetesメトリックエンドポイントにアクセスするために必要な権限が付与されます。

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

- apiGroups: [""]
  resources:
    - "nodes"
    - "nodes/metrics"
    - "nodes/stats"
    - "nodes/proxy"
    - "pods"
    - "services"
  verbs: ["get", "list"]
- nonResourceURLs: ["/metrics"]
  verbs: ["get"]

ヒント

サイドカーが注入され、オペレーターがインストールされる前に展開されたポッドからメトリックを取得するには、影響を受ける展開のロールアウト（再起動）を手動で実行する必要があります。このようにして、ポッドが作成されると、オペレーターは監視サイドカーを注入できるようになります。New Relicは、予期しないサービスの中断やリソース使用量の急増を防ぐために、これを自動的に行わないことを選択しました。

インジェクションワークフローは次のとおりです。

自動注入インストール

ヒント

次の手順は、デフォルト設定用です。これらを完了する前に、以下の「構成」セクションを参照して、自動インジェクションのいずれかの側面を変更するかどうかを確認することをお勧めします。

最初に、これまでに追加したことがない場合は、NewRelicHelmリポジトリを追加します。

bash

$helm repo add newrelic https://helm-charts.newrelic.com

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

global:
  licenseKey: _YOUR_NEW_RELIC_LICENSE_KEY_
  cluster: _K8S_CLUSTER_NAME_
  fargate: true  # Enable fargate support

prometheus:
  # Automatically scrape prometheus metrics for annotated services in the cluster
  # Collecting prometheus metrics for large clusters might impact data usage significantly
  enabled: true
  lowDataMode: true  # Skip ingesting cluster-level metrics
webhook:
  # Deploy our webhook to link APM and Kubernetes entities
  enabled: true
kubeEvents:
  # Report Kubernetes events
  enabled: true
logging:
  # Report logs for containers running in the cluster
  enabled: true
ksm:
  # Deploy kube-state-metrics in the cluster.
  # Set this to true unless it is already deployed.
  enabled: true
newrelic-infra-operator:
  # Deploy the infrastructure operator, which will inject the monitoring sidecar on fargate pods
  enabled: true

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

bash

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

重要

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

構成

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

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

重要

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

Fargate統合をアンインストールします

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

--set global.fargate=trueフラグを保持することを強くお勧めします。これは、自動インジェクションを有効にしませんが、インストールの他のコンポーネントをFargate対応にし、望ましくない動作を防ぐためです。

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

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

サイドカーを取り外すには、ポッドをロールアウトします。

$ kubectl rollout restart deployment YOUR_APP

ガベージコレクションの秘密：

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

既知の制限：自動注入

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

現在、クラスター全体を監視して、不要になったシークレットがガベージコレクションされていることを確認するコントローラーはありません。ただし、すべてのオブジェクトは、必要に応じてすべてのリソースを削除するために使用できる同じラベルを共有します。ラベルnewrelic/infra-operator-created: trueを挿入します。これを使用して、1つのコマンドでリソースを削除できます。
現時点では、注入されたサイドカーを使用してポッドで実行されているサービスを監視することはできません。サイドカーはKubernetes自体のみを監視します。ただし、上級ユーザーは、これらのポッドを自動注入から除外し、それらを構成して適切な場所に構成をマウントすることにより、オンホスト統合が有効になっているカスタマイズされたバージョンのサイドカーを手動で注入したい場合があります。ヘルプについては、このチュートリアルを参照してください。

手動注射

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

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

nri-kubernetes統合に必要な権限を提供するClusterRole
ClusterRoleとポッドのサービスアカウントをリンクするClusterRoleBinding
各Fargate名前空間にNewRelic licenseKeyを保存するシークレット
監視対象ワークロードのスペックテンプレートのサイドカーコンテナ

手動注入インストール

ヒント

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

手動注入の場合は、次の手順を実行します。

ClusterRoleが存在しない場合は、を作成し、メトリックエンドポイントに到達するために必要な権限を付与します。同じクラスター内の複数のアプリケーションを監視する場合でも、これは1回だけ実行する必要があります。
このスニペットは、以下のように変更せずに使用できます。
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: labels: app: newrelic-infrastructure name: newrelic-newrelic-infrastructure-infra-agent rules: - apiGroups: - "" resources: - nodes - nodes/metrics - nodes/stats - nodes/proxy - pods - services verbs: - get - list - nonResourceURLs: - /metrics verbs: - get

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

次のスニペットのコンテナーを取得し、それを監視するワークロードに挿入し、 customAttributes変数にFargateProfileの名前を指定します。ボリュームはemptyDir: {}として定義できることに注意してください。

ヒント

KSMデプロイメントの特殊なケースでは、 DISABLE_KUBE_STATE_METRICS環境変数を削除し、リソース要求と制限を増やす必要もあります。

apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      containers:
      - name: newrelic-infrastructure
        env:
        - name: NRIA_LICENSE_KEY
          valueFrom:
            secretKeyRef:
              key: license
              name: newrelic-newrelic-infrastructure-config
        - name: NRIA_VERBOSE
          value: "1"
        - name: DISABLE_KUBE_STATE_METRICS
          value: "true"
        - name: CLUSTER_NAME
          value: testing-injection
        - name: COMPUTE_TYPE
          value: serverless
        - name: NRK8S_NODE_NAME
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: spec.nodeName
        - name: NRIA_DISPLAY_NAME
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: spec.nodeName
        - name: NRIA_CUSTOM_ATTRIBUTES
          value: '{"clusterName":"$(CLUSTER_NAME)", "computeType":"$(COMPUTE_TYPE)", "fargateProfile":"[YOUR FARGATE PROFILE]"}'
        - name: NRIA_PASSTHROUGH_ENVIRONMENT
          value: KUBERNETES_SERVICE_HOST,KUBERNETES_SERVICE_PORT,CLUSTER_NAME,CADVISOR_PORT,NRK8S_NODE_NAME,KUBE_STATE_METRICS_URL,KUBE_STATE_METRICS_POD_LABEL,TIMEOUT,ETCD_TLS_SECRET_NAME,ETCD_TLS_SECRET_NAMESPACE,API_SERVER_SECURE_PORT,KUBE_STATE_METRICS_SCHEME,KUBE_STATE_METRICS_PORT,SCHEDULER_ENDPOINT_URL,ETCD_ENDPOINT_URL,CONTROLLER_MANAGER_ENDPOINT_URL,API_SERVER_ENDPOINT_URL,DISABLE_KUBE_STATE_METRICS,DISCOVERY_CACHE_TTL
        image: newrelic/infrastructure-k8s:2.4.0-unprivileged
        imagePullPolicy: IfNotPresent
        resources:
          limits:
            memory: 100M
            cpu: 200m
          requests:
            cpu: 100m
            memory: 50M
        securityContext:
          allowPrivilegeEscalation: false
          readOnlyRootFilesystem: true
          runAsUser: 1000
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
        volumeMounts:
        - mountPath: /var/db/newrelic-infra/data
          name: tmpfs-data
        - mountPath: /var/db/newrelic-infra/user_data
          name: tmpfs-user-data
        - mountPath: /tmp
          name: tmpfs-tmp
        - mountPath: /var/cache/nr-kubernetes
          name: tmpfs-cache
[...]

ClusterRoleBindingを作成するか、以前に作成したものに、監視対象のアプリケーションのServiceAccountを追加します。すべてのワークロードが同じClusterRoleBindingを共有する場合がありますが、各ワークロードのServiceAccountを追加する必要があります。
監視するポッドのサービスアカウントをサブジェクトとして持つ次のClusterRoleBindingを作成します。
ヒント
同じサービスアカウントを2回繰り返す必要はありません。まだ含まれていないサービスアカウントでポッドを監視するたびに、それをリストに追加するだけです。
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: newrelic-newrelic-infrastructure-infra-agent roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: newrelic-newrelic-infrastructure-infra-agent subjects: - kind: ServiceAccount name: [INSERT_SERVICE_ACCOUNT_NAME_OF_WORKLOAD] namespace: [INSERT_SERVICE_ACCOUNT_NAMESPACE_OF_WORKLOAD]

NewRelicライセンスキーを含むシークレットを作成します。各名前空間には独自のシークレットが必要です。
NewRelicライセンスキーのBase64エンコード値を使用したライセンスを持つ次のSecretを作成します。監視するポッドが実行されている各名前空間に1つのシークレットが必要です。
apiVersion: v1 data: license: INSERT_YOUR_NEW_RELIC_LICENSE_ENCODED_IN_BASE64 kind: Secret metadata: name: newrelic-newrelic-infrastructure-config namespace: [INSERT_NAMESPACE_OF_WORKLOAD] type: Opaque

構成

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

重要

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

Fargate統合をアンインストールします

注入されたコンテナと関連リソースを削除するには、次のものを削除する必要があります。

もはや監視されるべきではないワークロードからのサイドカー。
newrelicライセンスを含むすべての秘密。
ClusterRole およびClusterRoleBindingオブジェクト。

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

トラブルシューティング：DaemonSetレプリカがFargateノードにデプロイされています

FargateノードでInfra DaemonSetレプリカがスケジュールされていることに気付いた場合は、 nodeAffinityルールが適切に構成されていないことが原因である可能性があります。

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

EKSデータを表示する

NewRelicUIでFargateノードがどのように表示されるかの例を次に示します。

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

one.newrelic.com >インフラストラクチャ>Kubernetesに移動し、次のいずれかを実行します。
- データを表示する統合名を選択します。
- AWSデータを表示するには、[データの探索]アイコンを選択します。
2つのFargateタグを使用してデータをフィルタリングします。
- computeType=serverless
- fargateProfile=[name of the Fargate profile to which the workload belongs]

本書は、お客様のご参考のために原文の英語版を機械翻訳したものです。

ベータ機能

重要

重要

インストール

自動注入（推奨）

オペレーターが行うこと

ヒント

自動注入インストール

ヒント

重要

構成

重要

最新バージョンまたは新しい構成に更新します

Fargate統合をアンインストールします

既知の制限：自動注入

手動注射

手動注入インストール

ヒント

ClusterRole

ContainerToInject

ヒント

ClusterRoleBinding

ヒント

ひみつ

構成

最新バージョンに更新する

重要

Fargate統合をアンインストールします

トラブルシューティング：DaemonSetレプリカがFargateノードにデプロイされています

EKSデータを表示する