Fly Kubernetes
O novo recurso “Fly Kubernetes” da Fly.io expõe uma API compatível com Kubernetes em cima da plataforma Machines existente, usando k3s e Virtual Kubelet para mapear pods diretamente para VMs da Fly. Os comentaristas ponderam os benefícios dessa abordagem — configs declarativas, compatibilidade com ferramentas e autoscaling por pod-por-VM — contra suas limitações e comportamento não padrão, como suporte incompleto a pods com múltiplos contêineres e volumes persistentes. A mudança é vista por alguns como um adaptador pragmático para organizações já investidas em Kubernetes e, por outros, como um passo arriscado para longe da simplicidade original da Fly e um lembrete de que a estabilidade da plataforma e a documentação ainda precisam de trabalho.
O que é Fly Kubernetes (FKS)
- Posicionado como uma interface opcional compatível com Kubernetes em cima de Fly Machines, não como uma migração da própria infraestrutura da Fly para Kubernetes.
- Implementado como k3s + Virtual Kubelet executando em uma única Fly Machine; os Pods são mapeados 1:1 para Machines.
- Objetivo: permitir que equipes reutilizem ferramentas do Kubernetes e YAML declarativo na Fly, enquanto delegam o agendamento e a infraestrutura à plataforma da Fly.
Posicionamento vs Outras Ofertas de Nuvem
- Alguns veem o FKS como semelhante, em espírito, ao GKE Autopilot ou ao EKS Fargate: cobrança por nível de pod sem gerenciamento de nós.
- Outros argumentam que é principalmente um “Kubernetes API shim” para a plataforma da Fly, não uma distribuição completa do Kubernetes.
- Vários კომენტários sugerem que a documentação e o marketing deveriam explicar com mais clareza o que o FKS é e o que não é, e quais recursos do Kubernetes são suportados.
Design Técnico & Limitações
- O plano de controle é k3s de nó único com SQLite; não é obviamente HA. Se essa Machine morrer, o acesso à API pode ser interrompido.
- Vários comentários questionam o suporte a Pods com múltiplos contêineres e sidecars; as Fly Machines atuais usam uma única imagem por Machine, então a paridade total não está clara e é reconhecida como um trabalho em andamento.
- A semântica de affinity/anti-affinity muda quando o “nó” é um virtual-kubelet com pod-por-VM; alguns padrões de resiliência podem não se traduzir diretamente.
- O armazenamento persistente continua vinculado a hosts físicos por meio de Fly Volumes; a Fly pode migrar volumes, mas falha de hardware ainda pode causar perda de dados, então recomenda-se replicação de banco de dados em nível superior ou bancos externos.
Ecossistema Kubernetes vs Plataformas Personalizadas
- Um ponto de vista: usar Kubernetes dá acesso a um ecossistema de padrões, ferramentas e talentos e evita reinventar a orquestração.
- Visão contrária: Kubernetes é complexo, às vezes exagerado; o scheduler personalizado e a stack de rede da Fly podem ser mais simples para o problema deles. O FKS é apenas um adaptador para usuários que insistem em K8s.
Reações e Preocupações dos Usuários
- Alguns estão animados para ganhar configs declarativas e fluxos de trabalho baseados em kubectl na Fly.
- Outros temem que isso dilua a simplicidade de PaaS da Fly ou seja um “footgun” que abraça a complexidade do Kubernetes.
- Preocupações de confiabilidade são levantadas sobre certas regiões da Fly e sobre a estabilidade geral da Fly e a consistência da documentação.
- Vários pedem garantias mais claras sobre uptime, tempo de vida dos pods, comportamento do armazenamento e comportamento entre regiões; muitos detalhes ainda não estão claros.