Você pode configurar um cluster do Tanzu Kubernetes para usar a rede de pod roteável especificando o antrea-nsx-routed
como o CNI para o seu cluster.
Apresentando a rede de pods roteáveis
O modelo de rede Kubernetes requer que um pod na rede do nó de um cluster seja capaz de se comunicar com todos os pods em todos os nós no mesmo cluster sem conversão de endereço de rede (NAT). Para satisfazer esse requisito, cada pod do Kubernetes recebe um endereço IP que é alocado de uma rede de pods dedicada.
Quando você provisiona um cluster Tanzu Kubernetes usando os plug-ins antrea
ou calico
CNI, o sistema cria a rede de pods padrão 192.168.0.0/16
. Essa sub-rede é um espaço de endereço privado exclusivo dentro do cluster e não roteável na Internet. Embora você possa personalizar o network.pods.cidrBlocks
, a rede de pods não pode ser roteável usando esses plug-ins CNI. Para obter mais informações, consulte Parâmetros de configuração para o provisionamento de clusters Tanzu Kubernetes usando a API do Tanzu Kubernetes Grid Service v1alpha2.
A API do Tanzu Kubernetes Grid Service v1alpha2 oferece suporte à rede de pod roteável usando o plug-in CNI do antrea-nsx-routed
. Essa interface de rede é um plug-in Antrea personalizado configurado para oferecer suporte a redes de pod roteáveis para clusters do Tanzu Kubernetes. Na especificação do cliente, o campo de blocos CIDR dos pods deve ser explicitamente nulo para que o gerenciamento de endereços IP (IPAM) seja manipulado pelo Supervisor Cluster.
- O tráfego é permitido entre um pod de cluster Tanzu Kubernetes e um vSphere Pod no mesmo vSphere Namespace.
- O tráfego é descartado entre um pod de cluster Tanzu Kubernetes e um vSphere Pod em um vSphere Namespaces diferente.
- Os nós do plano de controle do Supervisor Cluster podem alcançar Tanzu Kubernetes pods do cluster.
- Tanzu Kubernetes pods de cluster podem acessar a rede externa.
- A rede externa não pode acessar Tanzu Kubernetes pods de cluster. O tráfego é descartado por regras de isolamento de firewall distribuído (DFW) nos nós do cluster Tanzu Kubernetes.
Requisitos do sistema para pods roteáveis
A rede de pods roteáveis requer que o Supervisor Cluster seja configurado com NSX-T Data Center. Não é possível usar pods roteáveis com a rede nativa do vSphere vDS.
Os pods roteáveis exigem a API do Tanzu Kubernetes Grid Service v1alpha2. Consulte o Requisitos para usar a API do Tanzu Kubernetes Grid Service v1alpha2.
NSX-T Requisitos de configuração para pods roteáveis
Além dos requisitos básicos, não há nenhuma configuração especial de NSX-T necessária para usar redes de pods roteáveis com clusters Tanzu Kubernetes. Um ambiente do vSphere with Tanzu executando o vSphere U3 com o NSX-T inclui a versão do NCP para oferecer suporte a redes de pods roteáveis. Não há nenhuma configuração extra de NSX-T necessária.
- Se a rede de carga de trabalho estiver configurada com uma rede de namespaces, o NCP criará um ou mais pools de IP a partir dos blocos de IPs especificados para essa rede de namespaces.
- Se não houver uma rede de namespaces especificada para a rede de carga de trabalho, o NCP criará um ou mais pools de IPs do CIDR do pod do Supervisor Cluster.
Supervisor Cluster Requisitos de configuração para pods roteáveis
Além dos requisitos básicos, não há nenhuma configuração especial de Supervisor Cluster necessária para usar redes de pods roteáveis com clusters Tanzu Kubernetes.
Se a rede de pods roteáveis estiver ativada conforme descrito abaixo, o CIDR de pods do Tanzu Kubernetes cluster será alocado do pool de IPs criado na Rede de Namespaces ou, se não houver, no CIDR do Pod Supervisor Cluster.
Você deve certificar-se de que o CIDR de serviços de Supervisor Cluster que aloca os endereços IP para nós do cluster não se sobreponha ao CIDR de Rede de Namespace ou ao CIDR de Pod do Supervisor Cluster.
Exemplo de configuração de cluster para pods roteáveis
O exemplo de YAML a seguir mostra como configurar um cluster com uma rede de pods roteáveis. é uma configuração personalizada para invocar o Tanzu Kubernetes Grid Service e provisionar um cluster Tanzu Kubernetes usando a API v1alpha2.
A especificação do cluster declara antrea-nsx-routed
como o CNI para habilitar a rede de pods roteáveis. Quando o CNI é antrea-nsx-routed
é especificado, o campo pods.cidrBlock
deve estar vazio. Se antrea-nsx-routed
for especificado, o provisionamento de cluster falhará se a rede NSX-T não estiver sendo usada.
apiVersion: run.tanzu.vmware.com/v1alpha2 kind: TanzuKubernetesCluster metadata: name: tkgs-v2-cluster-routable-pods namespace: tkgs-cluster-ns spec: topology: controlPlane: replicas: 3 vmClass: guaranteed-medium storageClass: vwt-storage-policy tkr: reference: name: v1.21.2---vmware.1-tkg.1.ee25d55 nodePools: - name: worker-nodepool-a1 replicas: 3 vmClass: guaranteed-large storageClass: vwt-storage-policy tkr: reference: name: v1.21.2---vmware.1-tkg.1.ee25d55 settings: storage: defaultClass: vwt-storage-policy network: #`antrea-nsx-routed` is the required CNI #for routable pods cni: name: antrea-nsx-routed services: cidrBlocks: ["10.97.0.0/24"] serviceDomain: tanzukubernetescluster.local #`pods.cidrBlocks` value must be empty #when `antrea-nsx-routed` is the CNI pods: cidrBlocks: