• ログイン今すぐ開始

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

英語版と齟齬がある場合、英語版の定めが優先するものとします。より詳しい情報については、本リンクをご参照ください。

問題を作成する

APMをインストルメント化したアプリケーションをKubernetesにリンクする

Kubernetesメタデータを表示し、 分散トレースとしてAPMエージェントにリンクして、パフォーマンスの問題を調査し、トランザクションエラーのトラブルシューティングを行うことができます。詳細については、 Kubernetesを介したアプリのパフォーマンスのモニタリングに関するこのブログ投稿を参照してください。

さらに、Pixieでの自動テレメトリを使用して、Kubernetesクラスタのモニタリングをすばやく開始できます。このPixieのNewRelicへの統合には、言語エージェントは必要ありません。Pixieを使用した自動テレメトリの詳細については、 こちらをご覧ください。

メタデータインジェクション製品は、 MutatingAdmissionWebhookを使用して次の環境変数をポッドに追加します。

NEW_RELIC_METADATA_KUBERNETES_CLUSTER_NAME
NEW_RELIC_METADATA_KUBERNETES_NODE_NAME
NEW_RELIC_METADATA_KUBERNETES_NAMESPACE_NAME
NEW_RELIC_METADATA_KUBERNETES_DEPLOYMENT_NAME
NEW_RELIC_METADATA_KUBERNETES_POD_NAME
NEW_RELIC_METADATA_KUBERNETES_CONTAINER_NAME
NEW_RELIC_METADATA_KUBERNETES_CONTAINER_IMAGE_NAME

ヒント

Kubernetesメタデータインジェクションプロジェクトはオープンソースです。APMとインフラストラクチャデータをリンクするコードは次のとおりです。

互換性と要件

アプリケーションとKubernetesをリンクするには、 MutatingWebhookConfigurationをKubernetesクラスターにデプロイできる必要があります。

必要な権限があることを確認するには、次のコマンドを実行できます。

bash
$
kubectl auth can-i create mutatingwebhookconfigurations.admissionregistration.k8s.io -A

上記のコマンドの出力は、次のようになります。

yes

別の結果が表示される場合は、Kubernetesのドキュメントに従って、 クラスタでアドミッションコントロールを有効にしてください

ネットワーク要件

KubernetesがMutatingAdmissionWebhookと通信するには、マスターノード(またはクラスターの設定方法によってはAPIサーバーコンテナー)に、ポート443のHTTPSトラフィックの出力をクラスター内の他のすべてのノードのポッドに許可する必要があります。 。

これには、インフラストラクチャの設定方法(オンプレミス、AWS、Google Cloudなど)に応じて特定の構成が必要になる場合があります。

APMエージェントの互換性

次のNewRelicエージェントは、Kubernetesメタデータを収集します。

Openshiftの要件

OpenshiftとKubernetesをリンクするには、 Openshift3.9以降を必要とするアドミッションWebhookの変更を有効にする必要があります。

  1. プロセス中に、クラスターへのadmin権限を必要とするリソースをインストールします。これを実行して、adminとしてログインします。

    bash
    $
    oc login -u system:admin
  2. Webhookが正しく構成されていることを確認してください。そうでない場合は、 master-config.yamlファイルを更新します。

    admissionConfig:
    pluginConfig:
    MutatingAdmissionWebhook:
    configuration:
    apiVersion: apiserver.config.k8s.io/v1alpha1
    kubeConfigFile: /dev/null
    kind: WebhookAdmission
    ValidatingAdmissionWebhook:
    configuration:
    apiVersion: apiserver.config.k8s.io/v1alpha1
    kubeConfigFile: /dev/null
    kind: WebhookAdmission
    location: ""

    重要

    Openshiftのいくつかの問題に対処するには、 kubeConfigFile: /dev/nullを追加します。

  3. YAMLファイルを編集して構成を更新することにより、証明書の署名を有効にします。

    kubernetesMasterConfig:
    controllerArguments:
    cluster-signing-cert-file:
    - "/etc/origin/master/ca.crt"
    cluster-signing-key-file:
    - "/etc/origin/master/ca.key"
  4. マスターノードでOpenshiftサービスを再起動します。

重要

Openshift 4.0以降では、これらのバージョンではmaster-config.yamlファイルがサポートされていないため、アドミッションWebhookを有効にするために ダイナミックアドミッションコントロールが必要です。

メタデータの注入を設定する

Helmを使用して統合をインストールすると、メタデータの挿入が含まれます。チャートを構成するときに、メタデータを挿入するWebhookが有効になっていることを確認してください。

webhook:
enabled: true

デフォルトでは、APMエージェントを含む作成するすべてのポッドに正しい環境変数が設定されており、メタデータインジェクションはクラスター全体に適用されます。環境変数が設定されていることを確認するには、実行中のすべてのコンテナーを停止し、新しいインスタンスを開始する必要があります( メタデータの挿入の検証を参照)。

このデフォルト設定では、 Kubernetes証明書APIを使用して、インジェクションに必要な証明書を自動的に管理します。必要に応じて、メタデータの挿入をクラスター内の特定の名前空間に制限したり、証明書を自己管理したりできます。

カスタム構成

インジェクションの対象となる名前空間を制限する

ラベルを使用して、メタデータの挿入を特定の名前空間にのみ制限できます。

この機能を有効にするには、 values-newrelic.yamlファイルに以下を追加します。

nri-metadata-injection:
injectOnlyLabeledNamespaces: true

このオプションを使用すると、インジェクションはnewrelic-metadata-injectionラベルがenabledに設定されている名前空間にのみ適用されます。

bash
$
kubectl label namespace YOUR_NAMESPACE newrelic-metadata-injection=enabled

cert-managerを使用して証明書を生成します

デフォルトでは、チャートはkube-webhook-certgenを使用して、Webhookを実行するために必要な証明書を自動的に生成します。

ただし、 cert-managerがインストールされている場合は、代わりにcert-managerを使用するようにチャートを構成できます。これにより、展開プロセスが大幅に簡素化されます。

nri-metadata-injection:
certManager:
enabled: true

カスタム証明書を管理する

ヒント

Webhook証明書を手動で管理することは、上級ユーザーにのみお勧めします。New Relicサポートチームは、この構成のトラブルシューティングを支援できない場合があります。

カスタム証明書を使用するには、Helmを使用してインストールするときに証明書の自動インストールを無効にする必要があります。

証明書のインストールを無効にするには、次のようにnri-bundleHelm values.yamlを変更します。

nri-metadata-injection:
customTLSCertificate: true

これで、カスタム証明書管理オプションを続行できます。

PEM形式でエンコードされた証明書、サーバーキー、および認証局(CA)バンドルが必要です。

  • それらが標準の証明書形式(X.509)である場合は、 opensslをインストールし、以下を実行します。
openssl x509 -in CERTIFICATE_FILENAME -outform PEM -out CERTIFICATE_FILENAME.pem
openssl x509 -in SERVER_KEY_FILENAME -outform PEM -out SERVER_KEY_FILENAME.pem
openssl x509 -in CA_BUNDLE_FILENAME -outform PEM -out BUNDLE_FILENAME.pem

署名された証明書とキーのペアを使用してTLSシークレットを作成し、次のコマンドを使用して、変更するWebhook構成にCAでパッチを適用します。

kubectl create secret tls newrelic-metadata-injection-admission \
--key=PEM_ENCODED_SERVER_KEY \
--cert=PEM_ENCODED_CERTIFICATE \
--dry-run -o yaml |
kubectl -n newrelic apply -f -

caBundle=$(cat PEM_ENCODED_CA_BUNDLE | base64 | td -d $'\n')
kubectl patch mutatingwebhookconfiguration newrelic-metadata-injection-cfg --type='json' -p "[{'op': 'replace', 'path': '/webhooks/0/clientConfig/caBundle', 'value':'${caBundle}'}]"

重要

Kubernetesによって署名された証明書の有効期限は1年です。詳細については、GitHubのKubernetesソースコードを参照してください。

メタデータの挿入を検証します

Webhook(メタデータの挿入を担当)が正しくインストールされたことを検証するには、新しいポッドをデプロイし、NewRelic環境変数を確認します。

  1. 次のコマンドを実行して、ダミーのnginxポッドを作成します。
bash
$
kubectl run test-nginx --image nginx -n newrelic
  1. NewRelic環境変数が挿入されたかどうかを確認します。
bash
$
kubectl exec -n newrelic test-nginx -- env | grep NEW_RELIC_METADATA_KUBERNETES

期待される出力は次のようになります。

NEW_RELIC_METADATA_KUBERNETES_CLUSTER_NAME=cluster-name
NEW_RELIC_METADATA_KUBERNETES_NODE_NAME=nodea
NEW_RELIC_METADATA_KUBERNETES_NAMESPACE_NAME=newrelic
NEW_RELIC_METADATA_KUBERNETES_POD_NAME=test-nginx
NEW_RELIC_METADATA_KUBERNETES_CONTAINER_NAME=nginx

メタデータの挿入を無効にする

メタデータの挿入を無効化/アンインストールするには、 values-newrelic.yamlファイルを次のように変更します。

webhook:
enabled: false

そして、 インストールコマンドを再実行します。

トラブルシューティング

必要に応じて、これらのトラブルシューティングのヒントに従ってください。

Copyright © 2022 New Relic株式会社。

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