O Google Distributed Cloud é uma solução de software e hardware totalmente gerenciada que estende a infraestrutura e os serviços doGoogle Cloud para seu data center. O Google Distributed Cloud está disponível em configurações conectadas e com isolamento físico que são executadas no hardware fornecido pelo Google. O Google Distributed Cloud também está disponível como um produto apenas de software executado no seu próprio hardware. O software Google Distributed Cloud pode ser instalado em VMware ou bare metal. Este guia é para o software do Google Distributed Cloud executado diretamente em máquinas bare metal.
O software Google Distributed Cloud é baseado no Google Kubernetes Engine (GKE) com o próprio pacote do Kubernetes que estende o GKE para uso em um ambiente local. Com o Google Distributed Cloud, é possível criar, gerenciar e fazer upgrade de clusters do GKE nas suas instalações enquanto usa os recursos doGoogle Cloud , além de implantar e operar aplicativos conteinerizados nos clusters em grande escala usando a infraestrutura do Google.
Por que usar o Distributed Cloud somente software em bare metal?
A execução do software do Distributed Cloud somente para bare metal usa sua infraestrutura empresarial atual e ajuda a modernizar aplicativos durante todo o ciclo de vida deles.
Traga seu próprio nó
Com uma instalação somente de software em bare metal do Google Distributed Cloud, você implanta aplicativos por conta própria infraestrutura de hardware do Google, que oferece o melhor desempenho e flexibilidade. Você tem controle direto sobre o escalonamento do aplicativo, a segurança e a latência da rede. Você também tem os benefícios dos aplicativos conteinerizados com os componentes do GKE.
Melhor desempenho e menor custo
O Google Distributed Cloud gerencia a implantação e a integridade do aplicativo nos seus data centers corporativos atuais para garantir uma operação mais eficiente. Além disso, é possível executar contêineres na borda da rede para que os apps de análise sejam executados com máximo desempenho.
O uso do software do Distributed Cloud somente para bare metal em vez de máquinas virtuais permite gerenciar contêineres de aplicativos em diversos tipos de hardware com desempenho otimizado, como GPUs e SSDs. A execução do software do Distributed Cloud somente para bare metal também permite o acesso direto de aplicativos ao hardware.
Segurança compatível
Como você controla o ambiente do nó, é possível otimizar a rede, o hardware e os aplicativos para atender aos requisitos específicos. Como resultado, é possível controlar diretamente a segurança do sistema, sem precisar se preocupar com a compatibilidade com máquinas virtuais e sistemas operacionais.
Implantação de aplicativos monitorados
O Google Distributed Cloud oferece monitoramento avançado da integridade e do desempenho do ambiente. Esse recurso de monitoramento ajuda a ajustar o escalonamento de aplicativos e manter a confiabilidade, independentemente das flutuações da carga de trabalho e do tráfego de rede.
Use o Agente do Connect para gerenciar o monitoramento, a geração de registros e a análise de clusters e cargas de trabalho.
Latência e flexibilidade da rede
Como você gerencia os requisitos da sua rede, ela pode ser otimizada para baixa latência. Essa otimização de rede pode ser essencial para o desempenho em análises comerciais ou financeiras e outros aplicativos de borda corporativos ou de rede.
Altamente disponível
O Google Distributed Cloud inclui suporte para vários nós do plano de controle em um cluster. Se um nó do plano de controle ficar inativo, você ainda poderá administrar seu ambiente.
Design e controle seguros
A segurança da sua infraestrutura pode ser personalizada para suas próprias necessidades, com um mínimo de conexões com recursos externos. Mais importante ainda, não há a complexidade da VM durante a implantação de sistemas de segurança, e você mantém a transparência total do SO ao interagir com os sistemas de segurança atuais.
O Google Distributed Cloud funciona com conexões seguras leves a APIs do Google. É possível gerenciar clusters e aplicativos de um local central com o Connect e o Cloud Monitoring. Essa centralização também ajuda a manter suas implantações funcionando sem problemas e permite que o suporte do Google Cloud ajude a solucionar problemas de maneira mais eficaz.
Verificações de simulação na instalação
Com o Google Distributed Cloud, seus clusters são executados em sistemas Linux corporativos e de código aberto e em uma infraestrutura de hardware mínima, o que cria flexibilidade no seu ambiente. Ele também inclui várias verificações de simulação para garantir o sucesso das configurações e das instalações.
Implantação de aplicativos e balanceamento de carga
O Google Distributed Cloud inclui mecanismos de balanceamento de carga da camada 4 e 7 na criação do cluster.
Maior confiabilidade com etcd
Para monitorar o tamanho e desfragmentar os bancos de dados etcd, os planos de controle do Google Distributed Cloud
incluem um pod etcddefrag. O pod etcddefrag recupera
o armazenamento de grandes bancos de dados etcd e recupera etcd quando o espaço
em disco é excedido.
Como funciona
O Google Distributed Cloud estende o Google Kubernetes Engine (GKE) para permitir que você crie clusters em servidores Linux no seu próprio local. É possível gerenciar esses clusters locais no Google Cloudcom clusters do GKE normais e clusters em outros ambientes, como parte de uma frota.
Os clusters do GKE são executados no Google Cloud , em que a infraestrutura de rede e o plano de controle do Kubernetes são gerenciados pelo Google Cloud. Como os clusters criados com o Google Distributed Cloud são executados no seu data center, fornecemos alguns softwares de administração e de plano de controle, além do software do GKE. O software em execução no data center é baixado como parte dos processos de instalação e atualização.
O seguinte diagrama mostra o resultado simplificado de uma instalação concluída:
Principais componentes
Os seguintes componentes compõem uma instalação somente de software do Google Distributed Cloud em bare metal:
O cluster de administrador consiste em um ou mais nós do plano de controle. Cada nó é uma máquina física que executa um sistema operacional Linux compatível. A implantação padrão consiste em um cluster de administrador que gerencia o ciclo de vida de um ou mais clusters de usuário por meio do Kubernetes Resource Management (KRM). Cada nó/máquina na instalação tem seu próprio endereço IP.
O cluster de usuário é onde as cargas de trabalho que implementam seus aplicativos são executadas, como no GKE no Google Cloud. Cada cluster de usuário consiste em pelo menos um nó do plano de controle e um nó de trabalho.
A estação de trabalho do administrador é uma máquina separada (normalmente) que inclui as ferramentas e os artefatos do cluster, como arquivos de configuração. Os criadores e desenvolvedores de clusters usam essas ferramentas e artefatos para gerenciar os clusters no local, com as permissões apropriadas:
A execução de
bmctlna estação de trabalho de administrador permite criar e atualizar clusters, além de executar outras tarefas administrativas.A execução de
kubectlna estação de trabalho de administrador permite que você interaja com os clusters de administrador e de usuário, incluindo a implantação e o gerenciamento de cargas de trabalho.
A API GKE On-Prem é a API hospedada no Google Cloudpara o gerenciamento do ciclo de vida de clusters. Use os clientes da API (console doGoogle Cloud , Google Cloud CLI e Terraform) para criar e gerenciar o ciclo de vida dos clusters no local como alternativa ao login na estação de trabalho do administrador para gerenciar os com a CLI
bmctl.O console também fornece uma interface da Web para seu projeto doGoogle Cloud , incluindo os clusters no local. O console mostra as principais métricas sobre os clusters para ajudar a monitorar a integridade deles.
Os administradores e desenvolvedores de clusters usam
kubectlpara acessar planos de controle de cluster por meio de endereços IP virtuais (VIPs, na sigla em inglês) especificados como parte da configuração do cluster. Os usuários e desenvolvedores de aplicativos usam VIPs de Serviço e de Entrada para acessar e expor cargas de trabalho, respectivamente.
Como se conectar à frota
Todos os clusters de usuário (e, opcionalmente, clusters de administrador) são membros de uma frota: um grupo lógico de clusters do Kubernetes. As frotas permitem que sua organização aumente o gerenciamento de clusters individuais para grupos inteiros de clusters e podem ajudar suas equipes a adotar práticas recomendadas semelhantes às usadas no Google. É possível consultar e gerenciar clusters da frota no console do Google Cloud e usar recursos do GKE com frota para gerenciar, controlar e operar as cargas de trabalho em escala. Confira a lista completa de recursos de frota disponíveis para ambientes locais.
A conexão de cada cluster de frota com o Google Cloud é gerenciada por um agente do Connect, que é implantado como parte do processo de instalação do Google Distributed Cloud. Saiba mais sobre o funcionamento desse agente em Visão geral do agente do Connect.
A associação da frota também é usada para gerenciar os preços do Google Distributed Cloud em bare metal, conforme descrito na próxima seção.
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
Para saber mais sobre as versões do Google Distributed Cloud, consulte a Política de suporte de versões.
Esta documentação abrange todas as versões compatíveis do Google Distributed Cloud. Quando relevante, também retemos informações limitadas sobre versões mais antigas e não compatíveis nesta documentação. Diferenças específicas da versão nos requisitos e comportamento são observados na documentação. Da mesma forma, quando um novo recurso é disponibilizado, a versão compatível com o recurso é documentada.
Para uma lista das versões secundárias e dos patches compatíveis disponíveis, consulte Controle de versões.
A partir da versão 1.29, não criamos mais um diretório numerado para a documentação da versão secundária anterior. A documentação arquivada da versão 1.16 e anteriores pode ser encontrada adicionando o número da versão secundária no seguinte URL:
https://cloud.google.com/anthos/clusters/docs/bare-metal/VERSION/
Substitua VERSION por uma versão secundária de 1.6 a 1.16 e copie o URL na barra de endereço do navegador.
Como instalar o Distributed Cloud somente software em bare metal
Como os clusters criados usando o Google Distributed Cloud são executados na sua própria infraestrutura, eles são altamente configuráveis. Depois de selecionar o modelo de implantação que atende às necessidades específicas do caso de uso e da organização, escolha entre vários modos de balanceamento de carga compatíveis, opções de endereços IP, recursos de segurança, opções de conectividade e muito mais. A configuração de um cluster envolve a tomada de decisões antes e durante a instalação. Este conjunto de documentação inclui guias para ajudar sua equipe a decidir sobre os recursos e as opções ideais para você. Para garantir que a instalação atenda às necessidades da sua organização, consulte as equipes de rede e aplicativo.
Onde seus dados são armazenados
Quando você executa o software do Distributed Cloud apenas para bare metal, seus clusters, aplicativos e dados da empresa permanecem no data center. Por padrão, o Google Distributed Cloud envia Google Cloud informações sobre os 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, back-ends de armazenamento local e os dados que seus aplicativos processam.
- O plano de controle (
kube-apiserver,kube-schedulerekube-controller-manager) e o banco de dadosetcd, que armazena todos os objetos do Kubernetes. - Chaves privadas para as autoridades certificadoras (CAs),
incluindo a CA do cluster, a CA
etcde a CA do proxy de front-end. O namespace do cluster de usuário do cluster de administrador armazena as CAs do cluster de usuário. - Os secrets do aplicativo, os tokens OAuth, as chaves privadas SSH,
as credenciais do Container Registry e os arquivos de chave da conta de serviço são armazenados no
etcdou na estação de trabalho do administrador. Eles não são enviados para a API GKE On-Prem, e o snapshot de diagnóstico padrão não inclui credenciais de cluster. - O arquivo de configuração do cluster é armazenado na estação de trabalho do administrador. Se um cluster estiver registrado na API GKE On-Prem, algumas configurações serão enviadas. Consulte Dados enviados para o Google Cloud para mais informações.
- Os registros de auditoria só serão gravados no disco se você desativar os Registros de auditoria do Cloud nos nós do plano de controle.
- Se você configurar uma conta de serviço para uploads de snapshots de diagnóstico, o arquivo será enviado para o Cloud Storage. Você pode escolher se quer compartilhar um snapshot com o Cloud Customer Care.
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) |
|
Gerencie clusters no console doGoogle Cloud , no gateway do Connect e na frota com o agente do Connect. | Obrigatório |
| Configurações e status do cluster ( gkeonprem.googleapis.com) |
|
Permite gerenciar clusters com o console do Google Cloud , a
Google Cloud CLI ou o Terraform. Armazenados pela API GKE On-Prem na região definida
em gkeOnPremAPI.location, que tem como padrão
clusterOperations.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 vCPU, 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 saúde do sistema ( logging.googleapis.com, monitoring.googleapis.com,
opsconfigmonitoring.googleapis.com) |
|
Usado para o Cloud Monitoring, visualizações de status do console do Google Cloud e solução de problemas do atendimento ao cliente. Armazenado no projeto do Google Cloud
definido em clusterOperations.projectID. As métricas são armazenadas na
região definida em clusterOperations.location, 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 (audit-proxy): 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 , no
bucket _Required, e mantidos por 400 dias. |
Ativado. Para desativar, defina
clusterOperations.disableCloudAuditLogging como true.
Os registros de auditoria são mantidos apenas nos discos dos nós do plano de controle. |
A seguir
Para começar a usar o Google Distributed Cloud, consulte os seguintes guias:
- Criar clusters de administrador e de usuário de demonstração do Google Distributed Cloud em VMs do Compute Engine
- Planejar uma instalação básica no hardware
- Criar clusters básicos no hardware