Talos Linux: O Sistema Operacional Imutável e Otimizado para Kubernetes

Visão geral da arquitetura imutável

Talos linux foi projetado como um sistema Operacional Imutável (Immutable OS) que elimina a camada tradicional de gerenciamento de pacotes e arquivos de configuração mutáveis. Em vez disso, todo o estado do nó é descrito por arquivos declarativos versionados, armazenados em /var/lib/talos. Essa abordagem reduz drasticamente a superfície de ataque e elimina deriva de configuração entre nós, permitindo que o cluster self‑heal de forma automática.

Bootstrapping de um cluster Talos com Terraform

Para integrar Talos em pipelines de IaC, o provedor oficial talos para Terraform expõe recursos como talos_machine_secrets e talos_cluster. A seguir, um exemplo mínimo que provisiona três control‑plane e dois workers em AWS:

provider "aws" {
  region = "us-east-1"
}

resource "talos_machine_secrets" "example" {}

resource "talos_cluster" "k8s" {
  name        = "talos-demo"
  controlplane = [
    { address = "10.0.1.10" },
    { address = "10.0.1.11" },
    { address = "10.0.1.12" },
  ]
  workers = [
    { address = "10.0.2.20" },
    { address = "10.0.2.21" },
  ]
  secrets = talos_machine_secrets.example.id
}

Após terraform apply, o provedor gera arquivos talosconfig e kubeconfig que podem ser consumidos diretamente pelo talosctl e kubectl. Essa integração permite que o cluster seja criado, destruído e versionado como código, alinhado com práticas GitOps.

Gerenciamento de nós com talosctl

O cliente de linha de comando talosctl substitui o tradicional ssh + systemctl. Todas as operações são executadas via API gRPC segura, usando certificados gerados no bootstrap. Exemplos de comandos críticos:

# Listar nós do cluster
$ talosctl get nodes

# Aplicar uma nova configuração declarativa
$ talosctl apply-config --insecure -n 10.0.1.10 -f controlplane.yaml

# Reiniciar o agente kubelet sem reboot
$ talosctl service restart -n 10.0.2.20 kubelet

Note que talosctl aceita a flag --insecure apenas em ambientes de teste; em produção, recomenda‑se usar o talosconfig com ca e client certificados.

Definição declarativa de configuração

A configuração de um nó Talos é descrita em YAML, seguindo o esquema v1alpha1. O arquivo contém seções para machine, network, kubernetes e system. Abaixo, um exemplo de controlplane.yaml que habilita o CNI Calico e define o endpoint de API:

version: v1alpha1
machine:
  type: controlplane
  token: "${TALOS_TOKEN}"
  network:
    interfaces:
      - device: eth0
        dhcp: true
  install:
    image: ghcr.io/siderolabs/installer:latest
    bootloader: true
kubernetes:
  version: v1.28.0
  apiServer:
    extraArgs:
      service-node-port-range: "30000-32767"
  controllerManager:
    extraArgs:
      allocate-node-cidrs: "true"
  scheduler:
    extraArgs:
      address: "0.0.0.0"
  clusterName: talos-demo
  podSubnet: 10.244.0.0/16
  serviceSubnet: 10.96.0.0/12
  cni:
    name: calico
    urls:
      - https://docs.projectcalico.org/manifests/calico.yaml
system:
  extensions:
    - image: ghcr.io/siderolabs/extensions/etcd:latest
      name: etcd
      version: v3.5.9

Ao aplicar esse manifesto com talosctl apply-config, o nó executa um reboot controlado, carrega a nova imagem do instalador e inicia o kube‑apiserver com as opções especificadas. Não há necessidade de editar arquivos /etc diretamente.

Integração com CI/CD: pipeline GitHub Actions

Um fluxo típico de entrega contínua para clusters Talos inclui:

Commit de alterações no diretório clusters/ contendo arquivos *.yaml de configuração.
GitHub Actions dispara um job que valida o YAML com yamllint e o esquema Talos via talosctl validate.
Se a validação passar, o job usa terraform apply -auto-approve para provisionar ou atualizar a infraestrutura.
Por fim, um step executa talosctl apply-config em todos os nós, garantindo consistência.

Exemplo de workflow (arquivo .github/workflows/talos.yml):

name: Deploy Talos Cluster
on:
  push:
    paths:
      - 'clusters/**'
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Install talosctl
        run: |
          curl -Lo talosctl https://github.com/siderolabs/talos/releases/download/v1.5.0/talosctl-linux-amd64
          chmod +x talosctl && sudo mv talosctl /usr/local/bin/
      - name: Lint YAML
        run: yamllint clusters/
      - name: Terraform Init & Apply
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        run: |
          terraform init
          terraform apply -auto-approve
      - name: Apply Talos Config
        run: |
          for node in $(talosctl get nodes -o json | jq -r '.[].address'); do
            talosctl apply-config -n $node -f clusters/controlplane.yaml
          done

Esse pipeline garante que toda mudança de configuração seja auditável, reproduzível e aplicada de forma atômica.

Segurança por design: imutabilidade e assinatura de imagens

Talos utiliza Secure Boot e TPM para validar a assinatura da imagem do instalador antes de iniciar. A imagem oficial ghcr.io/siderolabs/installer é assinada com cosign; o bootloader verifica a assinatura contra a chave pública embutida no firmware. Além disso, o systemExtensions são distribuídos como containers OCI, permitindo que atualizações sejam feitas via docker pull ou ctr com verificação de digest.

Exemplo de verificação de assinatura com cosign:

$ cosign verify ghcr.io/siderolabs/installer:latest 
    --key cosign.pub

Qualquer tentativa de substituir a imagem sem a assinatura correta resulta em falha de boot, reforçando a postura de zero‑trust no nível do SO.

Operação de upgrades sem downtime

Talos suporta rolling upgrades nativas. O processo consiste em:

Gerar um novo manifesto controlplane.yaml com a versão desejada do Kubernetes.
Aplicar a configuração em um nó de controle por vez usando talosctl upgrade --image ghcr.io/siderolabs/installer:new-version.
O nó entra em modo drain automático, migra pods críticos e, após reboot, reporta seu status ao controlador.

Com isso, o cluster mantém a disponibilidade 99.95% mesmo durante upgrades de SO e de componentes Kubernetes.

Observabilidade integrada

Talos expõe métricas via Prometheus no endpoint /metrics da API gRPC. Além disso, o agente talos-metrics coleta informações de hardware (temperatura, uso de CPU, I/O) e as envia para o stack de observabilidade do cluster. Configuração típica:

system:
  metrics:
    enabled: true
    listenAddress: 0.0.0.0:9090
    scrapeInterval: 30s

Para integrar ao Grafana, basta criar um datasource apontando para http://:9090/metrics e usar os dashboards oficiais disponibilizados no repositório talos-observability.

Comparativo rápido: Talos vs. Ubuntu Core vs. Flatcar

Critério	Talos Linux	Ubuntu Core	Flatcar Container Linux
Modelo de Imutabilidade	Full OS immutable, config via talosctl	Snap‑based, mutable rootfs	Immutable, but uses Ignition for config
Kubernetes Native	Built‑in, no kubeadm	Requires manual kubeadm	Requires manual kubeadm
Atualizações OTA	Atomic, signed images	Snap refresh	Ignition + reboot
Suporte a TPM/SecureBoot	Sim, obrigatório	Opcional	Opcional
CLI de gerenciamento	talosctl (gRPC)	snap, ssh	fleetctl, ssh

Essa tabela evidencia que Talos oferece a experiência mais integrada para clusters Kubernetes, reduzindo a necessidade de ferramentas externas.

Próximos passos: automatizando o ciclo de vida completo

Para equipes que desejam adotar Talos em produção, recomenda‑se:

Versionar todos os manifests (*.yaml) em um repositório Git separado por ambiente (dev, staging, prod).
Utilizar Argo CD ou Flux para aplicar as configurações de Kubernetes, enquanto talosctl gerencia o SO.
Implementar políticas de assinatura de imagens via cosign e policy-controller para garantir que apenas imagens aprovadas sejam executadas.
Monitorar a integridade do nó com talosctl health e configurar alertas no Prometheus para eventos de reboot inesperados.

Com essas práticas, o ciclo de vida – provisionamento, atualização, observabilidade e destruição – torna‑se totalmente declarativo e auditável, alinhado com os princípios de GitOps e Zero‑Touch Operations.

Rogerio Lima

Sou um profissional na área de Tecnologia da informação, especializado em monitoramento de ambientes, Sysadmin e na cultura DevOps. Possuo certificações de Segurança, AWS e Zabbix.