Revise os requisitos do sistema para configurar o vSphere with Tanzu em um cluster do vSphere usando a pilha de rede do NSX-T Data Center.
Limites de configuração para vSphere with Tanzu clusters
O VMware fornece limites de configuração na ferramenta VMware Máximos de configuração .
Para limites de configuração específicos para vSphere with Tanzu, incluindo Supervisor Clusters e Tanzu Kubernetes clusters, selecione e clique em View Limits (View Limits), ou siga este link .
Requisitos para um cluster de domínio de gerenciamento, de borda e de carga de trabalho
| Sistema | Tamanho mínimo de implantação | CPU | Memória | Armazenamento |
|---|---|---|---|---|
| vCenter Server 7.0 | Pequeno | 2 | 16 GB | 290 GB |
| ESXi hosts 7.0 | 3 ESXi hosts com 1 IP estático por host. Se você estiver usando o vSAN: 3 hosts ESXi com pelo menos 2 NICs físicas por host é o mínimo. No entanto, 4 hosts ESXi são recomendados para resiliência durante a aplicação de patches e a atualização. Os hosts devem ser unidos em um cluster com o vSphere DRS e HA habilitados. O vSphere DRS deve estar no modo Totalmente Automatizado ou Parcialmente Automatizado. |
8 | 64 GB por host | Não aplicável |
| NSX Manager | Médio | 6 | 24 GB | 300 GB |
| NSX Edge 1 | Grande | 8 | 32 GB | 200 GB |
| NSX Edge 2 | Grande | 8 | 32 GB | 200 GB |
| VMs de plano de controle do Kubernetes | 3 | 4 | 16 GB | 16 GB |
Topologia com gerenciamento separado e cluster de borda e cluster de gerenciamento de carga de trabalho
Você pode implantar o vSphere with Tanzu em dois clusters, um cluster para as funções de gerenciamento e de borda e outro dedicado ao gerenciamento de carga de trabalho.
| Sistema | Tamanho mínimo de implantação | CPU | Memória | Armazenamento |
|---|---|---|---|---|
| vCenter Server 7.0 | Pequeno | 2 | 16 GB | 290 GB |
| ESXi hosts 7.0 | 2 ESXi hosts | 8 | 64 GB por host | Não aplicável |
| NSX Manager | Médio | 6 | 24 GB | 300 GB |
| NSX Edge 1 | Grande | 8 | 32 GB | 200 GB |
| NSX Edge 2 | Grande | 8 | 32 GB | 200 GB |
| Sistema | Tamanho mínimo de implantação | CPU | Memória | Armazenamento |
|---|---|---|---|---|
| ESXi hosts 7.0 | 3 ESXi hosts com 1 IP estático por host. Se você estiver usando o vSAN: 3 ESXi hosts com pelo menos 2 NICs físicas por host é o mínimo; no entanto, 4 hosts ESXi são recomendados para resiliência durante a aplicação de patches e a atualização. Os hosts devem ser unidos em um cluster com o vSphere DRS e HA habilitados. O vSphere DRS deve estar no modo Fully Automated. |
8 | 64 GB por host | Não aplicável |
| VMs de plano de controle do Kubernetes | 3 | 4 | 16 GB | 16 GB |
Requisitos de rede
Independentemente da topologia que você implementa para o gerenciamento de carga de trabalho do Kubernetes no vSphere, sua implantação deve atender aos seguintes requisitos de rede:
| Componente | Quantidade Mínima | Configuração necessária |
|---|---|---|
| IPs estáticos para VMs do plano de controle do Kubernetes | Bloco de 5 | Um bloco de 5 endereços IP estáticos consecutivos a serem atribuídos às VMs do plano de controle do Kubernetes no Supervisor Cluster. |
| Rede de tráfego de gerenciamento | 1 | Uma rede de gerenciamento que é roteável para os hosts ESXi, vCenter Server e um servidor DHCP. A rede deve ser capaz de acessar um registro de contêiner e ter conectividade com a Internet se o registro de contêiner estiver na rede externa. O registro do contêiner deve ser resolvido por meio do DNS, e a configuração de saída descrita abaixo deve ser capaz de alcançá-lo. |
| Servidor NTP e DNS | 1 | Um servidor DNS e um servidor NTP que podem ser usados para o vCenter Server.
Observação: Configure o NTP em todos os hosts ESXi,
vCenter Server sistemas e instâncias do NSX Manager.
|
| Servidor DHCP | 1 | Opcional. Configure um servidor DHCP para adquirir automaticamente endereços IP para o gerenciamento. O servidor DHCP deve oferecer suporte a identificadores de cliente e fornecer servidores DNS compatíveis, domínios de pesquisa DNS e um servidor NTP. |
| Registro de imagem | 1 | Acesso a um registro para o serviço. |
| Sub-rede de gerenciamento | 1 |
A sub-rede usada para o tráfego de gerenciamento entre ESXi hosts e
vCenter Server, NSX Appliances e o plano de controle do Kubernetes. O tamanho da sub-rede deve ser o seguinte:
Observação: A rede de gerenciamento e a rede de carga de trabalho devem estar em sub-redes diferentes. A atribuição da mesma sub-rede às redes de gerenciamento e de carga de trabalho não tem suporte e pode levar a erros e problemas do sistema.
|
| VLAN de rede de gerenciamento | 1 | A ID de VLAN da sub-rede da rede de gerenciamento. |
| VLANs | 3 | Esses IPs de VLAN são os endereços IP para os endpoints de túnel (TEPs). Os TEPs de host ESXi e os TEPs de borda devem ser roteáveis.
Os endereços IP da VLAN são necessários para o seguinte:
Observação: O ESXi Host VTEP e o Edge VTEP devem ter um tamanho de MTU maior que 1600.
ESXi hosts e NSX-T nós Edge atuam como endpoints de túnel, e um IP de ponto final de túnel (TEP) é atribuído a cada host e nó de borda. Como os IPs de TEP para hosts ESXi criam um túnel de sobreposição com IPs de TEP nos nós de borda, os IPs de VLAN devem ser roteáveis. Uma VLAN adicional é necessária para fornecer conectividade Norte-Sul ao gateway de nível 0. Os pools de IPs podem ser compartilhados entre clusters. No entanto, o pool de IPs de sobreposição de host / VLAN não deve ser compartilhado com o pool de IPs de sobreposição de Borda / VLAN.
Observação: Se o TEP do host e o TEP do Edge estiverem usando NICs físicas diferentes, eles poderão usar a mesma VLAN.
|
| IP de uplink de nível 0 | / 24 Endereços IP privados | A sub-rede IP usada para o uplink de Tie-0. Os requisitos para o endereço IP do uplink de nível 0 são os seguintes:
O IP de gerenciamento do Edge, a sub-rede, o gateway, o IP de uplink, a sub-rede e o gateway devem ser exclusivos. |
| Rede física MTU | 1600 | O tamanho da MTU deve ser 1600 ou maior em qualquer rede que transporte tráfego de sobreposição. |
| vSphere Pod Intervalo CIDR | / 23 Endereços IP privados | Um intervalo CIDR privado que fornece endereços IP para vSphere Pods. Esses endereços também são usados para os nós do cluster Tanzu Kubernetes.
Você deve especificar um intervalo de CIDR de
vSphere Pod exclusivo para cada cluster.
Observação: O intervalo CIDR
vSphere Pod e o intervalo CIDR para os endereços de serviço do Kubernetes não devem se sobrepor.
|
| Intervalo CIDR de serviços do Kubernetes | / 16 Endereços IP privados | Um intervalo CIDR privado para atribuir endereços IP aos serviços do Kubernetes. Você deve especificar um intervalo de CIDR de serviços Kubernetes exclusivo para cada Supervisor Cluster. |
| Intervalo de saída do CIDR | / 27 Endereços IP estáticos | Uma anotação CIDR privada para determinar o IP de saída para serviços do Kubernetes. Apenas um endereço IP de saída é atribuído para cada namespace no Supervisor Cluster. O IP de saída é o endereço que as entidades externas usam para se comunicar com os serviços no namespace. O número de endereços IP de saída limita o número de políticas de saída que o Supervisor Cluster pode ter.
O mínimo é um CIDR de / 27 ou mais. Por exemplo,
10.174.4.96/27
Observação: Os endereços IP de saída e os endereços IP de entrada não devem se sobrepor.
|
| CIDR do Ingress | / 27 Endereços IP estáticos | Um intervalo CIDR privado a ser usado para endereços IP de ingressos. O Ingress permite que você aplique políticas de tráfego a solicitações que entram no Supervisor Cluster de redes externas. O número de endereços IP de entrada limita o número de entradas que o cluster pode ter.
O mínimo é um CIDR de / 27 ou mais.
Observação: Os endereços IP de saída e os endereços IP de entrada não devem se sobrepor.
|
