Nesta página, descrevemos as imagens de nó disponíveis para os nós do Google Kubernetes Engine (GKE).
Os nós do GKE Autopilot sempre usam o Container-Optimized OS com o containerd (cos_containerd
), que é o sistema operacional de nós recomendado. Se você usa o GKE Standard,
é possível escolher a imagem do sistema operacional que é executada em cada
nó durante a criação do cluster ou pool de nós. Também é possível fazer upgrade de um cluster Standard já existente para usar uma imagem de nó diferente. Para instruções sobre como
configurar a imagem de nó, consulte
Como especificar uma imagem de nó.
Imagens de nó disponíveis
O GKE oferece as seguintes opções de imagem de nó por SO para o cluster:
SO | Imagens de nó |
---|---|
Container-Optimized OS |
|
Ubuntu |
|
Windows Server |
|
Container-Optimized OS
As imagens de nó do Container-Optimized OS do Google são baseadas em uma versão recente do kernel do Linux e otimizadas para melhorar a segurança do nó. As imagens do Container-Optimized OS são apoiadas por uma equipe do Google que pode corrigir rapidamente as imagens por segurança e iterar os recursos. A imagem do Container-Optimized OS oferece melhor suporte, segurança e estabilidade do que as outras.
Para informações sobre o projeto e a família de imagens, consulte Projetos de origem de imagens do nó.
Variantes do Container-Optimized OS
São oferecidos dois ambientes de execução com o Container-Optimized OS. As imagens são as mesmas, exceto a escolha do ambiente de execução de contêiner.
- Container-Optimized OS com containerd (
cos_containerd
): a imagemcos_containerd
usa o containerd como o ambiente de execução de contêiner integrado diretamente ao Kubernetes. Os clusters do GKE Autopilot sempre usam essa imagem. Para mais informações, consulte Imagens de nó em contêiner. - Container-Optimized OS com Docker (
cos
): a imagemcos
usa o ambiente de execução de contêiner do Docker.
Ubuntu
A imagem de nó do Ubuntu foi validada em relação aos requisitos de imagem de nó do GKE. Será preciso usar a imagem de nó do Ubuntu se os nós exigirem compatibilidade com os pacotes XFS, CephFS ou Debian.
Para informações sobre o projeto e a família de imagens, consulte Suporte aos recursos de acordo com o sistema operacional.
Variantes do Ubuntu
São oferecidos dois ambientes de execução de contêiner com o Ubuntu. As imagens são as mesmas, exceto a escolha do ambiente de execução de contêiner.
Ubuntu com containerd (
ubuntu_containerd
): a imagemubuntu_containerd
usa containerd como o ambiente de execução de contêiner. Para mais informações, consulte Imagens de nó em contêiner.Ubuntu com Docker (
ubuntu
): a imagemubuntu
usa o Docker como o ambiente de execução do contêiner.
Windows Server
Ao criar um cluster usando pools de nós do Windows Server, é possível usar uma imagem de nó de Canal Semestral (SAC, na sigla em inglês) ou de Canal de Manutenção de Longo Prazo (LTSC, na sigla em inglês). Todas as imagens de nó do Windows são imagens do Windows Server Datacenter Core. Um único cluster pode ter vários pools de nós do Windows Server usando diferentes versões do Windows Server, mas cada pool de nós individual só pode usar uma versão do Windows Server. Para mais informações, consulte Escolher a imagem de nó do Windows.
Dois tempos de execução de contêiner são oferecidos com as imagens de nó LTSC e SAC do Windows Server: Docker e Containerd. As imagens são as mesmas, exceto a escolha do ambiente de execução de contêiner.
Imagens de ambiente de execução containerd (disponíveis na versão 1.21 e posteriores do GKE):
Windows Server LTSC com containerd (
windows_ltsc_containerd
): a imagemwindows_ltsc_containerd
usa o containerd como o ambiente de execução de contêiner. Atualmente, esse tipo de imagem é mapeado para duas imagens de nó: Windows Server 2022 e Windows Server 2019. É possível criar pools de nós LTSC2022 do Windows usando o comando da CLI com a sinalizaçãowindows-os-version
.Para mais informações sobre como criar pools de nós do Windows Server 2022, consulte Criar pools de nós do Windows.
Para mais informações sobre imagens de nó containerd, consulte Imagens de nó containerd.
Windows Server SAC com containerd (
windows_sac_containerd
): a imagemwindows_sac_containerd
usa o containerd como o ambiente de execução do contêiner.Para mais informações, consulte Imagens de nó em containerd.
Imagens de ambiente de execução do Docker (disponíveis na versão 1.16 e posteriores do GKE):
- Windows Server LTSC com Docker (
windows_ltsc
): a imagemwindows_ltsc
usa o Docker como o ambiente de execução do contêiner. - Windows Server SAC com Docker (
windows_sac
): a imagemwindows_sac
usa o Docker como o ambiente de execução do contêiner.
- Windows Server LTSC com Docker (
Para informações sobre o projeto e a família de imagens, consulte Suporte aos recursos de acordo com o sistema operacional.
Comparação de imagens de nós do Linux
As seções a seguir comparam os aspectos operacionais das imagens de nó do Container-Optimized OS e do Ubuntu, incluindo:
- Gerenciamento de pacotes de software
- Inicialização do sistema
- Coleta de registros
- Layout do sistema de arquivos
- Compatibilidade com driver de armazenamento
Gerenciador de pacotes de software
As imagens de nó cos
e cos_containerd
usam um sistema de arquivos raiz mínimo com suporte integrado para o ambiente de execução de contêiner do Docker (containerd). Ele também funciona como gerenciador de pacotes para instalar softwares no host. A imagem do Ubuntu usa o
gerenciador de pacotes APT.
Como gerenciar software no Container-Optimized OS
A imagem do Container-Optimized OS não inclui um software de gerenciamento de pacotes, como o apt-get
. Não é possível instalar softwares arbitrários nos nós usando mecanismos convencionais. Na verdade, você precisa criar uma imagem de contêiner que tenha o software necessário.
Em clusters padrão apenas para fins de depuração,
o Container-Optimized OS inclui o
CoreOS Toolbox para instalar
e executar ferramentas de depuração comuns, como ping
e psmisc
. ou pstree
.
Para mais informações sobre a depuração dos nós do Container-Optimized OS, consulte os
guias de instruções do Container-Optimized OS.
Como gerenciar software no Ubuntu
A imagem do Ubuntu usa o gerenciador de pacotes APT. Use o comando
apt-get
para instalar pacotes nessas imagens. Por exemplo, para instalar pacotes
ceph
:
sudo apt-get update
sudo apt-get install ceph
Inicialização do sistema
As imagens de nó do Ubuntu e do Container-Optimized OS usam o systemd
para gerenciar recursos e serviços do sistema durante o processo de inicialização dele.
As duas imagens de nó usam arquivos de serviço systemd para definir services
no nó e também systemd.targets
para agrupar destinos de inicialização por meio de dependências (páginas em inglês).
Coleta de registros
As imagens de nó do Ubuntu e do Container-Optimized OS usam systemd-journald
(em inglês) para coletar registros de todo o sistema.
Como exibir registros no Container-Optimized OS e no Ubuntu
Para ver registros em um nó com a imagem do Ubuntu ou do Container-Optimized OS, é preciso usar o comando journalctl
(em inglês). Por exemplo, para ver registros do daemon containerd:
sudo journalctl -u containerd
Para ver registros do kubelet:
sudo journalctl -u kubelet
Layout do sistema de arquivos
A imagem de nó do Ubuntu usa o layout padrão do sistema de arquivos do Linux.
O layout do sistema de arquivos de imagem de nó do Container-Optimized OS é otimizado para melhorar a segurança do nó. O espaço do disco de inicialização foi dividido em três tipos de partições:
- partição raiz, que é montada como somente leitura
- partições com estado, que podem ser gravadas e têm estado
- partições sem estado, que podem ser gravadas, mas o conteúdo não permanece durante as reinicializações
Ao usar o Container-Optimized OS, fique atento ao particionamento se você executar serviços próprios com certas expectativas sobre o layout do sistema de arquivos fora dos contêineres.
Como trabalhar com o sistema de arquivos do Container-Optimized OS
Na lista a seguir, mostramos os caminhos no sistema de arquivos de imagem do node do Container-Optimized OS, juntamente com as propriedades e o uso recomendado:
Caminho | Propriedades | Finalidade |
---|---|---|
/ |
|
O sistema de arquivos raiz é ativado como somente leitura para manter a integridade. O kernel verifica a integridade do sistema de arquivos raiz durante a inicialização e se recusa a inicializar em caso de erros. |
/home /var |
|
Esses caminhos visam armazenar dados que permanecem durante todo o período do disco de inicialização. Eles são montados a partir de /mnt/stateful_partition . |
/var/lib/google /var/lib/docker /var/lib/toolbox |
|
Esses caminhos são diretórios de trabalho para pacotes do Compute Engine (como o serviço de gerente de contas), Docker e Toolbox, respectivamente. |
/var/lib/cloud |
|
Esse caminho é o diretório de trabalho do pacote cloud-init . |
/etc |
|
Geralmente mantém sua configuração. Por exemplo, os serviços do
systemd definidos por meio do cloud-init .
É recomendável registrar o estado pretendido das instâncias no
cloud-init , já que o cloud-init é aplicado quando uma
instância é criada ou
reinicializada. |
/tmp |
|
Normalmente é usado como um espaço de rascunho. Não o use para armazenar dados persistentes. |
/mnt/disks |
|
É possível montar discos permanentes nos diretórios em /mnt/disks . |
Compatibilidade com driver de armazenamento
Cada imagem do node difere nos tipos de plug-ins de armazenamento com os quais é compatível. Os termos a seguir são usados para descrever a compatibilidade de uma imagem do node com determinado driver de armazenamento:
- sim - teste/suporte total: este plug-in de armazenamento tem suporte total e foi completamente testado com a imagem de nó especificada.
- Sim — teste limitado: este plug-in de armazenamento funciona com a imagem de nó especificada, mas foi testado apenas de maneira limitada. Talvez haja algum comportamento inesperado. Para o Container-Optimized OS, esses plugins serão testados e totalmente compatíveis.
- Não compatível: este plug-in de armazenamento não foi testado nem usado com a imagem de nó especificada, e o GKE não oferece nenhuma garantia de funcionalidade. Não há planos de testá-lo.
- Não: este plug-in de armazenamento não funciona com a imagem de nó especificada devido a uma limitação inerente ao SO do nó ou ao Google Cloud.
A matriz a seguir descreve como cada imagem de nó do GKE é compatível com alguns plug-ins de armazenamento comuns.
Tipo de volume | Funciona no Container-Optimized OS (cos )? |
Ele funciona no Ubuntu? |
---|---|---|
Compute Engine Disco permanente (EXT4 ou XFS) |
Sim: totalmente testado/compatível (O XFS é compatível somente com o cos-85 e posterior.) Consulte as notas da versão do GKE | Sim - teste/suporte total |
NFSv3 | Sim — totalmente testado/compatível | Sim — totalmente testado/compatível |
NFSv4 | Sim — totalmente testado/compatível | Sim — totalmente testado/compatível |
CephFS | Não | Sim – teste limitado O driver não é instalado por padrão. Você precisa instalar o cliente ceph , de preferência por meio do DaemonSet . |
Cinder | Não | Não |
Fibre Channel | Não | Não |
Flocker | Não compatível | Não compatível |
iSCSI | Não | Não |
RBD | Não | Não |
Modificações na VM do nó
As modificações no disco de inicialização da VM do nó não são mantidas na recriação dos nós. Eles são recriados durante upgrades manuais, upgrades automáticos, reparos automáticos e escalonamentos automáticos. Além disso, os nós são recriados quando você ativa um recurso que exija esse processo, como o GKE Sandbox, a visibilidade intranós e os nós protegidos.
Para manter as modificações durante a recriação dos nós, DaemonSet.
Não é recomendável gerenciar softwares importantes fornecidos por uma imagem de nó, como o kernel ou o ambiente de execução do contêiner, seja o containerd
ou o docker
. As imagens de nó são amplamente testadas, e a modificação de softwares importantes fornecidos nelas coloca o nó em um estado desconhecido e não testável.
Os nós do GKE Autopilot não permitem a modificação do software do nó.
Mapear versões de imagem de nó do Container-Optimized OS para versões de patch do GKE
O GKE publica um mapeamento JSON de versões de patch do GKE para as versões de imagem do nó do Container-Optimized OS:
É possível usar esse mapeamento para fazer upgrade para uma versão específica do GKE para conseguir uma versão de imagem específica. Por exemplo, se o cluster precisar de um determinado recurso ou correção de uma versão de imagem, é possível encontrar o mapeamento e fazer o upgrade do cluster para uma versão específica do GKE para obter a versão de imagem do Container-Optimized OS com as alterações. Para mais informações sobre para versões de imagem do Container-Optimized OS, consulte as notas de lançamento do Container-Optimized OS.
Em média, esta lista é atualizada toda semana. Para conferir a atualização das
informações, consulte o campo creation_time
no arquivo JSON.
Notas de lançamento das imagens de nós
Container-Optimized OS
O Google oferece uma documentação abrangente para o Container-Optimized OS:
Ubuntu
Periodicamente, o Google atualiza as imagens do Ubuntu que estão disponíveis para uso em nós de clusters. Consulte as Notas de lançamento do GKE para saber mais sobre essas atualizações, incluindo um link para um manifesto que lista os pacotes instalados por padrão.
Problemas conhecidos
Redefinição de conexão aleatória em nós do GKE usando o SO Container-Optimized com o ambiente de execução do Docker
O nó do GKE que usa o SO Container-Optimized com Docker (cos
) pode
passar por redefinições de conexão TCP aleatória quando dois pods no mesmo nó
se comunicam usando um serviço ClusterIP do Kubernetes.
As seguintes versões do GKE são afetadas:
- 1.20.5-gke.100 ou mais recente
Para resolver o problema, use uma das seguintes opções:
Projetos de origem da imagem do nó
As imagens de nó disponíveis para clusters do GKE estão localizadas nos seguintes projetos de origem:
- Imagens do Container-Optimized OS:
gke-node-images
- Imagens do Ubuntu:
ubuntu-os-gke-cloud
- Imagens do Windows Server:
gke-windows-node-images
Além dos projetos de origem listados acima, o GKE também usa os seguintes projetos de origem para uso exclusivo pela equipe do GKE:
ubuntu-os-gke-cloud-private
(reservado para uso exclusivo pela equipe do GKE)ubuntu-os-gke-cloud-devel
(reservado para uso exclusivo pela equipe do GKE)
Talvez você precise saber os nomes dos projetos de origem ao configurar clusters altamente seguros. Os projetos de origem listados estão sujeitos a alterações.