Se você estiver executando a versão 2, verifique estes erros comuns de integração do Kubernetes. Esses erros aparecem no log padrão não detalhado do agente de infraestrutura. Se precisar de um log mais detalhado, consulte LogKubernetes .
A integração do Kubernetes requer kube-state-metrics. Se estiver faltando, você verá um erro como este no log do contêiner 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"Os motivos comuns para esse erro incluem:
kube-state-metricsnão foi implantado no cluster.kube-state-metricsé implantar usando uma implantação personalizada.- Há diversas versões de
kube-state-metricsem execução e a integração do Kubernetes não está encontrando a versão correta.
A integração do Kubernetes descobre automaticamente kube-state-metrics em seu cluster usando esta lógica:
- Ele procura um serviço
kube-state-metricsem execução no namespacekube-system. - Se não for encontrado, ele procura uma etiqueta de serviço com o rótulo
"k8s-app: kube-state-metrics".
A integração também exige que o pod kube-state-métrica tenha o rótulo k8s-app: kube-state-metrics ou app: kube-state-metrics. Se nenhum deles for encontrado, haverá uma entrada de log como esta:
$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\"\nPara resolver esse problema, adicione o rótulo k8s-app=kube-state-metrics ao pod kube-state-metrics .
Se as métricas para nós, pod e contêiner Kubernetes estiverem aparecendo, mas as métricas para namespace, implantação e ReplicaSets estiverem faltando, a integração Kubernetes não consegue se conectar a kube-state-metrics.
Indicadores de namespace, implantação e dados ReplicaSet ausentes:
No gráfico
# of K8s objects
, esses dados estão faltando.
Consulta para
K8sNamespaceSample,K8sDeploymentSampleeK8sReplicasetSamplenão mostram nenhum dado.
Existem algumas razões possíveis para isso:
kube-state-metricsserviço foi personalizado para escutar na porta 80. Se estiver usando uma porta diferente, você poderá ver um erro como este no registroverbose: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"Este é um problema conhecido que acontece em alguns clusters onde o
kube-state-metricsdemora muito para coletar todas as informações do cluster antes de enviar para a integração.Como solução alternativa, aumente o tempo limite do cliente kube-state-métrica.
kube-state-metricsa instância está sendo executada atrás dekube-rbac-proxy. Atualmente, a New Relic não oferece suporte a esta configuração. Você poderá ver um erro como o seguinte no registroverbose: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"A carga útil do KSM é muito grande e a integração do Kubernetes que processa a data está sendo eliminada pelo OOM. Como a integração não é o processo principal do contêiner, o pod não é reiniciado. Essa situação pode ser detectada no log do pod
newrelic-infraem execução no mesmo nó do KSM:bash$time="2020-12-10T17:40:44Z" level=error msg="Integration command failed" error="signal: killed" instance=nri-kubernetes integration=com.newrelic.kubernetesComo solução alternativa, aumente os limites de memória do DaemonSet para que o processo não seja eliminado.
O pod Newrelic e a conta de serviço newrelic não são implantados no mesmo namespace. Geralmente isso ocorre porque o contexto atual especifica um namespace. Se for esse o caso, você verá um erro como o seguinte:
$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\"Para verificar se este é o caso, execute:
$kubectl describe serviceaccount newrelic | grep Namespace$kubectl get pods -l name=newrelic-infra --all-namespaces$kubectl config get-contextsPara resolver esse problema, altere o namespace da conta de serviço no arquivo YAML New Relic DaemonSet para ser igual ao namespace do contexto atual:
- kind: ServiceAccount name: newrelic namespace: default---Não vendo dados do plano de controle
Execute os seguintes comandos para localizar manualmente os nós mestres:
$kubectl get nodes -l node-role.kubernetes.io/master=""$kubectl get nodes -l kubernetes.io/role="master"Se os nós mestres seguirem a convenção de rotulagem definida no componente Plano de controle, você deverá obter alguma saída como:
$NAME STATUS ROLES AGE VERSION$ip-10-42-24-4.ec2.internal Ready master 42d v1.14.8Se nenhum nó for encontrado, existem dois cenários:
Seus nós principais não possuem os rótulos necessários que os identifiquem como mestres. Neste caso, você precisa adicionar ambos os rótulos aos seus nós mestres.
Você está em um cluster gerenciado e seu provedor está gerenciando os nós principais para você. Nesse caso, não há nada que você possa fazer, pois seu provedor está limitando o acesso a esses nós.
Para identificar um pod de integração em execução em um nó mestre, substitua NODE_NAME no comando a seguir por um dos nomes de nó listados na etapa anterior:
$kubectl get pods --field-selector spec.nodeName=NODE_NAME -l name=newrelic-infra --all-namespacesO próximo comando é igual ao anterior, apenas seleciona o nó para você:
$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-namespacesSe tudo estiver correto, você deverá obter alguma saída como:
$NAME READY STATUS RESTARTS AGE$newrelic-infra-whvzt 1/1 Running 0 6d20hCaso a integração não esteja rodando em seus nós mestres, verifique se o daemonset possui toda a instância desejada rodando e pronta.
$kubectl get daemonsets -l app=newrelic-infra --all-namespacesConsulte a seção de documentação de descoberta de nós principais e componentes do plano de controle e procure os rótulos que a integração usa para descobrir os componentes. Em seguida, execute os seguintes comandos para ver se há algum pod com esses rótulos e os nós onde eles estão sendo executados:
$kubectl get pods -l k8s-app=kube-apiserver --all-namespacesSe houver um componente com o rótulo fornecido, você verá algo como:
$NAMESPACE NAME READY STATUS RESTARTS AGE$kube-system kube-apiserver-ip-10-42-24-42.ec2.internal 1/1 Running 3 49dO mesmo deve ser feito com o restante dos 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-namespacesPara recuperar o log, siga as instruções em obter log do pod em execução em um nó mestre. A integração registra para cada componente a seguinte mensagem Running job: COMPONENT_NAME. Por exemplo:
$Running job: scheduler$Running job: etcd$Running job: controller-manager$Running job: api-serverSe você não especificou a opção de configuração ETCD_TLS_SECRET_NAME , encontrará esta mensagem no registro:
$Skipping job creation for component etcd: etcd requires TLS configuration, none givenCaso ocorra algum erro na consulta da métrica de algum componente, o mesmo será registrado após a mensagem Running job .
Para obter o endpoint do componente do plano de controle que você deseja consultar, consulte o componente Plano de controle. Com o endpoint, você pode usar o pod de integração que está rodando no mesmo nó que o componente a ser consultado. Veja estes exemplos de como consultar o agendador Kubernetes :
$kubectl exec -ti POD_NAME -- wget -O - localhost:10251/metricsO comando a seguir faz o mesmo que o anterior, mas também escolhe o pod para você:
$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/metricsSe tudo estiver correto, você deverá obter alguma métrica no formato Prometheus, algo assim:
$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