Visão geral

A versão 2 da integração do Kubernetes tem algumas configurações e requisitos diferentes da versão 3. Este documento aborda as configurações que são diferentes da versão 3 e que você precisará para a versão 2. Se não especificarmos nada diferente, você poderá usar as configurações da versão 3.

Cuidado

Tenha em mente que substituímos a versão 2 e você não deve usá-la. Mantemos esta documentação para usuários que ainda utilizam a versão 2.

Consulte Introdução à integração do Kubernetes para começar a usar a versão atual do Kubernetes.

Para entender as alterações da versão 3, consulte o documento Alterações introduzidas na versão 3 da integração do Kubernetes .

Plano de controle de monitoramento com integração versão 2

Esta seção aborda como configurar o monitoramento do plano de controle nas versões 2 e anteriores da integração.

Observe que essas versões tinham opções de descoberta automática menos flexíveis e não suportavam endpoint externo. Recomendamos fortemente que você atualize para a versão 3 o mais rápido possível.

Descoberta automática e configuração padrão: `hostNetwork` e `privileged`

Nas versões anteriores à v3, quando a integração for implantada usando privileged: false, a configuração hostNetwork do componente do plano de controle também será definida como false.

Descoberta de nós mestres e componentes do plano de controle

A integração do Kubernetes depende das convenções de rotulagem kubeadm para descobrir os nós principais e os componentes do plano de controle. Isso significa que os nós mestres devem ser rotulados com node-role.kubernetes.io/master="" ou kubernetes.io/role="master".

Os componentes do plano de controle devem ter os rótulos k8s-app ou tier e component . Consulte esta tabela para combinações e valores de rótulos aceitos:

Componente	Rótulo	Endpoint
Servidor API	Kubeadm / Kops / ClusterAPI `k8s-app=kube-apiserver` `tier=control-plane component=kube-apiserver` OpenShift `app=openshift-kube-apiserver apiserver=true`	`localhost:443/metrics` por padrão (pode ser configurado) se a solicitação falhar, volta para `localhost:8080/metrics`
etcd	Kubeadm / Kops / ClusterAPI `k8s-app=etcd-manager-main` `tier=control-plane component=etcd` OpenShift `k8s-app=etcd`	`localhost:4001/metrics`
Agendador	Kubeadm / Kops / ClusterAPI `k8s-app=kube-scheduler` `tier=control-plane component=kube-scheduler` OpenShift `app=openshift-kube-scheduler scheduler=true`	`localhost:10251/metrics`
Gerente de controlador	Kubeadm / Kops / ClusterAPI `k8s-app=kube-controller-manager` `tier=control-plane component=kube-controller-manager` OpenShift `app=kube-controller-manager kube-controller-manager=true`	`localhost:10252/metrics`

Quando a integração detecta que está rodando dentro de um nó mestre, ela tenta descobrir quais componentes estão rodando no nó procurando por pods que correspondam aos rótulos listados na tabela acima. Para cada componente em execução, a integração faz uma solicitação ao seu endpoint métrico.

Configuração

O monitoramento do plano de controle é automático para agentes rodando dentro de nós mestres. O único componente que requer uma etapa extra para ser executado é o etcd, porque ele usa autenticação TLS mútua (mTLS) para solicitações de clientes. O API Server também pode ser configurado para ser consultado através da Porta Segura.

Importante

O monitoramento do plano de controle para OpenShift 4.x requer configuração adicional. Para obter mais informações, consulte a seção Configuração do OpenShift 4.x.

etcd

Para definir o mTLS para consultar o etcd, você precisa definir estas duas opções de configuração:

Opção	Valor
`ETCD_TLS_SECRET_NAME`	Nome de um segredo do Kubernetes que contém a configuração do mTLS. O segredo deve conter as seguintes chaves: `cert`: o certificado que identifica o cliente que faz a solicitação. Deve ser assinado por uma CA confiável do etcd. `key`: a chave privada usada para gerar o certificado do cliente. `cacert`: a CA raiz usada para identificar o certificado do servidor etcd. Se a opção `ETCD_TLS_SECRET_NAME` não estiver definida, a métrica do etcd não será buscada.
`ETCD_TLS_SECRET_NAMESPACE`	O namespace onde o segredo especificado em `ETCD_TLS_SECRET_NAME` foi criado. Se não for definido, o namespace `default` será usado.

Opção

Valor

ETCD_TLS_SECRET_NAME

Nome de um segredo do Kubernetes que contém a configuração do mTLS.

O segredo deve conter as seguintes chaves:

cert: o certificado que identifica o cliente que faz a solicitação. Deve ser assinado por uma CA confiável do etcd.
key: a chave privada usada para gerar o certificado do cliente.
cacert: a CA raiz usada para identificar o certificado do servidor etcd.
Se a opção ETCD_TLS_SECRET_NAME não estiver definida, a métrica do etcd não será buscada.

ETCD_TLS_SECRET_NAMESPACE

O namespace onde o segredo especificado em ETCD_TLS_SECRET_NAME foi criado. Se não for definido, o namespace default será usado.

Servidor API

Por padrão, as métricas do servidor API são consultadas usando o endpoint inseguro localhost:8080. Se esta porta estiver desabilitada, você também poderá consultar estas métricas através da porta segura. Para habilitar isso, defina a seguinte opção de configuração no arquivo de manifesto de integração do Kubernetes:

Opção	Valor
`API_SERVER_ENDPOINT_URL`	A URL (segura) para consultar a métrica. O servidor API usa `localhost:443` por padrão Certifique-se de que `ClusterRole` tenha sido atualizado para a versão mais recente encontrada no manifesto Adicionado na versão 1.15.0

Opção

Valor

API_SERVER_ENDPOINT_URL

A URL (segura) para consultar a métrica. O servidor API usa localhost:443 por padrão

Certifique-se de que ClusterRole tenha sido atualizado para a versão mais recente encontrada no manifesto

Adicionado na versão 1.15.0

Importante

Observe que a porta pode ser diferente de acordo com a porta segura utilizada pelo servidor API.

Por exemplo, no Minikube, a porta segura do servidor API é 8443 e, portanto API_SERVER_ENDPOINT_URL deve ser definido como https://localhost:8443

Configuração do OpenShift

Os componentes do plano de controle no OpenShift 4.x usam URLs de endpoint que exigem SSL e autenticação baseada em conta de serviço. Portanto, você não pode usar as URLs de endpoint padrão .

Importante

Ao instalar openshift por meio do Helm, especifique a configuração para incluir automaticamente esses endpoints. A configuração openshift.enabled=true e openshift.version="4.x" incluirá o terminal seguro e ativará o tempo de execução /var/run/crio.sock .

Para configurar o monitoramento do plano de controle no OpenShift, remova o comentário das seguintes variáveis de ambiente no manifesto customizado. Os valores de URL são pré-configurados para os URLs base padrão para o endpoint de monitoramento métrico do plano de controle no OpenShift 4.x.

- name: "SCHEDULER_ENDPOINT_URL"
        value: "https://localhost:10259
        - name: "ETCD_ENDPOINT_URL"
        value: "https://localhost:9979"
        - name: "CONTROLLER_MANAGER_ENDPOINT_URL"
        value: "https://localhost:10257"
        - name: "API_SERVER_ENDPOINT_URL"
        value: "https://localhost:6443"

Importante

Mesmo que o ETCD_ENDPOINT_URL personalizado esteja definido, o etcd requer que a autenticação HTTPS e mTLS seja configurada. Para obter mais informações sobre como configurar mTLS para etcd no OpenShift, consulte Configurar mTLS para etcd no OpenShift.

Registro Kubernetes

Se você deseja gerar log detalhado e obter informações de versão e configuração, basta conferir as informações abaixo.

Para a integração Kubernetes , o agente de infraestrutura apenas adiciona uma entrada log em caso de erro. Os erros mais comuns são exibidos no log padrão (não detalhado). Se estiver fazendo uma investigação mais aprofundada por conta própria ou com o suporte da New Relic, você pode ativar o modo detalhado.

Cuidado

O modo detalhado aumenta significativamente a quantidade de informações enviadas ao arquivo de log. Habilite este modo apenas temporariamente para fins de resolução de problemas e redefina o nível de log quando terminar.

Para ativar o registro detalhado usando um arquivo de manifesto:

Habilite o registro detalhado: No arquivo de implantação, defina o valor de NRIA_VERBOSE para 1.
Aplique a configuração modificada executando:
bash
```
$kubectl apply -f your_newrelic_k8s.yaml
```
Deixe no modo detalhado por alguns minutos ou até que ocorra atividade suficiente.
Desative o modo detalhado: defina o valor NRIA_VERBOSE novamente como 0.
Aplique a configuração restaurada executando:
bash
```
$kubectl apply -f your_newrelic_k8s.yaml
```
Obtenha uma lista de nós no ambiente:
bash
```
$kubectl get nodes --all-namespaces
```

Obtenha uma lista de infraestrutura e pod kube-state-métrica:

bash

$kubectl get pods --all-namespaces -o wide | egrep 'newrelic|kube-state-metrics'

Obtenha o registro do pod conectado a kube-state-metrics.
Recuperar kube-state-metrics configuração de serviço.

Para a integração Kubernetes , o agente de infraestrutura apenas adiciona uma entrada log em caso de erro. Os erros mais comuns são exibidos no log padrão (não detalhado). Se você estiver fazendo uma investigação mais aprofundada por conta própria ou com o suporte da New Relic, poderá ativar o modo detalhado.

Cuidado

Para ativar o registro detalhado usando Helm:

Execute este comando:

bash

$helm upgrade -n <namespace> --reuse-values newrelic-bundle --set newrelic-infrastructure.verboseLog=true newrelic/nri-bundle

Deixe no modo detalhado por alguns minutos ou até que ocorra atividade suficiente.

Quando você tiver as informações necessárias, desative o registro detalhado:

bash

$helm upgrade --reuse-values newrelic-bundle --set newrelic-infrastructure.verboseLog=false newrelic/nri-bundle

Aplique a configuração restaurada executando:
bash
```
$kubectl apply -f your_newrelic_k8s.yaml
```
Obtenha uma lista de nós no ambiente:
bash
```
$kubectl get nodes --all-namespaces
```

Obtenha uma lista de infraestrutura e pod kube-state-métrica:

bash

$kubectl get pods --all-namespaces -o wide | egrep 'newrelic|kube-state-metrics'

Obtenha o registro do pod conectado a kube-state-metrics.
Recuperar kube-state-metrics configuração de serviço.

Para obter o registro do pod conectado a kube-state-metrics:

Execute este comando:

bash

$kubectl get pods --all-namespaces -o wide | grep kube-state-metrics

Procure uma saída semelhante a esta:

bash

$kube-system   kube-state-metrics-5c6f5cb9b5-pclhh     2/2
$    Running   4          4d        172.17.0.3   minikube

Obtenha o pod New Relic que está em execução no mesmo nó que kube-state-metrics:

bash

$kubectl describe node minikube | grep newrelic-infra

Procure uma saída semelhante a esta:

bash

$default                    newrelic-infra-5wcv6                     100m (5%)
$0 (0%)      100Mi (5%)       100Mi (5%)

Recupere o log dos nós executando:
bash
```
$kubectl logs newrelic-infra-5wcv6
```

Para obter o log de um pod em execução em um nó mestre:

Obtenha os nós rotulados como mestres:

bash

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

Ou,

bash

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

Procure uma saída semelhante a esta:

bash

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

Obtenha o pod New Relic que está em execução em um dos nós retornados na etapa anterior:
bash
```
$kubectl get pods --field-selector spec.nodeName=ip-10-42-24-4.ec2.internal -l name=newrelic-infra --all-namespaces
```
Procure uma saída semelhante a esta:
bash
```
$newrelic-infra-whvzt
```
Recupere o log dos nós executando este comando:
bash
```
$kubectl logs newrelic-infra-whvzt
```

Monitor serviços em execução no Kubernetes

Os serviços de monitoramento no Kubernetes funcionam aproveitando nosso agente de infraestrutura e integração no host e um mecanismo de autodescoberta para apontá-los para o pod com um seletor especificado.

Verifique o documento Habilitar monitoramento de serviços usando o Helm Chart para saber como fazer isso. Confira este exemplo da versão 2, que mostra a configuração yaml para a integração do Redis adicionada ao arquivo values.yml do gráfico nri-bundle .

newrelic-infrastructure:
    integrations_config:
    - name: nri-redis.yaml
    data:
    discovery:
    command:
    # Run NRI Discovery for Kubernetes
    # https://github.com/newrelic/nri-discovery-kubernetes
    exec: /var/db/newrelic-infra/nri-discovery-kubernetes --tls --port 10250
    match:
    label.app: redis
    integrations:
    - name: nri-redis
    env:
    # using the discovered IP as the hostname address
    HOSTNAME: ${discovery.ip}
    PORT: 6379
    labels:
    env: test

Adicione um YAML de serviço à configuração de integração do Kubernetes

Se você estiver usando a versão 2 da integração do Kubernetes, será necessário adicionar uma entrada para este ConfigMap na seção volumes e volumeMounts do spec do DaemonSet, para garantir que todos os arquivos no ConfigMap sejam montados em /etc/newrelic-infra/integrations.d/.

Esta tradução de máquina é fornecida para sua comodidade.

Cuidado

Plano de controle de monitoramento com integração versão 2

Descoberta automática e configuração padrão: `hostNetwork` e `privileged`

Descoberta de nós mestres e componentes do plano de controle

Configuração

Importante

etcd

Servidor API

Importante

Configuração do OpenShift

Importante

Importante

Registro Kubernetes

Habilite o registro detalhado usando um arquivo de manifesto

Cuidado

Habilite o registro detalhado usando Helm

Cuidado

Obtenha o log do pod conectando-se ao kube-state-métrica

Obtenha o log de um pod em execução em um nó mestre

Monitor serviços em execução no Kubernetes

Adicione um YAML de serviço à configuração de integração do Kubernetes

Esta tradução de máquina é fornecida para sua comodidade.

Visão geral

Cuidado

Plano de controle de monitoramento com integração versão 2 .css-21sua1{background:none;border:none;width:0;padding:0;}

Descoberta automática e configuração padrão: hostNetwork e privileged

Descoberta de nós mestres e componentes do plano de controle

Configuração

Importante

etcd

Servidor API

Importante

Configuração do OpenShift

Importante

Importante

Registro Kubernetes

Habilite o registro detalhado usando Helm

Obtenha o log do pod conectando-se ao kube-state-métrica

Obtenha o log de um pod em execução em um nó mestre

Monitor serviços em execução no Kubernetes

Adicione um YAML de serviço à configuração de integração do Kubernetes

Plano de controle de monitoramento com integração versão 2

Descoberta automática e configuração padrão: `hostNetwork` e `privileged`