Em clusters ACK Edge, os nós de borda abrangem domínios de rede isolados e podem ter endereços IP conflitantes. Isso impede que componentes da nuvem, como APIServer, MetricsServer e Prometheus, alcancem as cargas de trabalho na borda. O Raven resolve esse problema criando túneis criptografados entre a nuvem e os nós de gateway de borda, o que permite monitoramento e operações entre domínios sem alterar a topologia de rede existente.
Este tópico descreve a arquitetura do Raven, seu funcionamento e como escolher entre seus dois modos de comunicação.
Contexto
Os clusters ACK Edge utilizam uma arquitetura de colaboração nuvem-borda: os componentes do plano de controle são executados na nuvem, enquanto as cargas de trabalho rodam na borda, em data centers ou dispositivos específicos. Os nós de borda conectam-se ao endpoint público do plano de controle do ACK pela Internet.
Os nós de borda organizam-se em node pools, e cada pool representa um domínio de rede distinto. Nós em pools diferentes não se comunicam diretamente e podem ter endereços IP sobrepostos. Esse isolamento é intrínseco à computação de borda, mas impede que componentes da nuvem acessem as cargas de trabalho na borda para monitoramento e operação.
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 meio desses túneis.
Fase 1: Inicialização
Em cada node pool, um nó é eleito como nó de gateway de borda. Nós fora de qualquer pool atuam como seu próprio gateway.
O DaemonSet raven-agent-ds é executado em todos os nós do cluster usando o modo de rede do host. Nos nós de gateway, ele estabelece túneis criptografados com o nó de gateway da nuvem.
O componente do plano de controle ack-edge-yurt-manager divide os nós em domínios de rede conforme a associação aos node pools e cria um recurso personalizado
gatewaypara cada domínio, registrando informações dos nós e configurações.
Fase 2: Encaminhamento de requisições
Requisições entre domínios originadas por componentes da nuvem passam pelo nó de gateway da nuvem até o nó de gateway de borda apropriado.
O nó de gateway de borda encaminha as requisições para o host, contêiner ou serviço de destino dentro de seu domínio de rede.
Escolha um modo de comunicação
O Raven oferece dois modos de comunicação.
|
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 |
|
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 eleito e o nó de gateway da nuvem. O nó de gateway da nuvem encaminha requisições entre domínios para o nó de gateway de borda na Camada 7, utilizando a combinação NodeName+Port para identificar o destino. Um nó isolado atua como gateway e pode estabelecer diretamente um túnel com o gateway na nuvem.
O modo Proxy suporta:
Comunicação via rede do host para APIServer, MetricsServer e Prometheus
Comandos
kubectl logs,kubectl exec,kubectl attachekubectl topNode pools com faixas de endereços IP conflitantes
Em cenários com conflito de IP, utilize o modo Proxy. 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 eleito e o nó de gateway da nuvem. Dentro de cada domínio de rede, o Raven cria uma rede de sobreposição Virtual Extensible LAN (VXLAN) usando Flannel VXLAN, e todo o tráfego de contêineres entre domínios passa pelo túnel VPN via VXLAN.
O modo Túnel suporta:
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 funciona apenas em node pools onde os nós possuem conectividade direta entre si.
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. Se encontrar problemas ou tiver 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 |
|
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 registrar as informações dos nós e as 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 nuvem (obrigatório durante a criação do cluster ACK Edge)
Caso os hosts de borda se comuniquem com o plano de controle do ACK Edge pela Internet: uma instância Classic Load Balancer (CLB), um endereço IP elástico (EIP) e listas de controle de acesso de rede (ACLs) configuradas — esses recursos estabelecem os túneis criptografados entre nós de gateway em diferentes node pools
Próximos passos
Para alterar o modo de comunicação, configurar ACLs de rede ou definir gateways personalizados, consulte Usar o componente de comunicação de O&M entre regiões Raven.
Para notas de versão do raven-agent-ds, consulte raven-agent-ds.