Balanceamento de carga em pacote com o Seesaw

10

Version 1.10 

• Version 1.28 (latest)
• Version 1.16
• Version 1.15
• Earlier versions (unsupported)

Os clusters do Anthos no VMware (GKE no local) podem ser executados em um dos três modos de balanceamento de carga: integrado, manual ou pacote. Neste documento, mostramos como configurar clusters do Anthos no VMware para executar o balanceador de carga Seesaw (em inglês) no modo em pacote.

As instruções aqui são completas. Para uma introdução mais rápida ao uso do balanceador de carga da Seesaw, consulte Balanceador de carga da Seedaw (guia de início rápido).

No modo de balanceamento de carga agrupado, os clusters do Anthos no VMware fornecem e gerenciam o balanceador de carga. Não é necessário ter uma licença de balanceador de carga e a configuração que você precisa fazer é mínima.

Neste documento, mostramos como configurar o balanceador de carga Seesaw para um cluster de administrador e um cluster de usuário associado. É possível executar o balanceador de carga do Seesaw em uma única VM ou executar o balanceador de carga no modo de alta disponibilidade (HA, na sigla em inglês), que usa duas VMs. No modo de alta disponibilidade, o balanceador de carga do Seesaw usa o Protocolo de redundância de roteador virtual (VRRP). As duas VMs são chamadas de Mestre e Backup. Cada VM do Seesaw recebe um identificador de roteador virtual (VRID, na sigla em inglês) de sua escolha.

Exemplo de uma configuração do Seesaw

Veja um exemplo de configuração para clusters que executam o balanceador de carga Seesaw no modo de alta disponibilidade:

Configuração do balanceador de carga Seesaw no modo de alta disponibilidade (clique para ampliar)

O diagrama anterior mostra duas VMs do Seesaw para o cluster de administrador e o cluster de usuário. Neste exemplo, o cluster de administrador e o cluster de usuário estão em duas VLANs separadas, e cada cluster está em uma sub-rede separada:

Cluster	Sub-rede
Cluster de administrador	172.16.20.0/24
Cluster de usuário	172.16.40.0/24

admin-cluster.yaml

O seguinte exemplo de um arquivo de configuração do cluster de administrador mostra a configuração vista no diagrama anterior de:

• O endereço IP mestre do par de VMs do Seesaw que atende o cluster de administrador.

• VIPs designados para o servidor da API Kubernetes e complementos do cluster de administrador.

network:
  hostConfig:
  ...

  ipMode:
    type: "static"
    ipBlockFilePath: "config-folder/admin-cluster-ipblock.yaml"
...

loadBalancer:
  seesaw:
    ipBlockFilePath: "config-folder/admin-seesaw-ipblock.yaml"
    masterIP: 172.16.20.57
  ...

  vips:
    controlPlaneVIP: "172.16.20.70"
    addonsVIP: "172.16.20.71"

admin-cluster-ipblock.yaml

O exemplo a seguir de um arquivo de bloco de IP mostra a designação de endereços IP para os nós no cluster de administrador. Isso também inclui o endereço do nó do plano de controle do cluster de usuário e um endereço IP a ser usado durante o upgrade do cluster.

blocks:
- netmask: "255.255.255.0"
  gateway: "17.16.20.1"
  ips:
  - ip: 172.16.20.50
    hostname: admin-vm-1
  - ip: 172.16.20.51
    hostname: admin-vm-2
  - ip: 172.16.20.52
    hostname: admin-vm-3
  - ip: 172.16.20.53
    hostname: admin-vm-4
  - ip: 172.16.20.54
    hostname: admin-vm-5

admin-seesaw-ipblock.yaml

O exemplo a seguir de outro arquivo de bloco de IPs especifica dois endereços IP para as VMs do Seesaw que atendem o cluster de administrador. Esse é um arquivo de bloco de IP separado para VMs do balanceador de carga, não nós de cluster.

blocks:
  - netmask: "255.255.255.0"
    gateway: "172.16.20.1"
    ips:
    - ip: "172.16.20.60"
      hostname: "admin-seesaw-vm-1"
    - ip: "172.16.20.61"
      hostname: "admin-seesaw-vm-2"

user-cluster.yaml

O seguinte exemplo de um arquivo de configuração do cluster de usuário mostra a configuração de:

• O endereço IP mestre do par de VMs do Seesaw que atende o cluster de usuário.

• VIPs designados para o servidor da API Kubernetes e o serviço de entrada no cluster de usuário. O VIP do servidor da API Kubernetes está na sub-rede do cluster de administrador porque o plano de controle de um cluster de usuário é executado em um nó no cluster de administrador.

network:
  hostConfig:
  ...

  ipMode:
    type: "static"
    ipBlockFilePath: "config-folder/user-cluster-ipblock.yaml"
...

loadBalancer:
  seesaw:
    ipBlockFilePath: "config-folder/user-seesaw-ipblock.yaml"
    masterIP: 172.16.40.31
  ...

  vips:
    controlPlaneVIP: "172.16.20.72"
    ingressVIP: "172.16.40.100"

user-cluster-ipblock.yaml

O exemplo a seguir de um arquivo de bloco de IP mostra a designação de endereços IP para os nós no cluster de usuário. Isso inclui um endereço IP a ser usado durante o upgrade do cluster.

blocks:
- netmask: "255.255.255.0"
  gateway: "17.16.40.1"
  ips:
  - ip: 172.16.40.21
    hostname: user-vm-1
  - ip: 172.16.40.22
    hostname: user-vm-2
  - ip: 172.16.40.23
    hostname: user-vm-3
  - ip: 172.16.40.24
    hostname: user-vm-4
  - ip: 172.16.40.25
    hostname: user-vm-5

user-seesaw-ipblock.yaml

O exemplo a seguir de outro arquivo de bloco de IPs especifica dois endereços IP para as VMs do Seesaw que atendem o cluster de usuário.

blocks:
  - netmask: "255.255.255.0"
    gateway: "172.16.40.1"
    ips:
    - ip: "172.16.40.29"
      hostname: "user-seesaw-vm-1"
    - ip: "172.16.40.30"
      hostname: "user-seesaw-vm-2"

Grupos de portas

A tabela a seguir descreve a configuração das interfaces de rede para cada uma das VMs do Seesaw e seus grupos de portas conectadas, conforme mostrado no diagrama anterior.

VMs do Seesaw	Interface de rede	Configuração de interface de rede	Grupo de portas conectadas
mestre	network-interface-1	VIPs	load-balancer
	network-interface-2	Endereço IP retirado do arquivo de bloco de IPs para VMs do Seesaw	cluster-node
Backup	network-interface-1	Nenhuma configuração	load-balancer
	network-interface-2	Endereço IP retirado do arquivo de bloco de IPs para VMs do Seesaw	cluster-node

Os nós do cluster também são conectados ao grupo de portas cluster-node.

Conforme mostrado na tabela anterior, cada uma das VMs do Seesaw para os clusters de administrador e de usuário tem duas interfaces de rede. Para cada VM do Seesaw, as duas interfaces de rede são conectadas a dois grupos de portas separados:

• Grupo de portas load-balancer

• Grupo de portas cluster-node

Os dois grupos de portas de um cluster estão na mesma VLAN desse cluster.

Configurar o balanceador de carga Seesaw

Versões recomendadas

O diagrama anterior mostra a configuração de rede recomendada para o balanceamento de carga do Seesaw. Ao planejar sua configuração, recomendamos que você use o vSphere 6.7 ou mais recente e o Virtual Distributed Switch (VDS) 6.6 ou mais recente para o modo de balanceamento de carga em pacote.

Se preferir, use versões anteriores, mas a instalação será menos segura. Nas seções restantes deste tópico, fornecemos mais detalhes sobre as vantagens de segurança do uso do vSphere 6.7 e posteriores e do VDS 6.6 e posteriores.

Planejar suas VLANs

Com o modo de balanceamento de carga em pacote, recomendamos que você tenha seus clusters em VLANs separadas.

Se o cluster de administrador estiver na própria VLAN, o tráfego do plano de controle será separado do tráfego do plano de dados. Essa separação protege os planos de controle do cluster de administrador e de usuário contra erros de configuração inadvertidos. Por exemplo, esses erros podem causar problemas como uma tempestade de transmissão causada por loops da camada 2 na mesma VLAN ou um endereço IP conflitante que elimine a separação desejada entre o plano de dados e o plano de controle.

Provisionar recursos de VM

Para as VMs que executam o balanceador de carga Seesaw, provisione recursos de CPU e memória de acordo com o tráfego de rede que você espera encontrar.

O balanceador de carga Seesaw não consome muita memória e pode ser executado em VMs com 1 GB de memória. No entanto, o requisito da CPU aumenta à medida que a taxa de pacotes de rede aumenta.

A tabela a seguir mostra as diretrizes de armazenamento, CPU e memória para provisionar VMs do Seesaw. Como a taxa de pacotes não é uma medida comum de desempenho de rede, mostramos também na tabela as diretrizes do número máximo de conexões de rede ativas. As diretrizes também presumem que será usado um ambiente em que as VMs tenham um link de 10 Gbps e as CPUs sejam executadas com menos de 70% de capacidade.

Quando o balanceador de carga Seesaw é executado no modo de alta disponibilidade, ele usa um par de mestre(backup),. Assim, todo o tráfego flui por uma única VM. Como os casos de uso reais variam, essas diretrizes precisam ser modificadas com base no tráfego real. Monitore as métricas de CPU e de taxa de pacotes para determinar as alterações necessárias.

Se você precisar alterar a CPU e a memória das VMs do Seesaw, consulte Como fazer upgrade de um balanceador de carga. É possível manter a mesma versão do balanceador de carga e alterar apenas o número de CPUs e de alocação de memória.

Para clusters de administração pequenos, recomendamos duas CPUs e, para clusters de administração grandes, recomendamos quatro CPUs.

Armazenamento	CPU	Memória	Taxa de pacotes (pps)	Máximo de conexões ativas
20 GB	1 (não produção)	1 GB	250 mil	100
20 GB	2	3 GB	450 mil	300
20 GB	4	3 GB	850 mil	6.000
20 GB	6	3 GB	1.000.000	10.000

Reservar VIPs e endereços IP

VIPs

Independentemente da sua escolha de modo de balanceamento de carga, você precisa separar vários endereços IP virtuais (VIPs, na sigla em inglês) que pretende usar para balanceamento de carga. Esses VIPs permitem que clientes externos alcancem os servidores da API Kubernetes, os serviços de entrada e os serviços complementares.

Considere também a quantidade de Serviços do tipo LoadBalancer que provavelmente estarão ativos no cluster de usuário em um determinado momento e reserve VIPs suficientes para esses Serviços. À medida que você criar Serviços do tipo LoadBalancer mais tarde, os clusters do Anthos no VMware configurarão automaticamente os VIPs de Serviço no balanceador de carga.

Endereços IP de nós

Com o modo de balanceamento de carga em pacote, é possível especificar endereços IP estáticos para os nós de cluster ou que os nós de cluster recebam endereços IP de um servidor DHCP.

Se quiser que os nós de cluster tenham endereços IP estáticos, reserve endereços suficientes para os nós no cluster de administrador e os nós em todos os clusters de usuário que você pretende criar. Além disso, reserve um endereço IP extra para cada cluster usar durante seu upgrade. Para detalhes sobre quantos endereços IP de nó precisam ser reservados, consulte Como criar um cluster de administrador.

Endereços IP para VMs do Seesaw

Em seguida, para cada cluster, administrador e usuário, reserve endereços IP para as VMs que executarão os balanceadores de carga Seesaw. O número de endereços que você reserva depende dos balanceadores de carga a serem criados, Seesaw altamente disponíveis ou não.

Endereços IP mestre

Além dos endereços IP das VMs do Seesaw, reserve também um único endereço IP mestre para o par de VMs do Seesaw para cada cluster.

Configuração sem alta disponibilidade

Se sua configuração for uma sem alta disponibilidade:

• Para o cluster de administrador, reserve um endereço IP para uma VM do Seesaw e um endereço IP mestre para o balanceador de carga Seesaw. Os dois endereços precisam estar na mesma VLAN dos nós de cluster de administrador.

• Para o cluster de usuário, reserve um endereço IP para uma VM do Seesaw e um endereço IP mestre para o balanceador de carga Seesaw. Os dois endereços precisam estar na mesma VLAN que os nós de cluster de usuário.

Planejar os grupos de portas

O diagrama anterior descreveu os dois grupos de portas usados em uma configuração de alta disponibilidade e como eles são conectados às interfaces de rede nas VMs do Seesaw. Para uma VM do Seesaw individual, decida se quer que as duas interfaces de rede sejam conectadas ao mesmo grupo de portas do vSphere ou a grupos de portas separados. Se os grupos de portas estiverem separados, eles precisarão estar na mesma VLAN. Recomendamos que você tenha dois grupos de portas separados.

Criar arquivos de bloco de IP

Para cada cluster, administrador e usuário, especifique os endereços escolhidos para as VMs do Seesaw em um arquivo de bloco de IPs. Se você pretende usar endereços IP estáticos para os nós de cluster, crie arquivos de bloco de IPs separados para eles.

Preencher os arquivos de configuração

Prepare um arquivo de configuração para o cluster de administrador e outro arquivo de configuração para o cluster de usuário.

No arquivo de configuração de um determinado cluster, defina loadBalancer.kind como "Seesaw".

Em loadBalancer, preencha a seção seesaw:

loadBalancer:
  kind: Seesaw
  seesaw:

Para informações sobre como preencher a seção seesaw de um arquivo de configuração de cluster, consulte loadbalancer.seesaw (cluster de administrador) ou loadbalancer.seesaw (cluster de usuário)

No arquivo de configuração do cluster de administrador, atribua:

• VIP para o servidor da API Kubernetes do cluster de administrador
• VIPs para os complementos do cluster de administrador;
• Endereço IP mestre para o par de VMs do Seesaw que atende o cluster de administrador.

Esses VIPs precisam estar na sub-rede do cluster de administrador.

No arquivo de configuração do cluster de usuário, atribua:

• VIP para o servidor da API Kubernetes do cluster de usuário (precisa estar na sub-rede do cluster de administrador);
• VIP de entrada no cluster de usuário;
• Endereço IP mestre para o par de VMs do Seesaw que atende o cluster de usuário.

Os últimos dois endereços na lista anterior precisam estar na sub-rede do cluster de usuário.

Ativar o aprendizado MAC ou o modo promíscuo (somente alta disponibilidade)

Se você estiver configurando um balanceador de carga que não seja altamente disponível, ignore esta seção.

Se você definiu loadBalancer.seesaw.disableVRRPMAC como verdadeiro, pule esta seção.

Se você estiver configurando um balanceador de carga HA Seeaw e tiver definido loadBalancer.seesaw.disableVRRPMAC como false, será necessário ativar alguma combinação de aprendizado MAC, transmissões forjadas e modo de composição em seu balanceador de carga grupo de portas.

A forma como você ativa esses recursos varia de acordo com o tipo de switch:

Tipo de switch	Como ativar recursos	Impacto na segurança
vSphere 7.0 VDS	Para o vSphere 7.0 com HA, é necessário definir loadBalancer.seesaw.disableVRRPMAC como true. O aprendizado MAC não é compatível.
vSphere 6.7 com VDS 6.6	Ative o aprendizado por MAC e as transmissões forjadas do balanceador de carga executando este comando: gkectl prepare network --config [CONFIG_FILE], em que [CONFIG_FILE] é o caminho do arquivo de configuração do cluster. Você precisa da permissão dvPort group.Modify (em inglês) para fazer isso.	Mínima. Se o grupo de portas do balanceador de carga estiver conectado apenas às VMs do Seesaw, será possível limitar o aprendizado MAC às VMs confiáveis do Seesaw.
vSphere 6.5 ou vSphere 6.7 com uma versão do VDS anterior à 6.6	Ative o modo promíscuo e as transmissões forjadas para o grupo de portas do balanceador de carga. Use a interface do usuário do vSphere na página do grupo de portas na guia Networking: Edit Settings -> Security.	Todas as VMs no seu grupo de portas do balanceador de carga estão no modo promíscuo. Portanto, qualquer VM no seu grupo de portas do balanceador de carga pode ver todo o tráfego. Se o grupo de portas do balanceador de carga estiver conectado apenas às VMs do Seesaw, apenas essas VMs poderão ver todo o tráfego.
Switch lógico NSX-T	Ative o aprendizado MAC no switch lógico.	O vSphere não é compatível com a criação de dois switches lógicos no mesmo domínio da camada 2. Portanto, as VMs do Seesaw e os nós de cluster precisam estar no mesmo switch lógico. Isso significa que o aprendizado MAC está ativado para todos os nós de cluster. Um invasor pode atingir um spoofing de MAC executando pods privilegiados no cluster.
Switch vSphere padrão	Ative o modo promíscuo e as transmissões forjadas para o grupo de portas do balanceador de carga. Use a interface do usuário do vSphere em cada host ESXI: Configure -> Virtual switches -> Standard Switch -> Edit Setting on the port group -> Security.	Todas as VMs no seu grupo de portas do balanceador de carga estão no modo promíscuo. Portanto, qualquer VM no seu grupo de portas do balanceador de carga pode ver todo o tráfego. Se o grupo de portas do balanceador de carga estiver conectado apenas às VMs do Seesaw, apenas essas VMs poderão ver todo o tráfego.

Concluir o preenchimento do arquivo de configuração do cluster de administrador

Siga as instruções em Criar um cluster de administrador para concluir o preenchimento do arquivo de configuração do cluster de administrador.

Executar verificações de simulação

Execute verificações de simulação no arquivo de configuração do cluster de administrador:

gkectl check-config --config ADMIN_CLUSTER_CONFIG

Substitua ADMIN_CLUSTER_CONFIG pelo caminho do arquivo de configuração do cluster de administrador.

Faça upload de imagens do SO

Faça upload de imagens do SO para seu ambiente do vSphere:

gkectl prepare --config ADMIN_CLUSTER_CONFIG

Criar um balanceador de carga para o cluster de administrador

gkectl create loadbalancer --config [ADMIN_CLUSTER_CONFIG]

Crie seu cluster de administrador

Siga as instruções em Criar um cluster de administrador para criar seu cluster de administrador.

Concluir o preenchimento dos arquivos de configuração do cluster de usuário

Siga as instruções em Criar um cluster de usuário para concluir o preenchimento do arquivo de configuração de cluster de usuário.

Executar verificações de simulação

Execute verificações de simulação no arquivo de configuração do cluster de usuário:

gkectl check-config --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Substitua:

• ADMIN_CLUSTERE_KUBECONFIG: o caminho do arquivo kubeconfig do cluster de administrador;

• USER_CLUSTER_CONFIG: o caminho do arquivo de configuração do cluster de usuário.

Faça upload de imagens do SO

Faça upload de imagens do SO para seu ambiente do vSphere:

gkectl prepare --config USER_CLUSTER_CONFIG

Criar um balanceador de carga para o cluster de usuários

Criar um balanceador de carga para o cluster de usuários:

gkectl create loadbalancer --config USER_CLUSTER_CONFIG

Crie o cluster de usuário

Siga as instruções em Criar um cluster de usuários para criar seu cluster de usuário.

Teste de desempenho e carga

A capacidade de download do aplicativo é escalonada linearmente com o número de back-ends. Isso ocorre porque os back-ends enviam respostas diretamente aos clientes usando o Direct Server Return, ignorando o balanceador de carga.

Por outro lado, a capacidade de upload do aplicativo é limitada pela capacidade da VM do Seesaw que realiza o balanceamento de carga.

Os aplicativos variam na quantidade de CPU e memória que exigem. Por isso, é importante fazer um teste de carga antes de começar a atender a um grande número de clientes.

O teste indica que uma VM do Seesaw com 6 CPUs e 3 GB de memória pode manipular 10 GB/s (taxa de linha) de tráfego de upload com 10 mil conexões TCP simultâneas. No entanto, é importante executar seu próprio teste de carga se você planeja aceitar um grande número de conexões TCP simultâneas.

Limites de escalonamento

Com o balanceamento de carga em pacote, há limites para o volume de escalonamento do cluster. Há um limite para o número de nós no cluster e para o número de serviços que podem ser configurados no balanceador de carga. Há também um limite para verificações de integridade. O número de verificações de integridade depende do número de nós e do número de serviços.

A partir da versão 1.3.1, o número de verificações de integridade depende do número de nós e do número de serviços locais de tráfego. Um serviço local de tráfego é um serviço que tem o externalTrafficPolicy definido como "Local".

	Versão 1.3.0	Versão 1.3.1 e mais recentes
Máximo de serviços (S)	100	500
Máximo de nós (N)	100	100
Máximo de verificações de integridade	S * N <= 10 mil	N + L * N <= 10 mil, em que L é o número de serviços locais de tráfego

Exemplo: na versão 1.3.1, suponha que você tenha 100 nós e 99 serviços locais de tráfego. Então, o número de verificações de integridade é 100 + 99 * 100 = 10.000, o que está dentro do limite de 10 mil.

Fazer upgrade do balanceador de carga para um cluster

Quando você faz upgrade de um cluster, o balanceador de carga é atualizado automaticamente. Não é necessário executar um comando separado para fazer upgrade do balanceador de carga.

Se quiser, atualize as CPUs ou a memória das VMs do Seesaw sem fazer um upgrade completo. Primeiro, edite os valores cpus e memoryMB no arquivo de configuração do cluster. Exemplo:

apiVersion: v1
bundlePath:
loadBalancer:
  kind: Seesaw
  seesaw:
    cpus: 3
    memoryMB: 3072

Em seguida, para atualizar o balanceador de carga para um cluster de administrador:

gkectl upgrade loadbalancer --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config ADMIN_CLUSTER_CONFIG --admin-cluster

Para atualizar o balanceador de carga para um cluster de usuário:

gkectl upgrade loadbalancer --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG

Substitua:

• ADMIN_CLUSTER_KUBECONFIG: o caminho do arquivo kubeconfig do cluster de administrador;

• ADMIN_CLUSTER_CONFIG: o caminho do arquivo de configuração do cluster de administrador.

• USER_CLUSTER_CONFIG: o caminho do arquivo de configuração do cluster de usuário.

Ver registros do Seesaw

O balanceador de carga em pacote Seesaw armazena arquivos de registro nas VMs do Seesaw em /var/log/seesaw/. O arquivo de registro mais importante é seesaw_engine.INFO.

A partir da v1.6, se o Stackdriver estiver ativado, os registros também serão enviados para o Cloud. É possível vê-los no recurso "anthos_l4lb". Para desativar o upload de registros, use ssh na VM e execute:

sudo systemctl disable --now docker.fluent-bit.service

Ver informações sobre as VMs do Seesaw

É possível receber informações sobre as VMs do Seesaw de um cluster pelo recurso personalizado SeesawGroup.

Visualize o recurso personalizado SeesawGroup de um cluster:

kubectl --kubeconfig CLUSTER_KUBECONFIG get seesawgroups -n kube-system -o yaml

Substitua CLUSTER_KUBECONFIG pelo caminho do arquivo kubeconfig do cluster.

A saída tem um campo isReady que mostra se as VMs estão prontas para manipular tráfego. A saída também mostra os nomes e endereços IP das VMs do Seesaw e a VM principal:

apiVersion: seesaw.gke.io/v1alpha1
kind: SeesawGroup
metadata:
  ...
  name: seesaw-for-cluster-1
  namespace: kube-system
  ...
spec: {}
status:
  machines:
  - hostname: cluster-1-seesaw-1
    ip: 172.16.20.18
    isReady: true
    lastCheckTime: "2020-02-25T00:47:37Z"
    role: Master
  - hostname: cluster-1-seesaw-2
    ip: 172.16.20.19
    isReady: true
    lastCheckTime: "2020-02-25T00:47:37Z"
    role: Backup

Ver métricas do Seesaw

O balanceador de carga em pacote Seesaw oferece as seguintes métricas:

• Capacidade por serviço ou nó
• Taxa de pacotes por serviço ou nó
• Conexões ativas por serviço ou nó
• Uso de CPU e memória
• Número de pods de back-end íntegros por serviço
• VM principal e de backup
• Tempo de atividade

A partir da v1.6, essas métricas são enviadas para o Cloud com o Stackdriver. É possível visualizá-los no recurso de monitoramento do "anthos_l4lb".

Use qualquer solução de monitoramento e painel de sua escolha, desde que seja compatível com o formato do Prometheus.

Excluir um balanceador de carga

Se você excluir um cluster que usa balanceamento de carga em pacote, exclua as VMs do Seesaw desse cluster. É possível fazer isso excluindo as VMs do Seesaw na interface do usuário do vSphere.

Como alternativa, execute gkectl delete loadbalancer.

Para um cluster de administrador:

gkectl delete loadbalancer --config ADMIN_CLUSTER_CONFIG --seesaw-group-file GROUP_FILE

Para um cluster de usuário:

gkectl delete loadbalancer  --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG \
    --seesaw-group-file GROUP_FILE

Substitua:

• ADMIN_CLUSTER_CONFIG: é o caminho do arquivo de configuração do cluster de administrador

• USER_CLUSTER_CONFIG: é o caminho do arquivo de configuração do cluster de usuário

• ADMIN_CLUSTER_KUBECONFIG: o caminho do arquivo kubeconfig do cluster de administrador

• GROUP_FILE: o caminho do arquivo de grupo do Seesaw. O nome do arquivo de grupo tem o formato
  seesaw-for-CLUSTER_NAME-IDENTIFIER.yaml.
  Por exemplo: seesaw-for-gke-admin-12345.yaml.

Como configurar políticas de firewall distribuídas NSX-T sem estado para uso com o balanceador de carga Seesaw

Se sua configuração usar o firewall distribuído NSX-T com estado e você também quiser usar o balanceador de carga Seesaw, você terá várias opções. Escolha a opção mais adequada ao seu ambiente.

Observação: as instruções fornecidas aqui se referem ao NSX-T 3.1. Se você estiver executando uma versão mais antiga do NSX, as opções de menu poderão ser um pouco diferentes.

Observação: mesmo que não haja políticas de firewall distribuído ativadas, se o firewall distribuído não estiver explicitamente desativado, será necessário seguir uma das opções de configuração a seguir.

Lista de verificação de configuração de NSX

Antes de implementar uma das opções de correção descritas, verifique se você tem a seguinte configuração de NSX DFW:

• As seções de NSX DFW com estado são a configuração padrão. Isso provavelmente é o que você tem no ambiente. Consulte Seções e regras de firewall do firewall.

• Em alguns casos, a inserção de serviços é usada com o NSX DFW para fornecer cadeia de serviço e inspeção L7 como parte da integração do parceiro. Por padrão, as políticas de inserção de serviços também têm estado. Para confirmar se essa integração está ativada no seu ambiente, leia as seguintes informações.

Opção 1: criar uma política de firewall distribuída sem estado para os balanceadores de carga do Seesaw

Com essa opção, é possível manter o firewall distribuído ativado no ambiente ao mapear a infraestrutura do Anthos, especificamente os balanceadores de carga Seesaw, para uma Política sem estado. Considere as diferenças entre firewalls sem estado e com estado. Certifique-se de escolher o tipo mais adequado ao seu ambiente. Consulte Adicionar uma seção de regras de firewall no modo gerente - Procedimento – Etapa 6 da documentação do VMware.

Para criar uma política de firewall sem estado:

1. Acesse Inventário > Tags. Crie uma tag chamada seesaw.

2. Acesse Inventário > Grupos. Crie um grupo chamado Seesaw.

3. Configure os membros do conjunto do Seesaw.

   • Clique em Definir participantes. Configure membros do conjunto com critérios de associação com base na tag seesaw que você criou. Embora o uso de tags NSX geralmente seja uma prática recomendada pela VMware, essa metodologia requer automação para defini-las sempre que o ambiente for alterado, como ao fazer upgrade ou redimensionar os clusters do Anthos no ambiente. Nesse caso, uma política com base em outros critérios de associação pode funcionar melhor. Use outras opções de associação dinâmicas, como nomes das VMs (incluindo expressões regulares), segmentos e portas de segmento. Para mais informações sobre os critérios de associação a grupos, consulte Adicionar um grupo.

4. Navegue até Segurança > Firewall distribuído. Crie uma seção chamada Anthos.

5. Clique no ícone de engrenagem no canto superior direito e alterne a chave Com estado para Não.

   Observação: uma política sem estado não pode ser alterada com estado após a criação dela.

6. Adicione regras à seção. É recomendável adicionar pelo menos duas regras simétricas, como as seguintes:

   Source: Seesaw Group, Destination: Any, Applied to: Seesaw Group
   Source: Any, Destination: Seesaw Group, Applied to: Seesaw Group
   

7. Publique as alterações e verifique as operações.

A seção sem estado precisa ser colocada na tabela NSX DFW para ter precedência sobre outras seções que podem permitir o mesmo tráfego com estado, mascarando as regras sem estado. Certifique-se de que a seção sem estado seja a mais específica e que preceda outras políticas que poderiam criar uma sobreposição.

Embora não seja obrigatório, é possível criar um grupo que inclua todas as VMs do Anthos usando um critério de associação de alta granularidade, como a tag de segmento, o que significa que todas as VMs conectadas a uma rede NSX específica estão incluídas no grupo. Em seguida, use esse grupo na sua política sem estado.

Aviso: se você estiver usando a inserção de serviço de NSX, é provável que as regras de redirecionamento estejam dentro de uma política com estado. Nesse caso, crie uma nova política sem estado e garanta o redirecionamento para os balanceadores de carga do Anthos Seesaw.

Opção 2: adicionar as VMs do Seesaw à lista de exclusão de firewall distribuída

Com essa opção, é possível excluir totalmente as VMs da inspeção distribuída de firewall sem desativar a NSX DFW. Consulte Gerenciar uma lista de exclusão de firewalls.

1. Navegue até Segurança > Firewall distribuído. Selecione Ações > Lista de exclusão.

2. Escolha o grupo do Seesaw ou o grupo que inclui todas as VMs do Anthos.

Solução de problemas

Conseguir uma conexão SSH com uma VM do Seesaw

De vez em quando, será conveniente usar SSH em uma VM do Seesaw para solucionar problemas ou depurar.

Acessar a chave SSH

Se você já tiver criado o cluster, siga estas etapas para conseguir a chave SSH:

1. Consiga o secret seesaw-ssh do cluster. Consiga a chave SSH do secret e decodifique-a em base64. Salve a chave decodificada em um arquivo temporário:

   kubectl --kubeconfig CLUSTER_KUBECONFIG get -n  kube-system secret seesaw-ssh -o \
   jsonpath='{@.data.seesaw_ssh}' | base64 -d | base64 -d > /tmp/seesaw-ssh-key
   

   Substitua CLUSTER_KUBECONFIG pelo caminho do arquivo kubeconfig do cluster.

2. Defina as permissões apropriadas para o arquivo de chave:

   chmod 0600 /tmp/seesaw-ssh-key

   Se você ainda não criou o cluster, use as seguintes etapas para receber a chave SSH:

3. Localize o arquivo denominado seesaw-for-CLUSTER_NAME-IDENTIFIER.yaml.

   O arquivo, chamado de arquivo de grupo, está ao lado de config.yaml.

   Além disso, gkectl create loadbalancer imprime o local do arquivo de grupo.

4. No arquivo, consiga o valor de credentials.ssh.privateKey e decodifique-o em base64. Salve a chave decodificada em um arquivo temporário:

   cat seesaw-for-CLUSTER_NAME-IDENTIFIER.yaml  | grep privatekey | sed 's/    privatekey: //g' \
   | base64 -d > /tmp/seesaw-ssh-key
   

5. Defina as permissões apropriadas para o arquivo de chave:

   chmod 0600 /tmp/seesaw-ssh-key
   

Agora é possível usar SSH na VM do Seesaw:

ssh -i /tmp/seesaw-ssh-key ubuntu@SEESAW_IP

Substitua SEESAW_IP pelo endereço IP da VM do Seesaw.

Acessar snapshots

É possível capturar snapshots de VMs do Seesaw usando o comando gkectl diagnose snapshot com a sinalização --scenario.

Se você definir --scenario como all ou all-with-logs, a saída incluirá snapshots de Seesaw com outros snapshots.

Se você definir --scenario como seesaw, a saída incluirá apenas snapshots do Seesaw.

Exemplos:

gkectl diagnose snapshot --kubeconfig ADMIN_CLUSTER_KUBECONFIG --scenario seesaw

gkectl diagnose snapshot --kubeconfig ADMIN_CLUSTER_KUBECONFIG --cluster-name CLUSTER_NAME --scenario seesaw

gkectl diagnose snapshot --seesaw-group-file GROUP_FILE --scenario seesaw

Substitua:

• ADMIN_CLUSTER_KUBECONFIG: o caminho do arquivo kubeconfig do cluster de administrador

• GROUP_FILE: o caminho do arquivo de grupo do cluster.

Recriar VM do Seesaw com estado corrompido

Se uma VM do Seesaw for excluída acidentalmente, recrie-a usando o comando gkectl upgrade loadbalancer com as sinalizações --no-diff e --force. Isso recria todas as VMs do Seesaw no cluster, independentemente da existência ou do status de integridade. Se o balanceador de carga estiver no modo de alta disponibilidade e apenas uma das duas VMs for excluída, a execução desse comando recriará as duas VMs.

Por exemplo, para recriar o balanceador de carga Seesaw no cluster de administrador, execute o seguinte comando:

gkectl upgrade loadbalancer --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config ADMIN_CLUSTER_CONFIG --admin-cluster --no-diff --force

Para recriar o balanceador de carga Seesaw no cluster de usuário, execute o seguinte comando:

gkectl upgrade loadbalancer --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG --no-diff --force

Substitua:

• ADMIN_CLUSTER_KUBECONFIG: o caminho do arquivo kubeconfig do cluster de administrador;

• ADMIN_CLUSTER_CONFIG: o caminho do arquivo de configuração do cluster de administrador.

• USER_CLUSTER_CONFIG: o caminho do arquivo de configuração do cluster de usuário.

Problemas conhecidos

Cisco ACI não funciona com o retorno direto de servidor (DSR, na sigla em inglês)

O Seesaw é executado no modo DSR. Por padrão, ele não funciona na Cisco ACI devido ao aprendizado de IP de plano de dados. Você pode encontrar uma solução alternativa usando o grupo de endpoints de aplicativos aqui.

O Citrix Netscaler não funciona com o Direct Server Return (DSR)

Se você executar o balanceador de carga Netscaler na frente do Seesaw, o encaminhamento baseado em MAC (MBF, na sigla em inglês) precisará ser desativado. Consulte a documentação do Citrix (em inglês).

O upgrade do balanceador de carga da Seesaw não funciona em alguns casos

Se você tentar fazer upgrade de um cluster da versão 1.8.0 ou usar gkectl upgrade loadbalancer para atualizar alguns parâmetros do balanceador de carga da Seesaw na versão 1.8.0, isso não funcionará no modo DHCP ou IPAM. Aguarde uma correção anunciada em uma versão futura antes de fazer upgrade.