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.

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 do plano de controle e componentes do plano de controle

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

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:

Quando a integração detecta que está sendo executada dentro de um nó do plano de controle, ela tenta descobrir quais componentes estão sendo executados no nó procurando por pods que correspondem aos rótulos listados na tabela acima. Para cada componente em execução, a integração faz uma solicitação ao seu endpoint métrica.

Configuração

O monitoramento do plano de controle é automático para agentes que rodam dentro dos nós do plano de controle. 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 Servidor API também pode ser configurado para ser consultado usando a Porta Segura.

etcd

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

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:

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 .

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"

Registro Kubernetes

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

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/.