> ## Documentation Index > Fetch the complete documentation index at: https://docs.befailproof.ai/llms.txt > Use this file to discover all available pages before exploring further. # Implantação em Pod Único: Coletor + Sidecar de Aplicação no EKS > Documentação do AgentEye para implantação em pod único: Coletor + Sidecar de Aplicação no EKS. 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](/pt-br/agenteye/kubernetes-deployment). *** ## Visão geral ``` ┌──────────────────────────────── Pod ─────────────────────────────────┐ │ │ │ ┌──────────────────────┐ ┌──────────────────────┐ │ │ │ your-app │ │ agenteye-collector │ │ │ │ (SDK writes JSONL) │ │ (sweeps events/, │ │ │ │ │ │ uploads over mTLS) │ │ │ └──────────┬───────────┘ └──────────┬───────────┘ │ │ │ writes reads │ │ │ ▼ ▼ │ │ ┌────────────────────────────────────────────────────┐ │ │ │ emptyDir: /var/lib/agenteye/{events,failed}/ │ │ │ │ (AGENTEYE_HOME - shared event spool) │ │ │ └────────────────────────────────────────────────────┘ │ │ ▲ │ │ │ reads cert │ │ ┌────────┴─────────┐ │ │ │ CSI (read-only): │ │ │ │ /etc/agenteye/ │ │ │ │ tls/client.{crt, │ │ │ │ key}, ca.crt │ │ │ └────────┬─────────┘ │ └───────────────────────────────────────────────────┼──────────────────┘ │ mounted by │ Secrets Store CSI │ (AWS provider + │ IRSA) ┌────────┴──────────┐ │ AWS Secrets │ │ Manager │ │ agenteye/mtls- │ │ client/ │ └────────┬──────────┘ ▲ │ push on issue / │ renewal ┌────────┴──────────┐ │ Exosphere │ │ delivers the cert │ │ bundle into your │ │ Secrets Manager │ │ on renewal │ └───────────────────┘ Outbound: collector → AGENTEYE_URL (mTLS, using the CSI-mounted cert). ``` 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:** | Parte | Responsabilidade | | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Exosphere | Emite 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: ```bash theme={null} aws eks describe-cluster --name \ --query "cluster.identity.oidc.issuer" --output text ``` Se o comando retornar uma URL `https://oidc.eks.…`, o OIDC está habilitado. Caso contrário, associe um: ```bash theme={null} eksctl utils associate-iam-oidc-provider \ --cluster --approve ``` * O [Secrets Store CSI Driver](https://secrets-store-csi-driver.sigs.k8s.io/) e o [AWS provider](https://github.com/aws/secrets-store-csi-driver-provider-aws) 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/`) * 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](/pt-br/agenteye/api-keys)) *** ## 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: | Propriedade | Valor | | --------------- | ----------------------------------------------------------------------------------------------------------------------------- | | Nome do segredo | `agenteye/mtls-client/` (estável entre renovações) | | Região | A região AWS que você indicou para o seu cluster EKS | | Payload | Um único segredo JSON com três chaves (`client.crt`, `client.key` e `ca.crt`), cada uma contendo o material codificado em PEM | | Tag | `AgentEyeCluster=` | 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](/pt-br/agenteye/kubernetes-deployment). *** ## 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. ```bash theme={null} # CSI Driver helm repo add secrets-store-csi-driver \ https://kubernetes-sigs.github.io/secrets-store-csi-driver/charts helm install -n kube-system csi-secrets-store \ secrets-store-csi-driver/secrets-store-csi-driver \ --set syncSecret.enabled=true \ --set enableSecretRotation=true \ --set rotationPollInterval=1h # AWS provider kubectl apply -f \ https://raw.githubusercontent.com/aws/secrets-store-csi-driver-provider-aws/main/deployment/aws-provider-installer.yaml ``` **Verificação:** ```bash theme={null} kubectl get pods -n kube-system | grep -E 'csi-secrets-store|aws-provider' ``` 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`: ```json theme={null} { "Version": "2012-10-17", "Statement": [ { "Sid": "ReadAgentEyeMtlsBundle", "Effect": "Allow", "Action": [ "secretsmanager:GetSecretValue", "secretsmanager:DescribeSecret" ], "Resource": "arn:aws:secretsmanager:::secret:agenteye/mtls-client/-*" } ] } ``` Substitua ``, `` e ``. O `-*` no final corresponde ao sufixo aleatório de seis caracteres que a AWS acrescenta a cada ARN de segredo. Crie a política: ```bash theme={null} aws iam create-policy \ --policy-name AgentEyeMtlsReader- \ --policy-document file://agenteye-mtls-reader-policy.json ``` ### 3.2 Criar a função IAM e vinculá-la ao ServiceAccount do pod ```bash theme={null} eksctl create iamserviceaccount \ --name agenteye-pod \ --namespace \ --cluster \ --role-name AgentEyePodRole- \ --attach-policy-arn arn:aws:iam:::policy/AgentEyeMtlsReader- \ --approve ``` 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ão | Escopo | Motivo | | ------------------------------- | -------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | | `secretsmanager:GetSecretValue` | `arn:aws:secretsmanager:::secret:agenteye/mtls-client/-*` | O CSI Driver lê o bundle de certificados a cada montagem e a cada tick de rotação. | | `secretsmanager:DescribeSecret` | mesmo | O 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: ```json theme={null} { "Effect": "Allow", "Action": ["kms:Decrypt"], "Resource": "arn:aws:kms:::key/", "Condition": { "StringEquals": { "kms:ViaService": "secretsmanager..amazonaws.com" } } } ``` *** ## Fase 4: Implantar o Pod ### 4.1 SecretProviderClass `agenteye-mtls-spc.yaml`: ```yaml theme={null} apiVersion: secrets-store.csi.x-k8s.io/v1 kind: SecretProviderClass metadata: name: agenteye-mtls namespace: spec: provider: aws parameters: objects: | - objectName: "agenteye/mtls-client/" objectType: "secretsmanager" jmesPath: - path: '"client.crt"' objectAlias: "client.crt" - path: '"client.key"' objectAlias: "client.key" - path: '"ca.crt"' objectAlias: "ca.crt" ``` 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. ```bash theme={null} kubectl apply -f agenteye-mtls-spc.yaml ``` ### 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](/pt-br/agenteye/python-sdk)). > 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): ```yaml theme={null} apiVersion: apps/v1 kind: Deployment metadata: name: my-app-with-collector namespace: spec: replicas: 1 selector: matchLabels: app: my-app-with-collector template: metadata: labels: app: my-app-with-collector spec: serviceAccountName: agenteye-pod containers: - name: app image: env: # SDK writes event JSONL files into $AGENTEYE_HOME/events/ - name: AGENTEYE_HOME value: /var/lib/agenteye volumeMounts: - name: agenteye-spool mountPath: /var/lib/agenteye - name: agenteye-collector # Pin to a versioned :v tag for production; :beta-latest # tracks the current beta build (:latest exists only for stable releases). image: ghcr.io/agenteye-enterprise/collector:beta-latest args: ["start"] env: # Must match the app container's AGENTEYE_HOME so the collector # sweeps the same directory the SDK writes to. - name: AGENTEYE_HOME value: /var/lib/agenteye - name: AGENTEYE_URL value: "https://ingest.example.agenteye.com/events" - name: AGENTEYE_KEY valueFrom: secretKeyRef: name: agenteye-collector-api-key key: key - name: AGENTEYE_TLS_CERT value: /etc/agenteye/tls/client.crt - name: AGENTEYE_TLS_KEY value: /etc/agenteye/tls/client.key # Only when the AgentEye server presents a cert not signed by a # publicly-trusted CA (e.g. self-signed by an in-cluster issuer # because you have no real DNS domain). The CSI mount already # exposes ca.crt alongside the client cert/key. - name: AGENTEYE_TLS_CA value: /etc/agenteye/tls/ca.crt volumeMounts: - name: agenteye-spool mountPath: /var/lib/agenteye - name: agenteye-mtls mountPath: /etc/agenteye/tls readOnly: true livenessProbe: exec: command: ["agenteye-collector", "health"] initialDelaySeconds: 10 periodSeconds: 30 volumes: # Shared event spool between app and collector. emptyDir is fine: # events are transient and the collector drains them before pod # termination on graceful shutdown. - name: agenteye-spool emptyDir: {} # mTLS cert bundle, mounted read-only into the collector only. - name: agenteye-mtls csi: driver: secrets-store.csi.k8s.io readOnly: true volumeAttributes: secretProviderClass: agenteye-mtls ``` O Secret `agenteye-collector-api-key` contém a chave de API do coletor (consulte [enterprise-docs/api-keys.md](/pt-br/agenteye/api-keys) para provisionamento). **Aplicar:** ```bash theme={null} kubectl apply -f agenteye-pod.yaml ``` ### 4.3 Verificação ```bash theme={null} # O pod deve estar Running com 2/2 contêineres prontos kubectl get pods -n -l app=my-app-with-collector # Confirmar que o bundle de certificados foi montado kubectl exec -n deploy/my-app-with-collector \ -c agenteye-collector -- ls -l /etc/agenteye/tls/ ``` 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:** ```bash theme={null} # No coletor, deve mostrar os subdiretórios events/ e failed/ que # o coletor cria automaticamente na inicialização: kubectl exec -n deploy/my-app-with-collector \ -c agenteye-collector -- ls /var/lib/agenteye/ # Na aplicação, deve mostrar o mesmo conteúdo do diretório: kubectl exec -n deploy/my-app-with-collector \ -c app -- ls /var/lib/agenteye/ ``` 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:** ```bash theme={null} kubectl exec -n deploy/my-app-with-collector \ -c agenteye-collector -- agenteye-collector flush ``` 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: ```bash theme={null} kubectl rollout restart deploy/my-app-with-collector -n ``` 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 | Sintoma | Causa provável | Correção | | ------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Pod travado em `ContainerCreating`, eventos mostram `MountVolume.SetUp failed for volume "agenteye-mtls"` | O provedor CSI não consegue alcançar o Secrets Manager | Verifique se o IRSA está corretamente vinculado: `kubectl describe sa agenteye-pod -n ` deve mostrar a anotação `eks.amazonaws.com/role-arn`. Verifique o CloudTrail para a chamada AssumeRole. | | Erro: `AccessDeniedException: not authorized to perform secretsmanager:GetSecretValue` | A política IAM está com escopo para o ARN errado | O sufixo do ARN do segredo é aleatório; use `agenteye/mtls-client/-*` com o curinga, não o ARN exato. | | Erro: `ParameterNotFound` do AWS provider | Incompatibilidade de nome de segredo entre `SecretProviderClass.objects[].objectName` e o segredo entregue pela Exosphere | Confirme o nome exato com `aws secretsmanager list-secrets --filters Key=tag-key,Values=AgentEyeCluster`. | | Erro de `jmesPath`, apenas um arquivo montado | Sintaxe JMESPath | Os pontos nas chaves JSON exigem aspas duplas: `'"client.crt"'`, não `client.crt`. | | Coletor registra `tls: bad certificate` após uma renovação | O CSI Driver ainda não consultou a nova versão, ou o coletor ainda está rodando com o certificado anterior carregado na inicialização | Confirme 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 `. Consulte § Rotação de certificados. | | O contêiner do coletor entra em crashloop com `no such file or directory: /etc/agenteye/tls/client.crt` | Volume ainda não populado na primeira inicialização; probe de startup muito agressiva | Adicione 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 `OOMKilled` | Limites de memória padrão muito baixos para clusters com muitas SecretProviderClasses | Aumente 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 eventos | A aplicação e o coletor não estão compartilhando o spool de eventos | Verifique 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:** ```bash theme={null} kubectl logs -n kube-system -l app=secrets-store-csi-driver --tail=100 kubectl logs -n kube-system -l app=csi-secrets-store-provider-aws --tail=100 kubectl describe pod -n -l app=my-app-with-collector ``` *** ## 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. | Arquivo | Conteúdo | Usado pelo coletor como | | ------------ | ---------------------------------------- | ----------------------------------------------------------------------------------------------------------- | | `client.crt` | Certificado de cliente codificado em PEM | `AGENTEYE_TLS_CERT` | | `client.key` | Chave privada codificada em PEM | `AGENTEYE_TLS_KEY` | | `ca.crt` | Certificado de CA codificado em PEM | `AGENTEYE_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`. | Caminho | Gravado por | Lido por | Finalidade | | ------------------------------- | ------------------------------------ | ------------------ | ----------------------------------------------------------------------------------- | | `$AGENTEYE_HOME/events/*.jsonl` | Aplicação (SDK do AgentEye) | Sweeper do coletor | Lotes 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.json` | Você (opcional) | Coletor | Arquivo 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 * [enterprise-docs/collector-installation.md](/pt-br/agenteye/collector-installation): opções do binário do coletor, referência de configuração mTLS, modos daemon. * [enterprise-docs/kubernetes-deployment.md](/pt-br/agenteye/kubernetes-deployment): implantação multi-pod, detalhes internos de emissão de certificados, ciclo de vida e alertas de vencimento. * [enterprise-docs/api-keys.md](/pt-br/agenteye/api-keys): provisionamento da chave de API do coletor usada pelo pod. * [enterprise-docs/troubleshooting.md](/pt-br/agenteye/troubleshooting): índice de solução de problemas para todo o cluster.