Usando o plug-in CNI da Rede de Pods Nativa da VCN do OCI para a rede de pods

Saiba mais sobre o plug-in CNI de Rede de Pod Nativa da VCN do OCI para comunicação de pods em nós de trabalho em clusters criados usando o Kubernetes Engine (OKE).

O plug-in CNI de Rede de Pod Nativa da VCN do OCI fornece endereços IP para pods do bloco CIDR de uma VCN. O plug-in CNI do OCI VCN-Native Pod Networking permite que outros recursos dentro da mesma sub-rede (ou de outra sub-rede) se comuniquem diretamente com pods em um cluster do Kubernetes. Os endereços IP do pod são roteáveis diretamente de outras VCNs conectadas (pareadas) a essa VCN e de redes locais.

Como os pods são roteáveis diretamente, você pode usar a funcionalidade VCN 'nativa' para:

Controle o acesso de e para pods usando regras de segurança definidas como parte de grupos de segurança de rede (recomendado) ou listas de segurança. As regras de segurança se aplicam a todos os pods em todos os nós de trabalho conectados à sub-rede de pod especificada para um pool de nós. Consulte Grupos de Segurança de Rede e Listas de Segurança.
Observe o tráfego de/para e entre pods usando logs de fluxo da VCN para fins de solução de problemas e auditoria de conformidade. Consulte Logs de Fluxo da VCN.
Roteie solicitações de entrada para pods com base em políticas de roteamento especificadas por regras de roteamento e tabelas de roteamento. Consulte Tabelas de Roteamento da VCN.

Ao usar o plug-in CNI de Rede de Pod Nativa da VCN do OCI, os nós de trabalho são conectados a duas sub-redes especificadas para o pool de nós:

Sub-rede do Nó de Trabalho: A sub-rede do nó de trabalho suporta comunicação entre processos em execução no plano de controle do cluster (como kube-apiserver, kube-controller-manager, kube-scheduler) e processos em execução no nó de trabalho (como kubelet, kube-proxy). A sub-rede do nó de trabalho pode ser privada ou pública e pode ser uma sub-rede regional (recomendado) ou em diferentes sub-redes específicas do AD (uma em cada domínio de disponibilidade na região).
Sub-rede de Pod: A sub-rede de pod suporta comunicação entre pods e acesso direto a pods individuais usando endereços IP de pod privado. A sub-rede de pod deve ser privada e deve ser regional. A sub-rede de pod permite que os pods se comuniquem com outros pods no mesmo nó de trabalho, com pods em outros nós de trabalho, com serviços do OCI (por meio de um gateway de serviço) e com a internet (por meio de um gateway NAT). Você especifica uma única sub-rede de pod para todos os pods em execução nos nós de trabalho em um pool de nós. Você pode especificar a mesma sub-rede de pod ou sub-redes de pod diferentes para diferentes pools de nós em um cluster. Você pode especificar a mesma sub-rede de pod para pools de nós em clusters diferentes.

A sub-rede do nó de trabalho e a sub-rede do pod devem estar na mesma VCN. Em algumas situações, a sub-rede do nó de trabalho e a sub-rede do pod podem ser a mesma sub-rede (consulte Número Máximo de VNICs e Pods Suportados por Diferentes Formas). Se a sub-rede do nó de trabalho e a sub-rede do pod forem a mesma sub-rede, a Oracle recomenda definir regras de segurança em grupos de segurança de rede (em vez de em listas de segurança) para rotear o tráfego de rede para nós de trabalho e pods. A sub-rede do nó de trabalho e a sub-rede do pod são adicionais à sub-rede do ponto final da API do Kubernetes e a quaisquer sub-redes do balanceador de carga definidas para o cluster.

Ao usar o plug-in CNI de Rede de Pod Nativa da VCN do OCI, no mínimo duas VNICs são anexadas a cada nó de trabalho. A primeira VNIC está conectada à sub-rede do nó de trabalho. A segunda VNIC está conectada à sub-rede do pod. Por padrão, 31 endereços IP são designados à VNIC para uso por pods em execução no nó de trabalho. Para evitar a falta de endereços IP, os endereços IP são pré-alocados na sub-rede do pod antes da criação dos pods no cluster.

Se a forma selecionada para o pool de nós suportar mais de duas VNICs, as VNICs adicionais poderão ser conectadas à sub-rede do pod para fornecer mais endereços IP para suportar mais pods.

Você pode especificar o número máximo de pods que deseja executar em um único nó de trabalho em um pool de nós, até um limite de 110. O limite de 110 é imposto pelo Kubernetes. Se você quiser mais de 31 pods em um único nó de trabalho, a forma especificada para o pool de nós deverá suportar três ou mais VNICs (uma VNIC para estabelecer conexão com a sub-rede do nó de trabalho e pelo menos duas VNICs para estabelecer conexão com a sub-rede do pod). Consulte Número Máximo de VNICs e Pods Suportados por Diferentes Formas.

Se você quiser conservar o espaço de endereço da sub-rede do pod, reduza o número máximo de pods que deseja executar em um único nó de trabalho e, dessa forma, reduza o número de endereços IP pré-alocados na sub-rede do pod.

Observe o seguinte ao usar o plug-in CNI da Rede de Pod Nativa da VCN do OCI:

Você pode usar o plug-in CNI de Rede de Pod Nativa da VCN do OCI com pools de nós virtuais e pools de nós gerenciados.
Você pode usar o plug-in CNI do OCI VCN-Native Pod Networking com nós autogerenciados, desde que os nós do plano de controle do cluster estejam executando o Kubernetes versão 1.27.10 (ou posterior). Para obter mais informações, consulte Trabalhando com Nós Autogerenciados.
Você só pode usar o plug-in CNI da Rede de Pods Nativa da VCN do OCI com clusters que executam o Kubernetes 1.22 ou mais recente (consulte Usando o plug-in CNI da Rede de Pods Nativa da VCN do OCI para a rede de pods). Para obter mais informações, consulte Pod Networking.
Se você estiver usando o plug-in CNI de Rede de Pod Nativa da VCN do OCI e quiser especificar uma imagem do OKE como a imagem base para nós de trabalho, não selecione uma imagem do OKE liberada antes de junho de 2022.
Se você estiver usando o plug-in CNI de Rede de Pod Nativa da VCN do OCI e quiser rotear o tráfego de uma rede local para um pod, observe que o endereço IP do pod não será persistente se o pod for recriado. Por exemplo, um pod Nginx pode inicialmente ter 10.0.0.5 como seu endereço IP, mas se o pod for excluído e recriado, o pod poderá ter um endereço IP diferente (como 10.0.0.8).
Os produtos de malha de serviços (como Istio e Linkerd) são suportados ao usar o plug-in CNI de Rede de Pod Nativa da VCN do OCI para rede de pods. Observe que, com exceção do complemento Istio, o suporte está atualmente limitado ao Oracle Linux 7 (o suporte para Oracle Linux 8 está planejado). O complemento Istio é compatível com o Oracle Linux 7 e o Oracle Linux 8. Os nós de trabalho devem estar executando o Kubernetes 1.26 (ou posterior).

Regras de Segurança para Nós de Trabalho e Pods

Ao usar o plug-in CNI da Rede de Pod Nativa da VCN do OCI para a rede de pod, determinadas regras de segurança são necessárias para a sub-rede de pod e a sub-rede do nó de trabalho. Consulte Regras de Segurança para Sub-redes de Pod.

Número Máximo de VNICs e Pods Suportados por Diferentes Formas

O número máximo de VNICs (e, portanto, o número máximo de pods) para nós de trabalho em um pool de nós depende da forma selecionada para o pool de nós.

Para descobrir o número máximo de VNICs de uma forma específica, consulte Formas de Computação.

Para calcular o número máximo de pods em um pool de nós de uma forma específica, use a seguinte equação:

Maximum number of Pods per node = MIN( (Number of VNICs - 1) * 31 ), 110)

Política adicional do serviço IAM para acessar recursos com endereços IPv6

Para usar o plug-in CNI de Rede de Pod Nativa da VCN do OCI no qual os recursos relacionados a um cluster (como ponto final da API do Kubernetes, balanceador de carga e nós de trabalho) têm endereços IPv6, inclua uma instrução de política semelhante à seguinte em uma política do serviço IAM:

Allow any-user to use ipv6s in compartment <compartment-ocid-of-network-resources> where all { request.principal.id = '<cluster-ocid>' }

Política de IAM Adicional quando um Cluster e seus Recursos Relacionados estão em Diferentes Compartimentos

Para usar o plug-in CNI de Rede de Pod Nativa da VCN do OCI no cenário incomum em que os recursos relacionados de um cluster (como pools de nós, recursos de VCN e de VCN) estão em outro compartimento para o próprio cluster, inclua instruções de política semelhantes às seguintes em uma política do serviço IAM:

Allow any-user to manage instances in tenancy where all { request.principal.type = 'cluster' }

Allow any-user to use private-ips in tenancy where all { request.principal.type = 'cluster' }

Allow any-user to use network-security-groups in tenancy where all { request.principal.type = 'cluster' }

Se você considerar essas instruções de política muito permissivas, poderá restringir as permissões para especificar explicitamente o compartimento ao qual os recursos relacionados pertencem e/ou especificar explicitamente o cluster que tem recursos relacionados em outro compartimento. Por exemplo:

Allow any-user to manage instances in compartment <compartment-ocid-of-nodepool> where all { request.principal.id = '<cluster-ocid>' }

Allow any-user to use private-ips in compartment <compartment-ocid-of-network-resources> where all { request.principal.id = '<cluster-ocid>' }

Allow any-user to use network-security-groups in compartment <compartment-ocid-of-network-resources> where all { request.principal.id = '<cluster-ocid>' }

em que:

<compartment-ocid-of-nodepool> é o OCID do compartimento ao qual pertencem pools de nós e instâncias de computação.
<compartment-ocid-of-network-resources> é o OCID do compartimento ao qual a VCN e as sub-redes pertencem.

Atualizando o plug-in CNI da Rede de Pods Nativa da VCN do OCI

Quando você especifica a rede de pods nativa da VCN como tipo de rede de um cluster, o cluster e seus pools de nós executam inicialmente a versão mais recente do plug-in CNI de Rede de Pods Nativas da VCN do OCI.

As atualizações no plug-in CNI de Rede do Pod Nativo da VCN do OCI são liberadas periodicamente.

Nas versões do plug-in CNI de Rede de Pod Nativa da VCN do OCI anteriores à versão 2.3.0 (agosto de 2025), você pode especificar que deseja que a Oracle implante as atualizações no cluster automaticamente. Como alternativa, você pode especificar que deseja escolher a versão a ser implantada. Se decidir escolher uma versão (e a versão for anterior à versão 2.3.0), está a assumir a responsabilidade por manter a extensão atualizada. O plug-in CNI de Rede de Pods Nativos da VCN do OCI usa a estratégia de atualização RollingUpdate; portanto, os pods de plug-in CNI existentes são encerrados automaticamente e novos pods são criados executando a nova versão do plug-in CNI (para obter mais informações sobre a estratégia de atualização RollingUpdate, consulte DaemonSet Update Strategy na documentação do Kubernetes). As atualizações são aplicadas quando os nós de trabalho são reinicializados na próxima vez.

No plug-in CNI version 2.3.0 do OCI VCN-Native Pod Networking (agosto de 2025) e em versões posteriores, as atualizações do plug-in do CNI nunca são implantadas no cluster automaticamente. O plug-in CNI de Rede de Pods Nativos da VCN do OCI usa a estratégia de atualização OnDelete; portanto, o plug-in do CNI só pode ser atualizado excluindo explicitamente os pods de plug-in do CNI (para obter mais informações sobre a estratégia de atualização OnDelete, consulte DaemonSet Update Strategy na documentação do Kubernetes). Essa abordagem evita reinicializações inesperadas de pods de plug-in CNI durante atualizações de cluster. A versão 2.3.0 também introduz uma política de validação de admissão que restringe a exclusão de pods de plug-in CNI. Para atualizar o plugin CNI para uma versão mais recente ao usar a versão 2.3.0 ou posterior, adote uma das seguintes técnicas:

(recomendado) Provisionar novos nós no cluster: Quando você provisiona novos nós no cluster, eles recebem automaticamente pods de plug-in CNI que executam a versão mais recente do plug-in CNI. Opcionalmente, você pode drenar e remover nós com pods de plug-in CNI que estão executando versões mais antigas.
Atualizar nós existentes no cluster: Você pode atualizar a versão do plug-in CNI nos nós existentes excluindo os pods de plug-in CNI existentes. Você precisa remover a política de validação de admissão que restringe a exclusão de pods de plug-in CNI, excluir os pods de plug-in CNI existentes e, em seguida, restaurar a política. O DaemonsetController recria os pods de plug-in CNI, executando a versão mais recente do plug-in CNI. Siga estas etapas:
1. Identifique os pods de plug-in CNI dos nós existentes a serem atualizados, digitando:
```
kubectl get pods -n kube-system -l app=vcn-native-ip-cni
```
2. Exclua a política de validação de admissão para permitir que você exclua os pods de plug-in CNI da seguinte forma:
  1. Salve a política de admissão de validação e a vinculação de política de admissão de validação como vap-policy.yaml e vap-binding.yaml para que você possa restaurá-las posteriormente, informando os seguintes comandos:
```
kubectl get validatingadmissionpolicy npn-pod-deletion-deny-policy -o yaml > vap-policy.yaml
```
```
kubectl get validatingadmissionpolicyBinding npn-pod-deletion-deny-policy-binding -o yaml > vap-binding.yaml
```
  2. Exclua a política de admissão de validação e a vinculação da política de admissão de validação, inserindo os seguintes comandos:
```
kubectl delete validatingadmissionpolicy npn-pod-deletion-deny-policy
```
```
kubectl delete validatingadmissionpolicyBinding npn-pod-deletion-deny-policy-binding
```
3. Exclua os pods de plug-in CNI que você identificou anteriormente, digitando o seguinte comando para cada pod:
```
kubectl delete pod <cni-pod-name> -n kube-system
```
4. Restaure a política de admissão de validação e a vinculação de política que você excluiu anteriormente, usando os arquivos vap-policy.yaml e vap-binding.yaml criados anteriormente, digitando os seguintes comandos:
```
kubectl apply -f vap-policy.yaml
```
```
kubectl apply -f vap-binding.yaml
```

Para determinar se as atualizações foram implantadas e estão aguardando aplicação, inspecione os logs da Daemonset vcn-native-ip-cni digitando:

kubectl logs -n kube-system -l app=vcn-native-ip-cni --prefix | grep "reboot required"

Interprete a resposta ao comando da seguinte forma: