Visão geral do Distributed Cloud somente software para VMware

O software Distributed Cloud somente para VMware permite implantar e gerenciar clusters do Google Kubernetes Engine (GKE) em um ambiente VMware vSphere. É possível executar e fazer upgrade de aplicativos conteinerizados no data center enquanto usa os recursos e a infraestrutura do Google Cloud .

Para executar clusters somente de software diretamente em servidores físicos, consulte a visão geral do Distributed Cloud somente de software em bare metal.

Por que usar o software do Distributed Cloud somente para VMware?

A execução do software do Distributed Cloud somente para VMware na infraestrutura do vSphere permite modernizar aplicativos com o GKE, mantendo a plataforma de virtualização, o armazenamento e os processos operacionais que suas equipes já usam.

Integração com o ambiente do vSphere

O Google Distributed Cloud executa nós de cluster como máquinas virtuais no ambiente do vCenter, para que você possa adicionar cargas de trabalho conteinerizadas aos hosts do vSphere que já opera. Os clusters armazenam dados em repositórios de dados do vSphere com backup do vSAN, VMFS ou NFS, e é possível atribuir diferentes repositórios de dados a pools de nós individuais. O driver de Container Storage Interface (CSI) do vSphere provisiona volumes permanentes para cargas de trabalho com estado. Para mais detalhes, consulte Armazenamento.

Gerenciamento centralizado com dados no local

Gerencie, monitore e resolva problemas de clusters no console do Google Cloud , na Google Cloud CLI ou no Terraform usando a API GKE On-Prem, sem fazer login na estação de trabalho de administrador. Seus aplicativos e dados da empresa permanecem no seu data center. O Google Cloud recebe apenas metadados do cluster, informações de integridade e uso. Para mais detalhes, consulte Dados que permanecem no data center.

Confiabilidade e operações empresariais

O Google Distributed Cloud inclui recursos operacionais prontos para produção:

  • Alta disponibilidade: os clusters de administrador de alta disponibilidade e os planos de controle de cluster de usuário usam três nós de plano de controle para que você possa administrar seu ambiente mesmo que um nó falhe.
  • Reparo automático de nós: as verificações de integridade periódicas detectam nós não íntegros, e o reparo automático de nós os repara automaticamente. Esse recurso é ativado por padrão.
  • Escalonamento automático de clusters: o escalonador automático de clusters adiciona ou remove nós em um pool de nós com base nas solicitações de recursos das suas cargas de trabalho.
  • Balanceamento de carga flexível: use o balanceador de carga MetalLB em pacote, que é executado nos nós do cluster, ou configure um balanceador de carga de terceiros, como F5 BIG-IP ou Citrix. Para mais detalhes, consulte Visão geral do balanceamento de carga.

Como funciona

O Google Distributed Cloud estende o GKE para permitir que você crie clusters em servidores físicos em um ambiente do vSphere. Você gerencia esses clusters locais no Google Cloud com clusters baseados na nuvem como parte de uma frota unificada.

Nos clusters do GKE em execução no Google Cloud, o Google gerencia o plano de controle do Kubernetes e a infraestrutura de rede. Para clusters do Google Distributed Cloud em execução no seu data center, o Google Cloud fornece software de administração e plano de controle que é baixado e implantado nas máquinas virtuais do vSphere como parte dos processos de instalação e upgrade.

O diagrama a seguir mostra a arquitetura de uma instalação concluída com um cluster de administrador e um cluster de usuário:

Diagrama de um cluster de administrador e de cluster de usuário
Arquitetura do Google Distributed Cloud no VMware com um cluster de administrador e outro de usuário

Principais componentes

Os seguintes componentes compõem uma instalação do software do Distributed Cloud somente para VMware:

  • Cluster de administrador: gerencia um ou mais clusters de usuário. Os clusters de administrador consistem em um ou mais nós do plano de controle em execução em máquinas virtuais dedicadas.
  • Cluster de usuário: executa as cargas de trabalho conteinerizadas. Cada cluster de usuário consiste em pelo menos um nó do plano de controle e um ou mais nós de trabalho.
  • Estação de trabalho do administrador: uma máquina virtual dedicada que inclui arquivos de configuração de cluster e ferramentas de gestão:
    • gkectl: cria, atualiza e gerencia implantações de cluster.
    • kubectl: interage com clusters de administrador e de usuário para gerenciar cargas de trabalho.
  • Console doGoogle Cloud : uma interface da Web no Google Cloud para visualizar a integridade do cluster e realizar operações de ciclo de vida sem fazer login na estação de trabalho de administrador.
  • Endereços IP virtuais (VIPs): IPs virtuais configurados durante a instalação. Os administradores e desenvolvedores de clusters usam kubectl e VIPs do plano de controle para acessar planos de controle em clusters de administrador e de usuário. Os usuários e desenvolvedores de aplicativos usam VIPs de Serviço e de Entrada para acessar e expor cargas de trabalho, respectivamente. Para mais detalhes, consulte Planejar seus endereços IP.

Como se conectar à frota

Todos os clusters de usuário são membros de uma frota, que é um agrupamento lógico de clusters do Kubernetes que fornece gerenciamento unificado em todos os ambientes. As frotas permitem que você visualize clusters juntos no console do Google Cloud e use recursos ativados para frotas para gerenciar, controlar e operar cargas de trabalho em grande escala.

Cada cluster se conecta ao Google Cloud pelo agente do Connect, que é implantado automaticamente durante a instalação do cluster. A assinatura da frota também determina o faturamento do software do Distributed Cloud somente para VMware.

Preços

Os clusters no local criados usando o Google Distributed Cloud são cobrados por vCPU. Para ativar o faturamento, ative a API Anthos no projeto do Google Cloud.

Para informações completas sobre preços, inclusive como entrar em contato com a equipe de vendas, consulte Preços do Google Kubernetes Engine.

Versões

Esta documentação abrange todas as versões compatíveis do Google Distributed Cloud. Quando relevante, o Google também retém informações limitadas sobre versões mais antigas e não compatíveis nesta documentação.

Para ver as versões compatíveis e as políticas de lançamento, consulte os seguintes recursos:

A partir da versão 1.29, não criamos mais um diretório para a versão secundária anterior. As diferenças de comportamento estão descritas na documentação. Quando um novo recurso é disponibilizado, a versão compatível com ele é documentada.

A documentação da versão 1.16 e anteriores está arquivada em:

https://cloud.google.com/anthos/clusters/docs/on-prem/VERSION/

Substitua VERSION por uma versão secundária de 1.0 a 1.16. e copie o URL na barra de endereço do navegador.

Onde seus dados são armazenados

Quando você executa o Distributed Cloud somente software para VMware, seus clusters, aplicativos e dados da empresa permanecem no data center. Por padrão, o Google Distributed Cloud envia Google Cloud informações sobre seus clusters, como configurações, integridade e uso, mas não envia os dados do aplicativo.

Dados que permanecem no seu data center

Os seguintes dados permanecem no seu data center:

  • Contêineres, pods, PersistentVolumes e os dados que seus aplicativos processam.
  • Todos os objetos do Kubernetes são armazenados no plano de controle e no banco de dados etcd.
  • O plano de controle do cluster de administrador armazena chaves privadas etcd autoassinadas, chaves de cluster de usuário e autoridades de certificação (CAs) de cluster.
  • Secrets de aplicativos, tokens OAuth, chaves privadas SSH, credenciais do Container Registry, credenciais do vCenter e do F5 BIG-IP e arquivos de chave de conta de serviço, armazenados em etcd ou na estação de trabalho do administrador. Eles não são enviados para a API GKE On-Prem e são removidos dos snapshots de diagnóstico.
  • Os arquivos de configuração do cluster de administrador, do cluster de usuário e das credenciais são armazenados na estação de trabalho do administrador.
  • Os registros de auditoria são gravados no disco nos nós do plano de controle do cluster de administrador e nos clusters de usuário.
  • É possível fazer upload de snapshots de diagnóstico para o Cloud Storage.

Dados enviados para o Google Cloud

A tabela a seguir mostra o que é enviado, como é usado e armazenado e se é possível desativar:

Dados O que é enviado Uso e armazenamento Padrão
Conexão e registro de frota
(gkehub.googleapis.com, gkeconnect.googleapis.com)
  • Identidade do cluster: Google Cloud projeto, nome da assinatura da frota, UID do cluster, chaves públicas, versão do Kubernetes, tamanho do cluster e configuração do provedor de identidade.
  • Dados do Kubernetes solicitados no console do Google Cloud ou no gateway de conexão.
  • O token criptografado do Kubernetes no seu perfil de usuário até você sair do console do Google Cloud .
 Gerencie clusters no console doGoogle Cloud , no gateway do Connect e na frota com o agente do Connect. O kube-apiserver autentica, autoriza e registra em auditoria cada solicitação. Obrigatório
Configurações e status do cluster
(gkeonprem.googleapis.com)
  • Nome, UID, descrição, anotações, versão, estado do ciclo de vida e VIP do plano de controle.
  • Nomes de pools de nós, configurações de IP ou DHCP de nós, CIDRs de pods e serviços, VIPs de balanceador de carga, configurações de balanceador de carga.
  • Endereço do vCenter, data center, cluster, pool de recursos, armazenamento de dados, pasta e nome da política de armazenamento (não as credenciais do vCenter).
  • Endereços de e-mail dos administradores do cluster.
 Permite gerenciar clusters com o console do Google Cloud , a Google Cloud CLI ou o Terraform. A API GKE On-Prem armazena esses dados na região definida em gkeOnPremAPI.location. Ativado na versão 1.16 e mais recentes, se a API GKE On-Prem estiver ativada no projeto do Google Cloud . Para desativar, defina gkeOnPremAPI.enabled como false.
Uso do faturamento
(anthos.googleapis.com)		 Capacidade de vCPUs, contagem de nós e status de direito de licença. Usado para medição, faturamento e verificações de licença. Obrigatório. Os registros de faturamento são armazenados em buffer durante uma interrupção e enviados posteriormente.
Dados de integridade do sistema
(logging.googleapis.com, monitoring.googleapis.com, opsconfigmonitoring.googleapis.com)
  • Métricas: uso de CPU, memória, disco e rede, métricas do kubelet e kube-state-metrics para nós e pods do sistema.
  • Registros de contêiner e resultados da verificação de integridade de todos os componentes do cluster de administrador e dos namespaces do cluster de usuário kube-system, gke-system, gke-connect, istio-system e config-management-system.
  • Metadados: nomes e rótulos de nós, pods, implantações e serviços.
 Usado para o Cloud Monitoring, as visualizações de status do console do Google Cloud e a solução de problemas do Atendimento ao Cliente. Armazenado no projeto do Google Cloud definido em stackdriver.projectID. As métricas são armazenadas na região stackdriver.clusterLocation, e os registros seguem as configurações do roteador de registros. Ativado para registros e métricas do sistema, que são necessários para o suporte completo do Customer Care e a cobertura do SLA. Desativado para registros e métricas de aplicativos, a menos que você defina enableCloudLoggingForApplications ou enableGMPForApplications como true no recurso Stackdriver.
Registros de auditoria
(anthosaudit.googleapis.com)		 Registros de auditoria de atividade do administrador: quem mudou o que pelo kube-apiserver e quando. As entradas incluem o horário, o cluster, o host ou a VM, o usuário ou a conta de serviço, o papel do RBAC, a operação e o resultado. As solicitações de leitura não são registradas. Armazenados nos Registros de auditoria do Cloud no projeto do Google Cloud definido em cloudAuditLogging.projectID, no bucket _Required e mantidos por 400 dias. Opcional. Para ativá-lo, preencha a seção cloudAuditLogging. Para clusters de administrador, só é possível ativá-lo na criação. Para desativá-lo em um cluster de usuário, exclua a seção e atualize o cluster.

A seguir