Versão 1.3. Esta versão não é mais compatível, conforme descrito na Política de suporte da versão do Anthos. Para ver os patches e as atualizações mais recentes sobre vulnerabilidades de segurança, exposições e problemas que afetam os clusters do Anthos no VMware (GKE On-Prem), faça o upgrade para uma versão compatível. Você pode encontrar a versão mais recente neste link.

Versões disponíveis

Rede

O GKE On-Prem usa conceitos de rede do Kubernetes, como Serviço e Entrada. Neste documento, descrevemos como a rede do GKE On-Prem é configurada pronta para uso.

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

O GKE On-Prem usa uma configuração de modo Ilha, em que os pods podem se comunicar diretamente dentro de um cluster, mas não podem ser acessados de fora dele. 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ó. O GKE On-Prem inclui um balanceador de carga L7 com um controlador de entrada baseado em Envoy que processa regras de objeto de entrada 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. Ele será configurado em F5, apontando para os NodePorts do serviço.

Como alternativa ao uso do balanceador de carga F5, é possível ativar o modo de balanceamento de carga manual. 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, o GKE On-Prem é compatível com o VMware NSX-T versão 2.4.2 (link em inglês).

Arquitetura de rede

Diagrama que descreve a arquitetura do GKE On-Prem ^{Rede do GKE On-Prem}

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.
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 suas preferências no arquivo de configuração do GKE On-Prem.

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
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.

Como conectar-se ao Google