40 Requisitos e suposições #

40.1 Hardware #

Consulte abaixo os requisitos de hardware para o SUSE Telco Cloud:

Cluster de gerenciamento: contém componentes, como SUSE Linux Micro, RKE2, SUSE Rancher Prime e Metal³, e é usado para gerenciar vários clusters downstream. Dependendo do número de clusters downstream que será gerenciado, os requisitos de hardware para o servidor podem variar.
- Os requisitos mínimos para o servidor (VM ou bare metal) são:
  - RAM: mínimo de 8 GB (recomendamos pelo menos 16 GB)
  - CPU: mínimo de 2 (recomendamos pelo menos 4)
Clusters downstream: trata-se dos clusters implantados para executar as cargas de trabalho de telecomunicações. Requisitos específicos são necessários para habilitar determinados recursos de telecomunicações, como SR-IOV, otimização de desempenho da CPU etc.
- SR-IOV: para anexar funções virtuais (VFs, Virtual Functions) no modo de passagem a CNFs/VNFs, a NIC deve permitir que SR-IOV e VT-d/AMD-Vi sejam habilitados no BIOS.
- Processadores de CPU: para executar cargas de trabalho de telecomunicações, o modelo de processador da CPU deve ser adaptado para disponibilizar a maior parte dos recursos nesta tabela de referência (Capítulo 42, Configuração dos recursos de telecomunicações).
- Requisitos de firmware para instalação com mídia virtual:
  Hardware de servidor Modelo de BMC Gerenciamento
  Hardware Dell
  15ª geração
  iDRAC9
  Hardware Supermicro
  01.00.25
  Supermicro SMC – redfish
  Hardware HPE
  1.50
  iLO6

Hardware de servidor	Modelo de BMC	Gerenciamento
Hardware Dell	15ª geração	iDRAC9
Hardware Supermicro	01.00.25	Supermicro SMC – redfish
Hardware HPE	1.50	iLO6

40.2 Rede #

Como referência à arquitetura de rede, o seguinte diagrama mostra uma arquitetura de rede típica para um ambiente de telecomunicações:

A arquitetura de rede baseia-se nos seguintes componentes:

Rede de gerenciamento: essa rede é usada para gerenciamento de nós do cluster downstream. Ela é usada para gerenciamento fora da banda. Em geral, essa rede também é conectada a um comutador de gerenciamento separado, mas pode ser conectada ao mesmo comutador de serviço usando VLANs para isolar o tráfego.
Rede do plano de controle: essa rede é usada para comunicação entre os nós do cluster downstream e os serviços executados neles. Ela também é usada para comunicação entre os nós e os serviços externos, como servidores DHCP ou DNS. Em alguns casos, o comutador/roteador processa o tráfego pela Internet nos ambientes conectados.
Outras redes: em alguns casos, os nós podem se conectar a outras redes para finalidades específicas.

Nota

Para usar o fluxo de trabalho de provisionamento de rede direcionado, o cluster de gerenciamento deve ter conectividade de rede com o Baseboard Management Controller (BMC) do servidor de cluster downstream para que seja possível automatizar a preparação e o provisionamento do host.

40.3 Requisitos de porta #

Para operar de maneira apropriada, a implantação do SUSE Telco Cloud requer várias portas acessíveis nos nós de cluster Kubernetes tanto de gerenciamento quanto downstream.

Nota

A lista exata depende dos componentes opcionais implantados e das opções de implantação selecionadas (por exemplo, plug-in de CNI).

40.3.1 Nós de gerenciamento #

A seguinte tabela lista as portas abertas nos nós que executam o cluster de gerenciamento:

Nota

Para as portas relacionadas ao plug-in de CNI, consulte os requisitos de porta específicos da CNI (Seção 40.3.3, “Requisitos de porta específicos da CNI”).

Tabela 40.1: Regras de rede de entrada para nós de gerenciamento #

Protocolo	Porta	Fonte	Descrição
TCP	22	Qualquer fonte que exija acesso SSH	Acesso SSH aos nós do cluster de gerenciamento
TCP	80	Balanceador de carga/proxy que faça terminação TLS externa	IU do Rancher/API quando a terminação TLS externa é usada
TCP	443	Qualquer fonte que exija acesso TLS à IU do Rancher/API	Agente do Rancher, IU do Rancher/API
TCP	2379	Nós do servidor RKE2 (cluster de gerenciamento)	Porta do cliente `etcd`
TCP	2380	Nós do servidor RKE2 (cluster de gerenciamento)	Porta do peer `etcd`
TCP	6180	Um BMC⁽¹⁾ que já recebeu instruções do `Metal³/ironic` para extrair uma imagem ramdisk do IPA⁽²⁾ desta porta exposta (não TLS)	Servidor web não TLS httpd `Ironic` para exibir imagens ISO do IPA⁽²⁾ para inicialização com base em mídia virtual Se essa porta estiver habilitada, a funcionalidade equivalente, exceto aquela habilitada por TLS (veja abaixo), não será aberta
TCP	6185	Um BMC⁽¹⁾ que já recebeu instruções do `Metal³/ironic` para extrair uma imagem ramdisk do IPA⁽²⁾ dessa porta exposta (TLS)	Servidor web habilitado para TLS httpd `Ironic` para exibir imagens ISO do IPA⁽²⁾ para inicialização com base em mídia virtual Se essa porta estiver habilitada, a funcionalidade equivalente, exceto aquela desabilitada para TLS (veja abaixo), não será aberta
TCP	6385	Uma imagem ramdisk do IPA⁽¹⁾ do `Metal³/ironic` implantada e em execução na instância `BareMetalHost` "registrada"	API Ironic
TCP	6443	Qualquer nó do cluster de gerenciamento; qualquer cliente Kubernetes externo (ao cluster de gerenciamento)	API Kubernetes
TCP	6545	Qualquer nó do cluster de gerenciamento	Extrair artefatos do registro compatível com OCI (Hauler)
TCP	9345	Nós do agente e servidor RKE2 (cluster de gerenciamento)	API de supervisor RKE2 para registro de nós (porta aberta em todos os nós do servidor RKE2)
TCP	10250	Qualquer nó do cluster de gerenciamento	Métricas `kubelet`
TCP/UDP/SCTP	30000-32767	Qualquer fonte externa (ao cluster de gerenciamento) que acessa um serviço exposto na rede principal por um objeto de API de serviço `spec.type: NodePort` ou `spec.type: LoadBalancer`	Intervalo de portas `NodePort`

⁽¹⁾ BMC: Baseboard Management Controller
⁽²⁾ IPA: Ironic Python Agent

40.3.2 Nós downstream #

No SUSE Telco Cloud, antes de um servidor (downstream) fazer parte de um cluster Kubernetes downstream em execução (ou ser executado em um cluster Kubernetes downstream de nó único), ele deve passar por alguns dos estados de provisionamento do BaremetalHost.

O Baseboard Management Controller (BMC) de um servidor downstream recém-declarado deve ser acessível pela rede fora da banda. O BMC recebe instruções (do serviço Ironic executado no cluster de gerenciamento) sobre as etapas iniciais que deve seguir:
1. Extrair e carregar a imagem ramdisk indicada do IPA na mídia virtual oferecida pelo BMC.
2. Ligar o servidor.

A exposição das seguintes portas é esperada do BMC (podem variar de acordo com o hardware exato):

Tabela 40.2: Regras da rede de entrada para Baseboard Management Controllers #

Protocolo	Porta	Fonte	Descrição
TCP	80	Condutor do Ironic (do cluster de gerenciamento)	Acesso à API Redfish (HTTP)
TCP	443	Condutor do Ironic (do cluster de gerenciamento)	Acesso à API Redfish (HTTPS)

Depois que a imagem ramdisk do IPA carregada na mídia virtual do BMC for usada para inicializar a imagem do servidor downstream, a fase de inspeção do hardware será iniciada. A seguinte tabela lista as portas expostas pela imagem ramdisk do IPA em execução:

Tabela 40.3: Regras da rede de entrada para nós downstream – Fase de provisionamento do Metal³/Ironic #

Protocolo	Porta	Fonte	Descrição
TCP	22	Qualquer fonte que exija acesso SSH à imagem ramdisk do IPA	Acesso SSH a um nó do cluster downstream que está sendo inspecionado
TCP	9999	Condutor do Ironic (do cluster de gerenciamento)	Comandos do Ironic para a imagem ramdisk em execução

Depois que o host bare metal for devidamente provisionado e fizer parte de um cluster Kubernetes downstream, ele vai expor as seguintes portas:

Nota

Para as portas relacionadas ao plug-in de CNI, consulte os requisitos de porta específicos da CNI (Seção 40.3.3, “Requisitos de porta específicos da CNI”).

Tabela 40.4: Regras da rede de entrada para nós downstream #

Protocolo	Porta	Fonte	Descrição
TCP	22	Qualquer fonte que exija acesso SSH	Acesso SSH aos nós do cluster downstream
TCP	80	Balanceador de carga/proxy que faça terminação TLS externa	IU do Rancher/API quando a terminação TLS externa é usada
TCP	443	Qualquer fonte que exija acesso TLS à IU do Rancher/API	Agente do Rancher, IU do Rancher/API
TCP	2379	Nós do servidor RKE2 (cluster downstream)	Porta do cliente `etcd`
TCP	2380	Nós do servidor RKE2 (cluster downstream)	Porta do peer `etcd`
TCP	6443	Qualquer nó do cluster downstream; qualquer cliente Kubernetes externo (ao cluster downstream)	API Kubernetes
TCP	9345	Nós do agente e servidor RKE2 (cluster downstream)	API de supervisor RKE2 para registro de nós (porta aberta em todos os nós do servidor RKE2)
TCP	10250	Qualquer nó do cluster downstream	Métricas `kubelet`
TCP	10255	Qualquer nó do cluster downstream	Acesso somente leitura ao `kubelet`
TCP/UDP/SCTP	30000-32767	Qualquer fonte externa (ao cluster downstream) que acessa um serviço exposto na rede principal por um objeto de API de serviço `spec.type: NodePort` ou `spec.type: LoadBalancer`	Intervalo de portas `NodePort`

40.3.3 Requisitos de porta específicos da CNI #

Cada variante da CNI com suporte tem o próprio conjunto de requisitos de porta. Para obter mais detalhes, consulte CNI Specific Inbound Network Rules (Regras da rede de entrada específicas da CNI) na documentação do RKE2.

Quando cilium é definido como plug-in de CNI padrão/principal, a porta TCP a seguir também é exposta quando a carga de trabalho cilium-operator está configurada para expor as métricas fora do cluster Kubernetes no qual foi implantada. Isso garante que uma instância externa do servidor Prometheus em execução fora do cluster Kubernetes ainda possa coletar essas métricas.

Nota

Trata-se da opção padrão quando o cilium é implantado pelo gráfico Helm rke2-cilium.

Tabela 40.5: Regras da rede de entrada para nós de gerenciamento/downstream – exposição de métricas externa do cilium-operator habilitada #

Protocolo	Porta	Fonte	Descrição
TCP	9963	Coletor de métricas externo (ao cluster Kubernetes)	Exposição de métricas do cilium-operator

40.4 Serviços (DHCP, DNS etc.) #

Alguns serviços externos, como DHCP, DNS etc., podem ser necessários, dependendo do tipo de ambiente em que estão implantados:

Ambiente conectado: nesse caso, os nós são conectados à Internet (por protocolos de roteamento L3), e o cliente providencia os serviços externos.
Ambiente desconectado/air-gapped: nesse caso, os nós não têm conectividade IP de Internet e são exigidos serviços adicionais para espelhar localmente o conteúdo necessário pelo fluxo de trabalho de provisionamento de rede direcionado.
Servidor de arquivos: usado para armazenar as imagens de sistema operacional que são provisionadas nos nós do cluster downstream durante o fluxo de trabalho de provisionamento de rede direcionado. O gráfico Helm do Metal³ pode implantar um servidor de mídia para armazenar as imagens de sistema operacional. Consulte a seguinte seção (Nota), mas também é possível usar um servidor web local existente.

40.5 Desabilitando os serviços systemd #

Para cargas de trabalho de telecomunicações, é importante desabilitar ou configurar apropriadamente alguns dos serviços executados nos nós para evitar qualquer impacto no desempenho das cargas de trabalho em execução nos nós (latência).

rebootmgr é um serviço que permite configurar uma estratégia de reinicialização quando o sistema tem atualizações pendentes. Para cargas de trabalho de telecomunicações, é realmente importante desabilitar ou configurar apropriadamente o serviço rebootmgr para evitar a reinicialização dos nós em caso de atualizações programadas pelo sistema, a fim de evitar qualquer impacto nos serviços executados nos nós.

Nota

Para obter mais informações sobre o rebootmgr, consulte o repositório rebootmgr do GitHub.

Verifique a estratégia usada executando este comando:

cat /etc/rebootmgr.conf
[rebootmgr]
window-start=03:30
window-duration=1h30m
strategy=best-effort
lock-group=default

e você pode desabilitá-la executando:

sed -i 's/strategy=best-effort/strategy=off/g' /etc/rebootmgr.conf

ou usando o comando rebootmgrctl:

rebootmgrctl strategy off

Nota

É possível automatizar essa configuração para definir a estratégia rebootmgr usando o fluxo de trabalho de provisionamento de rede direcionado. Para obter mais informações, consulte a documentação sobre provisionamento automatizado (Capítulo 43, Provisionamento de rede direcionado totalmente automatizado).

transactional-update é um serviço que permite que o sistema controle as atualizações automáticas. Para cargas de trabalho de telecomunicações, é importante desabilitar as atualizações automáticas para evitar qualquer impacto nos serviços executados nos nós.

Para desabilitar as atualizações automáticas, execute:

systemctl --now disable transactional-update.timer
systemctl --now disable transactional-update-cleanup.timer

fstrim é um serviço que permite cortar os sistemas de arquivos automaticamente toda semana. Para cargas de trabalho de telecomunicações, é importante desabilitar o corte automático para evitar qualquer impacto nos serviços executados nos nós.

Para desabilitar o corte automático, execute:

systemctl --now disable fstrim.timer