2.5. Como planejar a rede¶

2.5.1. Requisitos gerais de rede¶

• O tráfego de armazenamento interno precisa ser separado dos outros tipos de tráfego.

2.5.2. Limitações de rede¶

• Os nós são adicionados aos clusters pelos endereços IP, não por FQDNs. A alteração do endereço IP de um nó no cluster causará sua remoção do cluster. Se você planeja usar DHCP em um cluster, verifique se os endereços IP estão vinculados aos endereços MAC das interfaces de usuário dos nós.
• Cada nó precisa ter acesso à Internet para que as atualizações possam ser instaladas.
• O valor de MTU é definido como 1500 por padrão. Consulte Etapa 2: configuração da rede para mais informações sobre como definir um valor de MTU ideal.
• A sincronização de hora da rede (NTP) é obrigatória para gerar estatísticas corretas. Ela é habilitada por padrão pelo uso do serviço chronyd. Se você quiser usar ntpdate ou ntpd, pare e desabilite chronyd primeiro.
• O tipo de tráfego Gerenciamento interno é atribuído automaticamente durante a instalação e não pode ser mudado no painel de administração posteriormente.
• Mesmo que o nó de gerenciamento possa ser acessado em um navegador da Web pelo nome do host, você ainda precisará especificar seu endereço IP, não o nome do host, durante a instalação.

2.5.3. Recomendações e requisitos de rede por nó¶

• Todas as interfaces de rede em um nó precisam estar conectadas a sub-redes diferentes. Uma interface de rede pode ser uma interface lógica marcada com VLAN, um vínculo não marcado ou um link Ethernet.

• Embora os nós do cluster tenham as regras de iptables necessárias configuradas, recomendamos o uso de um firewall externo para redes públicas não confiáveis, como a Internet.

• As portas que serão abertas nos nós do cluster dependem dos serviços que serão executados no nó e dos tipos de tráfego associados a eles. Antes de ativar um serviço específico em um nó de cluster, é necessário atribuir o respectivo tipo de tráfego a uma rede à qual este nó está conectado. A atribuição de um tipo de tráfego a uma rede configura um firewall nos nós conectados a essa rede, abre portas específicas nas interfaces de rede dos nós e define as regras iptables necessárias.

  A tabela abaixo lista todas as portas e serviços necessários associados a eles:

  Tabela 2.5.3.1 Portas abertas nos nós de cluster¶

  Serviço	Tipo de tráfego	Porta	Descrição
  Painel de controle da Web	Painel de administração*	TCP 8888	Acesso externo ao painel de administração.
  	Painel de autoatendimento	TCP 8800	Acesso externo ao painel de autoatendimento.
  Gerenciamento	Gerenciamento interno	qualquer porta disponível	Gerenciamento do cluster interno e transferências dos dados de monitoramento do nó para o painel de administração.
  Serviço de metadados	Armazenamento	qualquer porta disponível	Comunicação interna entre os serviços do MDS, bem como com os clientes e serviços de fragmentos.
  Serviço de fragmentos		qualquer porta disponível	Comunicação interna com os serviços do MDS e clientes.
  Cliente		qualquer porta disponível	Comunicação interna com os serviços de fragmentos e MDS.
  Gateway de backup	ABGW público	TCP 44445	Troca de dados externos com agentes do Acronis Backup e o Acronis Backup Cloud.
  	ABGW privado	qualquer porta disponível	Gerenciamento interno de e troca de dados entre diversos serviços de Backup Gateway.
  iSCSI	iSCSI	TCP 3260	Troca de dados externos com o ponto de acesso iSCSI.
  S3	S3 público	TCP 80, 443	Troca de dados externos com o ponto de acesso S3.
  	OSTOR privado	qualquer porta disponível	Troca de dados internos entre diversos serviços S3.
  NFS	NFS	TCP/UDP 111, 892, 2049	Troca de dados externos com o ponto de acesso NFS.
  	OSTOR privado	qualquer porta disponível	Troca de dados internos entre diversos serviços NFS.
  Computação	API de computação*		Acesso externo a pontos de extremidade de API do OpenStack:
  		TCP 5000	API de Identidade v3
  		TCP 6080	noVNC Websocket Proxy
  		TCP 8004	API de Serviço de Orquestração v1
  		TCP 8041	API de Gnocchi (serviço de medição de cobrança)
  		TCP 8774	API de computação
  		TCP 8776	API de armazenamento de bloco v3
  		TCP 8780	API de posicionamento
  		TCP 9292	API de Serviço de Imagem v2
  		TCP 9313	API de Gerente de Chaves v1
  		TCP 9513	API de Gerenciamento de Infraestrutura de Contêineres (Serviço de Kubernetes)
  		TCP 9696	API de redes v2
  		TCP 9888	API Octavia v2 (serviço do balanceador de carga)
  	VM privada	UDP 4789	Tráfego de rede entre VMs em redes virtuais privadas.
  		TCP 5900-5999	Tráfego de console VNC.
  	Backups de VM	TCP 49300-65535	Acesso externo aos pontos de extremidade NBD (Network Block Device).
  SSH	SSH	TCP 22	Acesso remoto aos nós via SSH.
  SNMP	SNMP*	UDP 161	Acesso externo às estatísticas de monitoramento de cluster de armazenamento por meio do protocolo SNMP.

  * As portas para esses tipos de tráfego devem estar abertas apenas nos nós de gerenciamento.

2.5.4. Requisitos de rede de Kubernetes¶

Para poder implantar clusters de Kubernetes no cluster de computação e trabalhar com eles, verifique se a sua configuração de rede permite que os serviços de computação e Kubernetes enviem as seguintes solicitações de rede:

1. A solicitação para inicializar o cluster etcd no serviço público de descoberta — de todos os nós de gerenciamento para https://discovery.etcd.io através da rede pública.
2. A solicitação para obter o arquivo “kubeconfig” —de todos os nós de gerenciamento através da rede pública:
   • Se HA (alta disponibilidade) estiver habilitada para VM, a solicitação é enviada ao endereço de IP flutuante ou público da VM de balanceador de carga associada à API de Kubernetes na porta 6443.
   • Se HA (alta disponibilidade) estiver desabilitada para VM, a solicitação é enviada ao endereço de IP flutuante ou público da VM de balanceador de carga associada à API de Kubernetes na porta 6443.
3. Solicitações das VMs mestre de Kubernetes para as APIs de computação (o tipo de tráfego API de computação) através da rede com o tipo de tráfego VM pública (por meio de uma interface de rede de VM disponível publicamente ou de um roteador virtual com SNAT habilitada). Como padrão, a API de computação é exposta através do endereço IP do nó de gerenciamento (ou ao seu endereço IP virtual se a alta disponibilidade estiver habilitada). Mas também pode acessar a API de computação pelo nome DNS (confira Setting a DNS Name for the Compute API).
4. A solicitação para atualizar estado de membro de cluster etcd no serviço público de descoberta—a partir das VMs mestre de Kubernetes para https://discovery.etcd.io através da rede com o tipo de tráfego VM pública (por meio de uma interface de rede de VM disponível publicamente ou de um roteador virtual com SNAT habilitada).
5. A solicitação para baixar as imagens de contêineres do repositório de Hub de Docker público—a partir das VMs mestre de Kubernetes para https://registry-1.docker.io através da rede com o tipo de tráfego VM pública (por meio de uma interface de rede de VM disponível publicamente ou de um roteador virtual com SNAT habilitada).

Também é necessário que a rede em que você cria um cluster de Kubernetes não se sobreponha a essas redes padrão:

• 10.100.0.0/24—usada para rede de nível de pod
• 10.254.0.0/16—usada para alocar endereços de IP de cluster de Kubernetes

2.5.5. Recomendações de rede para clientes¶

A tabela abaixo lista o desempenho máximo da rede que um cliente pode alcançar com a interface de rede especificada. A recomendação para os clientes é usar um hardware de rede de 10 Gbps entre dois nós de cluster e minimizar latências de rede, especialmente se usarem discos SSD.