Pular para o conteúdo principal
Execute sua aplicação e o coletor AgentEye no mesmo Pod do Kubernetes para que a telemetria nunca precise cruzar um limite de rede para ser coletada. O SDK da sua aplicação e o coletor compartilham um único spool de eventos dentro do pod, o que garante handoff de telemetria com baixa latência, sem necessidade de expor uma porta localhost, sem service mesh para atravessar, e com o ciclo de vida do coletor diretamente vinculado à carga de trabalho que ele observa. O certificado de cliente mTLS que o coletor apresenta é entregue diretamente no seu pod a partir do AWS Secrets Manager, de modo que a rotação de credenciais não exige nenhuma manipulação manual de arquivos da sua parte. O modelo sidecar + spool compartilhado descrito aqui é agnóstico em relação à nuvem; dois contêineres compartilhando um spool de eventos emptyDir funciona em qualquer distribuição Kubernetes. Apenas o caminho de entrega do certificado neste guia (AWS Secrets Manager + Secrets Store CSI Driver + IRSA) é específico para AWS/EKS. Se você operar em outro ambiente, mantenha o layout do pod e do spool e substitua o mecanismo de montagem de segredos da sua plataforma pelas Fases 2 e 3.
Quando usar este padrão. Opte pelo pod único quando sua aplicação não deve fazer chamadas através de um limite de rede para alcançar o coletor (IPC intra-pod de baixa latência, acoplamento rigoroso de ciclo de vida, isolamento de pod por tenant). Para frotas multi-aplicação que compartilham um único coletor por nó ou por cluster, consulte enterprise-docs/kubernetes-deployment.md.

Visão geral

Dois fluxos de dados, dois volumes:
  • Eventos (intra-pod): o SDK da sua aplicação grava arquivos .jsonl no emptyDir compartilhado em $AGENTEYE_HOME/events/; o sweeper do coletor os lê e realiza o upload. Sem porta localhost, sem loopback, handoff puro via sistema de arquivos compartilhado.
  • Certificado mTLS (pod ← nuvem): o Secrets Store CSI Driver monta o bundle de certificados do Secrets Manager em um volume somente leitura em /etc/agenteye/tls/, com escopo para o contêiner do coletor.
Duas partes independentes:
ParteResponsabilidade
ExosphereEmite o certificado de cliente mTLS e entrega o bundle no Secrets Manager da sua conta AWS com um nome estável. Republica o bundle renovado no mesmo segredo antes do vencimento.
VocêInstala o Secrets Store CSI Driver, concede ao ServiceAccount do pod acesso de leitura ao segredo via IRSA e aplica o manifesto do Pod. Só isso.

Pré-requisitos

Na sua conta AWS / cluster EKS

  • Um cluster EKS com um provedor OIDC associado. Confirme com:
    Se o comando retornar uma URL https://oidc.eks.…, o OIDC está habilitado. Caso contrário, associe um:
  • O Secrets Store CSI Driver e o AWS provider instalados no cluster (consulte a § Fase 2).
  • AWS CLI v2 e kubectl na sua estação de trabalho.

Coordenação com a Exosphere

Antes de fazer a implantação, a Exosphere entrega o bundle de cliente mTLS no Secrets Manager da sua conta AWS e fornece:
  • O nome do segredo (convenção: agenteye/mtls-client/<your-cluster>)
  • A região AWS onde o segredo está armazenado
  • A URL do backend do AgentEye para configurar o coletor
  • Sua chave de API do coletor (consulte enterprise-docs/api-keys.md)

Fase 1: O que a Exosphere entrega

Você não gera o certificado de cliente mTLS por conta própria. A Exosphere o emite e entrega o bundle diretamente no Secrets Manager da sua conta AWS, de modo que o único material de credencial que chega ao seu ambiente é o segredo pronto para montagem. O que chega na sua conta:
PropriedadeValor
Nome do segredoagenteye/mtls-client/<cluster-name> (estável entre renovações)
RegiãoA região AWS que você indicou para o seu cluster EKS
PayloadUm único segredo JSON com três chaves (client.crt, client.key e ca.crt), cada uma contendo o material codificado em PEM
TagAgentEyeCluster=<cluster-name>
Na renovação, o mesmo segredo é atualizado no local com uma nova versão, de modo que o ARN e o nome nunca mudam; sua SecretProviderClass e política IAM continuam funcionando sem alterações. Para o ciclo de vida do certificado (validade, cadência de renovação, alertas de vencimento), consulte enterprise-docs/kubernetes-deployment.md.

Fase 2: Instalar o Secrets Store CSI Driver + AWS provider

Pule esta etapa se você já executa outra carga de trabalho que monta segredos AWS via CSI.
Verificação:
Esperado: Running para todos os pods.
Por que rotationPollInterval=1h? Quando a Exosphere publica um certificado renovado, o Secrets Manager é atualizado no local. O CSI Driver relê o segredo nesse intervalo e regrava os arquivos montados. O coletor lê os arquivos de certificado uma única vez na inicialização, portanto começa a apresentar o certificado renovado apenas após uma reinicialização do processo; consulte a § Rotação de certificados para saber como acionar uma.

Fase 3: Conceder ao pod acesso de leitura ao segredo (IRSA)

3.1 Criar a política IAM

Salve como agenteye-mtls-reader-policy.json:
Substitua <region>, <account-id> e <cluster-name>. O -* no final corresponde ao sufixo aleatório de seis caracteres que a AWS acrescenta a cada ARN de segredo. Crie a política:

3.2 Criar a função IAM e vinculá-la ao ServiceAccount do pod

Isso cria um ServiceAccount chamado agenteye-pod com a anotação eks.amazonaws.com/role-arn apontando para a nova função.

3.3 Permissões IAM necessárias: resumo

PermissãoEscopoMotivo
secretsmanager:GetSecretValuearn:aws:secretsmanager:<region>:<acct>:secret:agenteye/mtls-client/<cluster>-*O CSI Driver lê o bundle de certificados a cada montagem e a cada tick de rotação.
secretsmanager:DescribeSecretmesmoO CSI Driver chama DescribeSecret para detectar mudanças de versão entre as consultas.
Não conceda secretsmanager:PutSecretValue, secretsmanager:UpdateSecret ou secretsmanager:DeleteSecret ao pod. O pod apenas lê o segredo; a gravação de novas versões é responsabilidade da Exosphere quando o certificado é emitido ou renovado. Se o segredo estiver criptografado com uma chave KMS gerenciada pelo cliente (e não a chave padrão aws/secretsmanager), conceda também:

Fase 4: Implantar o Pod

4.1 SecretProviderClass

agenteye-mtls-spc.yaml:
O bloco jmesPath instrui o AWS provider a dividir o segredo JSON em três arquivos separados no disco. As aspas em '"client.crt"' são obrigatórias porque o JMESPath trata . como operador de sub-expressão.

4.2 Manifesto do Pod / Deployment

Como os dois contêineres se comunicam. O SDK do AgentEye e o coletor não se comunicam via socket de rede; não há porta HTTP local. O SDK grava lotes de eventos como arquivos .jsonl em $AGENTEYE_HOME/events/, e o coletor monitora continuamente esse diretório e realiza o upload de cada arquivo. Para um pod sidecar, isso significa:
  • Ambos os contêineres montam o mesmo volume emptyDir no mesmo caminho.
  • Ambos os contêineres definem AGENTEYE_HOME para esse caminho.
  • A imagem da sua aplicação deve ter o SDK do AgentEye instalado e configurado (consulte enterprise-docs/python-sdk.md).
Quando AGENTEYE_HOME não está definido, tanto o SDK quanto o coletor usam ~/.agenteye como padrão, e os dois contêineres têm diretórios home diferentes, de modo que cada um utilizaria um spool separado e o handoff falharia silenciosamente. Defina AGENTEYE_HOME para o mesmo caminho explícito em ambos os contêineres. A verificação da §4.3 e a linha correspondente na seção de Solução de Problemas identificam esse erro caso seja cometido.
agenteye-pod.yaml (Deployment com uma réplica, escale conforme necessário):
O Secret agenteye-collector-api-key contém a chave de API do coletor (consulte enterprise-docs/api-keys.md para provisionamento). Aplicar:

4.3 Verificação

Esperado: client.crt, client.key e ca.crt todos presentes, somente leitura e de propriedade do usuário do contêiner. Confirmar que o spool de eventos compartilhado é visível para ambos os contêineres:
Se as duas listagens divergirem, o volume não está montado em ambos os contêineres (ou AGENTEYE_HOME é diferente); consulte a § Solução de Problemas. Teste de fumaça ponta a ponta:
Esperado: o coletor realiza o upload de todos os eventos enfileirados e exibe um resumo Done: N/N uploaded, 0 failed.. Se o spool estiver vazio, exibe No pending files. e encerra sem validar nada — portanto, execute isso apenas depois que sua aplicação tiver descarregado pelo menos um evento. Note que flush encerra com código diferente de zero apenas para falhas de configuração local: ausência de configuração (URL/chave não resolvidos) ou certificado TLS ilegível/não parseável (consulte § Solução de Problemas). Uma chave de API incorreta não altera o código de saída — o upload recebe um 401, o arquivo é movido para failed/, e o comando ainda exibe [FAILED] … por arquivo mais Done: 0/N uploaded, N failed. e encerra com 0. Para detectar uma chave inválida ou um upload rejeitado, leia a saída Done:/[FAILED] ou verifique se há arquivos em $AGENTEYE_HOME/failed/, não o código de saída.

Rotação de certificados

O certificado de cliente é válido por 90 dias e é renovado automaticamente cerca de 15 dias antes do vencimento; a Exosphere então publica o bundle renovado no mesmo segredo do Secrets Manager. A partir daí, o fluxo intra-pod é:
  1. O segredo no Secrets Manager recebe uma nova versão AWSCURRENT. O ARN e o nome permanecem inalterados.
  2. Dentro do rotationPollInterval (1h por padrão; consulte a § Fase 2), o CSI Driver lê a nova versão e regrava os arquivos em /etc/agenteye/tls/.
  3. O coletor carrega os arquivos de certificado uma vez na inicialização, portanto continua apresentando o certificado anterior até que o processo seja reiniciado. Para alternar para o material renovado, reinicie o coletor; uma reinicialização gradual é suficiente:
    Para automatizar isso, adicione um sidecar que monitore /etc/agenteye/tls/ (por exemplo, com inotifywait) e acione o rollout quando os arquivos mudarem.
Como o certificado anterior permanece válido por cerca de 15 dias após a renovação, você tem uma janela ampla para realizar a reinicialização sem interromper a ingestão. A Exosphere publica o bundle renovado por você; a única ação rotineira da sua parte é garantir que o coletor seja reiniciado dentro dessa janela.

Solução de Problemas

SintomaCausa provávelCorreção
Pod travado em ContainerCreating, eventos mostram MountVolume.SetUp failed for volume "agenteye-mtls"O provedor CSI não consegue alcançar o Secrets ManagerVerifique se o IRSA está corretamente vinculado: kubectl describe sa agenteye-pod -n <ns> deve mostrar a anotação eks.amazonaws.com/role-arn. Verifique o CloudTrail para a chamada AssumeRole.
Erro: AccessDeniedException: not authorized to perform secretsmanager:GetSecretValueA política IAM está com escopo para o ARN erradoO sufixo do ARN do segredo é aleatório; use agenteye/mtls-client/<cluster>-* com o curinga, não o ARN exato.
Erro: ParameterNotFound do AWS providerIncompatibilidade de nome de segredo entre SecretProviderClass.objects[].objectName e o segredo entregue pela ExosphereConfirme o nome exato com aws secretsmanager list-secrets --filters Key=tag-key,Values=AgentEyeCluster.
Erro de jmesPath, apenas um arquivo montadoSintaxe JMESPathOs pontos nas chaves JSON exigem aspas duplas: '"client.crt"', não client.crt.
Coletor registra tls: bad certificate após uma renovaçãoO CSI Driver ainda não consultou a nova versão, ou o coletor ainda está rodando com o certificado anterior carregado na inicializaçãoConfirme que os arquivos montados foram atualizados (ls -l /etc/agenteye/tls/) e reinicie o coletor para carregá-los: kubectl rollout restart deploy/my-app-with-collector -n <ns>. Consulte § Rotação de certificados.
O contêiner do coletor entra em crashloop com no such file or directory: /etc/agenteye/tls/client.crtVolume ainda não populado na primeira inicialização; probe de startup muito agressivaAdicione um pequeno atraso inicial ou use um init container que aguarde o arquivo existir: until [ -f /etc/agenteye/tls/client.crt ]; do sleep 1; done.
Pod do CSI Driver com OOMKilledLimites de memória padrão muito baixos para clusters com muitas SecretProviderClassesAumente com --set linux.resources.limits.memory=200Mi na instalação via Helm.
A aplicação roda normalmente, agenteye-collector flush reporta No pending files., mas o dashboard do AgentEye não mostra eventosA aplicação e o coletor não estão compartilhando o spool de eventosVerifique se (a) ambos os contêineres montam o mesmo emptyDir agenteye-spool no mesmo caminho, e (b) ambos definem AGENTEYE_HOME para esse caminho. Execute as duas verificações ls /var/lib/agenteye/ da § 4.3; as listagens devem ser idênticas.
Logs para coletar primeiro:

Referência: arquivos no disco do pod

O pod possui dois caminhos de dados no disco:

Bundle de certificados mTLS: /etc/agenteye/tls/ (CSI, somente leitura, apenas para o coletor)

Montado pelo Secrets Store CSI Driver a partir do AWS Secrets Manager.
ArquivoConteúdoUsado pelo coletor como
client.crtCertificado de cliente codificado em PEMAGENTEYE_TLS_CERT
client.keyChave privada codificada em PEMAGENTEYE_TLS_KEY
ca.crtCertificado de CA codificado em PEMAGENTEYE_TLS_CA (opcional, apenas quando o certificado do servidor AgentEye não é publicamente confiável)
Os três são montados somente leitura e de propriedade do usuário do contêiner. Eles são regravados pelo CSI Driver quando o segredo é rotacionado.

Spool de eventos: $AGENTEYE_HOME/ (emptyDir, compartilhado com leitura/escrita entre ambos os contêineres)

Compartilhado via volume emptyDir chamado agenteye-spool.
CaminhoGravado porLido porFinalidade
$AGENTEYE_HOME/events/*.jsonlAplicação (SDK do AgentEye)Sweeper do coletorLotes de eventos descarregados pelo SDK, aguardando upload.
$AGENTEYE_HOME/failed/Coletor (em caso de falha no upload)Você (ao depurar)Arquivos JSONL que o coletor não conseguiu enviar após as tentativas de retry.
$AGENTEYE_HOME/config.jsonVocê (opcional)ColetorArquivo de configuração opcional do coletor (alternativa às variáveis de ambiente).
Ambos os subdiretórios events/ e failed/ são criados automaticamente pelo coletor na inicialização; nenhum initContainer é necessário.

Documentação relacionada