Sobre o hipercluster do GKE

Muitos clientes do GKE executam cargas de trabalho de IA/ML em grande escala ou têm propriedade intelectual (PI) sensível, como ponderações de modelos proprietários. Este documento descreve uma arquitetura de infraestrutura que executa contêineres em instâncias remotas que podem ser executadas em várias regiões e são gerenciadas por nós no seu cluster. Essa infraestrutura vinculada, incluindo as várias imagens e recursos do sistema operacional (SO), é chamada de GKE Hypercluster.

O GKE Hypercluster é destinado a clientes que querem segurança e escalabilidade além dos limites do GKE ou do Hipercomputador de IA e estão dispostos a aceitar mais atrito operacional para atingir essas metas.

Quando usar o GKE Hypercluster

Por padrão, os clusters do GKE são projetados para atender aos requisitos da maioria das cargas de trabalho de IA de produção, incluindo aquelas com requisitos especiais de segurança e escalonabilidade. Por exemplo, o GKE oferece suporte a casos de uso como estes:

  • Execute GPUs em nós confidenciais do Google Kubernetes Engine e acesse vTPMs ou módulos de computação confidencial baseados em hardware nas suas cargas de trabalho.
  • Use a Federação de Identidade da Carga de Trabalho para GKE a fim de restringir o acesso a dados criptografados a identidades autorizadas específicas.
  • Implante nós de TPU e GPU com base na capacidade disponível usando ComputeClasses e a criação automática de pool de nós.
  • Controle e observe qualquer acesso da equipe do Google usando a Aprovação de acesso, a transparência no acesso e a autoridade do plano de controle do GKE.

A infraestrutura vinculada no GKE Hypercluster foi projetada para casos de uso específicos de segurança e escalonabilidade que exigem recursos além dos limites atuais da arquitetura típica do GKE. Por design, alguns recursos de observabilidade, solução de problemas e do GKE não estão disponíveis para a infraestrutura vinculada. Essa infraestrutura modifica a arquitetura típica do cluster do GKE para atender aos seguintes casos de uso especializados:

  • Proteja modelos e consultas contra ameaças internas: impeça o acesso a pesos de modelos proprietários ou consultas e respostas de inferência sensíveis por administradores da plataforma e funcionários do Google. Os recursos de IA são descriptografados apenas em ambientes atestados e verificáveis.

  • Executar cargas de trabalho de IA em várias regiões: implante cargas de trabalho em uma escala que vai além dos limites de escalonamento de nós compatíveis. Crie e use a infraestrutura de aceleradores em qualquer região com capacidade disponível, incluindo locais fora da região ou zona do cluster.

Como funciona

Conforme descrito em Arquitetura do cluster do GKE, um cluster do modo Standard tem um plano de controle regional ou zonal que atende à API Kubernetes e gerencia todos os nós e pools de nós no cluster. Todos os nós em um cluster usam uma rede VPC específica, que também pode ser usada por outros recursos do Google Cloud . Cada nó do GKE executa vários componentes do sistema, como agentes de nó kubelet, agentes de geração de registros e métricas e outros componentes do Kubernetes e do GKE.

Em contraste, o GKE Hypercluster usa instâncias chamadas executores vinculados que não são registradas como objetos Node no servidor da API Kubernetes. Essas instâncias têm as seguintes propriedades:

  • Nenhum agente do Kubernetes e um conjunto mínimo de componentes do GKE.
  • Imagens de SO especializadas com base no caso de uso. Nenhuma imagem de nó do GKE.
  • As instâncias usam uma rede VPC separada e dedicada.

Os executores vinculados são gerenciados por nós de controle no cluster que vinculam o executor ao cluster. Os nós de controle executam componentes do sistema, como os processos kubelet. Um único nó de controle pode ser vinculado a vários executores. Esses executores vinculados foram projetados para executar cargas de trabalho em grande escala, como um job de treinamento que exige mais energia do que o data center na região do cluster pode fornecer.

Durante a configuração da infraestrutura, você cria executores com uma configuração específica com base no seu caso de uso e vincula as instâncias a nós de controle dedicados no cluster. A API Kubernetes precisa gerenciar apenas os nós de controle, porque as instâncias de execução vinculadas não têm um kubelet e não geram tráfego do servidor da API. Ao criar instâncias de runner vinculadas, você pode configurá-las de uma das seguintes maneiras:

  • Configuração padrão: por padrão, as instâncias vinculadas são VMs do Compute Engine que executam uma imagem do Container-Optimized OS. Administradores da plataforma e pessoal de emergência, como SREs, podem acessar as instâncias usando SSH. Essas instâncias são úteis quando você quer manter o acesso de administrador à infraestrutura.
  • Configuração isolada: algumas cargas de trabalho de IA processam dados sensíveis, como pesos de modelos proprietários e consultas criptografadas. Em situações em que você precisa proteger seus recursos de IA contra todo tipo de acesso, incluindo funcionários do Google e seus próprios administradores, é possível configurar as instâncias de execução vinculadas no modo isolado. Essas instâncias seladas têm as seguintes propriedades:
    • Use uma imagem de SO mínima.
    • Use o enclave do Titanium Intelligence para TPUs e a computação confidencial da NVIDIA para GPUs.
    • Realizar atestação de firmware e no nível da carga de trabalho.
    • Validar assinaturas de imagens de contêiner.
    • Impeça todo o acesso administrativo a instâncias e contêineres.

Independente da configuração usada, as instâncias não incluem muitos dos componentes e recursos que estão nos nós do GKE, como parâmetros de tempo de execução de TPU específicos do GKE ou agentes de geração de registros e monitoramento do GKE.

Sobre a configuração padrão

Por padrão, as instâncias criadas para o GKE Hypercluster são projetadas para executar cargas de trabalho de produção e fornecer mecanismos semelhantes aos nós típicos do GKE para fins de solução de problemas e resposta a emergências. As instâncias são executadas em tipos de máquinas do Compute Engine e usam uma imagem do Container-Optimized OS. Durante incidentes como interrupções ou falhas, os administradores podem acessar diretamente as instâncias para resolver problemas. Ao contrário dos nós do Kubernetes, as instâncias não executam muitos dos componentes do sistema que ativam os recursos do Kubernetes e do GKE, o que resulta em mais recursos alocáveis em cada instância.

É possível criar instâncias em qualquer região Google Cloud e vinculá-las a nós de controle no cluster. Os nós de controle executam muitas das funções do plano de controle do Kubernetes, gerenciando o ciclo de vida das cargas de trabalho implantadas.

Sobre a configuração isolada

Se o principal caso de uso for proteger seus recursos de todo o acesso, você poderá configurar os executores vinculados para usar uma configuração isolada, o que resulta em instâncias com as seguintes propriedades de segurança:

  • Cada instância é um ambiente de execução confiável (TEE) baseado em tecnologias específicas:
  • As instâncias executam uma imagem mínima do SO, baseada no Container-Optimized OS, que desativa o acesso SSH, impede o acesso ao shell do contêiner e executa um agente de comprovação.
  • Você define uma política que especifica exatamente quais cargas de trabalho podem ser executadas nas instâncias. Por exemplo, é possível exigir que as cargas de trabalho usem resumos de imagens de contêiner assinados ou tenham uma especificação de pod específica.
  • Um agente de atestação envia medições de firmware e carga de trabalho para o Google Cloud Attestation e retorna tokens de resultados de declarações de atestação verificáveis.

As instâncias resultantes fornecem ambientes restritos e validados em que apenas códigos aprovados podem ser executados e dados sensíveis são processados em enclaves seguros baseados em hardware. As informações de atestado retornadas pelas instâncias verificam se as cargas de trabalho executam código aprovado e são implantadas nas instâncias corretas.

É possível usar essas instâncias isoladas para proteger seus modelos, consultas e respostas criptografados das seguintes maneiras:

  • Pesos do modelo:

    1. Criptografar pesos de modelo usando uma chave do Cloud HSM no Cloud KMS.
    2. Armazene pesos de modelo criptografados no Cloud Storage.
    3. Conceda acesso de leitura ao bucket somente a cargas de trabalho atestadas.
    4. Conceda acesso à chave de descriptografia apenas a cargas de trabalho atestadas.

  • Consultas e respostas:

    1. Criptografar consultas e respostas usando uma chave do Cloud HSM no Cloud KMS.
    2. Conceda acesso de descriptografia apenas a cargas de trabalho atestadas.
    3. Exigir prova de atestado ao enviar dados criptografados entre cargas de trabalho.

A configuração isolada é uma camada opcional de segurança para as instâncias de runner vinculadas. Assim como na configuração padrão, é possível criar as instâncias hermeticamente isoladas em qualquer região e zona. No entanto, as propriedades de segurança das instâncias protegidas significam que administradores e funcionários do Google não podem acessar instâncias de host para solucionar problemas.

Qualificação

O GKE Hypercluster foi projetado para casos de uso específicos de IA/ML que não podem ser atendidos pela arquitetura e pelos recursos típicos do cluster do GKE. Os clientes que usam o GKE Hypercluster têm requisitos atípicos de segurança e escalonabilidade. O GKE Hypercluster está disponível apenas para clientes qualificados do GKE. Para verificar se você se qualifica e solicitar acesso, entre em contato com sua equipe de conta dedicada.