Aplica-se a SUSE Telco Cloud 3.7

24 Requisitos de porta #

Para operar corretamente, uma implantação do SUSE Telco Cloud requer que várias portas estejam acessíveis nos nós do cluster de gerenciamento e nos nós do cluster Kubernetes downstream.

Nota

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

24.1 Nós de gerenciamento #

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

Nota

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

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

Protocolo	Portar	Origem	Descrição
TCP	22	Qualquer origem que exija acesso SSH	Acesso SSH aos nós do cluster de gerenciamento
TCP	80	Balanceador de carga/proxy que realiza terminação TLS externa	UI/API do Rancher quando a terminação TLS externa é usada
TCP	443	Qualquer origem que exija acesso TLS à UI/API do Rancher	Agente do Rancher, UI/API do Rancher
TCP	2379	Nós de servidor RKE2 (cluster de gerenciamento)	`etcd` Porta de cliente
TCP	2380	Nós de servidor RKE2 (cluster de gerenciamento)	`etcd` Porta de par
TCP	6180	Qualquer BMC⁽¹⁾ instruído anteriormente pelo `Metal³/ironic` a extrair uma imagem de ramdisk IPA⁽²⁾ desta porta exposta (sem TLS)	`Ironic` Servidor web httpd sem TLS fornecendo imagem ISO IPA⁽²⁾ para inicialização baseada em mídia virtual Caso esta porta esteja habilitada, a funcionalmente equivalente, porém habilitada para TLS (veja abaixo), não é aberta
TCP	6185	Qualquer BMC⁽¹⁾ instruído anteriormente pelo `Metal³/ironic` a extrair uma imagem de ramdisk IPA⁽²⁾ desta porta exposta (com TLS)	`Ironic` Servidor web httpd habilitado para TLS fornecendo imagem ISO IPA⁽²⁾ para inicialização baseada em mídia virtual Caso esta porta esteja habilitada, a funcionalmente equivalente, porém desabilitada para TLS (veja acima), não é aberta
TCP	6385	Qualquer imagem de ramdisk `Metal³/ironic` IPA⁽¹⁾ implantada e em execução em uma instância `BareMetalHost` "inscrita"	API do 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 de um registro compatível com OCI (Hauler)
TCP	9345	Nós de servidor e agente RKE2 (cluster de gerenciamento)	API do supervisor RKE2 para registro de nós (porta aberta em todos os nós de servidor RKE2)
TCP	10250	Qualquer nó do cluster de gerenciamento	`kubelet` métricas
TCP/UDP/SCTP	30000-32767	Qualquer fonte externa (ao cluster de gerenciamento) acessando um serviço exposto na rede primária através de um `spec.type: NodePort` ou `spec.type: LoadBalancer` objeto de API de serviço	`NodePort` Intervalo de porta disponível

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

24.2 Nós downstream #

No SUSE Telco Cloud, antes que qualquer servidor downstream se torne parte de um cluster Kubernetes downstream em execução (ou execute um cluster Kubernetes downstream de nó único), é necessário passar por alguns dos estados de provisionamento BaremetalHost.

O Baseboard Management Controller (BMC) de um servidor downstream recém-declarado deve estar acessível através da rede out-of-band. O BMC é instruído (pelo serviço ironic em execução no cluster de gerenciamento) sobre as etapas iniciais a serem seguidas:
1. Extrair e carregar a imagem de ramdisk IPA indicada no virtual media oferecido pelo BMC.
2. Ligar o servidor.

Espera-se que as seguintes portas sejam expostas pelo BMC (elas podem diferir dependendo do hardware exato):

Tabela 24.2: Regras de rede de entrada para Baseboard Management Controllers #

Protocolo	Portar	Origem	Descrição
TCP	80	Ironic conductor (do cluster de gerenciamento)	Acesso à API Redfish (HTTP)
TCP	443	Ironic conductor (do cluster de gerenciamento)	Acesso à API Redfish (HTTPS)

Assim que a imagem de ramdisk do IPA carregada no BMC virtual media for usada para inicializar a imagem do servidor downstream, a fase de inspeção de hardware começa. A tabela a seguir lista as portas expostas por uma imagem de ramdisk do IPA em execução:

Tabela 24.3: Regras de rede de entrada para nós downstream - Metal³/Ironic fase de provisionamento #

Protocolo	Portar	Origem	Descrição
TCP	22	Qualquer origem que exija acesso SSH à imagem de ramdisk do IPA	Acesso SSH a um nó de cluster downstream sendo inspecionado
TCP	9999	Ironic conductor (do cluster de gerenciamento)	Comandos Ironic para a imagem de ramdisk em execução

Assim que o host baremetal for provisionado corretamente e tiver ingressado em um cluster Kubernetes downstream, ele expõe as seguintes portas:

Nota

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

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

Protocolo	Portar	Origem	Descrição
TCP	22	Qualquer origem que exija acesso SSH	Acesso SSH a nós de cluster downstream
TCP	80	Balanceador de carga/proxy que realiza terminação TLS externa	UI/API do Rancher quando a terminação TLS externa é usada
TCP	443	Qualquer origem que exija acesso TLS à UI/API do Rancher	Agente do Rancher, UI/API do Rancher
TCP	2379	Nós de servidor RKE2 (cluster downstream)	`etcd` Porta de cliente
TCP	2380	Nós de servidor RKE2 (cluster downstream)	`etcd` Porta de par
TCP	6443	Qualquer nó de cluster downstream; qualquer cliente Kubernetes externo (ao cluster downstream).	API Kubernetes
TCP	9345	Nós de servidor e agente RKE2 (cluster downstream)	API do supervisor RKE2 para registro de nós (porta aberta em todos os nós de servidor RKE2)
TCP	10250	Qualquer nó de cluster downstream	`kubelet` métricas
TCP	10255	Qualquer nó de cluster downstream	`kubelet` Acesso somente leitura
TCP/UDP/SCTP	30000-32767	Qualquer origem externa (ao cluster downstream) acessando um serviço exposto na rede primária por meio de um `spec.type: NodePort` ou `spec.type: LoadBalancer` objeto de API de serviço	`NodePort` Intervalo de porta disponível

24.3 Requisitos de porta específicos de CNI #

Cada variante de CNI suportada vem com seu próprio conjunto de requisitos de porta. Para mais detalhes, consulte Regras de rede de entrada específicas de CNI na documentação do RKE2.

Quando o cilium é definido como plug-in CNI padrão/primário, a seguinte porta TCP é adicionalmente exposta quando a carga de trabalho cilium-operator é configurada para expor métricas fora do cluster Kubernetes no qual está implantada. Isso garante que uma instância de servidor Prometheus externa, executada fora desse cluster Kubernetes, ainda possa coletar essas métricas.

Nota

Esta é a opção padrão ao implantar o cilium via gráfico Helm rke2-cilium.

Tabela 24.5: Regras de Rede de Entrada para Nós de Gerenciamento/Downstream - exposição de métricas externas do cilium-operator ativada #

Protocolo	Portar	Origem	Descrição
TCP	9963	Coletor de métricas externo (ao cluster Kubernetes)	exposição de métricas do cilium-operator