Mudanças introduzidas na integração do Kubernetes versão 3

A partir da versão 3, o New Relic Kubernetes integração recurso e arquitetura torna o AI Monitoring mais modular e configurável, dando mais poder de escolha como será implantado e tornando-o compatível com mais ambientes.

Os dados relatados pela versão 3 da integração do Kubernetes não mudaram desde a versão 2. Para a versão 3, nos concentramos na configurabilidade, estabilidade e experiência do usuário. Veja as últimas notas de versão da integração aqui.

Guia de migração

Para facilitar ao máximo a migração de versões anteriores, desenvolvemos uma camada de compatibilidade que traduz a maioria das opções configuráveis do antigo gráfico newrelic-infrastructure para suas novas contrapartes. Esta camada de compatibilidade é temporária e será removida no futuro. Recomendamos que você leia este guia com atenção e migre a configuração com supervisão humana. Você pode ler mais sobre o gráfico newrelic-infrastructure atualizado aqui.

Configuração da métrica do estado Kube (KSM)

• disableKubeStateMetrics foi substituído por ksm.enabled. O padrão ainda é o mesmo (raspagem KSM habilitada).
• kubeStateMetricsScheme, kubeStateMetricsPort, kubeStateMetricsUrl, kubeStateMetricsPodLabel e kubeStateMetricsNamespace foram substituídos pelo mais abrangente e flexível ksm.config.
• Observe que o KSM v2+ desativa os rótulos métricos por padrão. Você pode ativar o monitoramento da métrica dos rótulos de destino usando as metricLabelsAllowlist opções descritas aqui no seu cluster do Kubernetes.

O objeto ksm.config tem a seguinte estrutura:

ksm:
  config:
   # When autodiscovering KSM, force the following scheme. By default, `http` is used.
   scheme: "http"
   # Label selector to find kube-state-metrics endpoints. Defaults to `app.kubernetes.io/name=kube-state-metrics`.
   selector: "app.kubernetes.io/name=kube-state-metrics"
   # Restrict KSM discovery to this particular namespace. Defaults to all namespaces.
   namespace: ""
   # When autodiscovering, only consider endpoints that use this port. By default, all ports from the discovered `endpoint` are probed.
   #port: 8080
   # Override autodiscovery mechanism completely and specify the KSM url directly instead
   #staticUrl: "http://test.io:8080/metrics"

Configuração do plano de controle

A configuração do plano de controle mudou substancialmente. Se você ativou anteriormente o monitoramento do plano de controle, recomendamos que você dê uma olhada em nossa documentação Configurar monitoramento do plano de controle .

As seguintes opções foram substituídas por uma configuração mais abrangente, abordada na seção vinculada acima:

• apiServerSecurePort
• etcdTlsSecretName
• etcdTlsSecretNamespace
• controllerManagerEndpointUrl, etcdEndpointUrl, apiServerEndpointUrl e schedulerEndpointUrl

Configuração do agente

O arquivo de configuração do agente, especificado anteriormente em config, foi movido para common.agentConfig. O formato do arquivo não mudou e toda a gama de opções que podem ser configuradas pode ser encontrada aqui.

As seguintes opções de agente foram previamente "aliadas" na raiz do arquivo values.yml e são no longer available:

• logFile foi substituído por common.agentConfig.log_file.
• eventQueueDepth foi substituído por common.agentConfig.event_queue_depth.
• customAttributes mudou de formato para um objeto yaml. O formato anterior, uma string codificada manualmente em JSON, por exemplo {"team": "devops"}, está obsoleto.
• Anteriormente, customAttributes tinha uma entrada clusterName padrão que poderia ter consequências indesejadas se fosse removida. Este não é mais o caso; o usuário agora pode substituir customAttributes por completo com segurança.
• discoveryCacheTTL foi completamente removido, pois a descoberta agora é realizada usando informantes Kubernetes, que possuem um cache integrado.

Integração configuração

Integração foram previamente configuradas em integrations_config, utilizando um formato de matriz:

integrations_config:
  - name: nri-redis.yaml
    data:
      discovery:  # ...
      integrations:  # ...

O mecanismo permanece o mesmo, mas alteramos o formato para ser mais amigável ao usuário:

integrations:
  nri-redis-sampleapp:
    discovery:  # ...
    integrations:  # ...

Além disso, os sinalizadores --port e --tls agora são obrigatórios no comando de descoberta. No passado, o seguinte funcionaria:

integrations:
  nri-redis-sampleapp:
    discovery:
      command:
        exec: /var/db/newrelic-infra/nri-discovery-kubernetes

Da v3 em diante, você deve especificar --port e --tls:

integrations:
  nri-redis-sampleapp:
    discovery:
      command:
        exec: /var/db/newrelic-infra/nri-discovery-kubernetes --tls --port 10250

Essa alteração é necessária porque na v2 e abaixo, o componente nrk8s-kubelet (ou seu equivalente) era executado com hostNetwork: true, então nri-discovery-kubernetes poderia se conectar ao kubelet usando localhost e http simples. Por razões de segurança, este não é mais o caso; daí a necessidade de especificar ambos os sinalizadores de agora em diante.

Para mais detalhes sobre como configurar integração no host no Kubernetes, consulte nossos serviçosmonitor na documentação Kubernetes .

Valores diversos do gráfico

Embora não estejam relacionadas à configuração de integração, as seguintes opções diversas para o gráfico do Helm também foram alteradas:

• runAsUser foi substituído por securityContext, que é modelado diretamente no pod e mais configurável.

• resources foi removido, pois agora implantamos três cargas de trabalho diferentes. Os recursos de cada um podem ser configurados individualmente em:

  • ksm.resources
  • kubelet.resources
  • controlPlane.resources

• tolerations foi dividido em três e o anterior não é mais válido. Todos os três são padronizados para tolerar qualquer valor para NoSchedule e NoExecute:

  • ksm.tolerations
  • kubelet.tolerations
  • controlPlane.tolerations

• image e todas as suas subchaves foram substituídas por seções individuais para cada uma das três imagens que agora estão implantadas:

  • images.forwarder.* para configurar o encaminhador do agente de infraestrutura.
  • images.agent.* para configurar o pacote de imagens do agente de infraestrutura e integração no host.
  • images.integration.* para configurar a imagem responsável pela coleta de dados do k8s.

Atualizar da v2

Para atualizar a integração do Kubernetes da versão 2 (incluída nas versões 3.x do gráfico nri-bundle ), recomendamos fortemente que você crie um arquivo values-newrelic.yaml com o chave de licençae a configuração desejados. Se você já instalou nosso gráfico diretamente da CLI, por exemplo, usando um comando como o seguinte:

$
helm install newrelic/nri-bundle \
>
--set global.licenseKey=<New Relic License key> \
>
--set global.cluster=<Cluster name> \
>
--set infrastructure.enabled=true \
>
--set prometheus.enabled=true \
>
--set webhook.enabled=true \
>
--set ksm.enabled=true \
>
--set kubeEvents.enabled=true \
>
--set logging.enabled=true

Você pode pegar os argumentos --set fornecidos e colocá-los em um arquivo yaml como este:

# values-newrelic.yaml
global:
  licenseKey: <New Relic License key>
  cluster: <Cluster name>
infrastructure:
  enabled: true
prometheus:
  enabled: true
webhook:
  enabled: true
ksm:
  enabled: true
kubeEvents:
  enabled: true
logging:
  enabled: true

Depois de fazer isso e adaptar qualquer outra configuração que possa ter sido alterada de acordo com o guia de migração acima, você poderá atualizar seu nri-bundle executando o seguinte comando:

$
helm upgrade newrelic newrelic/nri-bundle \
>
--namespace newrelic --create-namespace \
>
-f values-newrelic.yaml