Suporte para políticas de rede do Kubernetes

Visão geral da política de rede do Kubernetes

As políticas de rede do Kubernetes permitem especificar como os pods se comunicam com outros pods e endpoints de rede. Um recurso do Kubernetes NetworkPolicy permite que um pod se comunique com:

• Outros pods na lista de permitidos (um pod não pode bloquear o acesso a si mesmo).

• Namespaces na lista de permitidos.

• Blocos de IP ou roteamento entre domínios sem classe (CIDRs).

As políticas de rede do Kubernetes aplicam-se apenas a pods em um namespace e definem regras de entrada (fonte) e saída (destino). As políticas de rede do Kubernetes têm as seguintes características quando aplicadas a um pod:

• Pod específico e aplicar-se a um único pod ou a um grupo de pods. As regras da política de rede determinam o tráfego para esse pod.

• Definir regras de tráfego para um pod para tráfego de entrada, tráfego de saída ou ambos. Se você não especificar uma direção explicitamente, a política se aplica à direção de entrada por padrão.

• Deve conter regras explícitas que especifiquem o tráfego da lista de autorização nas direções de entrada e saída. O tráfego que não corresponde às regras da lista de permitidos é negado.

• O tráfego permitido inclui tráfego correspondente a qualquer uma das políticas de rede aplicadas a um pod.

As políticas de rede do Kubernetes têm as seguintes características adicionais:

• Quando não é aplicado a um pod, esse pod aceita o tráfego de todas as fontes.

• Aja em conexões em vez de pacotes individuais. Por exemplo, se o tráfego do pod A ao pod B for permitido pela política configurada, os pacotes do pod B ao pod A também serão permitidos, mesmo que a política em vigor não permita que o pod B inicie uma conexão ao pod A.

Uma política de rede do Kubernetes compreende as seguintes seções:

• spec: Descreve o estado desejado de um objeto Kubernetes. Para uma política de rede, os campos e policyTypes os podSelector campos dentro da especificação especificam as regras para essa política.

• podSelector: Seleciona os grupos de pods aos quais a política se aplica. Um vazio podSelector seleciona todos os pods no namespace.

• policyTypes: Especifica se a política se aplica ao tráfego de entrada de pods selecionados ou tráfego de saída para pods selecionados. Se não policyTypes for especificado, a direção de entrada é selecionada por padrão.

• ingress: Permite o tráfego de entrada que corresponda às from ports seções. No exemplo a seguir, a regra de entrada permite conexões a todos os pods no dev namespace com o aplicativo de rótulo: webserver-dev na porta TCP 80 a partir de:

  • Qualquer pod no namespace padrão com o rótulo app: client1-dev.

  • Todos os endereços IP dentro da faixa de 10.169.25.20/32.

  • Qualquer pod no namespace padrão com o rótulo project: jtac.

• egress: Permite o tráfego de saída que corresponda às to portsseções. No exemplo 1, a regra de saída permite conexões de qualquer pod no namespace padrão com o rótulo app: dbserver-dev para portar TCP 80.

• ipBlock: Seleciona as faixas de IP CIDR para permitir como destinos de entrada ou saída. A ipBlock seção de uma política de rede contém os seguintes dois campos:

  • cidr (ipBlock.cidr): A política de rede permite a saída de tráfego ou entrada de tráfego a partir da faixa de IP especificada.

  • exceto (ipBlock.excepto): o Kubernetes espera que o tráfego na faixa de IP especificada não corresponda à política. A política de rede nega a entrada de tráfego ou saída de tráfego da faixa de IP especificada em except.

    Nota: Se você usar except em uma política de rede, o Kubernetes espera que o tráfego identificado na except faixa de IP não corresponda à política. A CN2 não oferece suporte a este cenário específico em que você usa o except termo. Como resultado, recomendamos que você evite usar except.

O exemplo de recursos a seguir NetworkPolicy mostra ingress e egress regras:

Neste exemplo, é permitido retirar o tráfego de TCP de IPs dentro da port: 80 CIDR10.169.25.20/32. É permitido habilitar TCP port: 80 o tráfego de saída para pods.matchLabels app: dbserver-dev

Implante uma política de rede kubernetes no Cloud-Native Contrail Networking

Na CN2, depois de configurar e implantar uma política de rede kubernetes, essa política é criada automaticamente no Contrail. Aqui está um exemplo de uma política de rede do Kubernetes:

Essa política resulta na criação dos seguintes objetos na CN2:

Tags

Grupos de endereços

Regras de firewall

Política de firewall

Correspondências da política de rede do KubernetesExpressões

A partir do Cloud-Native Contrail Networking 22.3, o CN2 oferece suporte à política de rede do Kubernetes com matchExpressions. Para obter mais informações sobre matchExpressions, veja "Recursos que oferecem suporte a requisitos baseados em conjunto" na documentação do Kubernetes.