Crie clusters ACK Edge para conectar dispositivos em data centers e dispositivos de borda ao Container Service for Kubernetes (ACK). Assim, você utiliza os recursos fornecidos pelo ACK e gerencia recursos de computação locais. Este tópico descreve os principais conceitos e arquiteturas de rede utilizados na rede de clusters ACK Edge, incluindo a conexão de rede nuvem-borda, Container Network Interface (CNI), Service e Ingress. Compreender esses termos ajuda a otimizar os modelos de implantação de aplicativos e os métodos de acesso à rede.
Modos de conexão de rede nuvem-borda
Os clusters ACK Edge podem ser conectados no modo de rede pública ou no modo de rede privada.
Modo de rede pública: Data centers locais e dispositivos de borda se conectam por meio de gateways NAT da Internet ou controladores de interface de rede (NICs) públicos, o que permite o acesso aos planos de controle do ACK e a outros serviços da Alibaba Cloud.
Modo de rede privada: Dispositivos de computação em data centers e dispositivos de borda se conectam por meio de linhas dedicadas, gateways VPN ou outras redes privadas, permitindo o acesso aos planos de controle do ACK hospedados na nuvem e a outros serviços da Alibaba Cloud. A figura a seguir usa o O que é Express Connect da Alibaba Cloud como exemplo.
Componentes de comunicação de O&M nuvem-borda
Os clusters ACK Edge utilizam uma arquitetura de colaboração nuvem-borda na qual a nuvem central gerencia data centers de borda e dispositivos de borda. Como os dispositivos de computação costumam estar distribuídos por várias regiões e domínios de rede, a comunicação direta entre a nuvem central e o lado da borda nem sempre é possível.
Para atender aos requisitos de O&M e monitoramento da nuvem central para dispositivos de borda, duas soluções estão disponíveis:
Comunicação por rede privada: Conecte a virtual private cloud (VPC) da nuvem central com data centers ou dispositivos na borda por meio de redes privadas para ative a comunicação entre a nuvem e a borda.
Tunelamento pela Internet: Utilize o componente de comunicação de O&M nuvem-borda Raven para estabelecer um túnel reverso pela Internet. Esse túnel reverso facilita a transferência de dados de O&M e monitoramento entre a nuvem e a borda. Certifique-se de que os data centers ou dispositivos de borda tenham acesso à Internet. Para mais informações, consulte O componente de comunicação O&M entre domínios Raven.
CNI
O Kubernetes utiliza plug-ins CNI para ative e padronizar a rede de contêineres:
Os pods entram na rede de contêineres ao serem criados e saem ao serem excluídos.
Cada pod recebe um endereço IP exclusivo.
Os pods podem se comunicar com endpoints dentro e fora do cluster.
Os plug-ins CNI implementam a rede de contêineres. O plug-in CNI escolhido determina a alocação de IP dos pods, o uso de rede overlay, o encaminhamento de tráfego dentro do cluster e o controle de acesso aos pods. Plug-ins CNI open-source conhecidos incluem Calico, Flannel e Cilium.
Os clusters ACK Edge suportam os plug-ins de rede Flannel e Terway Edge, cada um com recursos distintos. Antes de criar um cluster, consulte as seções a seguir para selecione o plug-in de rede apropriado.
Após a criação do cluster, não é possível alternar entre Terway Edge e Flannel.
Flannel (redes overlay para contêineres)
Em clusters ACK Edge, o Flannel opera no modo Virtual Extensible Local Area Network (VXLAN) para estabelecer uma rede de contêineres sobre a rede de host de Camada 3, permitindo a comunicação de pods entre hosts.
O plug-in de rede Flannel garante que o bloco CIDR dos pods não se sobreponha ao bloco CIDR da VPC. O bloco CIDR dos pods é dividido uniformemente e alocado aos nós do cluster. Cada pod em um nó recebe um endereço IP pertencente ao bloco CIDR desse nó. O plug-in de rede Flannel possui os seguintes recursos:
O bloco CIDR dos pods não se sobrepõe ao bloco CIDR da VPC.
O host encapsula os pacotes de contêiner usando VXLAN para transmissão.
Não requer configuração adicional de dispositivos de rede externos e pode ser usado imediatamente após a instalação.
Para mais informações sobre o plug-in de rede Flannel, consulte Flannel.
Terway Edge (redes underlay para contêineres)
O Terway Edge adota uma solução de rede nativa da nuvem dentro do pool de nós da nuvem. Ele configure a rede de contêineres usando elastic network interfaces (ENIs). As ENIs são NICs virtuais que atribuem endereços IP dentro de uma VPC aos pods. Para um pool de nós de borda, especifique um bloco CIDR para os pods. Os contêineres obterão endereços IP desse bloco CIDR. O plug-in de rede Terway Edge possui os seguintes recursos:
O bloco CIDR dos pods da nuvem e das instâncias do Elastic Compute Service (ECS) está dentro do intervalo de endereços IP da VPC e no mesmo plano de rede.
O bloco CIDR dos pods de borda não se sobrepõe ao bloco CIDR do host.
A comunicação entre pods ocorre sem encapsulamento, oferecendo eficiência superior à da rede overlay.
É necessária a configuração de rotas em dispositivos de rede externos para a transmissão de pacotes de contêiner.
Suporta acesso direto aos contêineres dentro do cluster a partir de hosts externos, contêineres e serviços na nuvem por meio do IP do pod.
Para mais informações sobre o plug-in de rede Terway Edge, consulte Plug-in de rede Terway Edge.
Visão geral do Service
Um Service é um método para expor aplicativos fornecendo um ponto de entrada para um grupo de pods. O ACK oferece os seguintes tipos de Services para lidar com solicitações de diferentes origens e clientes:
Tipo | Descrição |
ClusterIP | Um Service ClusterIP lida com o acesso dentro do cluster. Se seu aplicativo precisar de exposição interna no cluster, crie um Service ClusterIP. Nota Por padrão, o ClusterIP é selecionado quando você cria um Service. |
NodePort | Um Service NodePort expõe um aplicativo à Internet. Use o endereço IP e a porta de um nó do cluster para expor seu aplicativo. Dessa forma, o acesso ao aplicativo ocorre por meio do endereço IP e da porta do nó. |
LoadBalancer | Um Service LoadBalancer expõe um aplicativo à Internet. Esse tipo de Service utiliza uma instância SLB para a exposição, proporcionando maior disponibilidade e desempenho em comparação aos Services NodePort. Para mais informações sobre como usar um Service LoadBalancer para expor aplicativos, consulte Usar Services LoadBalancer para expor aplicativos. |
Headless Service | |
ExternalName | Um Service ExternalName mapeia um nome de serviço interno para um nome de domínio externo. Isso permite que os pods dentro do cluster acessem o domínio externo usando o nome do serviço interno. |
Em clusters ACK Edge, os recursos de computação frequentemente se espalham por diferentes domínios de rede. Os seguintes recursos estão disponíveis para cenários distribuídos:
|
Recurso |
Descrição |
|
Topologia de Service |
A topologia de Service garante que as solicitações dos clientes sejam direcionadas a pods de backend dentro do mesmo domínio de rede ou no mesmo nó. Assim, restringe-se a comunicação entre clientes e pods de serviço localizados em domínios de rede diferentes. Para mais informações, consulte Topologia de Service para pools de nós. |
|
Isolamento de portas para Service NodePort |
Para isolar portas de Services NodePort em vários domínios de rede, configure a escuta NodePort com base em pools de nós. Para mais informações, consulte Configurar escuta NodePort com base em pools de nós. |
Visão geral do Ingress
Nos clusters ACK Edge, os Services suportam balanceamento de carga de Camada 4. No entanto, os Ingresses gerenciam o acesso externo aos Services no cluster na Camada 7. Um Ingress funciona como um ponto de acesso que expõe múltiplos Services no cluster. Utilize Ingresses para configurar diferentes regras de encaminhamento de Camada 7. Por exemplo, encaminhe solicitações para diferentes Services com base em nomes de domínio ou caminhos. Para mais informações, consulte Visão geral do Ingress.
