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-metrics
não foi implantado no cluster.kube-state-metrics
é implantar usando uma implantação personalizada.- Há diversas versões de
kube-state-metrics
em 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-metrics
em 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\"\n
Para 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
,K8sDeploymentSample
eK8sReplicasetSample
não mostram nenhum dado.
Existem algumas razões possíveis para isso:
kube-state-metrics
serviç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-metrics
demora 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-metrics
a 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-infra
em 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-contexts
Para 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.8
Se 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-namespaces
O 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-namespaces
Se tudo estiver correto, você deverá obter alguma saída como:
$NAME READY STATUS RESTARTS AGE$newrelic-infra-whvzt 1/1 Running 0 6d20h
Caso 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-namespaces
Consulte 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-namespaces
Se 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 49d
O 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-namespaces
Para 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-server
Se 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 given
Caso 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/metrics
O 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/metrics
Se 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