Use discos de arranque secundários para pré-carregar dados ou imagens de contentores

Esta página mostra-lhe como melhorar a latência de arranque da carga de trabalho através da utilização de discos de arranque secundários no Google Kubernetes Engine (GKE) para pré-carregar dados ou imagens de contentores em novos nós. Isto permite que as cargas de trabalho alcancem um início a frio rápido e melhorem a utilização geral dos recursos aprovisionados.

Antes de ler esta página, certifique-se de que conhece o Google Cloud, o Kubernetes, os contentores, o YAML, o tempo de execução do containerd e a CLI Google Cloud.

Vista geral

A partir da versão 1.28.3-gke.1067000 do GKE em clusters padrão e da versão 1.30.1-gke.1329000 do GKE em clusters do Autopilot, pode configurar o conjunto de nós com discos de arranque secundários. Pode indicar ao GKE para aprovisionar os nós e pré-carregá-los com dados, como um modelo de aprendizagem automática (AA) ou uma imagem de contentor. A utilização de imagens de contentores pré-carregadas ou dados num disco secundário tem as seguintes vantagens para as suas cargas de trabalho:

  • Latência reduzida ao extrair imagens de contentores grandes ou transferir dados
  • Escala automática mais rápida
  • Recuperação mais rápida de interrupções, como eventos de manutenção e erros do sistema

As secções seguintes descrevem como configurar o disco de arranque secundário em clusters do GKE Autopilot e Standard.

Como funcionam os discos de arranque secundários

A sua carga de trabalho pode ser iniciada mais rapidamente através da imagem ou dos dados do contentor pré-carregados em discos de arranque secundários. Os discos de arranque secundários têm as seguintes características:

  • Os discos de arranque secundários são discos persistentes suportados por armazenamento de blocos distribuído.
  • O Persistent Disk é instanciado a partir de imagens de disco que cria antecipadamente.
  • Por motivos de escalabilidade, cada nó recebe a sua própria instância de disco persistente criada a partir da imagem de disco. Estas instâncias de disco persistente são eliminadas quando o nó é eliminado.
  • Se a imagem de disco já estiver a ser usada na zona, o tempo de criação de todos os discos subsequentes criados a partir da mesma imagem de disco será inferior.
  • O tipo de disco de arranque secundário é o mesmo que o disco de arranque do nó.
  • O tamanho do disco de arranque secundário é determinado pelo tamanho da imagem do disco.

Normalmente, a adição de discos de arranque secundários aos conjuntos de nós não aumenta o tempo de aprovisionamento dos nós. O GKE aprovisiona discos de arranque secundários a partir da imagem de disco em paralelo com o processo de aprovisionamento de nós.

Prática recomendada:

Para suportar imagens de contentores pré-carregadas, o GKE expande o tempo de execução do containerd com plug-ins que leem as imagens de contentores de discos de arranque secundários. As imagens de contentores são reutilizadas pelas camadas base.

Pré-carregue grandes camadas base no disco de arranque secundário, enquanto as pequenas camadas superiores podem ser extraídas do registo de contentores.

Antes de começar

Antes de começar, certifique-se de que realizou as seguintes tarefas:

  • Ative a API Google Kubernetes Engine.
    • Ative a API Google Kubernetes Engine
  • Se quiser usar a CLI gcloud para esta tarefa, instale-a e, em seguida, inicialize-a. Se instalou anteriormente a CLI gcloud, execute gcloud components update para obter a versão mais recente.

Requisitos

Os seguintes requisitos aplicam-se à utilização do disco de arranque secundário:

  1. Os seus clusters estão a executar a versão 1.28.3-gke.1067000 do GKE no GKE Standard ou a versão 1.30.1-gke.1329000 no GKE Autopilot.
  2. Quando modifica a imagem do disco, tem de criar um novo conjunto de nós. A atualização da imagem de disco em nós existentes não é suportada.
  3. Configure a transmissão de imagens para usar a funcionalidade de disco de arranque secundário.
  4. Use o SO otimizado para contentores com uma imagem de nó do containerd. Por predefinição, os nós do Autopilot usam esta imagem de nó.

  5. Prepare a imagem de disco com dados prontos durante o tempo de compilação ou com imagens de contentores pré-carregadas. Certifique-se de que o cluster tem acesso à imagem do disco para carregar nos nós.

    Prática recomendada:

    Automatize a imagem de disco num pipeline de CI/CD.

Limitações

Não pode atualizar os discos de arranque secundários para nós existentes. Para anexar uma nova imagem de disco, crie um novo conjunto de nós.

Preços

Quando cria pools de nós com discos de arranque secundários, o GKE anexa um Persistent Disk a cada nó no pool de nós. Os Persistent Disks são faturados com base nos preços dos discos do Compute Engine.

Prepare a imagem do disco de arranque secundário

Para preparar a imagem do disco de arranque secundário, escolha o separador Imagens para pré-carregar imagens de contentores ou escolha o separador Dados para pré-carregar dados e, em seguida, conclua as seguintes instruções:

Imagens

O GKE fornece uma ferramenta denominada gke-disk-image-builder para criar uma máquina virtual (VM), extrair as imagens de contentores num disco e, em seguida, criar uma imagem do disco.

Para criar uma imagem de disco com várias imagens de contentores pré-carregadas, conclua os seguintes passos:

  1. Crie um contentor do Cloud Storage para armazenar os registos de execução do gke-disk-image-builder.
  2. Crie uma imagem de disco com o gke-disk-image-builder.
go run ./cli \
    --project-name=PROJECT_ID \
    --image-name=DISK_IMAGE_NAME \
    --zone=LOCATION \
    --gcs-path=gs://LOG_BUCKET_NAME \
    --disk-size-gb=10 \
    --container-image=docker.io/library/python:latest \
    --container-image=docker.io/library/nginx:latest

Substitua o seguinte:

  • PROJECT_ID: o nome do seu Google Cloud projeto.
  • DISK_IMAGE_NAME: o nome da imagem do disco. Por exemplo, nginx-python-image.
  • LOCATION: a localização do cluster.
  • LOG_BUCKET_NAME: o nome do contentor do Cloud Storage para armazenar os registos de execução. Por exemplo,gke-secondary-disk-image-logs/.

Quando cria uma imagem de disco com o comando gke-disk-image-builder, Google Cloud cria vários recursos para concluir o processo (por exemplo, uma instância de VM, um disco temporário e um disco persistente). Após a execução, o criador de imagens limpa todos os recursos, exceto a imagem do disco que criou.

Dados

Crie uma imagem de disco personalizada como origem de dados concluindo os seguintes passos:

  1. Crie uma VM com um disco em branco.
  2. Use o SSH para estabelecer ligação à VM.
    1. Monte o disco em branco.
    2. Transfira os dados para o disco em branco.
  3. Crie uma imagem personalizada a partir do disco.

Configure o disco de arranque secundário

Pode configurar o disco de arranque secundário num cluster do GKE Autopilot ou Standard.

Práticas recomendadas:

Use um cluster do Autopilot para uma experiência do Kubernetes totalmente gerida. Para escolher o modo de funcionamento do GKE mais adequado às suas cargas de trabalho, consulte o artigo Escolha um modo de funcionamento do GKE.

Utilize o GKE Autopilot

Nesta secção, cria uma lista de autorizações de imagens de disco para permitir a imagem de disco num cluster do GKE Autopilot existente. Em seguida, modifique o seletor de nós do pod para usar um disco de arranque secundário.

Permita as imagens de disco no seu projeto

Nesta secção, cria um GCPResourceAllowlist para permitir que o GKE crie nós com discos de arranque secundários a partir das imagens de disco no seu projetoGoogle Cloud .

  1. Guarde o seguinte manifesto como allowlist-disk.yaml:

    apiVersion: "node.gke.io/v1"
kind: GCPResourceAllowlist
metadata:
  name: gke-secondary-boot-disk-allowlist
spec:
  allowedResourcePatterns:
  - "projects/PROJECT_ID/global/images/.*"

    Substitua PROJECT_ID pelo ID do seu projeto para alojar a imagem do disco.

  2. Aplique o manifesto:

    kubectl apply -f allowlist-disk.yaml

    O GKE cria nós com discos de arranque secundários a partir de todas as imagens de disco no projeto.

Atualize o seletor de nós do pod para usar um disco de arranque secundário

Nesta secção, vai modificar a especificação do pod para que o GKE crie os nós com o disco de arranque secundário.

  1. Adicione um nodeSelector ao seu modelo de pod:

    nodeSelector:
    cloud.google.com.node-restriction.kubernetes.io/gke-secondary-boot-disk-DISK_IMAGE_NAME: CONTAINER_IMAGE_CACHE.PROJECT_ID

    Substitua o seguinte:

    • DISK_IMAGE_NAME: o nome da imagem de disco.
    • PROJECT_ID: o ID do projeto para alojar a imagem do disco.

  2. Use o comando kubectl apply para aplicar a especificação do Kubernetes com o modelo de pod.

  3. Confirme se a cache do disco de arranque secundário está em utilização:

    kubectl get events --all-namespaces

    O resultado é semelhante ao seguinte:

    75s         Normal      SecondaryDiskCachin
node/gke-pd-cache-demo-default-pool-75e78709-zjfm   Image
gcr.io/k8s-staging-jobsejt/pytorch-mnist:latest is backed by secondary disk cache

  4. A forma mais fiável de confirmar que a cache do disco de arranque secundário está a ser usada:

    Consulte o registo do nó que lhe interessa com este nome de registo:

    logName="projects/PROJECT_ID/logs/gcfs-snapshotter"

    Substitua PROJECT_ID pelo ID do seu Google Cloud projeto.

    O registo semelhante a: Image gcr.io/k8s-staging-jobsejt/pytorch-mnist:latest is backed by secondary boot disk caching by 100.0%... é uma indicação de que foi usada a cache do disco de arranque secundário.

  5. Verifique a latência de obtenção de imagens:

    kubectl describe pod POD_NAME

    Substitua POD_NAME pelo nome do pod.

    O resultado é semelhante ao seguinte:

    …
  Normal  Pulled     15m   kubelet            Successfully pulled image "docker.io/library/nginx:latest" in 0.879149587s
…

A latência de obtenção de imagens esperada para a imagem do contentor em cache deve ser significativamente reduzida, independentemente do tamanho da imagem.

Use o GKE Standard

Para criar um cluster padrão do GKE e um conjunto de nós, conclua as seguintes instruções, escolhendo o separador Imagens ou Dados com base no facto de querer pré-carregar imagens de contentores ou pré-carregar dados no disco de arranque secundário:

Imagens

Para configurar um disco de arranque secundário, use a Google Cloud CLI ou o Terraform:

gcloud

  1. Crie um cluster padrão do GKE com a transmissão de imagens ativada:

    gcloud container clusters create CLUSTER_NAME \
    --location=LOCATION \
    --cluster-version=VERSION \
    --enable-image-streaming

    Substitua o seguinte:

    • CLUSTER_NAME: o nome do cluster.
    • LOCATION: a localização do cluster.
    • VERSION: a versão do GKE a usar. A versão do GKE tem de ser 1.28.3-gke.1067000 ou posterior.

  2. Crie um node pool com um disco de arranque secundário no mesmo projeto:

    gcloud container node-pools create NODE_POOL_NAME \
--cluster=CLUSTER_NAME \
--location LOCATION \
--enable-image-streaming \
--secondary-boot-disk=disk-image=global/images/DISK_IMAGE_NAME,mode=CONTAINER_IMAGE_CACHE

    Substitua o seguinte:

    • NODE_POOL_NAME: o nome do node pool.
    • CLUSTER_NAME: o nome do cluster existente.
    • LOCATION: a zona ou as zonas de computação separadas por vírgulas do cluster.
    • DISK_IMAGE_NAME: o nome da imagem de disco.

    Para criar um conjunto de nós com um disco de arranque secundário a partir da imagem do disco num projeto diferente, conclua os passos em Use um disco de arranque secundário num projeto diferente.

  3. Adicione um nodeSelector ao seu modelo de pod:

    nodeSelector:
    cloud.google.com/gke-nodepool: NODE_POOL_NAME

  4. Confirme se a cache do disco de arranque secundário está em utilização:

    kubectl get events --all-namespaces

    O resultado é semelhante ao seguinte:

    75s       Normal      SecondaryDiskCachin
node/gke-pd-cache-demo-default-pool-75e78709-zjfm Image
gcr.io/k8s-staging-jobsejt/pytorch-mnist:latest is backed by secondary disk cache

  5. A forma mais fiável de confirmar que a cache do disco de arranque secundário está a ser usada:

    Consulte o registo do nó que lhe interessa com este nome de registo:

    logName="projects/PROJECT_ID/logs/gcfs-snapshotter"

    Substitua PROJECT_ID pelo ID do seu Google Cloud projeto.

    O registo semelhante a: Image gcr.io/k8s-staging-jobsejt/pytorch-mnist:latest is backed by secondary boot disk caching by 100.0%... é uma indicação de que foi usada a cache do disco de arranque secundário.

  6. Verifique a latência de obtenção de imagens executando o seguinte comando:

    kubectl describe pod POD_NAME

    Substitua POD_NAME pelo nome do pod.

    O resultado é semelhante ao seguinte:

    …
  Normal  Pulled     15m   kubelet            Successfully pulled image "docker.io/library/nginx:latest" in 0.879149587s
…

A latência de obtenção de imagens esperada para a imagem do contentor em cache não deve exceder alguns segundos, independentemente do tamanho da imagem.

Terraform

  1. Para criar um cluster com o node pool predefinido através do Terraform, consulte o seguinte exemplo:

    resource "google_container_cluster" "default" {
  name               = "default"
  location           = "us-central1-a"
  initial_node_count = 1

  # secondary_boot_disks require GKE 1.28.3-gke.106700 or later, which should
  # be true for all release channels apart from EXTENDED.
  # If required, Use `release_channel = "EXTENDED"` and set `min_master_version`.
}

  2. Crie um node pool com um disco de arranque secundário no mesmo projeto:

    resource "google_container_node_pool" "secondary-boot-disk-container" {
  name               = "secondary-boot-disk-container"
  location           = "us-central1-a"
  cluster            = google_container_cluster.default.name
  initial_node_count = 1

  node_config {
    machine_type = "e2-medium"
    image_type   = "COS_CONTAINERD"
    gcfs_config {
      enabled = true
    }
    secondary_boot_disks {
      disk_image = ""
      mode       = "CONTAINER_IMAGE_CACHE"
    }
  }
}

    Para saber mais sobre a utilização do Terraform, consulte o artigo Compatibilidade do Terraform com o GKE.

  3. Adicione um nodeSelector ao seu modelo de pod:

    nodeSelector:
    cloud.google.com/gke-nodepool: NODE_POOL_NAME

  4. Confirme se a cache do disco de arranque secundário está em utilização:

    kubectl get events --all-namespaces

    O resultado é semelhante ao seguinte:

    75s       Normal      SecondaryDiskCachin
node/gke-pd-cache-demo-default-pool-75e78709-zjfm Image
gcr.io/k8s-staging-jobsejt/pytorch-mnist:latest is backed by secondary disk cache

  5. Verifique a latência de obtenção de imagens executando o seguinte comando:

    kubectl describe pod POD_NAME

    Substitua POD_NAME pelo nome do pod.

    O resultado é semelhante ao seguinte:

    …
  Normal  Pulled     15m   kubelet            Successfully pulled image "docker.io/library/nginx:latest" in 0.879149587s
…

A latência de obtenção de imagens esperada para a imagem do contentor em cache não deve demorar mais do que alguns segundos, independentemente do tamanho da imagem.

Para saber mais sobre a utilização do Terraform, consulte o artigo Compatibilidade do Terraform com o GKE.

Dados

Pode configurar um disco de arranque secundário e pré-carregar dados através da CLI Google Cloud ou do Terraform:

gcloud

  1. Crie um cluster padrão do GKE com a transmissão de imagens ativada:

    gcloud container clusters create CLUSTER_NAME \
    --location=LOCATION \
    --cluster-version=VERSION \
    --enable-image-streaming

    Substitua o seguinte:

    • CLUSTER_NAME: o nome do cluster.
    • LOCATION: a localização do cluster.
    • VERSION: a versão do GKE a usar. A versão do GKE tem de ser 1.28.3-gke.1067000 ou posterior.

  2. Crie um node pool com um disco de arranque secundário através da flag --secondary-boot-disk:

    gcloud container node-pools create NODE_POOL_NAME \
--cluster=CLUSTER_NAME \
--location LOCATION \
--enable-image-streaming \
--secondary-boot-disk=disk-image=global/images/DISK_IMAGE_NAME

    Substitua o seguinte:

    • NODE_POOL_NAME: o nome do node pool.
    • CLUSTER_NAME: o nome do cluster existente.
    • LOCATION: a zona ou as zonas de computação separadas por vírgulas do cluster.
    • DISK_IMAGE_NAME: o nome da imagem de disco.

    Para criar um conjunto de nós com um disco de arranque secundário a partir da imagem do disco num projeto diferente, conclua os passos em Use um disco de arranque secundário num projeto diferente.

    O GKE cria um node pool onde cada nó tem um disco secundário com dados pré-carregados. O GKE anexa e monta o disco de arranque secundário no nó.

  3. Para aceder aos dados, monte a imagem de disco de arranque secundária nos contentores do pod através de uma montagem de volume hostPath. Defina /usr/local/data_path_sbd para o caminho no seu contentor onde quer que os dados residam:

    apiVersion: v1
kind: Pod
metadata:
  name: pod-name
spec:
  containers:
  ...
  volumeMounts:
  - mountPath: /usr/local/data_path_sbd
    name: data-path-sbd
...
volumes:
  - name: data-path-sbd
    hostPath:
        path: /mnt/disks/gke-secondary-disks/gke-DISK_IMAGE_NAME-disk

    Substitua DISK_IMAGE_NAME pelo nome da imagem de disco.

Terraform

  1. Para criar um cluster com o node pool predefinido através do Terraform, consulte o seguinte exemplo:

    resource "google_container_cluster" "default" {
  name               = "default"
  location           = "us-central1-a"
  initial_node_count = 1

  # secondary_boot_disks require GKE 1.28.3-gke.106700 or later, which should
  # be true for all release channels apart from EXTENDED.
  # If required, Use `release_channel = "EXTENDED"` and set `min_master_version`.
}

  2. Crie um node pool com um disco de arranque secundário no mesmo projeto:

    resource "google_container_node_pool" "secondary-boot-disk-data" {
  name               = "secondary-boot-disk-data"
  location           = "us-central1-a"
  cluster            = google_container_cluster.default.name
  initial_node_count = 1

  node_config {
    machine_type = "e2-medium"
    image_type   = "COS_CONTAINERD"
    gcfs_config {
      enabled = true
    }
    secondary_boot_disks {
      disk_image = ""
    }
  }
}

    Para saber mais sobre a utilização do Terraform, consulte o artigo Compatibilidade do Terraform com o GKE.

  3. Para aceder aos dados, monte a imagem de disco de arranque secundária nos contentores do pod através de uma montagem de volume hostPath. Defina /usr/local/data_path_sbd para o caminho no seu contentor onde quer que os dados residam:

    apiVersion: v1
kind: Pod
metadata:
  name: pod-name
spec:
  containers:
  ...
  volumeMounts:
  - mountPath: /usr/local/data_path_sbd
    name: data-path-sbd
...
volumes:
  - name: data-path-sbd
    hostPath:
        path: /mnt/disks/gke-secondary-disks/gke-DISK_IMAGE_NAME-disk

    Substitua DISK_IMAGE_NAME pelo nome da imagem de disco.

Escala automática do cluster com discos de arranque secundários

Para criar um node pool e configurar o dimensionamento automático do cluster num disco de arranque secundário, use a Google Cloud CLI:

  gcloud container node-pools create NODE_POOL_NAME \
      --cluster=CLUSTER_NAME \
      --location LOCATION \
      --enable-image-streaming \
      --secondary-boot-disk=disk-image=global/images/DISK_IMAGE_NAME,mode=CONTAINER_IMAGE_CACHE \
      --enable-autoscaling \
      --num-nodes NUM_NODES \
      --min-nodes MIN_NODES \
      --max-nodes MAX_NODES

Substitua o seguinte:

  • NODE_POOL_NAME: o nome do node pool.
  • CLUSTER_NAME: o nome do cluster existente.
  • LOCATION: a zona ou as zonas de computação separadas por vírgulas do cluster.
  • DISK_IMAGE_NAME: o nome da imagem de disco.
  • MIN_NODES: o número mínimo de nós a dimensionar automaticamente para o node pool especificado por zona. Para especificar o número mínimo de nós para todo o conjunto de nós nas versões 1.24 e posteriores do GKE, use --total-min-nodes. As flags --total-min-nodes e --total-max-nodes são mutuamente exclusivas com as flags --min-nodes e --max-nodes.
  • MAX_NODES: o número máximo de nós a dimensionar automaticamente para o node pool especificado por zona. Para especificar o número máximo de nós para todo o conjunto de nós nas versões 1.24 e posteriores do GKE, use --total-max-nodes. As flags --total-min-nodes e --total-max-nodes são mutuamente exclusivas com as flags --min-nodes e --max-nodes.

Aprovisionamento automático de nós com discos de arranque secundários

No GKE 1.30.1-gke.1329000 e posterior, pode configurar o aprovisionamento automático de nós para criar e eliminar automaticamente conjuntos de nós de forma a satisfazer as exigências de recursos das suas cargas de trabalho.

  1. Crie um recurso personalizado de lista de autorizações de imagem de disco para o disco de arranque secundário para a administração de contas automática de nós do GKE semelhante ao seguinte:

    apiVersion: "node.gke.io/v1"
kind: GCPResourceAllowlist
metadata:
  name: gke-secondary-boot-disk-allowlist
spec:
  allowedResourcePatterns:
  - "projects/<PROJECT_ID>/global/images/.*"

    Substitua PROJECT_ID pelo ID do seu projeto para alojar a imagem do disco.

  2. Para implementar o recurso personalizado da lista de autorizações no cluster, execute o seguinte comando:

    kubectl apply -f ALLOWLIST_FILE

    Substitua ALLOWLIST_FILE pelo nome do ficheiro do manifesto.

  3. Atualize o seletor de nós do pod para usar o disco de arranque secundário:

    nodeSelector:
    cloud.google.com.node-restriction.kubernetes.io/gke-secondary-boot-disk-DISK_IMAGE_NAME:CONTAINER_IMAGE_CACHE.PROJECT_ID

    Substitua o seguinte:

    • DISK_IMAGE_NAME: o nome da imagem de disco.
    • PROJECT_ID: o ID do projeto para alojar a imagem do disco.

Use um disco de arranque secundário num projeto diferente

Quando cria um conjunto de nós com um disco de arranque secundário, pode indicar ao GKE para usar a imagem do disco num projeto diferente através da flag --secondary-boot-disk.

  1. Crie um node pool com um disco de arranque secundário a partir da imagem de disco num projeto diferente usando a flag --secondary-boot-disk. Por exemplo:

    gcloud beta container node-pools create NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location LOCATION \
    --enable-image-streaming \
    --secondary-boot-disk=disk-image=projects/IMAGE_PROJECT_ID/global/images/DISK_IMAGE_NAME,mode=CONTAINER_IMAGE_CACHE

    Substitua o seguinte:

    • DISK_IMAGE_NAME: o nome da imagem de disco.
    • IMAGE_PROJECT_ID: o nome do projeto ao qual a imagem do disco pertence.

    O GKE cria um node pool onde cada nó tem um disco secundário com dados pré-carregados. O GKE anexa e monta o disco de arranque secundário no nó.

  2. Conceda acesso a imagens de disco pertencentes a um projeto diferente adicionando funções de "Utilizador de imagens de computação" para as contas de serviço do cluster:

    • Conta de serviço de computação predefinida: CLUSTER_PROJECT_NUMBER@cloudservices.gserviceaccount.com
    • Conta de serviço do GKE: service-CLUSTER_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com
    gcloud projects add-iam-policy-binding IMAGE_PROJECT_ID \
    --member serviceAccount:CLUSTER_PROJECT_NUMBER@cloudservices.gserviceaccount.com \
    --role roles/compute.imageUser

gcloud projects add-iam-policy-binding IMAGE_PROJECT_ID \
    --member serviceAccount:service-CLUSTER_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com \
    --role roles/compute.imageUser

O que se segue?