Seleção de uma interface de rede de contêiner

Nuvem Privada Virtual

Analise as informações a seguir para selecionar uma interface de rede de contêiner (CNI).

Na versão Red Hat OpenShift on IBM Cloud 4.20 e posteriores, Calico é o CNI padrão, mas os clusters de VPC que usam nós de trabalho RHCOS têm a opção de selecionar Open Virtual Network (OVN) como o CNI do cluster.

Calico Padrão: Calico é uma plataforma única para rede, segurança de rede e observabilidade para qualquer distribuição Kubernetes na nuvem, no local ou na borda. Não importa se você está apenas começando com o Kubernetes ou se está operando em escala, as edições de código aberto, empresarial e de nuvem do Calico fornecem a rede, a segurança e a observabilidade de que você precisa. Para obter mais informações, consulte a documentação do site Calico.
OVN- Kubernetes (OVN) 4.20 e posterior Somente nós de trabalho RHCOS: OVN- Kubernetes é baseado na Open Virtual Network (OVN) e fornece uma implementação de rede baseada em sobreposição. Um cluster que usa o plug-in OVN- Kubernetes também executa o Open vSwitch (OVS) em cada nó. O OVN configura o OVS em cada nó para implementar a configuração de rede declarada. Para obter mais informações, consulte a documentação do site Red Hat

Comparação entre Calico e OVN

Analise a tabela a seguir para comparar os recursos e a funcionalidade do Calico e do OVN.

Ao usar a OVN, você deve garantir que as sub-redes da VPC não se sobreponham às sub-redes adicionais especificadas na tabela a seguir. Se houver uma sobreposição de sub-rede, a rede pod a pod falhará.

Layer2 e as redes definidas pelo usuário (UDN) do layer3 não são compatíveis com cargas de trabalho que utilizam DHCP, como as máquinas virtuais (VMs) do OpenShift Virtualization.

Calico e tabela de comparação da OVN
Componente	Calico	OVN- Kubernetes
Encapsulamento	IP em IP Protocol (não UDP ou TCP ) Encapsula apenas o tráfego de pod para pod de pods em execução em nós que estão em sub-redes diferentes.	Geneve: UDP Protocolo na porta 6081 Encapsula todo o tráfego de pod para pod
Rede padrão do cluster / MTU do pod	1480 bytes (cabeçalho IPinIP de 20 bytes) por padrão. Isso pode ser alterado.	1400 bytes (cabeçalho Geneve de 100 bytes) por padrão. Isso pode ser alterado. O Daemonset precisa criar o arquivo NetworkManager em vez de apenas executar `ip link set dev ens3 mtu`. Você também deve reiniciar os novos nós de trabalho.
Pod IPAM	Calico aloca inicialmente a cada novo nó uma sub-rede /26 (64 IPs, pelo menos um normalmente usado como tunl0 IP, o restante está disponível para pods). Se todos os IPs do pod em um /26 forem usados, o site Calico atribuirá uma segunda sub-rede /26 ao nó e mais se/quando necessário. Você pode usar o site `calicoctl ipam check` para ver as sub-redes atribuídas a cada nó.	A OVN aloca inicialmente a sub-rede do pod /24 (256 IPs) para cada novo nó do cluster. Não há opção para adicionar mais sub-redes de pod. Ele também aloca um IP de sub-rede de associação para cada novo nó, que é usado internamente pela OVN
Roteamento de pod para pod	Usa rotas do Linux. Usa BGP para distribuir rotas. `tunl0` interface em cada nó para encapsulamento.	O Open vSwitch (OVS) é executado em cada nó e roteia o tráfego de pod para pod. O OVN configura os fluxos do OVS para definir o roteamento de pod para pod. Muitas outras interfaces são criadas em cada nó, como: `ovs-system`, `genev_sys_6081`, `ovn-k8s-mp0`, `br-int`, `br-ex` e são usadas pelo OVN e pelo OVS
Políticas de rede do Kubernetes	Implementado por `calico-node` adicionando regras do iptables. O registro de tráfego bloqueado por políticas de rede é possível, mas complicado. Isso requer políticas Calico adicionais que usem uma ação "Log" e alguma reflexão e planejamento sobre onde/quando colocar essas ações de Log. Registros para `syslog` no nó de trabalho, que podem ser difíceis de recuperar. Os registros não incluem qual política permitiu ou bloqueou o tráfego.	Implementado pelo OVS usando ACLs em portas lógicas (não iptables). O registro de quedas e/ou tráfego permitido da política de rede é muito mais fácil com o uso de anotações. Anote o(s) namespace(s) em que deseja registrar a atividade da política e se deseja registrar permissões, negações ou ambos. Os registros são enviados para o arquivo `/var/log/ovn/acl-audit-log.log` no pod `ovnkube-node`. Existem opções de configuração para enviar esses logs para outros destinos de log. Os registros incluem qual política permitiu o tráfego, mas não qual tráfego o negou, pois as políticas são somente de permissão. Deve haver pelo menos uma política em vigor para que o tráfego permitido seja registrado.
Políticas de rede de host	Calico GlobalNetworkPolicies	Nenhum
Sub-redes adicionais	Nenhum	Sub-rede de ingresso: `100.64.0.0/16` ( OpenShift padrão). Sub-rede de mascaramento: `169.254.64.0/18`. Isso é diferente do padrão OpenShift de `169.254.0.0/17`. Essa diferença é para evitar conflitos com os IPs `169.254.2.0/24` usados para o haproxy de registro local. Sub-rede de trânsito:`100.88.0.0/16` ( OpenShift padrão).
Relógios do servidor de APIs	`calico-typha` registra as observações de recursos e atua como um proxy para os pods `calico-node` para notificar as alterações. `calico-node` conecta-se a um dos pods `calico-typha` e registra-se para receber notificações de alterações de recursos.	O contêiner `ovnkube-cluster-manager` no plano de controle procura por novos nós. O contêiner `ovnkube-controller` em cada nó do cluster observa os recursos e os converte em entradas lógicas da OVN no nbdb.
CNI	Os binários CNI `calico` e `calico-ipam` são copiados para cada nó pelo pod `install-cni` initContainer no pod `calico-node`.	O contêiner `ovnkube-controller` do pod `ovnkube-node` executa o binário da CNI para adicionar e excluir chamadas.
Recursos criados	`calico-apiserver` namespace `calico-apiserver` (implantação, 2 pods) `calico-system` namespace `calico-node` (cada nó) `calico-typha` (implantação, de 2 a 10 pods). `calico-kube-controllers` (1 nó). Espaço de nomes `openshift-kube-proxy`. `openshift-kube-proxy` (cada nó). `tigera-operator` namespace. `tigera-operator` (implantação, 1 pod). O binário da CNI `calico`, o binário da CNI `calico-ipam` e vários outros binários da CNI são copiados para cada nó por `install-cni` initContainer em `calico-node`.	`openshift-ovn-kubernetes` `ovnkube-node` em cada nó com 8 contêineres, `ovnkube-controller` observa os recursos, aloca IPs de pod e converte os recursos em entradas lógicas da OVN em `nbdb`. Também lida com adição e exclusão de CNI. `nbdb` armazena entradas lógicas. `northd` converte entradas lógicas de `nbdb` em fluxos lógicos em `sbdb`. `sbdb` armazena fluxos lógicos. `ovn-controller` converte fluxos lógicos em `sbdb` e programa o switch OVS. `ovn-acl-logging`. `kube-rbac-proxy-node` protege as métricas do nó para que somente os usuários autorizados possam extraí-las. `kube-rbac-proxy-ovn-metrics` protege as métricas da OVN para que somente usuários autorizados possam extraí-las.
Conexões entre pods	O pod `calico-node` se conecta inicialmente ao apiserver kube por meio do haproxy local no pod proxy que escuta em TCP 172.20.0.1:2040 para obter a lista de pods `calico-typha`. O pod `calico-node` se conecta a um dos pods `calico-typha` na porta 5473 do TCP para ouvir as atualizações de recursos do cluster. O pod `calico-node` executa o daemon bird BGP que se conecta em uma malha completa a todos os outros daemons bird BGP do `calico-node` na porta 179 do TCP. O tráfego de pod para pod acontece diretamente para pods em nós na mesma sub-rede. O tráfego de pod para pod entre pods em nós em diferentes sub-redes é encapsulado usando o encapsulamento IPinIP (ou VxLAN para clusters Satellite ).	O contêiner `ovnkube-controller` em cada nó se conecta ao apiserver do kube por meio do haproxy local no pod de proxy que escuta em TCP `172.20.0.1:2040` para ver os recursos. Todo o tráfego de pod para pod é encapsulado usando o Geneve e é enviado pela porta 6081 do UDP. Para obter mais informações, consulte Configuração do firewall.