A Sidero Labs anunciou o lançamento do Talos 1.14.0, a mais recente atualização de seu sistema operacional imutável e focado na execução de clusters Kubernetes. A nova versão introduz mudanças arquiteturais profundas voltadas para segurança, roteamento avançado e flexibilidade de armazenamento, além de atualizar os componentes base do sistema para versões mais recentes, incluindo o Kubernetes 1.37.0 e o Kernel Linux 6.18.
O que isso muda na prática para os administradores
O Talos 1.14.0 marca uma transição importante na forma como o sistema gerencia permissões e configurações. A implementação do isolamento de cargas de trabalho torna o ambiente mais seguro por padrão, mas exige atenção imediata de quem ainda utiliza plugins de volume in-tree antigos, como iSCSI, que deixarão de funcionar. Além disso, a fragmentação da configuração monolítica em múltiplos documentos e a migração de portas do etcd exigem revisões nos firewalls e nos manifestos de infraestrutura como código das equipes de operações.
Isolamento de cargas de trabalho (sandboxd) e fim dos plugins in-tree
A mudança de segurança mais significativa desta versão é o novo modelo de execução do plano de tempo de execução de contêineres. O CRI containerd, o kubelet e todos os pods agora operam dentro de um namespace de PID e montagem dedicado, ancorado pelo novo serviço sandboxd.
Este serviço roda em seu próprio domínio SELinux com privilégios mínimos. Caso o processo falhe, o Kernel Linux derruba o namespace e o Talos recria o ambiente automaticamente, reiniciando o CRI e os pods sem a necessidade de reiniciar o nó inteiro. Novos clusters gerados com o Talos 1.14+ já possuem o isolamento habilitado por padrão. Clusters atualizados mantêm o comportamento anterior não isolado até que a configuração seja explicitamente adicionada.
Como consequência direta desse isolamento de namespaces, o kubelet perdeu a capacidade de alcançar daemons no nível do host. Isso significa que os plugins de volume in-tree do Kubernetes (especialmente o iSCSI) param de funcionar. A recomendação da Sidero Labs é que os administradores migrem obrigatoriamente para drivers CSI, que operam em seus próprios pods privilegiados e não são afetados pelo sandbox.
BGP nativo e novidades em rede
A necessidade de instalar a extensão de sistema do FRR para casos de uso comuns de roteamento fabric foi eliminada. O Talos 1.14.0 traz suporte a instâncias BGP nativas no host por meio de servidores GoBGP embutidos. O recurso é configurado através dos documentos BGPInstanceConfig, suportando peering numerado e não numerado (IPv6 link-local), multipath (ECMP) e detecção rápida de falhas (BFD) no domínio de roteamento padrão.
No gerenciamento de resolução de nomes, o sistema ganhou suporte a DNS over TLS (DoT) e DNS over HTTPS (DoH), criptografando consultas e respostas para aumentar a privacidade do tráfego DNS. O componente Flannel também foi atualizado e agora opera com a opção EnableNFTables ativada, utilizando o backend nativo do nftables em vez da camada de compatibilidade iptables-nft.
Armazenamento avançado: Btrfs, LVM e RAID
A gestão de discos e partições recebeu expansões que tornam o Talos capaz de lidar de forma nativa e declarativa com infraestruturas de armazenamento mais complexas:
- Btrfs: O suporte para provisionamento e montagem do sistema de arquivos btrfs foi introduzido via extensão de sistema.
- LVM: Administradores agora podem criar e expandir Volume Groups (VG) e Logical Volumes (LV) declarativamente usando os documentos
LVMVolumeGroupConfigeLVMLogicalVolumeConfig. O reconciliador é estritamente aditivo, evitando risco de exclusão acidental de dados. - RAID por software: Através do
RAIDArrayConfig, é possível configurar arrays MD do Linux declarativamente. O Talos 1.14.0 permite inclusive instalar e inicializar o sistema a partir de um array RAID1 com metadados no formato 1.0. - Partições de sistema dedicadas: Os volumes do sistema (
/var/lib/etcd,/var/lib/containerd,/var/lib/kubelete/var/log) podem ser isolados em partições dedicadas no disco, aplicando diretivas adicionais de segurança comonoexecpara o etcd e logs. - TRIM de disco: O sistema agora pode rodar a manutenção periódica do sistema de arquivos, descartando blocos não utilizados (fstrim), com periodicidade padrão configurada para uma vez por semana em unidades elegíveis.
Modernização das configurações e comportamento do etcd
A arquitetura de configuração v1alpha1 do Talos iniciou sua transição para um formato multi-documento mais modular. Campos legados relacionados a configurações de parâmetros do Kernel Linux (sysctls, sysfs, módulos), Kubernetes, udev rules e CoreDNS foram descontinuados em favor de novos documentos específicos, embora a retrocompatibilidade seja mantida para agilizar migrações.
O comando talosctl apply-config também teve o comportamento modificado e perdeu a flag --mode=reboot. Por padrão, as configurações agora são aplicadas sem exigir o reinício do nó, exceto em casos específicos documentados pelo sistema.
O etcd foi atualizado para a versão 3.7.1 (sendo estritamente compatível apenas com a série 3.6.x para origens de atualização). Uma mudança técnica importante no etcd exige atenção de infraestrutura: os endpoints HTTP (métricas, verificação de saúde e gateway JSON) foram separados da porta gRPC e movidos para um ouvinte dedicado na porta 2383. A Sidero Labs explica que a separação evita a inanição do fluxo de monitoramento (starvation) em cenários de alta carga sobre TLS. Firewalls que gerenciam a comunicação interna precisam ser ajustados para liberar essa nova porta.
Componentes atualizados
O núcleo do sistema reflete componentes técnicos fundamentais atualizados para versões recentes:
- Kernel Linux: 6.18.48
- Kubernetes: 1.37.0
- containerd: 2.3.4
- etcd: 3.7.1
- Flannel: 0.28.9
- runc: 1.5.1
- CoreDNS: 1.14.7
O sistema foi inteiramente construído com a linguagem Go 1.26.7.
