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 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 na sua infraestrutura empresarial atual oferece acesso direto ao hardware, segurança empresarial e gerenciamento centralizado em todos os ambientes.
Controle e desempenho diretos do hardware
A implantação direta em servidores físicos oferece controle direto sobre a escala, a latência e o desempenho do aplicativo, além de reduzir os custos usando sua infraestrutura atual. 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. É possível otimizar cargas de trabalho para tipos de hardware especializados, como GPUs e SSDs, e executar aplicativos de baixa latência na borda da rede sem sobrecarga de hipervisor.
Segurança no nível do sistema operacional
Como você mantém o controle direto sobre os sistemas operacionais dos nós e as configurações de rede, é possível personalizar as políticas de segurança para atender aos requisitos de compliance. Os clusters se comunicam com as APIs do Google por conexões seguras e leves, eliminando a complexidade da máquina virtual e mantendo os controles de segurança atuais.
Gerenciamento e monitoramento centralizados
Gerencie, monitore e resolva problemas de clusters no console doGoogle Cloud usando o Cloud Monitoring e o Agente do Connect. Essa visibilidade centralizada ajuda a manter a confiabilidade e ajustar a escala do aplicativo em data centers distribuídos.
Confiabilidade e operações empresariais
O Google Distributed Cloud inclui recursos operacionais prontos para produção:
- Alta disponibilidade: o suporte a vários nós do plano de controle garante que você possa administrar seu ambiente mesmo que um nó falhe.
- Verificações de simulação automatizadas: a validação integrada ajuda a verificar as configurações de hardware e sistema operacional antes da instalação.
- Balanceamento de carga integrado: os mecanismos de balanceamento de carga da camada 4 e da camada 7 são implantados automaticamente durante a criação do cluster.
- Manutenção do banco de dados: a desfragmentação automatizada (
etcddefrag) recupera o armazenamento para manter a integridade e a estabilidade doetcd.
Como funciona
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 você baixa e instala nos servidores físicos do Linux. Você gerencia esses clusters locais no Google Cloud com clusters baseados na nuvem como parte de uma frota unificada.
O diagrama a seguir mostra a arquitetura de uma instalação concluída com um cluster de administrador e um cluster de usuário:
Principais componentes
Uma implantação bare metal somente de software consiste nos seguintes componentes:
- Cluster de administrador: gerencia o ciclo de vida dos clusters de usuário usando o Kubernetes Resource Management (KRM). 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. Um cluster de administrador consiste em uma ou mais máquinas Linux físicas que servem como nós do plano de controle. Cada nó/máquina na instalação tem seu próprio endereço IP.
- 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 nó de trabalho.
- Estação de trabalho do administrador: uma máquina dedicada que hospeda arquivos de configuração
e ferramentas administrativas:
bmctl: cria, atualiza e gerencia clusters.kubectl: interage com clusters de administrador e de usuário e gerencia cargas de trabalho.
- API GKE On-Prem: a API hospedada no Google Cloudpara o gerenciamento do ciclo de vida de clusters. Clientes, como o console do Google Cloud , a Google Cloud CLI e o Terraform, permitem gerenciar clusters locais sem fazer login na estação de trabalho de administrador.
- Console doGoogle Cloud : fornece uma interface da Web para seu projeto do Google Cloud, incluindo clusters no local. O console do Google Cloud exibe as principais métricas sobre os clusters para ajudar a monitorar a integridade deles e o status da frota.
- Endereços IP virtuais (VIPs): IPs virtuais configurados durante a instalação.
Os administradores e desenvolvedores de clusters usam
kubectlpara acessar planos de controle de cluster por meio de VIPs do plano de controle. 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
Os clusters de usuário e, opcionalmente, os clusters de administrador são registrados em uma frota, que é um agrupamento lógico de clusters do Kubernetes que fornece gerenciamento unificado em todos os ambientes. 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 visualizar clusters no console doGoogle Cloud e usar recursos ativados para frota para gerenciar, controlar e operar cargas de trabalho em escala.
Cada cluster se conecta ao Google Cloud pelo agente do Connect, que é implantado automaticamente durante a instalação do cluster. A associação à frota também determina o faturamento do Google Distributed Cloud.
Preços
Os clusters locais criados com o Google Distributed Cloud são cobrados por vCPU. Para ativar o faturamento, ative a API Anthos no projeto do Google Cloud.
Para detalhes sobre preços e dados de contato 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, o Google também retém 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.0 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 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 saúde do sistema ( logging.googleapis.com, monitoring.googleapis.com,
opsconfigmonitoring.googleapis.com) |
|
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 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