Este documento descreve as opções e os recursos de cluster do Kubernetes disponíveis no Google Distributed Cloud (GDC) com isolamento físico. Os clusters do Kubernetes fornecem um serviço gerenciado do Kubernetes com o Google Kubernetes Engine (GKE) que permite implantar e executar cargas de trabalho de contêiner usando metodologias padrão do setor.
Este documento é destinado a públicos-alvo, como administradores de TI no grupo de administradores de plataforma e desenvolvedores de aplicativos no grupo de operadores de aplicativos, responsáveis por gerenciar cargas de trabalho de contêiner na organização. Para mais informações, consulte Públicos-alvo da documentação do GDC com isolamento físico.
GKE em um ambiente desconectado
O GKE no GDC é um serviço gerenciado do Kubernetes que oferece os principais recursos e funcionalidades do GKE ao seu ambiente desconectado. Para fins de documentação, os clusters gerenciados pelo GKE no GDC são chamados de clusters do Kubernetes. Para mais informações sobre os conceitos do Kubernetes, consulte Começar a aprender sobre o Kubernetes.
O GKE no GDC permite criar e gerenciar cargas de trabalho de contêiner no seu ambiente desconectado de maneira semelhante ao uso do GKE no público Google Cloud.
A tabela a seguir compara clusters no GDC e Google Cloud:
| Recurso | Descrição | GKE no GDC | GKE em Google Cloud |
|---|---|---|---|
| Totalmente desconectado | Operável em um ambiente sem conexão com a Internet. | Sim | Não |
| Solução de backup | Serviço para criar cópias de dados e configurações de um cluster para garantir a proteção de dados e permitir a recuperação de falhas, erros ou ataques cibernéticos. | Backup para GDC | Backup para GKE |
| Geração de registros e monitoramento integrados | Serviço que combina a coleta e a análise de registros com o monitoramento de indicadores principais de desempenho para uma visão abrangente do comportamento do cluster. | Prometheus, Grafana e Loki | Cloud Logging e Cloud Monitoring |
| Registro de contêiner gerenciado | Serviço que hospeda e organiza imagens de contêiner, processando infraestrutura, disponibilidade e segurança para as imagens. | Serviço Harbor gerenciado | Artifact Registry |
| Isolamento de contêiner | Capacidade de manter aplicativos de contêiner e dependências separados e independentes uns dos outros e do sistema host. | Sim | Sim |
| Suporte a GPUs e TPUs | Unidades de computação de alto desempenho que permitem recursos de processamento aprimorados. | Somente GPUs | GPUs e TPUs |
| Escalonamento automático do pod horizontal | Ajuste automatizado do número de réplicas de pod em uma implantação ou outra carga de trabalho com base em métricas observadas, como uso da memória ou uso de CPU. | Sim | Sim |
| Contêineres Linux | Ambiente isolado para executar aplicativos em um host Linux. | Sim | Sim |
| UI para clusters | Interface gráfica que oferece uma maneira visual e fácil de usar para gerenciar e monitorar um cluster. | Somente cluster compartilhado | Sim |
| UI para recursos de cluster | Interface gráfica que oferece uma maneira visual e fácil de usar para gerenciar e monitorar as cargas de trabalho de contêiner de um cluster. | Acesso de visualização | Sim |
Para mais informações sobre o GKE e o conjunto completo de recursos disponíveis no público Google Cloud, consulte Explorar a documentação do GKE.
Benefícios dos clusters do Kubernetes
O GKE no GDC oferece benefícios importantes para os clusters do Kubernetes, como:
- Gerenciamento do ciclo de vida de vários clusters: implante vários clusters no GDC simultaneamente para diversas instâncias hospedadas para cargas de trabalho de contêiner.
- Distribuição do Kubernetes com suporte total: crie clusters agrupados com recursos padrão atualizados do Kubernetes.
- Visibilidade de custos: monitore o uso e os insights em tempo real, ajudando a monitorar continuamente os custos do Kubernetes.
- Gerenciamento de várias equipes: conceda acesso a vários grupos de usuários aos clusters do Kubernetes para limites de gerenciamento flexíveis.
- Fluxos de trabalho automatizados do Kubernetes: conte com o provisionamento automático de nós e o escalonamento automático de pods horizontais para gerenciar cargas de trabalho de contêiner sem problemas.
Todos esses recursos vêm como padrão com o GKE no GDC e estão disponíveis para uso com clusters criados pelo serviço gerenciado do Kubernetes.
Arquitetura de cluster do GDC
Os clusters do Kubernetes são separados logicamente uns dos outros para fornecer diferentes domínios de falha e garantias de isolamento. Em alguns casos, eles são até mesmo separados fisicamente.
Você configura um cluster do Kubernetes como um cluster compartilhado ou padrão. Um cluster compartilhado abrange vários projetos. Um cluster padrão tem escopo para um único projeto. Para mais informações, consulte Configurações de cluster do Kubernetes.
Um cluster do Kubernetes consiste em um plano de controle e máquinas de worker chamadas nós. O plano de controle e os nós compõem o sistema de orquestração de clusters do Kubernetes. O GKE no GDC gerencia toda a infraestrutura de clusters, incluindo o plano de controle e todos os componentes do sistema. Você é responsável por gerenciar os nós de worker que executam as cargas de trabalho conteinerizadas.
O diagrama a seguir mostra a arquitetura de um cluster do Kubernetes:

Este diagrama mostra um cluster do Kubernetes com os seguintes componentes:
- Plano de controle, que inclui um servidor de API e serviços predefinidos, como armazenamento e programação de pods padrão.
- Nós de worker que executam cargas de trabalho de contêiner.
- Serviços do GDC, como rede VPC e balanceamento de carga, que são fornecidos pelo serviço gerenciado do GKE no GDC.
Sobre o plano de controle
O plano de controle executa processos como o servidor da API Kubernetes, o programador e os controladores dos recursos principais. O GKE no GDC gerencia o ciclo de vida do plano de controle desde a criação até a exclusão do cluster. Isso inclui upgrades da versão do Kubernetes em execução no plano de controle, que o GDC realiza automaticamente. O upgrade também pode ser feito manualmente antes da programação automática.
O plano de controle e a API Kubernetes
O plano de controle é o endpoint unificado para o cluster. Você interage com o plano de controle por meio de chamadas da API Kubernetes. O plano de controle executa o processo do servidor da API Kubernetes, ou kube-apiserver, para lidar com solicitações de API. É possível fazer chamadas da API Kubernetes destas formas:
- Chamadas diretas: KRM
- Chamadas indiretas: clientes de linha de comando do Kubernetes, como a CLI kubectl ou o console do GDC.
O processo do servidor da API é o hub central para todas as comunicações do cluster. Todos os componentes internos do cluster, como nós, processos do sistema e controladores de aplicativos, atuam como clientes do servidor da API.
As solicitações de API informam ao Kubernetes qual é o estado escolhido para os objetos no cluster. O Kubernetes tenta manter esse estado constantemente. O Kubernetes permite configurar objetos na API de maneira imperativa ou declarativa.
Gerenciamento de nós de trabalho
O plano de controle decide o que é executado em todos os nós do cluster. O plano de controle programa cargas de trabalho e gerencia o ciclo de vida, o escalonamento e os upgrades delas. O plano de controle também gerencia recursos de rede e de armazenamento para essas cargas de trabalho. O plano de controle e os nós se comunicam usando as APIs do Kubernetes.
Sobre os nós
Nós são as máquinas de worker que executam seus aplicativos conteinerizados e outras cargas de trabalho. As máquinas individuais são máquinas virtuais (VMs) criadas pelo GKE no GDC. O plano de controle administra e recebe atualizações sobre o status relatado de cada nó.
Um nó executa os serviços necessários para oferecer suporte aos contêineres que compõem as cargas de trabalho do cluster. Eles incluem o ambiente de execução e o agente do nó do Kubernetes, ou kubelet, que se comunica com o plano de controle e é responsável por iniciar e executar os contêineres programados nesse nó.
O GKE no GDC também executa vários contêineres do sistema que são executados como agentes por nó, chamados DaemonSets, que fornecem recursos como coleta de registros e conectividade de rede intracluster.
Os nós são agrupados em um pool de nós, que é um conjunto de nós em um cluster que compartilham a mesma configuração e características. Não é possível configurar um único nó em um pool de nós.
Os pools de nós personalizados são úteis ao programar pods que exigem mais recursos que outros, como mais memória ou espaço em disco local. É possível usar taints de nós se você precisar de mais controle sobre a programação de pods.
Para mais informações, consulte Gerenciar pools de nós.
Configurações de cluster do Kubernetes
As seguintes configurações de cluster estão disponíveis com o serviço GKE no GDC para gerenciar as cargas de trabalho de contêiner em uma organização:
- Cluster compartilhado: um cluster do Kubernetes com escopo da organização que abrange vários projetos e não é gerenciado por um único projeto, mas sim anexado a eles.
- Cluster padrão: um cluster do Kubernetes com escopo de projeto que gerencia recursos de cluster em um projeto e não pode abranger vários projetos.
É possível escolher o cluster que melhor atenda aos requisitos de gerenciamento de cargas de trabalho de contêiner. Para mais informações, consulte Configurações de cluster do Kubernetes.
Cargas de trabalho de GPU em um cluster
O GDC oferece suporte a GPUs NVIDIA para clusters do Kubernetes, e elas executam seus dispositivos de GPU como cargas de trabalho do usuário. Por exemplo, talvez você prefira executar notebooks de inteligência artificial (IA) e machine learning (ML) em um ambiente de GPU. É necessário configurar o cluster para oferecer suporte a dispositivos de GPU provisionando máquinas de GPU para eles. Para uma lista de tipos de máquina com suporte para clusters do Kubernetes no GDC, consulte Máquinas de nós de cluster.
As GPUs são alocadas estaticamente. As quatro primeiras GPUs são sempre dedicadas a cargas de trabalho como APIs de IA e ML pré-treinadas. Essas GPUs não são executadas em um cluster do Kubernetes. As GPUs restantes estão disponíveis para clusters do Kubernetes. Os notebooks de IA e ML são executados em clusters do Kubernetes.
Alocar máquinas de GPU para os tipos de cluster corretos para permitir que componentes como APIs de IA e ML sejam executados no cluster. Para mais informações, consulte Criar um cluster compartilhado ou Criar um cluster padrão.
Limitações do GKE no GDC
Os seguintes recursos do GKE são limitações não disponíveis para o GKE no GDC:
- Gerenciamento automatizado de clusters
- Reparos automáticos de nós: os clusters do Kubernetes no GDC não podem corrigir nós automaticamente quando eles ficam não íntegros.
- Upgrades automáticos de clusters: os clusters do Kubernetes do GDC não podem fazer upgrade automático de nós com novas atualizações de versão do Kubernetes. É necessário fazer upgrade manual de um cluster para incorporar novas atualizações do Kubernetes.
- Escalonamento automático de clusters: os clusters do Kubernetes no GDC não podem ajustar automaticamente o tamanho do nó com base nas demandas de carga de trabalho.
- Autopilot do GKE: o GDC não oferece um modo operacional totalmente gerenciado para clusters do Kubernetes para processar a infraestrutura.
- Escalonamento automático vertical de pods: as solicitações e os limites de CPU e memória para pods em um cluster do Kubernetes do GDC não podem ser ajustados automaticamente com base nas demandas de carga de trabalho.
- Multi-Cloud
- Anexar clusters multicloud: o GDC não pode gerenciar clusters do Kubernetes criados em outros ambientes de nuvem.
- Gateway do Connect: o GDC não pode conectar clusters de outros provedores de nuvem com sua Google Cloud identidade para autenticação.
- Ingress de vários clusters: os clusters do Kubernetes no GDC não podem compartilhar recursos de balanceamento de carga entre clusters.
- Operações
- Gerenciamento de recursos multizonal: os clusters e contêineres do Kubernetes no GDC não abrangem várias zonas como um recurso global.
- Suporte a contêineres do Windows: os aplicativos de contêiner no GDC não podem ser executados em ambientes isolados em um host do Windows.
A seguir
- Cargas de trabalho de contêiner no GDC
- Alta disponibilidade para seus apps
- Configurações de cluster do Kubernetes