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メタデータを収集します。

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

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

nri-metadata-injection:
  enabled: true

Webhook がデプロイされた後、アプリケーションポッドを再起動して、必要な環境変数を取得できるようにする必要があります。

デフォルトでは、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をインストールし、以下を実行します。

bash

$openssl x509 -in YOUR_CERTIFICATE_FILENAME -outform PEM -out YOUR_CERTIFICATE_FILENAME.pem
$openssl x509 -in YOUR_SERVER_KEY_FILENAME -outform PEM -out YOUR_SERVER_KEY_FILENAME.pem 
$openssl x509 -in YOUR_CA_BUNDLE_FILENAME -outform PEM -out YOUR_BUNDLE_FILENAME.pem

証明書とキーのペアが別の形式である場合は、 Digicertナレッジベースで詳細を確認してください。

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

bash

$kubectl create secret tls YOUR_NEWRELIC_METADATA_INJECTION_ADMISSION \
>  --key=YOUR_PEM_ENCODED_SERVER_KEY \
>  --cert=YOUR_PEM_ENCODED_CERTIFICATE \
>  --dry-run -o yaml |
$kubectl -n newrelic apply -f -
$
$caBundle=$(cat YOUR_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環境変数を確認します。

次のコマンドを実行して、ダミーのnginxポッドを作成します。

bash

$kubectl run test-nginx --image nginx -n newrelic

NewRelic環境変数が挿入されたかどうかを確認します。

bash

$kubectl exec -n newrelic test-nginx -- env | grep NEW_RELIC_METADATA_KUBERNETES

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

NEW_RELIC_METADATA_KUBERNETES_CLUSTER_NAME=THE_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

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

トラブルシューティング

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

問題

Kubernetesバージョン1.19.xで実行しているときにイメージで使用されるkubectlバージョンが原因で、 k8s-webhook-cert-managerジョブによるシークレットの作成が失敗していました。新しいバージョン1.3.2ではこの問題が修正されているため、実行するだけで十分です。この場合も、イメージの更新バージョンを使用して問題を修正します。

解決

イメージk8s-webhook-cert-managerを（バージョン> = 1.3.2に）更新し、ジョブを再実行します。
シークレットが正しく作成され、 k8s-metadata-injectionポッドを起動できるようになります。
マニフェストとnri-bundleの新しいバージョンは、正しいバージョンの画像ですでに更新されていることに注意してください。

問題

APMエージェントのトランザクションの属性または分散トレースに含まれるKubernetesメタデータはありません。

解決

インストールの検証手順で説明されている手順に従って、環境変数が正しく挿入されていることを確認します。
それらが存在しない場合は、次を実行してメタデータインジェクションポッドの名前を取得します。
bash
```
$kubectl get pods | grep newrelic-metadata-injection-deployment
$kubectl logs -f pod/my-pod
```

別のターミナルで、新しいポッドを作成し（たとえば、インストールの検証を参照）、メタデータインジェクションデプロイメントのログにエラーがないか調べます。作成されたポッドごとに、次のような4つの新しいエントリのセットがログに記録されます。

{"level":"info","ts":"2020-04-09T12:55:32.107Z","caller":"server/main.go:139","msg":"POST https://newrelic-metadata-injection-svc.default.svc:443/mutate?timeout=30s HTTP/2.0\" from 10.11.49.2:32836"}
{"level":"info","ts":"2020-04-09T12:55:32.110Z","caller":"server/webhook.go:168","msg":"received admission review","kind":"/v1, Kind=Pod","namespace":"default","name":"","pod":"busybox1","UID":"6577519b-7a61-11ea-965e-0e46d1c9335c","operation":"CREATE","userinfo":{"username":"admin","uid":"admin","groups":["system:masters","system:authenticated"]}}
{"level":"info","ts":"2020-04-09T12:55:32.111Z","caller":"server/webhook.go:182","msg":"admission response created","response":"[{\"op\":\"add\",\"path\":\"/spec/containers/0/env\",\"value\":[{\"name\":\"NEW_RELIC_METADATA_KUBERNETES_CLUSTER_NAME\",\"value\":\"adn_kops\"}]},{\"op\":\"add\",\"path\":\"/spec/containers/0/env/-\",\"value\":{\"name\":\"NEW_RELIC_METADATA_KUBERNETES_NODE_NAME\",\"valueFrom\":{\"fieldRef\":{\"fieldPath\":\"spec.nodeName\"}}}},{\"op\":\"add\",\"path\":\"/spec/containers/0/env/-\",\"value\":{\"name\":\"NEW_RELIC_METADATA_KUBERNETES_NAMESPACE_NAME\",\"valueFrom\":{\"fieldRef\":{\"fieldPath\":\"metadata.namespace\"}}}},{\"op\":\"add\",\"path\":\"/spec/containers/0/env/-\",\"value\":{\"name\":\"NEW_RELIC_METADATA_KUBERNETES_POD_NAME\",\"valueFrom\":{\"fieldRef\":{\"fieldPath\":\"metadata.name\"}}}},{\"op\":\"add\",\"path\":\"/spec/containers/0/env/-\",\"value\":{\"name\":\"NEW_RELIC_METADATA_KUBERNETES_CONTAINER_NAME\",\"value\":\"busybox\"}},{\"op\":\"add\",\"path\":\"/spec/containers/0/env/-\",\"value\":{\"name\":\"NEW_RELIC_METADATA_KUBERNETES_CONTAINER_IMAGE_NAME\",\"value\":\"busybox\"}}]"}
{"level":"info","ts":"2020-04-09T12:55:32.111Z","caller":"server/webhook.go:257","msg":"writing response"}

ログに新しいエントリがない場合は、apiserverがWebhookサービスと通信できないことを意味します。これは、ネットワークルールまたはセキュリティグループが通信を拒否したことが原因である可能性があります。

apiserverがWebhookと通信できないかどうかを確認するには、apiserverログで次のようなエラーがないかどうかを確認する必要があります。
```
failed calling webhook "metadata-injection.newrelic.com": THE_ERROR_REASON
```
apiserverログを取得するには：
1. ターミナルウィンドウで次のコマンドを実行して、Kubernetes APIサーバーへのプロキシを起動し、実行を続けます。
  bash
```
$kubectl proxy --port=8001
```
2. クラスタに新しいポッドを作成します。これにより、apiserverがWebhookとの通信を試みます。次のコマンドはbusyboxを作成します。
  bash
```
$kubectl create -f https://git.io/vPieo
```
3. apiserverログを取得します。
  bash
```
$curl localhost:8001/logs/kube-apiserver.log > apiserver.log
```
4. busyboxコンテナを削除します。
  bash
```
$kubectl delete -f https://git.io/vPieo
```
5. ログにエラーがないか調べます。
  bash
```
$grep -E 'failed calling webhook' apiserver.log
```
  ヒント
  メタデータインジェクションの要件の1つは、クラスターで実行されているポッドへの出力をapiserverに許可する必要があることです。接続のタイムアウトや接続の失敗に関するエラーが発生した場合は、クラスターのセキュリティグループとファイアウォールルールを確認してください。
apiserverログまたはメタデータインジェクションデプロイメントのいずれにもログエントリがない場合は、Webhookが正しく登録されていないことを意味します。
次の出力を調べて、メタデータインジェクションのセットアップジョブが正常に実行されたことを確認します。
bash
```
$kubectl get job newrelic-metadata-setup
```
ジョブが完了していない場合は、セットアップジョブのログを調べてください。
bash
```
$kubectl logs job/newrelic-metadata-setup
```
次のコマンドを実行して、 CertificateSigningRequestが承認および発行されていることを確認します。
bash
```
$kubectl get csr newrelic-metadata-injection-svc.default
```
次のコマンドを実行して、TLSシークレットが存在することを確認します。
bash
```
$kubectl get secret newrelic-metadata-injection-secret
```
CAバンドルが変更中のWebhook構成に存在することを確認します。
bash
```
$kubectl get mutatingwebhookconfiguration newrelic-metadata-injection-cfg -o json
```
サービスリソースのTargetPortがデプロイメントのコンテナのポートと一致することを確認します。
bash
```
$kubectl describe service/newrelic-metadata-injection-svc
$kubectl describe deployment/newrelic-metadata-injection-deployment
```

この機械翻訳は参考用に提供されます。

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

ヒント

互換性と要件

ネットワーク要件

APMエージェントの互換性

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

カスタム構成

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

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

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

ヒント

重要

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

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

トラブルシューティング

APMまたは分散トレーストランザクションにKubernetesメタデータがない

問題

解決

トランザクションの属性にKubernetesメタデータがありません

問題

解決

ヒント