Em cenários como IA e big data que exigem scale-out frequente, novos nós gastam muito tempo baixando imagens de componentes e aplicações ao ingressar em um cluster. Para melhorar a velocidade de prontidão do nó, armazene previamente componentes e imagens em cache no snapshot de disco de dados. Isso permite que os novos nós carreguem dados diretamente dos discos locais em vez de usar a rede, aumentando significativamente a eficiência do scale-out.
Como funciona
No processo padrão de scale-out, as etapas dependentes de rede abaixo consomem a maior parte do tempo entre a criação do nó e a execução bem-sucedida da aplicação:
Pull de imagem do sistema: O runtime de contêiner (containerd) precisa baixar as imagens necessárias para os Pods do sistema, como Terway e kube-proxy.
Pull de imagem da aplicação: Após o nó ficar pronto, os Pods são agendados nele e o runtime de contêiner deve baixar as imagens de contêiner da aplicação.
Quando um node pool usa um snapshot de disco de dados para scale-out, as operações de carregamento local substituem as operações de download via rede:
Prontidão do nó mais rápida: O script de inicialização verifica primeiro os caminhos locais. Como o snapshot já contém as imagens do sistema pré-carregadas, o nó ignora os processos de download e pull, atingindo o estado Ready mais rapidamente.
Inicialização da aplicação acelerada: Como as imagens da aplicação estão pré-armazenadas em cache no snapshot, quando um Pod é agendado para um novo nó, o runtime de contêiner encontra as imagens necessárias localmente, permitindo uma inicialização rápida da aplicação.
Etapa 1: Preparar um nó para snapshots
Crie uma instância ECS com os componentes principais do ACK e as imagens de aplicação necessários. Em seguida, crie um snapshot a partir do disco de dados dessa instância.
-
Prepare a instância ECS para a criação do snapshot.
-
Crie um node pool no cluster com as seguintes configurações principais. Durante esse processo, o ACK salva automaticamente no disco de dados as imagens de add-ons, como Terway e a imagem do componente kube-proxy.
Logon Type: Configure um par de chaves ou senha para fazer logon na instância.
Expected Number of Nodes: Defina como 1.
-
Data Disk: Adicione pelo menos um disco de dados.
Se você tiver aprovação para o recurso Initialization Settings por meio da lista de permissões, selecione Format and use as a directory of the container runtime. Isso garante o provisionamento do ambiente do runtime de contêiner no disco de dados.
Após o nó ficar pronto, remova-o do cluster. Ao remover o nó, não selecione Release ECS Instance para manter a instância ECS subjacente.
-
-
Faça logon na instância ECS mantida e adicione manualmente os componentes e arquivos de imagem necessários ao disco de dados.
Faça logon na instância ECS e execute o comando
lsblk -fpara visualizar o caminho de montagem do disco de dados, como/var/lib/container.-
Armazene em cache o componente kubelet.
-
Acesse o diretório de montagem do disco de dados e crie um diretório de cache para os componentes do ACK.
cd /var/lib/container mkdir -p ack -
Defina as variáveis de ambiente para sua região e versão do cluster.
# This example uses the cn-shanghai region and version 1.34.1-aliyun.1. Replace them with your actual values. export REGION="cn-shanghai" export KUBE_VERSION="1.34.1-aliyun.1" -
Baixe, extraia e mova o arquivo binário do kubelet para o diretório de cache.
wget http://aliacs-k8s-$REGION.oss-$REGION-internal.aliyuncs.com/public/pkg/kubernetes/kubernetes-$KUBE_VERSION-linux-amd64.tar.gz tar -xvf kubernetes-$KUBE_VERSION-linux-amd64.tar.gz mv pkg/kubernetes /var/lib/container/ack/ -
Limpe os arquivos temporários para manter o snapshot enxuto.
rm kubernetes-$KUBE_VERSION-linux-amd64.tar.gz rm -rf pkg
-
-
(Opcional) Armazene em cache as imagens da aplicação.
Baixe as imagens de aplicação mais usadas para a instância local. Essas imagens serão incluídas no snapshot, acelerando a inicialização dos Pods da sua aplicação.
# You can also use 'docker pull' if Docker is available in your environment. # The following command uses an Nginx image as an example. crictl pull anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
Etapa 2: Criar um snapshot de disco de dados
Crie um snapshot a partir do disco de dados que contém os componentes e imagens armazenados em cache. Esse snapshot pode ser reutilizado para futuros scale-outs de node pool.
-
Acesse ECS console - Instances e defina o status da instância de destino como Stop.
Para obter mais informações sobre como parar uma instância, consulte Parar uma instância .
Após parar a instância, acesse a página de detalhes dela e clique em EBS.
-
Localize o disco de dados que serve como diretório do runtime de contêiner. Na coluna Actions, clique em Create Snapshot e siga as instruções na tela para configurar o snapshot.
Para obter mais informações sobre como configurar um snapshot, consulte Criar um snapshot manualmente .
Etapa 3: Fazer scale-out com o snapshot e verificar os resultados
-
Crie um node pool e aplique o snapshot criado anteriormente. As configurações principais são as seguintes:
-
Operating System: Selecione um sistema operacional conforme necessário.
Atualmente, este recurso não é compatível com o ContainerOS versão 3.5 e posteriores.
Expected Number of Nodes: Defina como 1 ou mais.
-
Data Disk:
Selecione From Data Disk Snapshot e escolha o snapshot criado.
Caso tenha aprovação para o recurso Initialization Settings por meio da lista de permissões, selecione Format and use as a directory of the container runtime. Esse processo de formatação preserva os dados do snapshot.
-
User Data Para sistemas operacionais diferentes do ContainerOS, adicione o seguinte script para ignorar atualizações do
yume acelerar a inicialização do nó.touch /var/.skip-yum
-
-
Depois que os novos nós estiverem prontos, faça logon em um nó e verifique se o cache entrou em vigor com sucesso.
-
Verifique se o cache de imagens está efetivo.
Consulte os logs do kubelet. O cache estará efetivo se os logs não mostrarem registros de pull para as imagens pré-armazenadas em cache.
# If this command returns no output, or if the output does not contain pull records for pre-cached images like Terway or kube-proxy, the cache is effective. journalctl -u kubelet | grep "pulled image" -
Verifique se o cache do kubelet está efetivo.
Consulte o log do
ack-deploy. A ausência da mensagemcheck cached kubernetes failedindica que o cache está efetivo.# If this command returns no output, the cached kubelet was used successfully. cat /var/log/ack-deploy.log |grep "check cached kubernetes failed"
-
Faturamento
A instância ECS temporária usada para criar o snapshot, seus discos de nuvem anexados e o snapshot resultante geram cobranças.
Após concluir o processo, libere prontamente a instância ECS temporária. Gerencie regularmente o ciclo de vida do snapshot e exclua os snapshots desnecessários para reduzir custos.
Perguntas frequentes
Posso usar snapshots antigos após uma atualização?
Não recomendamos isso. A versão do kubelet armazenada em cache no snapshot pode ser incompatível com a nova versão do cluster, impedindo que os nós se registrem corretamente. Após uma atualização de cluster, recomendamos criar um novo snapshot de disco de dados.
Posso armazenar em cache arquivos além do kubelet e imagens de contêiner?
Sim. Qualquer arquivo colocado no caminho do disco de dados será incluído no snapshot. Você pode armazenar em cache outros arquivos dependentes, como arquivos de configuração ou modelos de dados, conforme as necessidades da sua aplicação. No entanto, certifique-se de gerenciar o tamanho e a conformidade do conteúdo dos seus snapshots.