Rede

Os clusters do Anthos no VMware (GKE no local) usam conceitos de rede do Kubernetes, como Service e Ingress. Neste documento, descrevemos como os clusters do Anthos na rede VMware são configurados imediatamente.

Operações de serviços de cluster e modo Ilha

Os clusters do Anthos no VMware usam uma configuração do Modo Island em que os pods podem se comunicar diretamente em um cluster, mas não podem ser acessados de fora do cluster. Essa configuração forma uma "ilha" dentro da rede, que não está conectada à rede externa. Os clusters formam uma malha completa de nó para nó entre os nós de cluster, permitindo que o pod alcance outros pods diretamente no cluster.

Todo o tráfego de saída do pod para destinos fora do cluster é convertido em endereços de rede pelo IP do nó. Os clusters do Anthos no VMware incluem um balanceador de carga L7 com um controlador de entrada baseado no Envoy que manipula as regras de objeto Ingress para serviços ClusterIP implantados no cluster. O próprio controlador de entrada é exposto como um serviço NodePort no cluster.

O serviço NodePort de entrada pode ser acessado por meio de um balanceador de carga L3/L4 F5. A instalação configura um endereço IP virtual (VIP, na sigla em inglês) (nas portas 80 e 443) no balanceador de carga. O VIP aponta para as portas no serviço NodePort do controlador de entrada. Dessa forma, os clientes externos podem acessar serviços no cluster.

Os clusters de usuário podem executar serviços do tipo LoadBalancer, desde que um campo loadBalancerIP esteja configurado na especificação do serviço. No campo loadBalancerIP, você precisa fornecer o VIP que quer usar. Isso é configurado no balanceador de carga, apontando para os NodePorts do serviço.

Os clusters do Anthos no VMware são compatíveis com várias opções de balanceamento de carga:

Balanceamento de carga em pacote com o Seesaw
Balanceamento de carga integrado com a F5 BIG-IP
Balanceamento de carga manual com a F5 BIG-IP
Balanceamento de carga manual com a Citrix

Se você optar por usar o balanceamento de carga manual, não será possível executar serviços do tipo LoadBalancer. Em vez disso, crie serviços do tipo NodePort e configure manualmente seu balanceador de carga para usá-los como back-ends. Além disso, é possível expor serviços a clientes externos usando um objeto de entrada.

Compatibilidade com VMware NSX-T

A partir da versão 1.2.0-gke.6, os clusters do Anthos no VMware são compatíveis com a versão 2.4.2 do VMware NSX-T.

Arquitetura de rede

Diagrama descrevendo os clusters do Anthos na arquitetura do VMware ^{Clusters do Anthos na rede VMware}

Endereços IP de nós: DHCP ou endereços IP atribuídos estaticamente para os nós (também chamados de máquinas virtuais ou VMs). Precisam ser roteáveis no data center. É possível atribuir IPs estáticos manualmente.
Bloco CIDR de pod: Bloco CIDR não roteável para todos os pods no cluster. A partir desse intervalo, intervalos /24 menores são atribuídos por nó. Se você precisar de um cluster com N nós, certifique-se de que esse bloco seja grande o suficiente para permitir N blocos /24.
Bloco CIDR de serviços: No modo Ilha, semelhante ao bloco CIDR de pod. Portanto, ele é usado apenas no cluster. Qualquer bloco de CIDR particular que não se sobreponha aos nós, VIPs ou bloco de CIDR de pod. É possível compartilhar o mesmo bloco entre clusters. O tamanho do bloco determina o número de serviços. Um IP de serviço é necessário para o serviço de entrada e 10 ou mais IPs para serviços do Kubernetes, como DNS de cluster etc.
VIPs de serviços: N endereços IP roteáveis a serem configurados em F5 para entrada L4 quando você expõe um serviço. Esses VIPs são os mesmos que os valores loadBalancerIP que você definiu ao criar serviços do tipo LoadBalancer.

Observação: esses VIPs de serviços podem compartilhar uma sub-rede usada por outros clusters do Anthos ou aplicativos que não sejam do Anthos.
VIP do plano de controle: Um endereço IP roteável a ser configurado no balanceador de carga F5 para o servidor da API Kubernetes.
VIP de entrada: Um endereço IP roteável a ser configurado no balanceador de carga F5, para a entrada L7 em conjunto com os proxies do Envoy em execução em cada nó.

Opções de configuração de rede

Há várias opções para configurar a rede de clusters:

Escolher uma rede global do vCenter ou usar uma rede diferente para clusters de administradores e usuários.
Usar um proxy HTTP e escolher quais endereços quer excluir do proxy.
Escolher a alocação de IP estático ou DHCP.
Escolher o modo de balanceamento de carga: integrado ou manual.

Durante a instalação, especifique as preferências no arquivo de configuração do cluster.

Configurações de rede do vCenter

O campo network da configuração determina qual rede do vCenter (em inglês) será usada para os clusters:

O campo vcenter.network global especifica uma rede.
admincluster.vcenter.network modifica o campo global e especifica a rede a ser usada para o cluster de administrador.
usercluster.vcenter.network modifica o campo global e especifica a rede a ser usada para o cluster de usuário.

Exemplo: acessar um aplicativo da Web por URL

Suponha que você tenha um aplicativo da Web de livro de visitas em execução no cluster como uma implantação chamada frontend. Você quer se conectar ao aplicativo usando um URL, www.guestbook.com. Você precisa de uma maneira de mapear o URL para a implantação em execução no cluster. É possível fazer isso usando um objeto de entrada do Kubernetes.

Para começar, primeiro crie uma entrada DNS curinga para *.guestbook.com que aponte para o VIP de entrada atual do cluster:

*.guestbook.com    A   [INGRESS_VIP]

Em seguida, crie um serviço para a implantação do front-end. A execução de kubectl expose cria um serviço que agrupa logicamente os pods da implantação e fornece a eles um endereço IP comum no cluster:

kubectl expose deployment frontend

Isso cria um serviço do tipo ClusterIP, como este:

apiVersion: v1
kind: Service
metadata:
  labels:
    app: guestbook
  name: frontend
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: guestbook
  type: ClusterIP

É necessário mapear o URL, www.guestbook.com, para o serviço de front-end que acabou de criar. Aplicar a entrada abaixo cria este mapeamento:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: frontend
  labels:
    app: guestbook
  annotations:
    kubernetes.io/ingress.class: istio
spec:
  rules:
    - host: www.guestbook.com
      http:
        paths:
          - backend:
              serviceName: frontend   # name of the frontend Service
              servicePort: 80

Agora, ao acessar o link www.guestbook.com, você abre o aplicativo da Web em seu navegador.

Veja como isso funciona:

Como criou essa entrada DNS curinga, ao acessar o URL, você acessa o VIP de entrada do cluster.
O cluster procura o objeto de Entrada correto com base no nome do host, que, neste caso, é www.guestbook.com.
O tráfego é encaminhado para um pod de front-end.

Exemplo: acessar um aplicativo da Web por um endereço IP

Se o aplicativo não for da Web ou se você tiver restrições de rede, convém criar um VIP especificamente para seu serviço. É possível fazer isso usando um serviço do Kubernetes do tipo LoadBalancer.

O serviço abaixo cria um VIP especificamente para o aplicativo guestbook:

apiVersion: v1
kind: Service
metadata:
  labels:
    app: guestbook
  name: frontend
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: guestbook
  type: LoadBalancer
  loadBalancerIP: [IP_ADDRESS]

Depois de aplicar esse serviço, você verá o VIP no console F5 e, no menu Pools do console, verá os endereços IP dos nós. O acesso ao endereço IP carrega o aplicativo.