Compartilhar via

Migração do NPM (Gerenciador de Políticas de Rede) para a Política de Rede do Cilium

Neste artigo, apresentamos um guia abrangente para planejar, executar e validar a migração do NPM (Gerenciador de Políticas de Rede) para a Política de Rede do Cilium. O objetivo é garantir a paridade da política, minimizar a interrupção do serviço e alinhar-se à direção estratégica da CNI do Azure em direção à rede baseada em eBPF e à observabilidade aprimorada.

Importante

Este guia se aplica exclusivamente aos clusters do AKS que executam nós do Linux. Atualmente, não há suporte para a Política de Rede do Cilium em nós do Windows no AKS.

Principais considerações antes de começar

  • Compatibilidade da política: o NPM e o Cilium são diferentes quanto aos modelos de imposição. Antes da migração, você precisa validar se as políticas existentes são compatíveis ou identificar as alterações necessárias. Veja a seção Validação pré-migração para obter diretrizes.
  • Expectativas de tempo de inatividade: a imposição da política pode ser temporariamente inconsistente durante a recriação de imagem do nó.
  • Pools de nós do Windows: atualmente, não há suporte para a Política de Rede do Cilium em nós do Windows no AKS.

Validação de pré-migração

Antes de migrar do NPM (Gerenciador de Políticas de Rede) para a Política de Rede do Cilium, é importante avaliar a compatibilidade das políticas de rede existentes. Embora a maioria das políticas continue funcionando como esperado após a migração, há cenários específicos em que o comportamento pode variar entre o NPM e o Cilium. Essas diferenças podem exigir atualizações nas políticas antes ou depois da migração para garantir a imposição consistente e evitar quedas de tráfego não intencionais. Nesta seção, descrevemos cenários conhecidos em que os ajustes de política podem ser necessários. Explicamos por que isso é importante e fornecemos diretrizes sobre quais ações, se houver, são necessárias para tornar as políticas compatíveis com o Cilium.

NetworkPolicy com endPort

Observação

O Cilium começou a dar suporte ao campo endPort na NetworkPolicy do Kubernetes na versão 1.17.

O campo endPort permite que você defina um intervalo de portas em uma só regra, em vez de especificar portas individuais.

Confira um exemplo de uma NetworkPolicy do Kubernetes que usa o campo endPort:

  egress:
    - to:
        - ipBlock:
            cidr: 10.0.0.0/24
      ports:
        - protocol: TCP
          port: 32000
          endPort: 32768

Ação obrigatória:

  • Se o cluster do AKS estiver executando o Cilium versão 1.17 ou posterior, nenhuma alteração será necessária, pois o endPort tem suporte completo.
  • Se o cluster estiver executando uma versão do Cilium anterior à 1.17, remova o campo endPort de todas as políticas antes de migrar. Em vez disso, use entradas de porta única explícitas.

NetworkPolicy com ipBlock

O campo ipBlock na NetworkPolicy do Kubernetes permite que você defina intervalos CIDR para fontes de entrada ou destinos de saída. Esses intervalos podem incluir IPs externos, IPs de pod ou IPs de nó. No entanto, o Cilium não permite a saída para IPs de pod ou nó com ipBlock, mesmo que esses IPs estejam no intervalo CIDR especificado.

Por exemplo, a seguinte NetworkPolicy usa um ipBlock para permitir que todo o tráfego de saída seja 0.0.0.0/0:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: example-ipblock
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    - to:
      - ipBlock:
          cidr: 0.0.0.0/0
  • No NPM, essa política permitirá a saída para todos os destinos, incluindo pods e nós.
  • Após a migração para o Cilium, a saída para IPs de pod e nó será bloqueada, mesmo que estejam dentro do intervalo 0.0.0.0/0.

Ação obrigatória:

  • Para permitir o tráfego para IPs de pod, antes da migração, substitua o ipBlock por uma combinação de namespaceSelector e podSelector.

Confira um exemplo de como usar namespaceSelector e podSelector:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: example-ipblock
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    - to:
      - ipBlock:
          cidr: 0.0.0.0/0
      - namespaceSelector: {}
      - podSelector: {}
  • Para os IPs de nó, não há nenhuma solução alternativa pré-migração. Após a migração, você precisa criar uma CiliumNetworkPolicy que permita explicitamente a saída para as entidades de host e/ou de nó remoto. Até que essa política esteja em vigor, o tráfego de saída para os IPs de nó será bloqueado.

Confira um exemplo de CiliumNetworkPolicy para permitir o tráfego bidirecional nós locais e remotos:

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: allow-node-egress
  namespace: ipblock-test
spec:
  endpointSelector: {}  # Applies to all pods in the namespace
  egress:
     - toEntities:
          - host # host allows traffic from/to the local node’s host network namespace
          - remote-node # remote-node allows traffic from/to the remote node’s host network namespace

NetworkPolicy com portas nomeadas

A NetworkPolicy do Kubernetes permite que você referencie portas por nome em vez de número. Se você estiver usando portas nomeadas nas NetworkPolicies, o Cilium poderá falhar ao impor as regras corretamente e resultar em um bloqueio de tráfego inesperado. Esse problema ocorre quando o mesmo nome da porta é usado para portas diferentes. Para obter mais informações, veja Problema do GitHub nº 30003 do Cilium.

Confira um exemplo de NetworkPolicy que usa a porta nomeada para permitir o tráfego de saída:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  annotations:
  name: allow-egress
  namespace: default
spec:
  podSelector:
    matchLabels:
      network-rules-egress: cilium-np-test
  egress:
  - ports:
    - port: http-test # Named port
      protocol: TCP
  policyTypes:
  - Egress

Ação obrigatória:

  • Antes da migração, substitua todas as portas nomeadas nas políticas pelos valores numéricos correspondentes.

NetworkPolicy com políticas de saída

A NetworkPolicy do Kubernetes no NPM não bloqueia o tráfego de saída de um pod para o IP do próprio nó, esse tráfego é implicitamente permitido. Após a migração para o Cilium, esse comportamento será alterado e o tráfego para nós locais permitidos anteriormente será bloqueado, a menos que seja explicitamente permitido.

Por exemplo, a seguinte política permite a saída apenas para uma sub-rede de API interna:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-egress 
  namespace: default
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    - to:
      - ipBlock:
          cidr: 10.20.30.0/24
  • Com o NPM: o tráfego de saída para 10.20.30.0/24 é permitido explicitamente e o tráfego de saída para o nó local é permitido implicitamente.
  • Com o Cilium: somente o tráfego para 10.20.30.0/24 é permitido; a saída para o IP do nó é bloqueada, a menos que você a permita explicitamente.

Ação obrigatória:

  • Analise todas as políticas de saída existentes das cargas de trabalho.
  • Se os aplicativos dependerem do comportamento de permissão implícita do NPM para saída para o nó local, você precisará adicionar regras de saída explícitas para manter a conectividade após a migração.
  • Você pode adicionar uma CiliumNetworkPolicy após a migração para permitir explicitamente o tráfego de saída para o host local.

Alterações no comportamento da política de entrada

No NPM (Gerenciador de Políticas de Rede), o tráfego de entrada que chega por meio de um serviço LoadBalancer ou NodePort com “externalTrafficPolicy=Cluster” – que é a configuração padrão – não está sujeito à imposição de política de entrada. Esse comportamento significa que, mesmo que um pod tenha uma política de entrada restritiva, o tráfego de fontes externas ainda poderá acessá-lo por meio dos serviços loadbalancer ou nodeport.

Por outro lado, o Cilium impõe políticas de entrada em todo o tráfego, incluindo o tráfego roteado internamente devido a externalTrafficPolicy=Cluster. Como resultado, após a migração, o tráfego permitido anteriormente poderá ser removido se as regras de entrada apropriadas não forem definidas explicitamente.

Por exemplo, o cliente cria uma política de rede para negar todo o tráfego de entrada

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  • Com o NPM: a conexão direta com o pod ou por meio do serviço ClusterIP é bloqueada. No entanto, o acesso por meio de NodePort ou LoadBalancer ainda é permitido, apesar da política deny-all.
  • Com o Cilium: todo o tráfego de entrada é bloqueado, incluindo o tráfego via NodePort ou LoadBalancer, a menos que seja explicitamente permitido.

Ação obrigatória:

  • Analise todas as políticas de entrada para cargas de trabalho protegidas pelos serviços LoadBalancer ou NodePort com externalTrafficPolicy=Cluster.
  • Verifique se as regras de entrada permitem explicitamente o tráfego das fontes externas esperadas (por exemplo, intervalos de IP, namespaces ou rótulos).
  • Se a política atualmente depender do comportamento de permissão implícita no NPM, você precisará adicionar regras de entrada explícitas para manter a conectividade após a migração.

Atualizar para o CNI do Azure alimentado pelo Cilium

Para usar a Política de Rede do Cilium, o cluster do AKS precisa executar a CNI do Azure da plataforma Cilium. Quando você habilita o Cilium em um cluster que atualmente usa o NPM, o mecanismo do NPM existente é automaticamente desinstalado e substituído pelo Cilium.

Aviso

O processo de atualização dispara cada pool de nós a ter a imagem recriada simultaneamente. Não há suporte para atualização de cada pool de nós separadamente. Todas as interrupções de rede de cluster são semelhantes a uma atualização de imagem de nó ou à atualização da versão do Kubernetes, em que uma imagem é criada de cada nó em um pool de nós. O Cilium começará a impor políticas de rede somente depois que a imagem de todos os nós tiver sido recriada.

Importante

Essas instruções se aplicam a clusters que atualizam da CNI do Azure para a CNI do Azure com o plano de dados do Cilium. As atualizações de Traga suas próprias CNIs ou alterações do modo IPAM não são abordadas aqui. Para obter mais informações, veja a documentação Atualizar a CNI do Azure.

Para executar a atualização, você precisa da CLI do Azure versão 2.52.0 ou posterior. Execute az --version para ver a versão atualmente instalada. Se você precisa instalar ou atualizar, consulte Instalar a CLI do Azure.

Use o comando a seguir para atualizar um cluster existente para o CNI do Azure da Plataforma Cilium. Substitua os valores de clusterName e resourceGroupName:

az aks update --name <clusterName> --resource-group <resourceGroupName> --network-dataplane cilium

Próximas etapas

  • Last updated on