Recentemente, tenho trabalhado com conteúdo PaaS e acabei de entrar em contato com o Kubernetes, que envolve cobertura de rede, ou seja, comunicação entre containers cross-host. Assim, uma série de componentes open source surgiu, como flanela, calicó, teia, etc. Aqui estão principalmente Calico e Fannel.
Princípio da flanela
Flannel, um projeto desenvolvido pela CoreOS, é provavelmente o plugin CNI mais direto e popular. É um dos exemplos mais maduros de arquitetura de rede em sistemas de orquestração de contêineres e foi projetado para permitir uma melhor rede entre contêineres e entre hosts. Com o surgimento do conceito CNI, o plugin Flannel CNI é uma das primeiras introduções.
Flanela é relativamente fácil de instalar e configurar comparado a outras opções. Ele é empacotado como um único binário FlannelD, e muitas ferramentas comuns de implantação de clusters Kubernetes e muitas distribuições Kubernetes podem instalar Flannel por padrão. O Flannel pode usar o cluster etcd existente do cluster Kubernetes para armazenar suas informações de estado usando a API, então não requer um armazenamento de dados dedicado.
O Flannel configura uma rede de sobreposição IPv4 de Camada 3. Ele cria uma grande rede interna que abrange todos os nós do cluster. Nessa rede Overlay, cada nó possui uma sub-rede que é usada para atribuir endereços IP internamente. Ao configurar um pod, a interface da ponte Docker em cada nó atribui um endereço a cada novo container. Pods no mesmo host podem se comunicar usando pontes Docker, enquanto pods em hosts diferentes usam flanneld para encapsular seu tráfego em pacotes UDP para que possam ser roteados para o destino apropriado.
Flanela possui vários tipos diferentes de backends que podem ser usados para encapsulamento e roteamento. A abordagem padrão e recomendada é usar VXLAN porque o VXLAN tem melhor desempenho e requer menos intervenção manual.
Arquitetura de calico
A calicó inclui os seguintes componentes importantes: Felix, etcd, BGP Client e BGP Route Reflector. A seguir, estão as explicações de cada um desses componentes.
Felix: Principalmente responsável pela configuração do roteamento, configuração das regras ACLS e entrega, elas existem em cada nó.
etcd: Armazenamento distribuído de chave-valor, principalmente responsável pela consistência dos metadados da rede, garantindo a precisão do estado da rede Calico, pode ser compartilhado com o Kubernetes;
O BGPClient (BIRD) é principalmente responsável por distribuir as informações de roteamento escritas pelo Felix para o kernel da rede Calico atual, garantindo a eficácia da comunicação entre cargas de trabalho.
O Refletor BGPRoute (BIRD) é usado em implantações em larga escala, abandonando o modo mesh de interconexão de todos os nós e utilizando um ou mais Refletores BGPRoute para completar o roteamento e distribuição centralizados.
O princípio da calicó
Como mostrado no diagrama a seguir, o processo é representado do contêiner de origem passando pelo host de origem, passando pelo roteamento do data center, e finalmente para o host de destino e, finalmente, atribuído ao contêiner de destino.
Contraste
A partir do princípio acima, pode-se ver que a flanela realiza operações de desempacotamento de pacotes com base no encaminhamento de roteamento, o que desperdiça recursos computacionais da CPU. O gráfico abaixo compara o desempenho de vários componentes de rede open source encontrados online. Pode-se ver que, em termos de largura de banda e latência de rede, o desempenho da Calico e do host é semelhante.
|
Publicado em 09/11/2020 11:23:01
|
|
|
|
