Problemas
Ha completado el procedimiento de instalación para la integración de Kubernetes de New Relic, está viendo datos de Kubernetes en su cuenta de New Relic pero no hay datos de ninguno de los componentes del plano de control.
En caso de que falten datos del plano de control, por ejemplo K8sSchedulerSample
, lo primero que debe hacer es verificar el registro detallado de los componentes del plano de control. Lea cómo habilitar el registro detallado
Una posibilidad es que el autodiscovery intente encontrar en el clúster el pod del plano de control aprovechando las etiquetas más comunes, en caso de que no se encuentre ningún pod para un solo componente no deja de evitar perder más datos. En este escenario verá un registro similar al siguiente:
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"En este caso, puede cambiar el comportamiento de descubrimiento con la configuración
controlplane.config.[component].autodiscover[].selector
de los valores del gráfico de timón. Lea más sobre los componentes del plano de control.También es posible que se encuentre el componente del plano de control, pero falle la autenticación con el extremo. En este escenario verá un registro similar al siguiente:
time="2022-06-21T15:54:52Z" level=debug msg="Endpoint \"https://localhost:10257\" probe failed, skipping: http request failed with status: 403 Forbidden"En este caso, puede cambiar el comportamiento de autenticación para cada extremo con la configuración
controlplane.config.[component].autodiscover[].endpoints[].auth
de los valores del gráfico de timón.También es posible que el componente del plano de control de la integración no se esté ejecutando en todos los nodos maestros.
Puedes volver a verificar que se esté ejecutando:
kubectl get pod -n <NEWRELIC_NAMESPACE> -l app.kubernetes.io/component=controlplane -o wideSi hay algún pod de plano de control que desea monitor ejecutándose en un nodo sin una instancia de monitoreo de Newrelic, puede cambiar según sea necesario
controlplane.affinity
,controlplane.nodeSelector
ycontrolplane.tolerations
de los valores del gráfico de timón.
En caso de que los componentes del plano de control no detecten automáticamente ni eliminen con éxito ningún módulo pod plano de control que ingrese en CrashLoopBackOff.
Como se describe en la sección anterior, puede cambiar el comportamiento del descubrimiento automático y los métodos de autenticación para satisfacer sus necesidades.
Por otro lado, si no está interesado en esos datos, simplemente puede desactivar el componente del plano de control configurando controlplane.enabled=false
en los valores del gráfico de timón.
Solución para integración versión V2
Ejecute los siguientes comandos para buscar manualmente los nodos maestros:
kubectl get nodes -l node-role.kubernetes.io/master=""
kubectl get nodes -l kubernetes.io/role="master"
Si los nodos maestros siguen la convención de etiquetado definida en la sección de documentación sobre descubrimiento de nodos maestros y componentes del plano de control, debería obtener un resultado como:
NAME STATUS ROLES AGE VERSIONip-10-42-24-4.ec2.internal Ready master 42d v1.14.8
Si no se encuentran nodos, existen dos escenarios:
Sus nodos maestros no tienen las etiquetas requeridas que los identifiquen como maestros; en este caso, debe agregar ambas etiquetas a sus nodos maestros.
Estás en un clúster administrado y tu proveedor maneja los nodos maestros por ti. En este caso no hay nada que puedas hacer, ya que tu proveedor está limitando el acceso a esos nodos.
Reemplace el marcador de posición en el siguiente comando con uno de los nombres de nodo devueltos en el paso anterior para ejecutar un pod de integración en un nodo maestro:
kubectl get pods --field-selector spec.nodeName=NODE_NAME -l name=newrelic-infra --all-namespaces
El siguiente comando es el mismo, solo que selecciona el nodo por usted:
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
Si todo es correcto deberías obtener algún resultado como:
NAME READY STATUS RESTARTS AGEnewrelic-infra-whvzt 1/1 Running 0 6d20h
Si la integración no se está ejecutando en sus nodos maestros, verifique que el daemonset tenga todas las instancias deseadas ejecutándose y listas.
kubectl get daemonsets -l app=newrelic-infra --all-namespaces
Consulte la sección de documentación sobre descubrimiento de nodos maestros y componentes del plano de control y busque las etiquetas que utiliza la integración para descubrir los componentes. Luego ejecute los siguientes comandos para ver si hay algún pod con dichas etiquetas y los nodos donde se están ejecutando:
kubectl get pods -l k8s-app=kube-apiserver --all-namespaces
Si hay un componente con la etiqueta dada, deberías ver algo como:
NAMESPACE NAME READY STATUS RESTARTS AGEkube-system kube-apiserver-ip-10-42-24-42.ec2.internal 1/1 Running 3 49d
Lo mismo se debe hacer con el resto de componentes:
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
Para recuperar el registro, siga las instrucciones sobre cómo obtener el registro del pod que se ejecuta en un nodo maestro. El registro de integración para cada componente muestra el siguiente mensaje "Running job: COMPONENT_NAME". Ex:
Running job: scheduler
Running job: etcd
Running job: controller-manager
Running job: api-server
Si no especificaste la opción de configuración ETCD_TLS_SECRET_NAME
, encontrarás el siguiente mensaje en el registro:
Skipping job creation for component etcd: etcd requires TLS configuration, none given
Si ocurre algún error al consultar la métrica de algún componente, se registrará después del mensaje Running job
.
Consulte la sección de documentación sobre descubrimiento de nodos maestros y componentes del plano de control para obtener el extremo del componente del plano de control que desea consultar. Con el extremo podemos usar el pod de integración que se ejecuta en el mismo nodo que el componente a consultar. Los siguientes son ejemplos de cómo consultar el programador Kubernetes :
kubectl exec -ti POD_NAME -- wget -O - localhost:10251/metrics
El siguiente comando hace lo mismo, pero también elige el pod por usted:
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
Si todo está correcto deberías obtener alguna métrica en el formato Prometheus, algo como:
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 counterapiserver_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 counterapiserver_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 histogramapiserver_client_certificate_expiration_seconds_bucket{le="0"} 0apiserver_client_certificate_expiration_seconds_bucket{le="1800"} 0apiserver_client_certificate_expiration_seconds_bucket{le="3600"} 0