Este documento mostra como resolver problemas comuns com snapshots de pods do GKE e os recursos associados.
Essas informações são importantes para os desenvolvedores de aplicativos e administradores e operadores de plataformas que usam snapshots de pods para fazer checkpoint e restaurar cargas de trabalho. Para mais informações sobre as funções comuns e tarefas de exemplo que referenciamos no Google Cloud conteúdo, consulte Funções e tarefas comuns de usuários do GKE.
Riscos de mutação pós-checkpoint com PVCs
Se o pod usar uma reivindicação de volume permanente (PVC), um risco significativo ocorrerá durante o fluxo de trabalho de checkpoint e retomada: se você configurar uma carga de trabalho para ser retomada imediatamente após um checkpoint (usando o campo postCheckpoint: resume), o aplicativo permanecerá ativo e poderá modificar a PVC após o checkpoint.
- Problema de desligamento normal: após o ciclo de checkpoint e retomada, quando
você exclui um pod, o Kubernetes inicia uma sequência de desligamento normal enviando um sinal
SIGTERMpara o processo principal no contêiner. Muitos aplicativos implementam uma lógica de desligamento normal durante a qual podem acionar rotinas de limpeza para excluir ou atualizar arquivos temporários na PVC. - Falha na restauração: se essas mudanças ocorrerem na PVC após a criação do snapshot do pod, o procedimento de restauração vai esperar o estado da PVC no momento exato do checkpoint, o que pode levar a falhas de restauração ou inconsistência de dados.
- Mitigação recomendada: se o uso de uma PVC for necessário para a carga de trabalho,
não a retome após um checkpoint. Use a configuração
postCheckpoint: stopnaPodSnapshotPolicy. Essa configuração ajuda a garantir que o processo não tenha a oportunidade de realizar gravações auxiliares ou mudanças de estado após a conclusão da fase de checkpoint.
Montagens de ConfigMap e mascaramento de diretório
Ao integrar dados de configuração em um contêiner, o método de montagem pode afetar a integridade de um snapshot.
Se um ConfigMap for montado usando uma montagem de volume padrão, o Kubernetes vai tratar todo o diretório de destino como uma montagem externa. Como as montagens externas são ignoradas durante os snapshots, todo o diretório é excluído do snapshot.
No exemplo a seguir, as mudanças no diretório /etc/my-app/ não são capturadas no snapshot porque todo o diretório é uma montagem externa:
apiVersion: v1
kind: ConfigMap
metadata:
name: my-config
data:
config.json: |
{
"mode": "local"
}
---
apiVersion: v1
kind: Pod
metadata:
name: my-app
spec:
runtimeClassName: gvisor
containers:
- name: my-app-container
image: my-app-image
volumeMounts:
- mountPath: /etc/my-app
name: config-volume
volumes:
- name: config-volume
configMap:
name: my-config
Para resolver esse problema, use um subPath. Um subPath ajuda a garantir que apenas o arquivo de configuração específico seja tratado como uma montagem externa. Essa configuração tem como destino o arquivo exato, o que permite que os arquivos e a estrutura restantes no diretório pai permaneçam parte do sistema de arquivos local do contêiner, que é capturado corretamente durante o processo de checkpoint.
O exemplo a seguir mostra a configuração volumeMounts que usa um subPath:
volumeMounts:
- mountPath: /etc/my-app/config.json
name: config-volume
subPath: config.json
Volumes anônimos implícitos
Algumas imagens de contêiner definem volumes nos metadados usando a instrução VOLUME no Dockerfile. Mesmo que a especificação do pod não defina um volume, o Kubernetes cria automaticamente um volume anônimo para qualquer caminho definido como um volume na imagem de base. Por exemplo, a imagem alpine/git
define /git como um volume implícito.
Esses volumes anônimos são tratados como montagens externas e, como as PVCs, não são verificados. Verifique as imagens de base para garantir que os dados críticos não sejam armazenados em volumes implícitos.