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 pesos 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 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 escalonabilidade além dos limites do GKE ou do Hipercomputador de IA e estão dispostos a aceitar maior atrito operacional para alcançar esses objetivos.

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 que têm requisitos especiais de segurança e escalonabilidade. Por exemplo, o GKE oferece suporte a casos de uso como os seguintes:

  • Execute GPUs em nós confidenciais do Google Kubernetes Engine e acesse vTPMs ou módulos de computação confidencial baseados em hardware nas cargas de trabalho.
  • Use a Federação de Identidade da Carga de Trabalho para GKE para 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 e funcionalidades de observabilidade e solução de problemas 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 dos administradores da plataforma e da equipe do Google. Os recursos de IA são descriptografados apenas em ambientes atestados e verificáveis.

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

Como funciona

Conforme descrito na 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 Google Cloud recursos. Cada nó do GKE executa vários componentes do sistema, como agentes de nós 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 são projetados para executar cargas de trabalho em uma escala muito grande, 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 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 executores vinculados não têm um kubelet e não geram tráfego do servidor da API. Ao criar as instâncias de executores vinculados, é possível 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. Os administradores da plataforma e a equipe de emergência, como os SREs, podem acessar as instâncias usando SSH. Essas instâncias funcionam bem quando você quer manter o acesso de administrador à infraestrutura.
  • Configuração selada: 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 todos os acessos, incluindo a equipe do Google e seus próprios administradores, é possível configurar as instâncias de executores vinculados no modo selado. Essas instâncias seladas têm as seguintes propriedades:
    • Use uma imagem mínima do SO.
    • Use o enclave do Titanium Intelligence para TPUs e a Computação confidencial da NVIDIA para GPUs.
    • Realize a atestação de carga de trabalho e firmware.
    • Valide as assinaturas de imagens de contêineres.
    • Impeça todo o acesso administrativo a instâncias e contêineres.

Independentemente da configuração usada, as instâncias não incluem muitos dos componentes e recursos incluídos nos nós do GKE, como parâmetros de ambiente 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, oferecendo 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 Google Cloud região e vincular essas instâncias 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 selada

Se o caso de uso principal for proteger seus recursos contra todos os acessos, configure os executores vinculados para usar uma configuração selada, 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, com base no Container-Optimized OS, que desativa o acesso SSH, impede o acesso ao shell do contêiner e executa um agente de atestaçã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êineres 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 o código aprovado pode ser executado e os dados sensíveis são processados em enclaves seguros baseados em hardware. As informações de atestação retornadas pelas instâncias verificam se as cargas de trabalho executam o código aprovado e são implantadas nas instâncias corretas.

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

  • Pesos do modelo:

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

  • Consultas e respostas:

    1. Criptografe consultas e respostas usando uma chave do Cloud HSM no Cloud KMS.
    2. Conceda acesso de descriptografia apenas para cargas de trabalho atestadas.
    3. Exija prova de atestação ao enviar dados criptografados entre cargas de trabalho.

A configuração selada é uma camada opcional de segurança para as instâncias de executores vinculados. Assim como na configuração padrão, é possível criar as instâncias seladas em qualquer região e zona. No entanto, as propriedades de segurança das instâncias seladas significam que os administradores e a equipe do Google não podem acessar instâncias de host para solução de 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.