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

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 usam o BGP (por meio do plug-in CNI do Calico) para formar uma malha completa de nó a nó entre os nós do cluster, permitindo que os pods acessem outros pods dentro do 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.

Observação: "externalTrafficPolicy": "Local" (em inglês) não é compatível com a integração F5 BIG-IP.

Arquitetura de rede

^{Figura: 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 próprio serviço de entrada e dez ou mais IPs para serviços do Kubernetes, como DNS do cluster etc.

VIPs de serviços

N número de endereços IP roteáveis a serem configurados no F5 para entrada L4 quando você expõe um serviço. Esses VIPs são iguais ao valor loadBalancerIP gerado por você para 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ó.

Configuração network

Esses parâmetros são capturados no campo network do arquivo de configuração do cluster.

Veja abaixo um exemplo de um campo network que especifica a maioria dos parâmetros:

# Example of a network section with static node IPs
network:
  clusterip:
    servicecidr: 10.96.232.0/24
    podcidr: 192.168.0.0/16
  nodeip:
    mode: static
    addressblock:
      hostconfig:
        dns: 8.8.8.8
        tod: 192.138.210.214
      blocks:
        - netmask: 255.255.252.0
          gateway: 10.116.232.0
          ips:
            - ip: 10.116.232.23
              hostname: host1.enterprise.net
            - ip: 10.116.232.65
              hostname: host2.enterprise.net
            - ip: 10.116.232.66
              hostname: host3.enterprise.net
  loadbalancer:
    controlplaneip: 10.115.231.45
    ingressip: 10.115.231.54
    kind: F5BigIP
    f5bigip:
      server: 10.113.24.12
      username: # encoded value
      password: # encoded value
      partition: admin-partition

O campo network consiste em três subcampos, clusterip, nodeip e loadbalancer, que definem diferentes configurações de rede para o cluster. O subcampo nodeip.blocks é opcional. Você só precisará especificar esse campo se nodeip.mode estiver definido como estático.

Se os nós estiverem configurados para receber IPs por meio do DHCP, configure o campo network da seguinte maneira:

# Example of a network section using DHCP for node IPs
network:
  clusterip:
    servicecidr: 10.96.232.0/24
    podcidr: 192.168.0.0/16
  nodeip:
    mode: dhcp
  loadbalancer:
    controlplaneip: 10.115.231.45
    ingressip: 10.115.231.54
    kind: F5BigIP
    f5bigip:
      server: 10.113.24.12
      username: admin
      password: secret
      partition: user-partition

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.