Compartilhar via

Configurar a CNI do Azure da plataforma Cilium no AKS (Serviço de Kubernetes do Azure)

  • Artigo

A CNI do Azure da plataforma Cilium combina o painel de controle robusto da CNI do Azure com o plano de dados da Cilium para fornecer segurança e rede de alto desempenho.

Ao usar programas eBPF carregados no kernel do Linux e uma estrutura de objeto de API mais eficiente, a CNI do Azure da plataforma Cilium oferece os seguintes benefícios:

  • Funcionalidade equivalente aos plug-ins existentes da CNI do Azure e de Sobreposição da CNI do Azure

  • Roteamento de serviço aprimorado

  • Imposição de política de rede mais eficiente

  • Melhor observabilidade do tráfego de cluster

  • Suporte para clusters maiores (mais nós, pods e serviços)

Gerenciamento de Endereço IP (IPAM) com a CNI do Azure da plataforma Cilium

A CNI do Azure da plataforma Cilium pode ser implantada usando dois métodos diferentes para atribuir IPs de pod:

  • Atribuir endereços IP de uma rede de sobreposição (semelhante ao modo de Sobreposição da CNI do Azure)

  • Atribuir endereços IP de uma rede virtual (semelhante à CNI do Azure existente com Atribuição de IP de Pod Dinâmico)

Se não tiver certeza de qual opção selecionar, leia "Escolhendo um modelo de rede a ser usado".

Imposição da política de rede

O Cilium impõe políticas de rede para permitir ou negar o tráfego entre pods. Com o Cilium, você não precisa instalar um mecanismo de política de rede separado, como o Azure Network Policy Manager ou o Calico.

Limitações

Atualmente, a CNI do Azure da plataforma Cilium tem as seguintes limitações:

  • Disponível apenas para Linux, e não para Windows.

  • A imposição da política L7 do Cilium está desabilitada.

  • As políticas de rede não podem usar ipBlock para permitir acesso a IPs de nós ou pods. Veja perguntas frequentes para obter detalhes e soluções alternativas recomendadas.

  • Vários serviços do Kubernetes não podem usar a mesma porta host com protocolos diferentes (por exemplo, TCP ou UDP) (problema do Cilium nº 14287).

  • Políticas de rede podem ser impostas em pacotes de resposta quando um pod se conecta a si mesmo por meio do IP do cluster de serviço (problema do Cilium nº 19406).

  • As políticas de rede não são aplicadas a pods usando a rede de host (spec.hostNetwork: true) porque esses pods usam a identidade do host em vez de ter identidades individuais.

Pré-requisitos

  • CLI do Azure, versão 2.48.1 ou posterior. Execute az --version para ver a versão atualmente instalada. Se você precisa instalar ou atualizar, consulte Instalar a CLI do Azure.

  • Se estiver usando modelos do ARM ou a API REST, a versão da API do AKS deverá ser 2022-09-02-preview ou posterior.

Observação

Versões anteriores da API do AKS (2022-09-02preview para 2023-01-02preview) usavam o campo networkProfile.ebpfDataplane=cilium. As versões da API do AKS desde 2023-02-02preview usam o campo networkProfile.networkDataplane=cilium para habilitar a CNI do Azure da plataforma Cilium.

Criar um cluster do AKS com a CNI do Azure da plataforma Cilium

Opção 1: atribuir endereços IP de uma rede de sobreposição

Use os comandos a seguir para criar um cluster com uma rede de sobreposição e Cilium. Substitua os valores de <clusterName>, <resourceGroupName> e <location>:

az aks create \
    --name <clusterName> \
    --resource-group <resourceGroupName> \
    --location <location> \
    --network-plugin azure \
    --network-plugin-mode overlay \
    --pod-cidr 192.168.0.0/16 \
    --network-dataplane cilium \
    --generate-ssh-keys

Observação

O sinalizador --network-dataplane cilium substitui o sinalizador preterido --enable-ebpf-dataplane usado em versões anteriores da extensão da CLI aks-preview.

Opção 2: atribuir endereços IP de uma rede virtual

Execute os comandos a seguir para criar um grupo de recursos e uma rede virtual com uma sub-rede para nós e uma para pods.

# Create the resource group
az group create --name <resourceGroupName> --location <location>

# Create a virtual network with a subnet for nodes and a subnet for pods
az network vnet create --resource-group <resourceGroupName> --location <location> --name <vnetName> --address-prefixes <address prefix, example: 10.0.0.0/8> -o none
az network vnet subnet create --resource-group <resourceGroupName> --vnet-name <vnetName> --name nodesubnet --address-prefixes <address prefix, example: 10.240.0.0/16> -o none
az network vnet subnet create --resource-group <resourceGroupName> --vnet-name <vnetName> --name podsubnet --address-prefixes <address prefix, example: 10.241.0.0/16> -o none

Crie o cluster usando --network-dataplane cilium:

az aks create \
    --name <clusterName> \
    --resource-group <resourceGroupName> \
    --location <location> \
    --max-pods 250 \
    --network-plugin azure \
    --vnet-subnet-id /subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/virtualNetworks/<vnetName>/subnets/nodesubnet \
    --pod-subnet-id /subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/virtualNetworks/<vnetName>/subnets/podsubnet \
    --network-dataplane cilium \
    --generate-ssh-keys

Perguntas frequentes

  • Posso personalizar a configuração do Cilium?

    Não, o AKS gerencia a configuração do Cilium e ela não pode ser modificada. Recomendamos que os clientes que precisam de mais controle usem o AKS BYO CNI e instalem o Cilium manualmente.

  • Posso usar recursos personalizados CiliumNetworkPolicy em vez de recursos NetworkPolicy do Kubernetes?

    CiliumNetworkPolicy os recursos personalizados têm suporte parcial. Os clientes podem usar a filtragem FQDN como parte do pacote de recursos Serviços Avançados de Redes de Contêineres.

    Este exemplo CiliumNetworkPolicy demonstra um padrão de correspondência de amostra para serviços que correspondem ao rótulo especificado.

    apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "example-fqdn"
spec:
  endpointSelector:
    matchLabels:
      foo: bar
  egress:
  - toFQDNs:
    - matchPattern: "*.example.com"

  • Por que o tráfego está sendo bloqueado quando o NetworkPolicy possui um ipBlock que permite o endereço IP?

    Uma limitação do CNI do Azure Powered by Cilium é que um NetworkPolicy's ipBlock não pode selecionar IPs de pod ou nó.

    Por exemplo, esse NetworkPolicy tem um ipBlock que permite que todas as saídas 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 # This will still block pod and node IPs.

    No entanto, quando esse NetworkPolicy for aplicado, o Cilium bloqueará a saída para IPs de pods e nós, mesmo que os IPs estejam dentro do ipBlock CIDR.

    Como solução alternativa, você pode adicionar namespaceSelector e podSelector para selecionar pods. O exemplo abaixo seleciona todos os pods em todos os namespaces:

    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: {}

    Observação

    Atualmente não é possível especificar um NetworkPolicy com um ipBlock para permitir o tráfego para IPs de nós.

  • O AKS configura limites de CPU ou memória no daemonset do Cilium?

    Não, o AKS não configura limites de CPU ou memória no daemonset Cilium porque o Cilium é um componente crítico do sistema para a rede de pods e a imposição da política de rede.

  • A CNI do Azure da plataforma Cilium usa o Kube-Proxy?

    Não, os clusters do AKS criados com um plano de dados de rede como o Cilium não usam o Kube-Proxy. Se os clusters do AKS estiverem na Sobreposição da CNI do Azure ou na CNI do Azure com alocação de IP dinâmica e forem atualizados para clusters do AKS que executam a CNI do Azure da plataforma Cilium, novas cargas de trabalho de nós serão criadas sem kube-proxy. Cargas de trabalho mais antigas também são migradas para serem executadas sem kube-proxy como parte desse processo de atualização.

Próximas etapas

Saiba mais sobre a rede no AKS nos seguintes artigos: