コントロールプレーンデータが見えない

コントロールプレーンデータが欠落している場合（たとえばK8sSchedulerSample ）、最初に行うことは、コントロールプレーンコンポーネントの詳細なログを確認することです。詳細ログを有効にする方法を読む

• 可能性としては、自動検出がクラスター内で最も一般的なラベルを利用してコントロールプレーンポッドを見つけようとすることがあります。単一のコンポーネントのポッドが見つからない場合でも、データの欠落を回避できます。このシナリオでは、次のようなログが表示されます。

  time="2022-06-21T12:21:25Z" level=debug msg="Autodiscovering pods for \"scheduler\""
  time="2022-06-21T12:21:25Z" level=debug msg="0 pods found with labels \"tier=control-plane,component=kube-scheduler\""
  time="2022-06-21T12:21:25Z" level=debug msg="No pod found for \"scheduler\" with labels \"tier=control-plane,component=kube-scheduler\""
  time="2022-06-21T12:21:25Z" level=debug msg="0 pods found with labels \"k8s-app=kube-scheduler\""
  time="2022-06-21T12:21:25Z" level=debug msg="No pod found for \"scheduler\" with labels \"k8s-app=kube-scheduler\""
  time="2022-06-21T12:21:25Z" level=debug msg="0 pods found with labels \"app=openshift-kube-scheduler,scheduler=true\""
  time="2022-06-21T12:21:25Z" level=debug msg="No pod found for \"scheduler\" with labels \"app=openshift-kube-scheduler,scheduler=true\""
  time="2022-06-21T12:21:25Z" level=debug msg="No \"scheduler\" pod has been discovered"

  コピー

  この場合、ヘルムチャート値のcontrolplane.config.[component].autodiscover[].selector設定を使用して検出動作を変更できます。コントロールプレーンコンポーネントの詳細をご覧ください。

• コントロールプレーンコンポーネントが見つかったが、エンドポイントでの認証が失敗した可能性もあります。このシナリオでは、次のようなログが表示されます。

  time="2022-06-21T15:54:52Z" level=debug msg="Endpoint \"https://localhost:10257\" probe failed, skipping: http request failed with status: 403 Forbidden"

  コピー

  この場合、ヘルムチャート値のcontrolplane.config.[component].autodiscover[].endpoints[].auth構成を使用して、各エンドポイントの認証動作を変更できます。

• 統合のコントロールプレーンコンポーネントがすべてのマスターノードで実行されていない可能性もあります。

  あなたはその実行を再確認することができます：

  kubectl get pod -n <NEWRELIC_NAMESPACE> -l app.kubernetes.io/component=controlplane -o wide

  コピー

  Newrelicモニタリングインスタンスなしでノード上で実行されているモニタリングしたいコントロールプレーンポッドがある場合は、必要に応じてヘルムチャート値のcontrolplane.affinity 、 controlplane.nodeSelector 、およびcontrolplane.tolerationsを変更できます。

コントロールプレーンコンポーネントがCrashLoopBackOffに入るコントロールプレーンポッドを自動検出またはスクレイピングしない場合。

前のセクションで説明したように、必要に応じて自動検出の動作と認証方法を変更できます。

一方、そのデータに関心がない場合は、ヘルムチャート値にcontrolplane.enabled=falseを設定することで、コントロールプレーンコンポーネントを無効にすることができます。

以下のコマンドを実行して、手動でマスターノードを探します。

kubectl get nodes -l node-role.kubernetes.io/master=""

kubectl get nodes -l kubernetes.io/role="master"

マスターノードが、 discovery of master nodes and control plane components documentation section で定義されているラベリング規則に従っている場合、以下のような出力が得られるはずです。

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

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

マスターノードにマスターであることを示すラベルがない場合、マスターノードに両方のラベルを追加する必要があります。

マネージドクラスターの中で、プロバイダーがマスターノードを処理している場合です。この場合、プロバイダーがこれらのノードへのアクセスを制限しているので、あなたにできることはありません。

次のコマンドのプレースホルダーを、前のステップで返されたノード名のいずれかに置き換えて、マスターノードで実行されている統合ポッドを取得します。

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/master="" -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

discovery of master nodes and control plane components documentation section を参照し、インテグレーションがコンポーネントの検出に使用しているラベルを探します。次に、以下のコマンドを実行して、このようなラベルを持つポッドがあるかどうか、またそれらが実行されているノードを確認します。

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メッセージの後にログに記録されます。

discovery of master nodes and control plane components documentation section を参照して、クエリを実行するコントロールプレーンコンポーネントのエンドポイントを取得します。このエンドポイントを使用して、クエリを実行するコンポーネントと同じノードで実行されている統合ポッドを使用することができます。以下は、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/master="" -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