Kubernetesインテグレーション エラー (バージョン 2)

Kubernetesにはkube-state-metrics が必要です。 これが欠落している場合は、 newrelic-infraコンテナ ログに次のようなエラーが表示されます。

$
2018-04-11T08:02:41.765236022Z time="2018-04-11T08:02:41Z" level=error 
$
msg="executing data source" data prefix="integration/com.newrelic.kubernetes" 
$
error="exit status 1" plugin name=nri-kubernetes stderr="time=\"2018-04-11T08:02:41Z\" 
$
level=fatal msg=\"failed to discover kube-state-metrics endpoint, 
$
got error: no service found by label k8s-app=kube-state-metrics\"\n"

このエラーが発生する一般的な理由は以下の通りです。

• kube-state-metrics クラスターにデプロイされていません。
• kube-state-metrics カスタム展開を使用して展開されます。
• kube-state-metricsの複数のバージョンが実行されており、Kubernetes統合が正しいバージョンを検出していません。

Kubernetes統合は、次のロジックを使用してクラスター内のkube-state-metricsを自動的に検出します。

1. kube-system名前空間で実行されているkube-state-metricsサービスを探します。
2. それが見つからない場合は、ラベル"k8s-app: kube-state-metrics"でタグ付けされたサービスを探します。

統合には、kube-state-metricsポッドにk8s-app: kube-state-metricsまたはapp: kube-state-metricsのラベルが必要です。どちらも見つからない場合は、次のようなログエントリがあります。

$
2018-04-11T09:25:00.825532798Z time="2018-04-11T09:25:00Z" level=error 
$
msg="executing data source" data prefix="integration/com.newrelic.kubernetes" 
$
error="exit status 1" plugin name=nri-kubernetes stderr="time=\"2018-04-11T09:25:00Z\" 
$
level=fatal msg=\"failed to discover nodeIP with kube-state-metrics, 
$
got error: no pod found by label k8s-app=kube-state-metrics\"\n

この問題を解決するには、 k8s-app=kube-state-metricsラベルをkube-state-metricsポッドに追加します。

Kubernetesノード、ポッド、およびコンテナーのメトリクスは表示されているが、ネームスペース、デプロイメント、および ReplicaSets のメトリクスが表示されていない場合、 Kubernetesインテグレーションは kube-state-metrics に接続できません。

これにはいくつかの理由が考えられます。

1. kube-state-metrics サービスはポート 80 でリッスンするようにカスタマイズされています。 別のポートを使用している場合は、 verboseログに次のようなエラーが表示されることがあります。

   bash

   コピー

   $
   time="2018-04-04T09:35:47Z" level=error msg="executing data source" 
   $
   data prefix="integration/com.newrelic.kubernetes" error="exit status 1" 
   $
   plugin name=nri-kubernetes stderr="time=\"2018-04-04T09:35:47Z\" 
   $
   level=fatal msg=\"Non-recoverable error group: error querying KSM. 
   $
   Get http://kube-state-metrics.kube-system.svc.cluster.local:0/metrics: 
   $
   net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)\"\n"

   これは、統合に送信する前にkube-state-metricsがすべてのクラスターの情報を収集するのに時間がかかりすぎる一部のクラスターで発生する既知の問題です。

   回避策として、 kube-state-metrics client timeout を増やしてください。

2. kube-state-metrics インスタンスはkube-rbac-proxyより遅れて実行されています。 New Relic現在この設定をサポートしていません。 verboseログに次のようなエラーが表示される場合があります。

   bash

   コピー

   $
   time="2018-03-28T23:09:12Z" level=error msg="executing data source" 
   $
   data prefix="integration/com.newrelic.kubernetes" error="exit status 1" 
   $
   plugin name=nri-kubernetes stderr="time=\"2018-03-28T23:09:12Z\" 
   $
   level=fatal msg=\"Non-recoverable error group: error querying KSM. 
   $
   Get http://192.168.132.37:8443/metrics: net/http: HTTP/1.x 
   $
   transport connection broken: malformed HTTP response \\\"\\\\x15\\\\x03\\\\x01\\\\x00\\\\x02\\\\x02\\\"\"\n"

3. KSMペイロードは非常に大きく、日付を処理するKubernetes統合はOOM-killされています。統合はコンテナのメインプロセスではないため、ポッドは再起動されません。この状況は、KSMの同じノードで実行されているnewrelic-infraポッドのログで確認できます。

   bash

   コピー

   $
   time="2020-12-10T17:40:44Z" level=error msg="Integration command failed" error="signal: killed" instance=nri-kubernetes integration=com.newrelic.kubernetes

   回避策としては、DaemonSetのメモリ制限を増やして、プロセスが殺されないようにします。

Newrelicのポッドとnewrelicのサービスアカウントが同じ名前空間にデプロイされません。これは通常、現在のコンテキストが名前空間を指定しているためです。このような場合は、以下のようなエラーが表示されます。

$
time=\"2018-05-31T10:55:39Z\" level=panic msg=\"p
$
ods is forbidden: User \\\"system:serviceaccount:kube-system:newrelic\\\" cannot list pods at the cluster scope\"

これを確認するには、次のように実行します。

$
kubectl describe serviceaccount newrelic | grep Namespace
$
kubectl get pods -l name=newrelic-infra --all-namespaces
$
kubectl config get-contexts

この問題を解決するには、New Relic DaemonSet YAMLファイルのサービスアカウントの名前空間を、現在のコンテキストの名前空間と同じになるように変更します。

- kind: ServiceAccount
  name: newrelic
  namespace: default
---

コントロール プレーン ノードを手動で検索するには、次のコマンドを実行します。

$
kubectl get nodes -l node-role.kubernetes.io/control-plane=""

コントロール プレーン ノードがコントロール プレーン コンポーネントで定義されたラベル付け規則に従っている場合は、次のような出力が表示されます。

$
NAME                         STATUS  ROLES          AGE   VERSION
$
ip-10-42-24-4.ec2.internal   Ready   control-plane  42d   v1.14.8

ノードが見つからない場合、2つのシナリオがあります。

コントロール プレーン ノードには、コントロール プレーンとして識別するための必要なラベルがありません。 この場合、コントロール プレーン ノードに両方のラベルを追加する必要があります。

管理対象クラスター内におり、プロバイダーがコントロール プレーン ノードを処理しています。 この場合、プロバイダーがそれらのノードへのアクセスを制限しているため、何もできません。

コントロール プレーン ノードで実行されている統合ポッドを識別するには、次のコマンドのNODE_NAME 、前の手順でリストされたノード名のいずれかに置き換えます。

$
kubectl get pods --field-selector spec.nodeName=NODE_NAME -l name=newrelic-infra --all-namespaces

次のコマンドは前のコマンドと同じですが、ノードを選択するだけです。

$
kubectl get pods --field-selector spec.nodeName=$(kubectl get nodes -l node-role.kubernetes.io/control-plane="" -o jsonpath="{.items[0].metadata.name}") -l name=newrelic-infra --all-namespaces

すべてが正しく行われていれば、次のような出力が得られるはずです。

$
NAME                   READY   STATUS    RESTARTS   AGE
$
newrelic-infra-whvzt   1/1     Running   0          6d20h

統合がコントロール プレーン ノードで実行されていない場合は、デーモンセットで必要なインスタンスがすべて実行され、準備ができていることを確認してください。

$
kubectl get daemonsets -l app=newrelic-infra --all-namespaces

コントロール プレーン ノードとコンポーネントの検出に関するドキュメントのセクションを参照し、統合がコンポーネントの検出に使用するラベルを探してください。 次に、次のコマンドを実行して、そのようなラベルを持つポッドと、それらが実行されているノードがあるかどうかを確認します。

$
kubectl get pods -l k8s-app=kube-apiserver --all-namespaces

与えられたラベルを持つコンポーネントがあれば、次のような表示になります。

$
NAMESPACE    NAME                                        READY  STATUS   RESTARTS  AGE
$
kube-system  kube-apiserver-ip-10-42-24-42.ec2.internal  1/1    Running  3         49d

残りの部品も同様にしてください。

$
kubectl get pods -l k8s-app=etcd-manager-main --all-namespaces

$
kubectl get pods -l k8s-app=kube-scheduler --all-namespaces

$
kubectl get pods -l k8s-app=kube-kube-controller-manager --all-namespaces

ログを取得するには、 「コントロール プレーン ノードで実行されているポッドからログを取得する」の手順に従います。 すべてのコンポーネントの統合ログには、次のメッセージRunning job: COMPONENT_NAME記録されます。 例:

$
Running job: scheduler

$
Running job: etcd

$
Running job: controller-manager

$
Running job: api-server

ETCD_TLS_SECRET_NAME設定オプションを指定しなかった場合、ログに次のメッセージが表示されます。

$
Skipping job creation for component etcd: etcd requires TLS configuration, none given

コンポーネントのメトリクスのクエリ中にエラーが発生した場合は、 Running jobメッセージの後にログが記録されます。

クエリを実行するコントロール プレーン コンポーネントのエンドポイントを取得するには、「 コントロール プレーン コンポーネント」を参照してください。 エンドポイントを使用すると、コンポーネントと同じノード上で動作する統合ポッドを使用して書くことができます。 Kubernetes スケジューラをクエリする方法については、次の例を参照してください。

$
kubectl exec -ti POD_NAME -- wget -O - localhost:10251/metrics

次のコマンドは前のコマンドと同じことを行いますが、ポッドも自動的に選択します。

$
kubectl exec -ti $(kubectl get pods --all-namespaces --field-selector spec.nodeName=$(kubectl get nodes -l node-role.kubernetes.io/control-plane="" -o jsonpath="{.items[0].metadata.name}") -l name=newrelic-infra -o jsonpath="{.items[0].metadata.name}") -- wget -O - localhost:10251/metrics

すべてが正しければ、次のような Prometheus 形式のメトリクスが得られるはずです。

$
Connecting to localhost:10251 (127.0.0.1:10251)
$
# HELP apiserver_audit_event_total Counter of audit events generated and sent to the audit backend.
$
# TYPE apiserver_audit_event_total counter
$
apiserver_audit_event_total 0
$
# HELP apiserver_audit_requests_rejected_total Counter of apiserver requests rejected due to an error in audit logging backend.
$
# TYPE apiserver_audit_requests_rejected_total counter
$
apiserver_audit_requests_rejected_total 0
$
# HELP apiserver_client_certificate_expiration_seconds Distribution of the remaining lifetime on the certificate used to authenticate a request.
$
# TYPE apiserver_client_certificate_expiration_seconds histogram
$
apiserver_client_certificate_expiration_seconds_bucket{le="0"} 0
$
apiserver_client_certificate_expiration_seconds_bucket{le="1800"} 0
$
apiserver_client_certificate_expiration_seconds_bucket{le="3600"} 0