O Google Distributed Cloud (GDC) isolado por air gap oferece um serviço gerenciado do Kubernetes com o Google Kubernetes Engine (GKE) Enterprise Edition, permitindo implantar e executar cargas de trabalho de contêineres usando metodologias padrão do setor do Kubernetes. O GKE no GDC traz os principais recursos e funcionalidades do GKE Enterprise para um ambiente desconectado. Outros recursos do GKE Enterprise vão estar disponíveis para o GKE no GDC com o tempo.
O GKE no GDC oferece recursos corporativos, como:
- Gerenciamento do ciclo de vida de vários clusters
- Distribuição do Kubernetes com suporte total
- Visibilidade de custo
- Gerenciamento de várias equipes
- Gerenciamento de configurações com base em GitOps
- Malha de serviço gerenciada
- Controle da política
Todos esses recursos vêm padrão com o GKE na GDC e estão disponíveis para uso com clusters criados pelo serviço gerenciado do Kubernetes.
Para fins de documentação, os clusters do GKE no GDC são chamados de clusters do Kubernetes ou clusters.
Arquitetura do cluster do GDC
Os clusters do Kubernetes são separados logicamente para oferecer diferentes domínios de falha e garantias de isolamento. Em alguns casos, eles são até mesmo separados fisicamente. Cada organização no GDC tem um conjunto dedicado de clusters do Kubernetes. Os seguintes tipos de cluster estão disponíveis especificamente para suas cargas de trabalho e serviços em cada organização:
- Cluster de infraestrutura da organização: executa os componentes do plano de controle e do plano de dados da organização. Ele também hospeda o servidor da API de gerenciamento em que todas as cargas de trabalho e serviços não conteinerizados são implantados.
- Cluster do Kubernetes: executa cargas de trabalho baseadas em contêineres para a organização. O número de nós de trabalho depende da utilização do cluster. É possível escalonar conforme as necessidades evoluem. Um cluster do Kubernetes às vezes é chamado de cluster de usuário no Distributed Cloud.
Quando o operador de infraestrutura (IO) cria uma organização, o GDC gera automaticamente o cluster de infraestrutura da organização. A configuração inicial do cluster de infraestrutura da organização é definida durante a criação da organização.
Como administrador, você cria e gerencia clusters do Kubernetes. Esta seção de tópicos aborda o gerenciamento de clusters do Kubernetes. Todas as cargas de trabalho conteinerizadas do Kubernetes são executadas em um cluster do Kubernetes. Para mais informações sobre como criar e gerenciar contêineres em um cluster do Kubernetes, consulte a seção Implantar cargas de trabalho de contêineres.
Um cluster do Kubernetes consiste em um plano de controle e máquinas de worker chamadas de nós. O plano de controle e os nós compõem o sistema de orquestração de clusters do Kubernetes. O GKE na GDC gerencia toda a infraestrutura subjacente dos clusters, incluindo o plano de controle e todos os componentes do sistema. Você é responsável por gerenciar os nós de trabalho que executam suas cargas de trabalho conteinerizadas.
O diagrama a seguir mostra a arquitetura de um cluster do Kubernetes:
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 na 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. Se você preferir, também é possível fazer o upgrade 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 de API do Kubernetes das seguintes maneiras:
- Chamadas diretas: KRM
- Chamadas indiretas: clientes de linha de comando do Kubernetes, como
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 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 gerencia e recebe atualizações sobre o status informado de cada nó.
Um nó executa os serviços necessários para a compatibilidade dos 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 no 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.
Limitações do GKE no GDC
As seguintes funcionalidades do GKE são limitações não disponíveis para GKE no GDC:
- Conectar gateway
- Como anexar clusters multicloud
- Autorização binária
- Transferência de dados em vários clusters