Imagens de nós

Esta página descreve as imagens de nós disponíveis para os nós do Google Kubernetes Engine (GKE).

Os nós do GKE Autopilot usam sempre o SO otimizado para contentores com o containerd (cos_containerd), que é o sistema operativo de nós recomendado. Se usar o GKE Standard, pode escolher a imagem do sistema operativo que é executada em cada nó durante a criação do cluster ou do conjunto de nós. Também pode atualizar um cluster padrão existente para usar uma imagem de nó diferente. Para ver instruções sobre como definir a imagem do nó, consulte Especificar uma imagem do nó.

Imagens de nós disponíveis

O GKE oferece as seguintes opções de imagem do nó por SO para o seu cluster:

SO Imagens de nós
SO otimizado para contentores
Ubuntu
Windows Server

SO otimizado para contentores

As imagens dos nós do SO otimizado para contentores da Google baseiam-se numa versão recente do kernel do Linux e estão otimizadas para melhorar a segurança dos nós. As imagens do SO otimizado para contentores são suportadas por uma equipa da Google que pode aplicar rapidamente patches às imagens para segurança e iterar nas funcionalidades. As imagens do SO otimizado para contentores oferecem melhor suporte técnico, segurança e estabilidade do que outras imagens.

Para informações sobre o projeto e a família de imagens, consulte o artigo Projetos de origem de imagens de nós.

Variantes do SO otimizado para contentores

São oferecidos dois tempos de execução de contentores com o SO otimizado para contentores. As imagens são iguais, exceto na escolha do tempo de execução do contentor.

  • SO otimizado para contentores com o containerd (cos_containerd): a imagem cos_containerd usa o containerd como o tempo de execução do contentor diretamente integrado com o Kubernetes. Os clusters do GKE Autopilot usam sempre esta imagem. Para mais informações, consulte o artigo Imagens de nós do Containerd.
  • SO otimizado para contentores com Docker (cos): a imagem cos usa o tempo de execução do contentor Docker.

Ubuntu

As imagens de nós do Ubuntu foram validadas em relação aos requisitos de imagens de nós do GKE. Deve usar as imagens de nós do Ubuntu se os seus nós precisarem de suporte para XFS, CephFS ou pacotes Debian.

Para obter informações sobre o projeto de imagem e a família, consulte o artigo Compatibilidade de funcionalidades por sistema operativo.

Variantes do Ubuntu

O Ubuntu oferece dois tempos de execução de contentores. As imagens são iguais, exceto na escolha do tempo de execução do contentor.

  • Ubuntu com o containerd (ubuntu_containerd): a imagem ubuntu_containerd usa o containerd como o tempo de execução do contentor. Para mais informações, consulte o artigo Imagens de nós do Containerd.

  • Ubuntu com Docker (ubuntu): a imagem ubuntu usa o Docker como tempo de execução do contentor.

Windows Server

Quando cria um cluster com pools de nós do Windows Server, pode usar uma imagem de nó do Windows Server Semi-Annual Channel (SAC) ou do Windows Server Long-Term Servicing Channel (LTSC). Todas as imagens de nós do Windows são imagens do Windows Server Datacenter Core. Um único cluster pode ter vários conjuntos de nós do Windows Server com diferentes versões do Windows Server, mas cada conjunto de nós individual só pode usar uma versão do Windows Server. Para mais informações, consulte o artigo Escolha a imagem do nó do Windows.

São oferecidos dois runtimes de contentores com imagens de nós do Windows Server LTSC e SAC: Docker e containerd. As imagens são iguais, exceto pela escolha do tempo de execução do contentor.

  • Imagens de tempo de execução do Containerd (disponíveis na versão 1.21 e posterior do GKE):

    • Windows Server LTSC com o containerd (windows_ltsc_containerd): a imagem windows_ltsc_containerd usa o containerd como o tempo de execução do contentor. Atualmente, este tipo de imagem é mapeado para duas imagens de nós: Windows Server 2022 e Windows Server 2019. Pode criar node pools do Windows LTSC2022 através do comando CLI com a flag windows-os-version.

      Para mais informações sobre como criar node pools do Windows Server 2022, consulte o artigo Crie node pools do Windows

      Para mais informações sobre imagens de nós do containerd, consulte o artigo Imagens de nós do containerd.

    • Windows Server SAC com o containerd (windows_sac_containerd): a imagem windows_sac_containerd usa o containerd como o tempo de execução do contentor.

      Para mais informações, consulte o artigo Imagens de nós do Containerd.

  • Imagens de tempo de execução do Docker (disponíveis na versão 1.16 e posteriores do GKE):

    • Windows Server LTSC com Docker (windows_ltsc): a imagem usa o Docker como tempo de execução do contentor.windows_ltsc
    • Windows Server SAC com Docker (windows_sac): a imagem windows_sac usa o Docker como tempo de execução do contentor.

Para obter informações sobre o projeto de imagem e a família, consulte o artigo Compatibilidade de funcionalidades por sistema operativo.

Comparação de imagens de nós Linux

As secções seguintes comparam os aspetos operacionais das imagens de nós do SO otimizado para contentores e do Ubuntu, incluindo:

  • Gestão de pacotes de software
  • Inicialização do sistema
  • Recolha de registos
  • Esquema do sistema de ficheiros
  • Compatibilidade com controladores de armazenamento

Gestor de pacotes de software

As imagens de nós cos e cos_containerd usam um sistema de ficheiros raiz mínimo com suporte integrado para o tempo de execução do contentor Docker (containerd), que também serve como gestor de pacotes de software para instalar software no anfitrião. A imagem do Ubuntu usa o gestor de pacotes APT.

Gerir software no Container-Optimized OS

A imagem do SO otimizado para contentores não fornece software de gestão de pacotes, como o apt-get. Não pode instalar software arbitrário nos nós através de mecanismos convencionais. Em alternativa, crie uma imagem de contentor que contenha o software de que precisa.

Em clusters padrão, apenas para fins de depuração, o SO otimizado para contentores inclui a caixa de ferramentas do CoreOS para instalar e executar ferramentas de depuração comuns, como ping, psmisc ou pstree. Para mais informações sobre a depuração de nós do SO otimizado para contentores, consulte os guias de instruções do SO otimizado para contentores.

Gerir software no Ubuntu

A imagem do Ubuntu usa o gestor de pacotes APT. Pode usar o comando apt-get para instalar pacotes nestas imagens. Por exemplo, para instalar pacotes ceph:

sudo apt-get update
sudo apt-get install ceph

Inicialização do sistema

A imagem do nó do SO otimizado para contentores e do Ubuntu usa o systemd para gerir os recursos e os serviços do sistema durante o processo de inicialização do sistema.

Ambas as imagens de nós usam ficheiros de serviço systemd para definir services no nó e systemd.targets para agrupar destinos de arranque através de dependências.

Recolha de registos

As imagens de nós do SO otimizado para contentores e do Ubuntu usam o systemd-journald para recolher registos ao nível do sistema.

Ver registos no SO otimizado para contentores e no Ubuntu

Para ver registos num nó com a imagem do nó do SO otimizado para contentores ou do Ubuntu, tem de usar o comando journalctl. Por exemplo, para ver os registos do daemon containerd:

sudo journalctl -u containerd

Para ver os registos do kubelet:

sudo journalctl -u kubelet

Esquema do sistema de ficheiros

A imagem do nó do Ubuntu usa o esquema do sistema de ficheiros Linux padrão.

O esquema do sistema de ficheiros da imagem do nó do SO otimizado para contentores está otimizado para melhorar a segurança do nó. O espaço do disco de arranque está dividido em três tipos de partições:

  • Partição raiz, que é montada como só de leitura
  • Partições com monitorização de estado, que são graváveis e com monitorização de estado
  • Partições sem estado, que são graváveis, mas o conteúdo não persiste nos reinícios

Quando usar o SO otimizado para contentores, tenha em atenção a partição se executar os seus próprios serviços que tenham determinadas expetativas sobre a disposição do sistema de ficheiros fora dos contentores.

Trabalhar com o sistema de ficheiros do SO otimizado para contentores

Segue-se uma lista de caminhos no sistema de ficheiros de imagem do nó do SO otimizado para contentores, juntamente com as respetivas propriedades e utilização recomendada:

Caminho Propriedades Finalidade
/
  • só de leitura
  • executável
 O sistema de ficheiros raiz está montado como só de leitura para manter a integridade. O kernel verifica o sistema de ficheiros raiz de integridade durante o arranque e recusa-se a arrancar em caso de erros.
/home
/var
  • gravável
  • não executável
  • com estado
 Estes caminhos destinam-se ao armazenamento de dados que persistem durante a duração total do disco de arranque. Estão montadas a partir de /mnt/stateful_partition.
/var/lib/google
/var/lib/docker
/var/lib/toolbox
  • gravável
  • executável
  • com estado
 Estes caminhos são diretórios de trabalho para pacotes do Compute Engine (por exemplo, o serviço de gestão de contas), o Docker e a caixa de ferramentas, respetivamente.
/var/lib/cloud
  • gravável
  • executável
  • sem estado
  • tmpfs
 Este caminho é o diretório de trabalho do pacote cloud-init.
/etc
  • gravável
  • executável
  • sem estado
  • tmpfs
 Normalmente, contém a sua configuração (por exemplo, os serviços definidos através de cloud-init). É recomendável capturar o estado pretendido das suas instâncias em cloud-init, uma vez que cloud-init é aplicado quando uma instância é criada recentemente, bem como quando uma instância é reiniciada.systemd
/tmp
  • gravável
  • não executável
  • sem estado
  • tmpfs
 Normalmente, é usado como um espaço temporário e não deve ser usado para armazenar dados persistentes.
/mnt/disks
  • gravável
  • executável
  • sem estado
  • tmpfs
 Pode montar discos persistentes em diretórios em /mnt/disks.

Compatibilidade com controladores de armazenamento

Cada imagem de nó difere nos tipos de plug-ins de armazenamento que suporta. Os seguintes termos aplicam-se quando descrevem o suporte de uma imagem de nó para um controlador de armazenamento específico:

  • Sim: totalmente testado/suportado: este plug-in de armazenamento é totalmente suportado e foi testado com a imagem do nó especificada.
  • Sim: testes limitados: este plug-in de armazenamento funciona com a imagem do nó especificada, mas foi testado apenas de forma limitada. Pode encontrar um comportamento inesperado. Para o SO otimizado para contentores, estes plug-ins vão ser totalmente testados e suportados.
  • Não suportado: este plugin de armazenamento não foi testado nem usado com a imagem do nó especificada, e o GKE não pode oferecer qualquer garantia de funcionalidade. Não existem planos para testar este plug-in de armazenamento.
  • Não: este plugin de armazenamento não funciona com a imagem do nó especificada devido a uma limitação inerente ao SO do nó ou Google Cloud.

A matriz seguinte descreve como cada imagem do nó do GKE suporta alguns plug-ins de armazenamento comuns.

Tipo de volume Funciona no SO otimizado para contentores (cos)? Funciona no Ubuntu?
Persistent Disk (EXT4 ou XFS) do Compute Engine
 Sim – Totalmente testado/suportado
(o XFS só é suportado no COS-85 e posteriores.) Consulte as notas de lançamento do GKE 		Sim – Totalmente testado/suportado
NFSv3 Sim – Totalmente testado/suportado Sim – Totalmente testado/suportado
NFSv4 Sim – Totalmente testado/suportado Sim – Totalmente testado/suportado
CephFS Não Sim – Testes limitados
(o controlador não está instalado por predefinição. Tem de instalar o cliente ceph, de preferência através do DaemonSet.)
Cinder Não Não
Fibre Channel Não Não
Flocker Não suportado Não suportado
iSCSI Não Não
RBD Não Não

Modificações da VM do nó

As modificações no disco de arranque de uma VM de nó não persistem nas recriações de nós. Os nós são recriados durante a atualização manual, atualização automática, reparação automática e escala automática. Além disso, os nós são recriados quando ativa uma funcionalidade que requer a recriação de nós, como o GKE Sandbox, a visibilidade intranós e os nós protegidos.

Para preservar as modificações na recriação de nós, use um DaemonSet.

Não é recomendado gerir software crítico fornecido por uma imagem do nó, como o kernel ou o tempo de execução do contentor (seja containerd ou docker). As imagens do nó são testadas exaustivamente e a modificação do software crítico fornecido na imagem do nó coloca o nó num estado desconhecido e não testável. Os nós do GKE Autopilot não permitem a modificação do software dos nós.

Mapeie as versões de imagens de nós do SO otimizado para contentores para as versões de patches do GKE

O GKE publica um mapeamento JSON das versões de patches do GKE para as versões de imagens de nós do SO otimizado para contentores:

Pode usar este mapeamento para atualizar para uma versão específica do GKE para obter uma versão de imagem específica. Por exemplo, se o seu cluster precisar de uma determinada funcionalidade ou correção de uma versão de imagem, pode encontrar o mapeamento e atualizar o cluster para uma versão específica do GKE para obter a versão de imagem do SO otimizado para contentores com as alterações. Para ver detalhes sobre os lançamentos de imagens do SO otimizado para contentores, consulte as notas de lançamento do SO otimizado para contentores.

Esta lista é atualizada semanalmente, aproximadamente. Para ver a atualidade das informações, consulte o campo creation_time no ficheiro JSON.

Notas de lançamento das imagens de nós

SO otimizado para contentores

A Google fornece documentação abrangente para o SO otimizado para contentores:

Ubuntu

Periodicamente, a Google atualiza as imagens do Ubuntu que estão disponíveis para utilização nos nós do cluster. Consulte as notas de lançamento do GKE para ver informações sobre estas atualizações, incluindo um link para um manifesto que liste os pacotes instalados por predefinição.

Problemas conhecidos

Reposições aleatórias de ligações em nós do GKE que usam o SO otimizado para contentores com o tempo de execução do Docker

O nó do GKE que usa o SO otimizado para contentores com o Docker (cos) pode ter reposições aleatórias de ligações TCP quando dois pods no mesmo nó comunicam através de um serviço ClusterIP do Kubernetes.

As seguintes versões do GKE são afetadas:

  • 1.20.5-gke.100 ou posterior

Para contornar o problema, use uma das seguintes opções:

Projetos de origem de imagens de nós

As imagens de nós disponíveis para clusters do GKE estão contidas nos seguintes projetos de origem:

  • Imagens do SO otimizado para contentores: gke-node-images
  • Imagens do Ubuntu: ubuntu-os-gke-cloud
  • Imagens do Windows Server: gke-windows-node-images

Além dos projetos de origem indicados acima, o GKE também usa os seguintes projetos de origem para utilização exclusiva pela equipa do GKE:

  • ubuntu-os-gke-cloud-private (reservado para utilização exclusiva da equipa do GKE)
  • ubuntu-os-gke-cloud-devel (reservado para utilização exclusiva da equipa do GKE)

Pode ter de saber os nomes dos projetos de origem ao configurar clusters altamente seguros. Os projetos de origem indicados estão sujeitos a alterações.

O que se segue?