Acerca das imagens instantâneas de pods do GKE

Os instantâneos de pods do Google Kubernetes Engine (GKE) ajudam a melhorar a latência de arranque da carga de trabalho restaurando instantâneos de pods em execução. Uma captura instantânea do pod guarda todo o estado do pod, incluindo as alterações à memória e ao sistema de ficheiros. Quando cria novas réplicas, estas são restauradas a partir do instantâneo, o que permite que a carga de trabalho seja retomada em vez de começar a partir de um novo estado.

Este documento fornece uma vista geral conceptual das capturas instantâneas de pods do GKE. Para saber como ativar e usar esta funcionalidade, consulte o artigo Restaurar a partir de uma captura instantânea do Pod.

Quando usar as capturas de ecrã de pods

Use instantâneos de pods para cargas de trabalho com longos tempos de inicialização, por exemplo, cargas de trabalho de inferência de IA que carregam modelos grandes na memória da CPU ou da GPU, ou grandes aplicações que carregam muitas bibliotecas e dependências. Geralmente, os fluxos de trabalho que já têm tempos de arranque rápidos não beneficiam das capturas instantâneas de pods.

Como funcionam os instantâneos do Pod

As capturas instantâneas de pods do GKE armazenam uma cópia exata do estado do processo de um pod num momento específico. Quando são criadas novas réplicas, em vez de inicializar o pod a partir de um estado novo, o pod é restaurado a partir de uma captura de ecrã, retomando a execução a partir do ponto em que a captura de ecrã foi feita.

Para usar as imagens instantâneas de pods, cria definições de recursos personalizados (CRDs) do Kubernetes para configurar declarativamente o comportamento das imagens instantâneas. Um agente executado em cada nó do GKE gere o ciclo de vida da captura instantânea. Com base nas políticas que definir, o agente determina quando criar novos instantâneos e quando usar instantâneos existentes para restaurar novos pods. Um controlador em execução no plano de controlo do GKE limpa as cópias instantâneas obsoletas e resolve os problemas. O Cloud Storage armazena as suas capturas de ecrã do Pod.

Definições de recursos personalizados

As capturas instantâneas de pods são configuradas de forma declarativa com os seguintes CRDs:

  • PodSnapshotStorageConfig: especifica a localização de armazenamento dos instantâneos. Apenas são suportados contentores do Cloud Storage.
  • PodSnapshotPolicy: define que Pods devem ser capturados com base nos seletores de etiquetas do Kubernetes. Este recurso contém a maioria das opções de configuração da funcionalidade, incluindo a forma como as capturas de ecrã são acionadas e as políticas de retenção.
  • PodSnapshotManualTrigger: (opcional) se não usar um acionador de carga de trabalho, define um acionador manual para criar um instantâneo para um pod específico.

Acionadores de instantâneos

Pode acionar uma captura instantânea do pod das seguintes formas:

  • Acionador de carga de trabalho: a aplicação no interior do pod sinaliza ao agente do GKE que está pronta para uma captura de ecrã. Este tipo de acionador é executado uma vez num ciclo de carga de trabalho, por exemplo, num estado de carga de trabalho pronto. Esta abordagem é mais adequada para melhorar a latência de arranque de cargas de trabalho de escalabilidade horizontal.
  • Acionador manual: pode acionar uma captura instantânea a pedido para um pod específico criando um PodSnapshotManualTrigger recurso personalizado. Este tipo de acionador pode ser executado as vezes que forem necessárias. Esta abordagem é mais adequada para situações em que não pode modificar a sua aplicação para sinalizar a disponibilidade.

Correspondência de instantâneos

A correspondência de pods determina se uma captura instantânea de um pod é compatível com um pod específico. Esta correspondência é alcançada através da criação de um hash exclusivo a partir das especificações de tempo de execução essenciais do Pod, também denominadas especificações do Pod refinadas. Em seguida, este hash é incorporado na captura instantânea do Pod. Para que um Pod posterior seja restaurado a partir desta imagem instantânea do Pod, tem de gerar um hash idêntico a partir da sua própria especificação do Pod destilada. Este processo ajuda a garantir que os Pods com pontos de verificação e restaurados são idênticos nas respetivas configurações de tempo de execução.

A destilação simplifica a especificação do Pod, retendo apenas os campos de tempo de execução críticos, como image, e removendo os campos não essenciais, como nodeName ou nodeSelector. Tem de garantir que os valores destes campos essenciais são consistentes entre o pod usado para a criação de pontos de verificação e o pod destinado ao restauro.

Os seguintes campos do objeto Pod influenciam o hash único:

  • metadata:
    • annotations: apenas anotações relevantes para o tempo de execução do gVisor, como anotações que começam com o prefixo dev.gvisor.*.
    • labels: batch.kubernetes.io/job-completion-index
  • spec:
    • volumes: name, volumeSource, hostPath, persistentVolumeClaim e configMap
    • containers:
      • name
      • image
      • command
      • args
      • workingDir
      • ports: name, containerPort, protocol
      • volumeMounts: name, readOnly, recursiveReadOnly, mountPath, subPath, mountPropagation e subPathExpr
      • volumeDevices: name
      • lifecycle: postStart, preStop
      • terminationMessagePath
      • terminationMessagePolicy
      • securityContext (e todos os subcampos)
      • stdin
      • stdinOnce
      • tty
    • initContainers: os mesmos subcampos que containers.
    • dnsPolicy
    • automountServiceAccountToken
    • hostNetwork
    • hostPID
    • hostIPC
    • shareProcessNamespace
    • securityContext
    • dnsConfig
    • runtimeClassName
    • os
    • hostUsers

Os seguintes critérios adicionais têm de corresponder para que a imagem instantânea seja considerada compatível:

  • Hardware: o novo pod tem de ser executado num nó com a mesma série de máquinas e arquitetura que o pod original. A série e a arquitetura da máquina têm de ser iguais. O número de CPUs e a quantidade de memória podem mudar. Os tipos de máquinas E2 não são suportados devido à respetiva arquitetura subjacente dinâmica.
  • Controlo de versões: a versão do kernel do gVisor e a versão do controlador da GPU têm de corresponder.

O GKE gere a compatibilidade de instantâneos. Se o GKE encontrar um instantâneo compatível, restaura o novo pod a partir do instantâneo. Se não existir nenhuma imagem instantânea compatível, o Pod é iniciado normalmente.

Restaure a preparação e o carregamento em segundo plano

Quando um pod é restaurado a partir de uma captura instantânea, o kernel do gVisor é restaurado primeiro, o que normalmente demora alguns segundos. Para minimizar a latência de arranque, a aplicação é retomada imediatamente após o restauro do kernel. Não aguarda que a memória da aplicação seja totalmente carregada. A memória da aplicação é restaurada através de um mecanismo de streaming em segundo plano.

Se a aplicação tentar aceder a uma parte da memória que ainda não foi carregada, ocorre uma falha de página. O gVisor interceta esta falha, pausa a thread da aplicação e obtém imediatamente a página de memória necessária do armazenamento. Esta obtenção a pedido tem prioridade sobre a stream em segundo plano.

Devido a este carregamento em segundo plano, o acesso à memória pode ter uma pequena quantidade de latência durante os primeiros segundos após um restauro se a aplicação precisar de memória que ainda não tenha sido transmitida. Esta latência desaparece quando o estado da memória está totalmente sincronizado.

Este comportamento de carregamento em segundo plano também se aplica ao estado da GPU. Por exemplo, um pod de modelo de linguagem grande (LLM) pode parecer estar no estado Running e responder a verificações de rede, mesmo que a respetiva memória da GPU ainda esteja a ser preenchida. O modelo não vai responder totalmente à inferência até o estado da GPU ser totalmente restaurado. Por este motivo, quando medir a velocidade de restauro, certifique-se de que captura o momento em que o servidor do modelo foi iniciado. Pode verificar quando o servidor do modelo é iniciado através de métricas como o tempo até ao primeiro token (TTFT) ou as sondas de prontidão do pod.

Estado da GPU

As capturas instantâneas de pods suportam a captura do estado das GPUs. Quando aciona uma captura instantânea para um pod que usa GPUs, a ferramenta cuda-checkpoint da NVIDIA guarda o estado da GPU na memória do processo. Isto significa que todos os dados armazenados na GPU, por exemplo, os pesos dos modelos, são incluídos na captura de ecrã. Em seguida, o Pod é pausado e é tirada uma captura de ecrã. Durante a restauração, o processo é invertido.

Uma vez que o estado da GPU é escrito na memória do processo, a utilização de memória do pod aumenta durante as operações de instantâneo e restauro. Deve ter em conta este requisito de memória adicional quando definir limites de memória para os seus pods.

Considerações para agrupamentos restaurados

Do ponto de vista da API Kubernetes, é criado um novo pod. Quando o Pod é iniciado, se existir um instantâneo correspondente para o Pod, o Pod é restaurado a partir desse instantâneo, incluindo a memória original e o estado do processo. No entanto, alguns aspetos do estado do Pod têm de mudar para que funcione como uma instância nova e única.

Considere as seguintes alterações de estado após um restauro:

  • Interfaces de rede: o Pod restaurado recebe um novo endereço IP. Todas as interfaces de rede e trajetos são reconfigurados. As ligações de rede ativas que existiam no momento do instantâneo são fechadas após o restauro. As portas de escuta continuam a funcionar.
  • Nome de anfitrião: o Pod restaurado assume uma nova identidade e recebe um novo nome de anfitrião.
  • Estado da aplicação: o estado da aplicação que tem de ser exclusivo para cada Pod, como IDs de experiências ou sementes de números aleatórios, tem de ser reinicializado após um restauro.
  • Segredos: as chaves de encriptação e os certificados criados antes de o instantâneo ser tirado têm de ser recriados.
  • Variáveis de ambiente: pode alterar as variáveis de ambiente entre uma captura de ecrã e um restauro. No entanto, uma vez que as variáveis de ambiente são armazenadas na memória da aplicação, o GKE Sandbox não consegue encontrá-las e substituí-las de forma fiável. Se a sua carga de trabalho depender de novas variáveis de ambiente após um restauro, o pod tem de as atualizar manualmente. As novas variáveis de ambiente estão disponíveis no ficheiro /proc/gvisor/spec_environ. O formato de ficheiro é o mesmo que /proc/<pid>/environ.

Estado que muda após o restauro

Nem todos os estados são mantidos após o restauro. As seguintes partes do estado do Pod são alteradas para que o Pod possa assumir uma nova identidade:

  • Interfaces de rede: o Pod restaurado recebe um novo endereço IP. Todas as interfaces e trajetos são reconfigurados. As ligações de rede ativas que existiam no momento da captura de ecrã são fechadas após o restauro. As portas de escuta, as ligações de loopback e as ligações de portas de domínio Unix continuam a funcionar.
  • Nome de anfitrião: o Pod restaurado assume uma nova identidade e recebe um novo nome de anfitrião.
  • Hora do relógio de parede: a hora do relógio de parede avança para a hora atual.

Limitações e requisitos

As capturas instantâneas de pods do GKE têm as seguintes limitações:

  • Os pods têm de ser executados no GKE Sandbox porque as capturas instantâneas de pods dependem do tempo de execução do contentor gVisor que o GKE Sandbox fornece.
  • As capturas instantâneas de pods não são compatíveis com tipos de máquinas E2.
  • As capturas instantâneas de pods funcionam com pods de GPU única. Apenas são suportadas as seguintes configurações com várias GPUs:
    • g2-standard-4 (1 x L4)
    • g2-standard-8 (1 x L4)
    • g2-standard-12 (1 x L4)
    • g2-standard-16 (1 x L4)
    • g2-standard-32 (1 x L4)
    • g2-standard-48 (4 x L4)
    • g2-standard-96 (8 x L4)
    • a2-highgpu-1g (1 x A100-40GB)
    • a2-ultragpu-1g (1 x A100-80GB)
    • a3-highgpu-1g (1 x H100-80GB)
  • A utilização parcial da GPU não é suportada. Se um nó tiver várias GPUs, um pod tem de usar todas elas. Por exemplo, não pode usar instantâneos de pods com quatro pods que usem cada um uma GPU numa máquina com quatro GPUs.
  • A utilização do contentor auxiliar do controlador CSI FUSE do Cloud Storage com instantâneos de pods não é suportada.

O que se segue?