Problemas
Você concluiu o procedimento de instalação para integração do Kubernetes do New Relic, está vendo dados do Kubernetes em sua conta do New Relic, mas não há dados de nenhum dos componentes do plano de controle.
Caso os dados do plano de controle estejam faltando, por exemplo K8sSchedulerSample, a primeira coisa a fazer é verificar o log detalhado dos componentes do plano de controle. Leia como ativar o registro detalhado
Uma possibilidade é que a autodescoberta tente encontrar no cluster o pod do plano de controle aproveitando os rótulos mais comuns, caso nenhum pod seja encontrado para um único componente ela não deixa de evitar a perda de mais dados. Neste cenário, você verá um log semelhante ao seguinte:
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"Nesse caso, você pode alterar o comportamento de descoberta com a configuração
controlplane.config.[component].autodiscover[].selectordos valores do gráfico do leme. Leia mais sobre os componentes do plano de controle.Também é possível que o componente controlplane seja encontrado, mas a autenticação com o endpoint falhe. Neste cenário, você verá um log semelhante ao seguinte:
time="2022-06-21T15:54:52Z" level=debug msg="Endpoint \"https://localhost:10257\" probe failed, skipping: http request failed with status: 403 Forbidden"Nesse caso, você pode alterar o comportamento de autenticação para cada endpoint com a configuração
controlplane.config.[component].autodiscover[].endpoints[].authdos valores do gráfico do helm.Também é possível que o componente controlplane da integração não esteja em execução em todos os nós mestres.
Você pode verificar isso executando:
kubectl get pod -n <NEWRELIC_NAMESPACE> -l app.kubernetes.io/component=controlplane -o wideSe houver algum pod do plano de controle que você deseja monitor em execução em um nó sem uma instância de monitoramento Newrelic, você poderá alterar conforme necessário
controlplane.affinity,controlplane.nodeSelectorecontrolplane.tolerationsdos valores do gráfico do leme.
Caso os componentes do plano de controle não descubram automaticamente ou raspem com sucesso qualquer pod do plano de controle que ele entrar no CrashLoopBackOff.
Conforme descrito na seção anterior, você pode alterar o comportamento da descoberta automática e dos métodos de autenticação para atender às suas necessidades.
Por outro lado, se você não estiver interessado nesses dados, você pode simplesmente desativar o componente do plano de controle definindo controlplane.enabled=false nos valores do gráfico do leme.
Solução para integração versão V2
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 na seção de documentação de descoberta de nós mestres e componentes do plano de controle, você deverá obter alguma saída como:
NAME STATUS ROLES AGE VERSIONip-10-42-24-4.ec2.internal Ready master 42d v1.14.8Se nenhum nó for encontrado, existem dois cenários:
Seus nós mestres não possuem os rótulos necessários que os identificam como mestres; nesse 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ê. Neste caso não há nada que você possa fazer, pois seu provedor está limitando o acesso a esses nós.
Substitua o espaço reservado no comando a seguir por um dos nomes de nó retornados na etapa anterior para executar um pod de integração em um nó mestre:
kubectl get pods --field-selector spec.nodeName=NODE_NAME -l name=newrelic-infra --all-namespacesO próximo comando é o mesmo, 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 AGEnewrelic-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 AGEkube-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-namespaceskubectl get pods -l k8s-app=kube-scheduler --all-namespaceskubectl 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”. Ex:
Running job: schedulerRunning job: etcdRunning job: controller-managerRunning job: api-serverSe você não especificou a opção de configuração ETCD_TLS_SECRET_NAME , você encontrará a seguinte mensagem no log:
Skipping job creation for component etcd: etcd requires TLS configuration, none givenCaso ocorra algum erro na consulta da métrica de algum componente ele será logado após a mensagem Running job .
Consulte a seção de documentação de descoberta de nós mestres e componentes do plano de controle para obter o endpoint do componente do plano de controle que você deseja consultar. Com o endpoint podemos usar o pod de integração que está rodando no mesmo nó que o componente a ser consultado. A seguir estão exemplos de como consultar o agendador Kubernetes :
kubectl exec -ti POD_NAME -- wget -O - localhost:10251/metricsO comando a seguir faz o mesmo, 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 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