• EnglishEspañol日本語한국어Português
  • EntrarComeçar agora

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

Caso haja alguma divergência entre a versão em inglês e a traduzida, a versão em inglês prevalece. Acesse esta página para mais informações.

Criar um problema

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.

Importante

A versão 3 da integração do Kubernetes (appVersion) está incluída no nri-bundle gráfico version 4.

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)

Dica

O monitoramento KSM funciona imediatamente para a maioria das configurações; a maioria dos usuários não precisará alterar esta configuração.

  • 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 metric-labels-allowlist opções descritas aqui em 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 e a configuração desejados. Se você já instalou nosso gráfico diretamente da CLI, por exemplo, usando um comando como o seguinte:

bash
$
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:

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

Importante

A sinalização --reuse-values não é compatível com upgrade da v2 para a v3.

Copyright © 2024 New Relic Inc.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.