Todos os produtos
Search
Central de documentação

Container Service for Kubernetes:Visão geral do Raven

Última atualização: Aug 27, 2026

Em clusters ACK Edge, o Raven fornece comunicação entre domínios de rede para viabilizar operações e manutenção (O&M) eficientes entre cloud e borda em múltiplas regiões. Este tópico descreve os conceitos do Raven, seu funcionamento e seus recursos.

O Raven oferece suporte ao modo proxy (Camada 7, resolve conflitos de IP) e ao modo túnel (Camada 3, conectividade no nível de contêiner).

Contexto

Os clusters ACK Edge utilizam uma arquitetura cloud-edge: os componentes do plano de controle são executados na cloud, enquanto as cargas de trabalho rodam em data centers ou dispositivos de borda. Os nós de borda se conectam ao endpoint público do plano de controle pela Internet.

image

Os nós de borda são organizados em node pools, e cada um representa um domínio de rede distinto. Nós pertencentes a diferentes node pools não se comunicam diretamente e podem ter endereços IP sobrepostos. Esse isolamento é intencional, mas impede que componentes da cloud acessem as cargas de trabalho na borda para monitoramento e operações.

Funcionamento

O Raven opera em duas fases: primeiro estabelece túneis entre os nós de gateway e, em seguida, encaminha o tráfego entre domínios por esses túneis.

Fase 1: Inicialização

  • Cada node pool elege um nó como gateway de borda. Nós isolados atuam como seu próprio gateway.

  • O DaemonSet raven-agent-ds é executado em todos os nós no modo de rede do host. Nos nós de gateway, ele estabelece túneis criptografados com o gateway da cloud.

  • O componente do plano de controle ack-edge-yurt-manager divide os nós em domínios de rede conforme sua associação aos node pools e cria um recurso personalizado gateway para cada domínio.

Fase 2: Encaminhamento de requisições

  • Requisições entre domínios originadas por componentes da cloud são roteadas pelo nó de gateway da cloud até o nó de gateway de borda correspondente.

  • O nó de gateway de borda encaminha as requisições para o host, contêiner ou service de destino dentro do seu domínio de rede.

image

Escolha um modo de comunicação

Escolha o modo com base na existência de conflitos de endereços IP entre seus node pools.

Modo

Tipo de tráfego

Suporta conflitos de IP

Indicado quando

Modo proxy

Nível de host (Camada 7)

Sim

Os node pools apresentam conflitos de IP ou você precisa usar kubectl logs/exec/attach/top

Modo túnel

Nível de contêiner (Camada 3)

Não

Os node pools possuem conectividade entre nós e não há conflitos de IP

Modo proxy

O modo proxy cria um canal reverso criptografado entre o nó de gateway de borda e o nó de gateway da cloud. O gateway da cloud encaminha requisições entre domínios para o gateway de borda na Camada 7, identificando os destinos por NodeName+Port. Um nó isolado atua como seu próprio gateway e estabelece um túnel direto com o gateway da cloud.

O modo proxy oferece suporte a:

  • Comunicação via rede do host para APIServer, MetricsServer e Prometheus

  • Comandos kubectl logs, kubectl exec, kubectl attach e kubectl top

  • Node pools com faixas de endereços IP conflitantes

Em cenários com conflito de IP, utilize o modo proxy, pois o modo túnel não consegue rotear tráfego no nível de host quando há sobreposição de endereços IP entre domínios de rede.

Modo túnel

O modo túnel estabelece túneis IPsec-VPN entre o nó de gateway de borda e o nó de gateway da cloud. Dentro de cada domínio de rede, o Raven cria uma rede sobreposta Virtual Extensible LAN (VXLAN) usando Flannel VXLAN, e todo o tráfego de contêineres entre domínios é roteado pelo túnel VPN via VXLAN.

O modo túnel oferece suporte a:

  • Comunicação entre contêineres em diferentes domínios de rede

  • Coleta de métricas de contêineres de borda pelo Prometheus

O modo túnel exige conectividade direta entre os nós dentro de cada node pool.

Importante

Pode ocorrer perda de dados durante a comunicação entre domínios pela Internet. Não use o modo túnel para transmitir dados críticos para o negócio. Em caso de problemas ou sugestões, envie um ticket para entrar em contato com a equipe técnica do ACK.

Arquitetura dos componentes

O Raven é composto por dois componentes:

Componente

Tipo

Função

ack-edge-yurt-manager

Plano de controle

Divide os nós em domínios de rede com base nos node pools e cria recursos personalizados gateway

raven-agent-ds

Plano de dados (DaemonSet)

É executado em todos os nós; configure rotas ou túneis VPN entre os nós de gateway

O Raven requer um recurso de cluster personalizado gateway para armazenar dados de nós e configurações de cada domínio de rede.

Pré-requisitos

Antes de começar, verifique se você possui:

  • Um cluster ACK Edge executando Kubernetes 1.26.3 ou superior

  • Pelo menos uma instância Elastic Compute Service (ECS) designada como nó de gateway da cloud (durante a criação do cluster)

  • Caso os hosts de borda acessem o plano de controle pela Internet: uma instância Classic Load Balancer (CLB), um endereço IP elástico (EIP) e listas de controle de acesso à rede (ACLs) configuradas

Próximos passos