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 os clusters do Anthos no VMware para serem executados no modo de balanceamento de carga em pacote.
O balanceador de carga do Anthos fornecido pelo Anthos no cluster é o Balanceador de carga da Seesaw.
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 balanceamento de carga em pacote para um cluster de administrador e um cluster de usuário associado.
Vantagens do modo de balanceamento de carga em pacote
O modo de balanceamento de carga em pacote oferece estas vantagens, em comparação com o modo de balanceamento de carga manual:
Uma única equipe pode ser responsável pela criação do cluster e pela configuração do balanceador de carga. Por exemplo, uma equipe de administração de cluster não precisaria depender de uma equipe de rede separada para adquirir, executar e configurar o balanceador de carga com antecedência.
Os clusters do Anthos no VMware configuram automaticamente endereços IP virtuais (VIPs) no balanceador de carga. No momento da criação do cluster, os clusters do Anthos no VMware configuram o balanceador de carga com VIPs para o servidor da API Kubernetes, o serviço de entrada e os complementos do cluster. clients medida que os clientes criam Serviços do tipo LoadBalancer, os clusters do Anthos no VMware configuram automaticamente os VIPs de serviço no balanceador de carga.
As dependências entre organizações, grupos e administradores são reduzidas. Especificamente, o grupo que gerencia um cluster depende menos do grupo que gerencia a rede.
Versões recomendadas
Recomendamos fortemente usar o vSphere 6.7 ou posteriores e o Virtual Distributed Switch (VDS) 6.6 ou posteriores para o modo de balanceamento de carga agrupado.
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.
Protocolo de redundância virtual do roteador
É 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.
Planejar suas VLANs
Neste exercício, você cria um cluster de administrador e um cluster de usuário. 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 |
Reserve endereços IP virtuais
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.
VIPs de cluster de administrador
Separe um VIP para o servidor da API do Kubernetes do cluster de administrador. No
arquivo de configuração do cluster de administrador, ele é chamado de controlPlaneVIP. Esse VIP
precisa estar na mesma VLAN dos nós de cluster de administrador e das VMs do Seesaw
do cluster de administrador.
Separe um VIP para os complementos no cluster de administrador. No arquivo de configuração do
cluster de administrador, ele é chamado de addonsVIP. Esse VIP precisa estar na mesma
VLAN dos nós de cluster de administrador e das VMs do Seesaw do cluster de administrador.
Usar VIPs de cluster
Reserve um VIP para o servidor da API Kubernetes do seu cluster de usuários. No
arquivo de configuração do cluster de usuário, ele é chamado de controlPlaneVIP. Esse VIP
precisa estar na mesma VLAN dos nós de cluster de administrador e das VMs do Seesaw
do cluster de administrador. Isso ocorre porque o servidor da API Kubernetes para o cluster de usuário
é executado em um nó no cluster de administrador.
Separe um VIP para entrada no cluster de usuário. No arquivo de configuração
do cluster de usuário, ele é chamado de ingressVIP. Esse VIP precisa estar na mesma
VLAN dos nós de cluster de usuário e das VMs do Seesaw no cluster de usuário.
Reservar endereços IP de nós
Com o modo de balanceamento de carga em pacote, ou você especifica endereços IP estáticos para seus nós de cluster ou os nós de cluster podem receber 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. Para detalhes sobre quantos endereços IP de nó precisam ser reservados, consulte Como criar um cluster de administrador.
Como reservar endereços IP para VMs do Seesaw
A seguir, reserve endereços IP para as VMs que executarão os balanceadores de carga do 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.
Caso 1: balanceadores de carga altamente disponíveis
Para o cluster de administrador, separe dois endereços IP para um par de VMs do Seesaw. Além disso, para o cluster de administrador, reserve um único endereço IP mestre para o par de VMs da Seesaw. Esses três endereços precisam estar na mesma VLAN que os nós de cluster de administrador.
Para o cluster de usuário, reserve dois endereços IP para um par de VMs do Seesaw. Além disso, separe um único endereço IP mestre para o par de VMs do Seesaw. Esses três endereços precisam estar na mesma VLAN que os nós de cluster de usuário.
Caso 2: balanceadores de carga não altamente disponíveis
Para o cluster de administrador, separe um endereço IP para uma VM do Seesaw. Além disso, para o cluster de administrador, reserve um IP mestre para o balanceador de carga do 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. Reserve também um endereço IP mestre para o balanceador de carga do Seesaw. Os dois endereços precisam estar na mesma VLAN que os nós de cluster de usuário.
Planejar os grupos de portas
Cada uma das VMs do Seesaw tem duas interfaces de rede. Para uma VM mestre do Seesaw, uma dessas interfaces de rede é configurada com VIPs, e a outra interface de rede é configurada com um endereço IP retirado de um arquivo de bloco IP que você fornece. Para uma VM do Seesaw de backup, uma interface é configurada com um endereço IP retirado do arquivo de bloco de IP, e nada é configurado na outra interface de rede.
Para uma VM individual do Seesaw, as duas interfaces de rede podem ser conectadas ao mesmo grupo de portas do vSphere ou conectadas a grupos de portas separados. Se os grupos de portas estiverem separados, eles precisarão estar na mesma VLAN.
Neste tópico, mencionamos dois grupos de portas:
Grupo de portas do balanceador de carga: para uma VM da Seesaw, a interface de rede configurada com VIPs de serviço é conectada a esse grupo de portas.
Grupo de portas do nó do cluster: para uma VM da Seesaw, a interface de rede configurada com um endereço IP retirado do arquivo de bloco de IP é conectada a esse grupo de portas. Os nós de cluster também estão conectados a esse grupo de portas.
O grupo de portas do balanceador de carga e o do nó de cluster podem ser iguais ou os mesmos. Porém, recomendamos que eles sejam separados.
No diagrama a seguir, ilustramos a configuração de rede recomendada para o balanceamento de carga da Seesaw:
VMs da Seesaw e nós de cluster em uma VLAN
O diagrama anterior representa um único cluster, que pode ser um cluster de administrador ou um cluster de usuário. Lembre-se de que recomendamos que cada cluster esteja na própria VLAN dele.
No diagrama, são exibidas as seguintes características da rede:
Há duas VMs da Seesaw, uma mestre e uma de backup.
As VMs da Seesaw estão na mesma VLAN dos nós do cluster.
A VM de backup da Seesaw tem duas interfaces de rede. Uma interface é configurada com um endereço IP retirado do arquivo de bloco de IP da Seesaw. A outra interface não é configurada com nenhum endereço IP.
A VM mestre da Seeaw tem duas interfaces de rede. Uma interface é configurada com um endereço IP retirado do arquivo de bloco de IP da Seesaw. A outra interface é configurada com VIPs.
Cada VM da Seeaw tem uma interface de rede conectada ao grupo de portas do balanceador de carga. Todas as outras interfaces de rede no diagrama estão conectadas ao grupo de portas do nó do cluster.
Todos os endereços IP, incluindo VIPs, configurados nas interfaces de rede mostradas no diagrama precisam ser roteáveis para a VLAN.
Para um cluster de administrador, a interface dos VIPs na VM mestre da Seesaw é configurada com os seguintes endereços IP:
- O VIP da VM mestre da Seesaw do cluster de administrador
- O VIP dos complementos do cluster de administrador
- O VIP do plano de controle do cluster de administrador
- O VIP do plano de controle do cluster de usuário
- Os VIPs de serviços do tipo LoadBalancer em execução no cluster de administrador
Para um cluster de usuário, a interface dos VIPs na VM mestre da Seesaw é configurada com os seguintes endereços IP:
- O VIP da VM mestre da Seesaw do cluster de usuário
- O VIP de entrada do cluster de usuário
- Os VIPs de serviços do tipo LoadBalancer em execução no cluster de usuário
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. Esse arquivo de bloco de IP é para as VMs do balanceador de carga, não para os nós do cluster. Se você pretende usar endereços IP estáticos para os nós de cluster, crie um arquivo hostconfig separado para eles. Veja um exemplo de arquivo de bloco de IP que especifica dois endereços IP para VMs da Seesaw:
blocks:
- netmask: "255.255.255.0"
gateway: "172.16.20.1"
ips:
- ip: "172.16.20.18"
hostname: "seesaw-vm-1"
- ip: "172.16.20.19"
hostname: "seesaw-vm-2"
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:
ipBlockFilePath:
vrid:
masterIP:
cpus:
memoryMB:
vCenter:
networkName:
enableHA:
disableVRRPMAC:
Para informações sobre como preencher a seção seesaw de um arquivo de configuração de cluster, loadbalancer.seesaw (cluster de administrador) ou loadbalancer.seesaw (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:
|
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.
Exemplo:seesaw-for-gke-admin-12345.yaml.
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:
Consiga o secret
seesaw-sshdo 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-keySubstitua CLUSTER_KUBECONFIG pelo caminho do arquivo kubeconfig do cluster.
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:
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 loadbalancerimprime o local do arquivo de grupo.No arquivo, consiga o valor de
credentials.ssh.privateKeye 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
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.
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 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.