Melhores Práticas de Rede

Melhores Práticas: Criar compartimentos separados para cada equipe

Recomendamos que você crie um compartimento separado para cada equipe se esperar que várias equipes criem clusters.

Por exemplo, recursos de rede como a Rede Virtual na Nuvem (VCN) e sub-redes usadas para o Kubernetes Engine podem residir no compartimento raiz. No entanto, se você espera que várias equipes criem clusters, recomendamos que você crie um compartimento separado para os recursos de cluster de cada equipe (por exemplo, como compartimentos filhos do compartimento raiz). A lógica é que, como um cluster e seus recursos não precisam estar no mesmo compartimento que a VCN e as sub-redes, ter compartimentos separados para cada equipe torna mais fácil e mais limpo segregar clusters e mantê-los seguros.

Consulte Configuração do Recurso de Rede para Criação e Implantação de Cluster.

Melhores Práticas: Dimensione sua VCN adequadamente

Recomendamos que você permita possíveis requisitos futuros de dimensionamento de cluster e pool de nós ao dimensionar a VCN na qual deseja criar e implantar clusters do Kubernetes.

A VCN deve ter um bloco CIDR grande o suficiente para alocar endereços de rede a todos os recursos que um cluster exige (sub-redes, ponto final da API do Kubernetes, nós de trabalho, pods, balanceadores de carga).

Consulte Configuração da VCN e Blocos IPv4 CIDR e OKE (Kubernetes Engine).

Melhores Práticas: Selecione o plug-in CNI de rede de pod que melhor atenda às suas necessidades

Recomendamos que você considere os requisitos de rede de pod com cuidado e, em seguida, selecione o plug-in CNI de rede de pod que melhor atenda às suas necessidades.

Por exemplo:

• Se os aplicativos exigirem o uso de requisitos de rede base (e não o uso de endereços IP da VCN) ou exigirem uma alta densidade de pods por nó de trabalho, recomendamos o uso do plug-in Flannel CNI.
• Se os aplicativos exigirem que os pods tenham um endereço IP do CIDR da VCN e/ou exijam o desempenho de rede consistente oferecido pelas máquinas virtuais (independentemente dos nós nos quais os pods estejam em execução) sem sobreposição adicional, recomendamos o uso do plug-in CNI de Rede de Pods Nativos da VCN do OCI.

Consulte Rede de Pods e Blocos IPv4 CIDR e OKE (Kubernetes Engine).

Melhores Práticas: Configure externalTrafficPolicy adequadamente ao expor aplicativos

Recomendamos que você considere cuidadosamente o valor mais apropriado para a definição externalTrafficPolicy ao provisionar um balanceador de carga de rede para um serviço Kubernetes do tipo LoadBalancer:

• externalTrafficPolicy: Cluster (modo de cluster)

  Especifique o modo de cluster se você sempre quiser rotear o tráfego para todos os pods que executam um serviço com distribuição igual e não quiser preservar endereços IP do cliente. No modo de cluster, o Kubernetes encaminha qualquer tráfego enviado a qualquer nó de trabalho em uma porta específica para um dos pods desse serviço.

  O modo de cluster geralmente resulta em menos rotatividade de backends no cluster porque o roteamento de solicitação não depende do estado dos pods no cluster. Qualquer solicitação pode ser enviada para qualquer nó, e o Kubernetes trata de colocar a solicitação no lugar certo. O modo de cluster resulta em boa distribuição de carga do balanceador de carga de rede nos nós de trabalho. Quando o tráfego atinge um nó de trabalho, o nó o trata da mesma maneira. O balanceador de carga não sabe quais nós do cluster estão executando pods para seu serviço. Se você tiver selecionado uma sub-rede regional para nós de trabalho, a carga será distribuída por todos os nós em todos os domínios de disponibilidade da região da sub-rede. No modo de cluster, o tráfego é balanceado por carga em todos os nós do cluster, mesmo os nós que não executam um pod relevante.

• externalTrafficPolicy: Local (modo local)

  Especifique o modo local se quiser que as solicitações sejam encerradas nos endereços IP do cliente especificados nos cabeçalhos do pacote IP. Você só tem a opção de preservar endereços IP do cliente quando as solicitações são encerradas nos endereços IP do cliente especificados nos cabeçalhos do pacote IP. Ou seja, quando a definição externalTrafficPolicy é definida como Local.

  O modo local remove o salto de rede extra necessário no modo de cluster, mas o tráfego de rede pode se tornar potencialmente desequilibrado se a rede não estiver configurada corretamente. No modo local, o tráfego de entrada deve ser enviado para nós que estão executando os pods correspondentes para esse serviço. Caso contrário, o tráfego será eliminado. Como resultado, alguns pods de aplicativos podem receber mais tráfego do que outros pods.

Para obter mais informações, consulte Encerrando solicitações no nó de recebimento e Preservando o endereço IP do cliente.

Melhores Práticas: Evite sobrepor blocos CIDR de pod e serviço com um bloco CIDR local e ao usar o plug-in CNI de flannel

Recomendamos que você evite a situação em que o bloco CIDR usado pela rede de sobreposição flannel para provisionar pods e serviços com endereços IP se sobrepõe a um bloco CIDR usado para provisionar instâncias de computação externas com endereços IP.

Os clusters do Kubernetes exigem um endereço IP exclusivo para cada pod. Portanto, o planejamento de endereços IP é necessário porque os endereços não podem se sobrepor ao espaço de endereço IP privado usado no local ou em outras VCNs conectadas.

Ao usar o plug-in flannel CNI, a comunicação entre pods em um cluster é encapsulada na rede de sobreposição flannel. A rede de sobreposição de flanela usa seu próprio bloco CIDR para provisionar pods e nós de trabalho com endereços IP. Os pods na rede de sobreposição de flanela só podem ser acessados de outros pods no mesmo cluster. As instâncias de computação externas fora do cluster não podem acessar pods diretamente. Se um pod tentar acessar uma instância de computação externa que tenha o mesmo endereço IP de outro pod no cluster, a solicitação será roteada incorretamente e ocorrerão problemas.

Consulte Usando o plug-in CNI flannel para a rede de pods.

Melhores Práticas: Use sub-redes regionais e distribua cargas de trabalho para alta disponibilidade

Recomendamos que você selecione sub-redes regionais para nós de trabalho para garantir alta disponibilidade e distribuir cargas de trabalho entre eles.

A VCN deve ter um número apropriado de sub-redes definidas para nós de trabalho, balanceadores de carga e o ponto final da API do Kubernetes. O uso de sub-redes regionais e a distribuição de cargas de trabalho entre elas garantem alta disponibilidade e tornam o failover entre domínios de disponibilidade mais simples de implementar.

Consulte Configuração da Sub-rede.

Melhores Práticas: Use restrições de propagação de topologia para controlar como os pods são distribuídos

Recomendamos que você use restrições de propagação de topologia de pod para controlar como os pods são distribuídos entre domínios de disponibilidade e nós de trabalho.

Por exemplo, quando muitos nós de trabalho estão disponíveis, mas apenas dois ou três pods são necessários, você geralmente não quer que todos os pods sejam executados no mesmo nó de trabalho para evitar o risco de um único ponto de falha se houver um problema.

No entanto, à medida que mais e mais pods são necessários para clientes em vários domínios de disponibilidade, você geralmente deseja distribuir os pods uniformemente entre vários nós de trabalho nesses diferentes domínios de disponibilidade. Nesse cenário, distribuir os pods para reduzir a latência e os custos de rede associados ao envio de tráfego de rede entre domínios de disponibilidade é uma preocupação tão grande quanto evitar um único ponto de falha. Talvez você prefira ter um número semelhante de pods em cada domínio de disponibilidade e ter a autocorreção do cluster se houver um problema.

O uso de restrições de propagação de topologia de pod permite configurar um cluster para atender às metas gêmeas de alta disponibilidade e utilização eficiente de recursos.

Consulte Restrições de Distribuição da Topologia do Pod na documentação do Kubernetes.

Melhores Práticas: Número de nós do plano

Recomendamos que você tenha um plano em vigor para o número de nós em um cluster que leve em consideração o tamanho do nó, o perfil do aplicativo de pods e o plug-in CNI de rede de pod selecionado.

Ao usar o plug-in flannel CNI, os clusters criados pelo Kubernetes Engine reservam uma faixa /25 para pods da rede de sobreposição flannel e permitem até 110 pods por nó. Ao usar o plug-in CNI do OCI VCN-Native Pod Networking, o mesmo nó pode ter uma faixa diferente com base na forma selecionada para nós de trabalho. Dependendo do tamanho dos nós e do perfil de aplicativo dos pods, decida antecipadamente o número de nós que você deseja no cluster.

Consulte Rede de Pod.

Melhores Práticas: Usar sub-redes separadas e regras de segurança

Recomendamos que você use sub-redes e regras de segurança separadas ao configurar recursos de rede.

A VCN na qual você deseja criar e implantar clusters deve ter pelo menos duas (opcionalmente, mais) subnets:

• uma sub-rede de ponto final da API do Kubernetes
• uma sub-rede de nós de trabalho
• uma regional ou duas sub-redes de balanceador de carga específicas do AD (opcional)
• uma sub-rede de pods (ao usar o plug-in CNI da Rede de Pod Nativa da VCN do OCI)
• uma sub-rede bastion (opcional)

Você pode optar por combinar as sub-redes e também as regras de segurança. No entanto, essa abordagem torna a segurança mais difícil de gerenciar e, portanto, não é recomendada, a menos que você esteja usando grupos de segurança de rede para controlar o acesso a clusters.

Consulte Configuração da Sub-rede.

Melhores Práticas: Use sub-redes separadas para balanceadores de carga

Recomendamos que você crie sub-redes separadas para que os balanceadores de carga exponham serviços.

Se você não criar uma sub-rede do balanceador de carga separada, os serviços serão expostos usando um endereço IP da sub-rede do nó de trabalho. Como resultado, o espaço alocado na sub-rede do nó de trabalho pode ser completamente usado antes do previsto, o que pode impedir que o cluster seja dimensionado para o número de nós especificados.

As sub-redes de balanceador de carga podem ser públicas ou privadas, dependendo de como os aplicativos implantados no cluster serão acessados. Se os aplicativos forem acessados internamente na sua VCN, use sub-redes privadas para as sub-redes de balanceador de carga. Se os aplicativos forem acessados pela Internet, use sub-redes públicas para as sub-redes de balanceador de carga.

Consulte Configuração de Sub-rede do Balanceador de Carga.

Melhores Práticas: Use uma sub-rede privada de nó de trabalho para obter segurança máxima

Recomendamos que você especifique uma sub-rede privada como a sub-rede de nó de trabalho para máxima segurança.

A sub-rede de nó de trabalho pode ser uma única sub-rede regional ou várias sub-redes específicas do AD (uma em cada um dos domínios de disponibilidade). A sub-rede de nó de trabalho pode ser uma sub-rede pública ou privada. No entanto, recomendamos que a sub-rede de nó de trabalho seja uma sub-rede privada para máxima segurança.

Consulte Configuração de Sub-rede de Nó de Trabalho.

Melhores Práticas: Migre clusters para serem nativos da VCN para integrar o ponto final da API do Kubernetes à sua VCN

Recomendamos que você migre clusters que ainda não sejam nativos da VCN para serem nativos da VCN.

Em um cluster nativo da VCN, nós de trabalho, balanceadores de carga e o ponto final da API do Kubernetes são totalmente integrados à sua própria VCN e você pode configurá-los como públicos ou privados. Você pode controlar o acesso à sub-rede do ponto final da API do Kubernetes usando regras de segurança definidas para grupos de segurança de rede (recomendado) ou listas de segurança.

Para aproveitar o controle de segurança oferecido pelos clusters nativos da VCN, migre um cluster que ainda não seja nativo da VCN para integrar seu ponto final da API do Kubernetes à sua própria VCN.

Consulte Migrando para Clusters Nativos de VCN.

Melhores Práticas: Crie um ConfigMap para substituir o comportamento padrão de CoreDNS

Recomendamos que, se você quiser personalizar o comportamento padrão do CoreDNS, crie e aplique seu próprio ConfigMap para substituir as definições no Corefile CoreDNS.

Observe que se você personalizar o comportamento padrão CoreDNS, as personalizações serão excluídas periodicamente durante atualizações internas para o cluster.

Consulte Configurando Servidores DNS para Clusters do Kubernetes.

Melhores Práticas: Use sondas de prontidão e vivacidade para verificações de saúde

Recomendamos que você use sondas de vida e prontidão do Kubernetes para verificar a integridade dos contêineres em um cluster e personalize as sondas para atender aos seus requisitos.

Gerenciar sistemas grandes e distribuídos pode ser complicado, especialmente quando algo dá errado. As verificações de integridade do Kubernetes são uma maneira fácil de garantir que as instâncias do aplicativo estejam funcionando. A criação de verificações de integridade personalizadas permite que você adapte as verificações de integridade ao seu ambiente.

Em particular, recomendamos que você considere o uso de sondas de prontidão e vivacidade para confirmar que os contêineres estão funcionando e funcionando corretamente antes de torná-los candidatos a receber tráfego de um serviço. Os parâmetros de sondagem e sondagem específicos a serem usados dependerão da carga de trabalho. Estabeleça um equilíbrio entre tornar a sonda muito agressiva e lenta demais e ajustar parâmetros para atender às necessidades do aplicativo.

Consulte Configure Liveness, Readiness and Startup Probes na documentação do Kubernetes.

Melhores Práticas: Use métricas do balanceador de carga e do balanceador de carga de rede para monitorar backends

Recomendamos que você use métricas para monitorar a integridade do balanceador de carga do OCI ou do balanceador de carga de rede provisionado para um serviço Kubernetes do tipo LoadBalancer.

Também recomendamos que você configure alarmes para alertá-lo se a disponibilidade de backend estiver abaixo de um limite de sua escolha. Por exemplo:

• Use a métrica UnhealthyBackendServers do balanceador de carga para configurar um alarme para alertá-lo se o número de servidores de backend não íntegros em um conjunto de backend subir acima de zero.
• Use a métrica BackendTimeouts do balanceador de carga para configurar um alarme para alertá-lo se o número de timeouts em todos os servidores de backend ultrapassar zero.
• Use a métrica HealthyBackends do balanceador de carga de rede para configurar um alarme para alertá-lo se o número de backends que a Oracle considera íntegros ficar abaixo de um.
• Use a métrica UnhealthyBackends do balanceador de carga de rede para configurar um alarme para alertá-lo se o número de backends que a Oracle considera não íntegros aumentar acima de zero.

Consulte Métricas do Balanceador de Carga, Métricas do Balanceador de Carga de Rede e Criando um Alarme.

Melhores Práticas: Use labels de nó para incluir um subconjunto de nós de trabalho em um conjunto de backend

Recomendamos que você use a anotação node-label-selector para incluir no conjunto de backend de um determinado balanceador de carga ou balanceador de carga de rede apenas esse subconjunto de nós de trabalho que têm os pods de aplicativo necessários. A inclusão de subconjuntos dos nós de trabalho de um cluster nos conjuntos de backend de diferentes balanceadores de carga e balanceadores de carga de rede permite que você apresente um único cluster do Kubernetes como vários clusters lógicos (serviços).

Tendo anexado um label Kubenetes aos nós de trabalho que você deseja incluir no conjunto de backend de um balanceador de carga ou balanceador de carga de rede, especifique esse label no manifesto do serviço do tipo LoadBalancer:

• para um balanceador de carga, use a anotação oci.oraclecloud.com/node-label-selector:
• para um balanceador de carga de rede, use a anotação oci-network-load-balancer.oraclecloud.com/node-label-selector:

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/node-label-selector: lbset=ServiceA
spec:
  type: LoadBalancer
...

apiVersion: v1
kind: Pod
...
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: lbset
            operator: In
            values:
            - ServiceA
...

Consulte Selecionando Nós de Trabalho a Serem Incluídos em Conjuntos de Backend.

Melhores Práticas: Instale o Calico antes de criar qualquer pool de nós

Recomendamos que, se você quiser usar o Calico para aprimorar a segurança do cluster, instale o Calico em um cluster antes de criar qualquer pool de nós.

Você pode aprimorar a segurança do cluster implementando políticas de rede do Kubernetes. Para implementar políticas de rede do Kubernetes, instale e configure um provedor de rede que suporte recursos NetworkPolicy. Um desses fornecedores é o Calico.

Se você instalar o Calico em um cluster que tenha pools de nós existentes, nos quais os pods já estejam em execução, será necessário recriar os pods quando a instalação do Calico for concluída. Por exemplo, executando o comando kubectl rollout restart. Se você instalar o Calico em um cluster antes de criar qualquer pool de nós no cluster (conforme recomendado), poderá ter certeza de que não haverá pods a serem recriados.

Observe que somente o uso do Calico open source é suportado. O uso do Calico Enterprise não é suportado.

Consulte Exemplo: Instalando o Calico e Configurando Políticas de Rede.