Comparação de Distribuições do Kubernetes para um Homelab com 3 Nós

Escolhendo a melhor versão do Kubernetes para o nosso homelab

Conteúdo da página

Estou comparando variantes de Kubernetes auto-hospedado que se adequam ao homelab baseado no Ubuntu com 3 nós (16 GB de RAM, 4 núcleos cada), focando na facilidade de instalação e manutenção, suporte para volumes persistentes e LoadBalancers.

Cenário: Temos três nós Ubuntu (16 GB de RAM, 4 núcleos de CPU cada) em um homelab. Alta disponibilidade (HA) e suporte a ARM não são prioridades. Queremos um cluster de Kubernetes fácil de instalar e de baixa manutenção (seja um único nó ou um cluster de 3 nós) com suporte para Volumes Persistentes (PV) e LoadBalancer (LB) (para que aplicações nativas da nuvem que exigem armazenamento ou IPs externos funcionem de forma suave). Vamos nos concentrar nas opções de clusters de 3 nós sem requisitos de HA ou compatibilidade com CPU ARM.

kubernetes homelab

Abaixo comparamos distribuições populares de Kubernetes leves [Kubernetes(https://www.glukhov.org/pt/post/2024/10/kubernetes-cheatsheet/ “lista e descrição dos comandos mais frequentes e úteis do k8s - k8s cheatsheet”) distribuições – K3s, MicroK8s, Minikube, e kubeadm (Kubernetes vanilla) – e como elas se comparam nos critérios principais (funcionalidades, instalação/manutenção, suporte a PV/LB, requisitos de recursos, configuração do cluster e ferramentas). Também temos algumas recomendações sobre qual escolher com base no cenário do homelab.

K3s (Kubernetes leve da Rancher)

Funcionalidades Principais: K3s é uma distribuição do Kubernetes certificada pela CNCF projetada para uso mínimo de recursos (pode funcionar com tão pouco quanto 512 MB de RAM). Ele empacota toda a camada de controle do Kubernetes em um único binário e processo, usando componentes leves (por exemplo, SQLite como armazenamento padrão em vez de etcd, flannel para rede). Ele inclui padrões sensatos, como um controlador de entrada embutido (Traefik) e um balanceador de carga simples. O K3s remove funcionalidades legadas/alpha para reduzir o excesso de informações.

  • Facilidade de Instalação e Manutenção: Muito simples – podemos instalá-lo com um script de uma linha (curl ... | sh) ou via ferramentas como K3sup. O servidor inicia com componentes padrão prontos para uso. Adicionar nós é direto (execute o agente K3s com um token do servidor). Atualizações são fáceis (substitua o binário ou use o script de instalação para a nova versão). Não é necessário configurar um etcd separado (a menos que você escolha uma configuração de HA multi-mestre). O K3s foi projetado para exigir o mínimo de ajustes após a instalação, tornando-o popular para IoT e homelabs.

  • Suporte a Volumes Persistentes: Incorporado. Por padrão, o K3s vem com a local-path StorageClass da Rancher, que provisiona dinamicamente PVs no sistema de arquivos do host para cada PVC. Isso significa que qualquer PVC será atendido criando automaticamente um volume hostPath no nó. É uma solução de armazenamento de único nó (cada volume está em um disco de um nó), mas funciona prontamente para aplicações estatais. Para armazenamento mais avançado, você pode adicionar algo como o Longhorn da Rancher (armazenamento de bloco distribuído), que o K3s suporta, mas para um homelab o provisionador local-path padrão geralmente é suficiente.

  • Suporte a LoadBalancer: Incorporado. O K3s inclui um controlador leve chamado ServiceLB (anteriormente “Klipper LB”) que permite que Serviços do tipo LoadBalancer obtenham um IP/porta no host sem qualquer provedor de nuvem externo. Quando criamos um serviço LoadBalancer, o K3s implanta um DaemonSet de pequenos pods LB (svc-...) em cada nó, que usam portas do host para encaminhar o tráfego para o serviço. Essencialmente, o K3s reutiliza o IP do nó (interno ou externo) para servir como o IP do LB e usa roteamento iptables nos pods LB para enviar o tráfego para o ClusterIP do serviço. Isso funciona com zero configuração – os serviços não ficarão “pendentes” (ao contrário do Kubernetes vanilla em hardware bare metal). O trade-off é que o IP externo do LB será um dos IPs dos nossos nós (ou todos os nós) e devemos garantir que a porta esteja livre. Para a maioria dos usos em homelab (expondo alguns serviços nas portas HTTP/HTTPS), isso é perfeitamente adequado. Se necessário, podemos desativar o LB embutido e instalar o MetalLB manualmente, mas a maioria dos usuários permanece com o conveniente padrão.

  • Requisitos de Recursos: Muito baixos. O K3s pode funcionar mesmo em hardware de baixa especificação. Oficialmente, 512 MB de RAM e alguns centenas de MB de disco são suficientes para um nó de servidor. Na prática, um pequeno cluster pode usar alguns centenas de MB de memória para a camada de controle. Seu binário é <100 MB. O overhead de CPU é mínimo (o K3s usa um pouco mais de CPU quando ocioso em comparação com o MicroK8s, mas não por uma grande margem). Nossos nós (16 GB cada) são mais do que suficientes para executar o K3s confortavelmente.

  • Único nó vs. Multi-nó: Adequado para ambos. O K3s pode funcionar com um único nó (todos os componentes de controle e cargas de trabalho em uma única máquina) ou multi-nó. Para uma configuração de 3 nós, poderíamos executar 1 servidor (mestre) e 2 agentes, ou até mesmo fazer todos os 3 servidores para HA (não necessário aqui, já que HA não é um objetivo). Juntar agentes é trivial com o token. O armazenamento padrão SQLite do K3s funciona para um único servidor; para HA multi-servidor, trocariamos para etcd embutido (o K3s pode fazer isso automaticamente ao iniciar múltiplos nós de servidor).

  • Ferramentas CLI e UI: Interagimos com o K3s da mesma forma que qualquer Kubernetes – via kubectl. O K3s inclui sua própria construção de kubectl (podemos executar k3s kubectl ... ou simplesmente usar um kubectl padrão apontando para o kubeconfig do K3s). Não há um CLI específico para K3s além dos comandos de instalação; ele é intencionalmente minimalista. Não há uma interface web embutida (o Dashboard upstream não é instalado por padrão). No entanto, podemos implantar manualmente o Kubernetes Dashboard ou outras ferramentas no K3s como qualquer cluster padrão. O Rancher (a ferramenta de gerenciamento GUI pela mesma empresa) também pode ser instalado no K3s se uma interface completa for desejada, mas não faz parte do K3s em si. Essencialmente, o K3s fornece as APIs centrais do k8s e adicionamos extras conforme necessário (ingress, armazenamento, etc. – alguns dos quais já estão embalados como mencionado).

MicroK8s (Kubernetes de baixa manutenção da Canonical)

Funcionalidades Principais: MicroK8s é a distribuição leve do Kubernetes da Canonical, entregue como um pacote snap. Ele instala um cluster de Kubernetes totalmente conforme (binários upstream) com um único comando e foi projetado para uso fácil (“baixa manutenção”) em uma única máquina ou pequeno cluster. Ele enfatiza uma abordagem de “baterias incluídas” – obtemos muitas funcionalidades opcionais que podem ser ativadas com comandos simples. O MicroK8s padrão é uma experiência de Kubernetes vanilla (todos os APIs padrão) mas com adições convenientes para necessidades comuns. Ele suporta implantações de único nó e multi-nó (podemos formar um cluster “juntando” nós), e até mesmo tem um modo HA para a camada de controle (usando Dqlite – um SQLite distribuído – quando temos 3 mestres).

  • Facilidade de Instalação e Manutenção: Muito fácil também – basta snap install microk8s --classic em uma máquina Ubuntu para configurar um nó Kubernetes. É um único pacote que inclui todos os componentes. O MicroK8s é mantido via sistema de snap da Ubuntu, o que significa que as atualizações são atômicas e podem ser automáticas (podemos acompanhar um canal para versões do Kubernetes). Essa capacidade de atualização automática é única entre essas opções – podemos optar por obter patches de segurança e atualizações menores via refreshes de snap. O gerenciamento do MicroK8s é feito via o comando microk8s, que tem subcomandos para habilitar/desabilitar funcionalidades. No geral, é muito de baixa fricção: não há containers ou VMs para gerenciar (executa nativamente no host) e não há etcd externo para configurar (usa um armazenamento interno). A manutenção é basicamente apenas atualizar o snap quando necessário e usar microk8s.status para monitorar.

  • Suporte a Volumes Persistentes: Disponível via adição. Por padrão, o MicroK8s não provisiona automaticamente PVs até que ativemos o “hostpath-storage”. Ativando isso (com microk8s enable hostpath-storage) cria uma StorageClass padrão que aloca volumes de um diretório no host. Isso é essencialmente um provisionador dinâmico de hostPath, semelhante em conceito ao local-path do K3s. Uma vez ativado, qualquer PVC se vinculará a um PV hostPath no nó do MicroK8s. (Em um cluster de múltiplos nós do MicroK8s, o PV hostPath residirá em um nó – adequado para testes ou uso em homelab, mas não armazenamento distribuído). O MicroK8s também oferece Mayastor e outros adições de armazenamento se quisermos armazenamento mais avançado em múltiplos nós, mas, para simplicidade, o armazenamento hostpath funciona bem. Nota: A adição não está ativada por padrão (para manter as coisas leves), então queremos ativá-la para que os PVCs funcionem. A Canonical observa que isso não é adequado para uso em produção HA (já que não é replicado), mas para um homelab é perfeito.

  • Suporte a LoadBalancer: Disponível via adição. O MicroK8s não embala um balanceador de carga padrão, mas oferece MetalLB como uma adição fácil. Executando microk8s enable metallb:<start-IP>-<end-IP> implanta o MetalLB no modo Layer 2 e permite que especificamos uma pool de IPs da sua LAN para usar em serviços LoadBalancer. Uma vez ativado, qualquer serviço do tipo LoadBalancer automaticamente obterá um IP dessa faixa (e o MicroK8s anunciará via ARP na LAN). Isso oferece uma experiência semelhante à nuvem em hardware bare metal. (Se não ativarmos o MetalLB, um serviço LoadBalancer permanecerá pendente, já que o MicroK8s sozinho não implementa um – assim como o Kubernetes upstream.) Em um homelab, o MetalLB é direto e nos permite acessar serviços em nossa rede local. Precisaremos escolher uma sub-rede ou faixa de IP livre em nossa rede para ele. O comando de habilitação do MicroK8s torna a configuração simples, mas ainda é um passo separado. (Em contraste, o K3s funciona prontamente para LB, mas com a limitação de usar IPs/ports dos nós.) Muitos usuários do MicroK8s simplesmente ativam o MetalLB como parte de sua configuração inicial para um LB funcional.

  • Requisitos de Recursos: O MicroK8s é bastante leve, embora ligeiramente acima do K3s em termos de footprint. Ele executa todos os serviços principais (servidor de API, controlador, escalonador, kubelet, etcd ou Dqlite) nativamente. O uso em estado ocioso é tipicamente ~500–600 MB de RAM para a camada de controle, dependendo de quais adições estão ativadas. A Canonical cita ~540 MB de memória como base. O uso de CPU é baixo em estado ocioso, e nossos nós de 16 GB têm mais do que suficiente espaço. O requisito de espaço em disco é pequeno (snap ~ 200 MB mais dados do etcd). Em resumo, o MicroK8s pode funcionar em hardware modesto (é até oferecido para Raspberry Pis), e em nosso cenário as máquinas facilmente acomodam. Se múltiplas adições estiverem ativadas (painel, monitoramento, etc.), o uso de recursos aumentará conforme necessário.

  • Único nó vs. Multi-nó: O MicroK8s funciona bem para ambos. Podemos usá-lo para um cluster de único nó (por exemplo, em uma máquina de desenvolvimento ou um servidor) ou criar um cluster multi-nó “juntando” nós. A documentação do MicroK8s fornece um comando para adicionar um nó (obtemos um token de junção do primeiro nó e usamos-o nos outros). Em uma configuração multi-nó sem HA, um nó será o plano de controle principal. Com 3 nós, também temos a opção de habilitar o ha-cluster (tornando o plano de controle HA executando Dqlite em 3 nós), embora, no nosso caso, HA não seja necessário. Seja um único nó ou três, a experiência é a mesma API do Kubernetes. O MicroK8s multi-nó é um pouco mais novo que a abordagem do K3s, mas é bastante estável agora. É uma boa escolha se quisermos uma “nuvem micro” de algumas máquinas Ubuntu executando k8s com pouco esforço.

  • Ferramentas CLI e UI: O MicroK8s vem com a microk8s ferramenta de linha de comando, que é muito útil. Por exemplo, microk8s enable <addon> ativa/desativa vários serviços (DNS, ingress, armazenamento, metallb, painel, etc.), e microk8s status mostra o que está em execução. Ele também inclui um kubectl embutido: podemos usar microk8s kubectl ... (ou aliasar) que se comunica com o cluster – isso é bom porque não precisamos configurar um kubeconfig. Para UI, o MicroK8s fornece o Kubernetes Dashboard como adição (microk8s enable dashboard), que implantará a interface web padrão. Uma vez ativado, podemos acessá-lo (executa na porta 10443 ou via proxy). O MicroK8s não tem uma GUI própria – depende do Kubernetes Dashboard ou outras ferramentas – mas a facilidade de ativá-lo é um plus. Em resumo, o MicroK8s enfatiza uma experiência de um único comando para tarefas comuns e uma filosofia de “funciona sem problemas”, abstraindo muita complexidade (ao custo de ocultar alguns detalhes internos). Isso o torna muito amigável para homelabs para aqueles que desejam um cluster Kubernetes sem a configuração manual de cada componente.

Contraste entre K3s e MicroK8s: Ambos são bastante semelhantes em objetivos e capacidades – leves, fáceis de usar, capazes de multi-nó. O K3s tende a ser um pouco mais “DIY” ao adicionar extras (dependendo de gráficos Helm ou manifestos manuais para coisas não incluídas), enquanto o MicroK8s oferece adições embutidas via sua CLI. O MicroK8s também é um Kubernetes mais “vanilla” sob o capô (componentes upstream, apenas empacotados como snap), enquanto o K3s usa alguns binários personalizados e um único serviço para tudo. Ambos são boas escolhas para um homelab; a decisão geralmente se reduz à preferência: se Ubuntu/snaps e uma sensação integrada forem preferíveis, o MicroK8s é excelente, enquanto se preferirmos uma abordagem minimalista com talvez um pouco mais de controle manual, o K3s é excelente. (Faremos recomendações no final.)

Minikube (Cluster Único Local K8s)

Funcionalidades Principais: Minikube é principalmente uma ferramenta para executar Kubernetes localmente (muitas vezes em um computador ou laptop do desenvolvedor) em vez de um cluster tradicional em várias máquinas. Ele cria um cluster Kubernetes de único nó em uma VM ou contêiner em nossa máquina. O Minikube é conhecido por sua ampla suporte a ambientes – ele pode ser executado em Linux, macOS, Windows e suporta diversos hipervisores (VirtualBox, KVM, Hyper-V, driver Docker, etc.). É mantido pelos SIGs do Kubernetes e é frequentemente usado para testes e aprendizado. Embora o Minikube possa ser configurado para um modo de múltiplos nós, ele é essencialmente destinado a clusters de único nó (o modo “multi-nó” do Minikube, na verdade, apenas inicia múltiplos nós no mesmo host usando runtimes de contêiner – útil para simular um cluster, mas não para executar em máquinas físicas separadas).

  • Facilidade de Instalação e Uso: O Minikube é muito fácil de começar em uma única máquina. Instalamos o binário minikube, garantimos que tenhamos um driver de VM (ou Docker) e executamos minikube start. Isso configurará uma VM/contêiner local e lançará o Kubernetes dentro dele. É provavelmente a maneira mais simples de executar um cluster Kubernetes pela primeira vez. O CLI (minikube) fornece comandos para interagir com a VM (iniciar, parar, excluir) e para habilitar adições. Como o Minikube é projetado para uso local, ele não é um “daemon de longa duração” – normalmente o iniciamos quando precisamos e o paramos quando terminamos, embora possamos mantê-lo em execução continuamente em um servidor de homelab se desejarmos. Manutenção/atualizações são fáceis: basta atualizar a versão do minikube e reiniciar o cluster (o Minikube também pode atualizar a versão do Kubernetes com uma bandeira). No entanto, uma limitação é que o Minikube é por design de único nó (adicionar mais nós significa iniciar instâncias VM adicionais no mesmo host, não unir hosts reais separados). Portanto, usar o Minikube em três nós físicos separados significaria basicamente executar três clusters de único nó independentes, o que provavelmente não é o que queremos. O Minikube brilha para desenvolvimento e testes em uma única máquina, mas não foi projetado para gerenciar um cluster espalhado por múltiplas máquinas físicas.

  • Suporte a Volume Permanente: Incorporado (hostPath). Os clusters do Minikube incluem automaticamente uma StorageClass padrão que usa um provisionador hostPath. Na verdade, o Minikube executa um pequeno controlador que cria dinamicamente PVs hostPath dentro da VM quando PVCs são solicitados. Isso significa que podemos criar PersistentVolumeClaims e eles serão satisfeitos usando o armazenamento no sistema de arquivos da VM do Minikube (geralmente sob /tmp/hostpath-provisioner ou algo semelhante). Isso funciona fora da caixa – nenhuma configuração é necessária para uso básico de PV. Por exemplo, a StorageClass padrão “standard” no Minikube mapeia para armazenamento hostPath no nó. Uma observação: se reiniciarmos ou deletarmos a VM do Minikube, esses volumes hostPath podem ser perdidos (o Minikube tenta persistir certos diretórios entre reinícios – por exemplo, /data, /var/lib/minikube, /tmp/hostpath* são preservados). Mas, em geral, para um ambiente não produtivo, isso está tudo bem. Se quisermos simular mais, o Minikube também tem um addon do driver hostpath CSI que suporta snapshots e pode funcionar no modo multi-nó, mas isso é mais para experimentação. Em resumo: o Minikube suporta PVs por padrão via hostPath, o que é suficiente para um teste de aplicações stateful em um homelab.

  • Suporte a LoadBalancer: Suportado via tunelamento (ou addon MetalLB). Em uma nuvem, um serviço LoadBalancer obtém um LB de nuvem com um IP externo. No Minikube, obviamente não há um provedor de nuvem, então o Minikube fornece dois mecanismos:

    • Tunel do Minikube: Podemos executar minikube tunnel em um processo separado, que criará uma rota de rede em nosso host e atribuirá um IP ao nosso serviço LoadBalancer. Essencialmente, ele usa nosso host para atuar como o “LB externo”. Ao criarmos um serviço LoadBalancer, o Minikube mostrará um “IP externo” (geralmente do sub-rede do cluster) e o processo minikube tunnel roteará isso para o serviço. Isso requer que o processo de tunelamento continue em execução (e normalmente permissão de root para criar rotas). É um pouco passo manual, mas o Minikube imprime um lembrete se tivermos um serviço LoadBalancer sem tunelamento em execução (“External-IP pendente” até que iniciemos o tunelamento).
    • Addon MetalLB: Versões mais recentes do Minikube também incluem um addon MetalLB. Podemos executar minikube addons enable metallb e configurar uma faixa de IP (o Minikube nos perguntará). Isso efetivamente implanta o MetalLB dentro do cluster do Minikube, que então lida com serviços LoadBalancer da mesma forma que faria em qualquer Kubernetes de metal nu. Isso é uma solução mais “dentro do cluster” e não requer um processo de tunelamento separado após a configuração inicial.

    Ambas as opções funcionam, e qual usar depende de nós. Para expor rapidamente um serviço, o minikube tunnel é rápido e efêmero. Para uma configuração mais permanente, o addon MetalLB pode ser habilitado para que os LBs obtenham IPs reais (por exemplo, poderíamos dar a ele uma faixa como 10.0.0.240-250 em um Minikube com rede em ponte). Lembre-se de que o Minikube é tipicamente de único nó, então, na prática, o “balanceador de carga” não está equilibrando entre múltiplos nós – ele apenas fornece acesso externo ao serviço do único nó. Isso está tudo bem para desenvolvimento. Em um homelab, se usarmos apenas um de nossos nós e executarmos o Minikube nele, poderíamos usar essas ferramentas para acessar nossas aplicações. Mas se quisermos aproveitar todos os 3 nós, a abordagem do Minikube para LB não é destinada a esse cenário.

  • Requisitos de Recursos: O Minikube em si é leve, mas, como normalmente executa um Kubernetes completo de único nó (em uma VM), o uso de recursos é semelhante ao de um cluster pequeno normal. O mínimo recomendado é 2 GB de RAM e 2 CPUs para a VM. Por padrão, o Minikube frequentemente aloca 2 GB de RAM para sua VM. No nosso caso, com 16 GB por máquina, isso é trivial. O Minikube ocioso (Kubernetes) pode usar ~600 MB de memória. Uma coisa a considerar é que o Minikube será executado sobre nosso sistema operacional – seja como uma VM via hipervisor ou um contêiner Docker – o que adiciona alguma sobrecarga. Em um servidor de homelab, poderíamos executar o Minikube com o driver “none” (que instala diretamente os componentes Kubernetes no host). No entanto, o driver “none” (também conhecido como “bare-metal”) é essencialmente semelhante ao uso de kubeadm nesse nó e requer limpeza manual, então não é tão popular. A maioria usa um driver de VM ou Docker. Em resumo, qualquer um dos nossos nós de homelab pode executar o Minikube facilmente. A única restrição é que o Minikube não usará os recursos de todos os 3 nós – ele será confinado ao único host em que ele executa (a menos que use a abordagem experimental de múltiplos nós dentro de um único host).

  • Único Nó vs. Múltiplos Nós: Primariamente único nó. O Minikube é ideal para um cluster de único nó em uma única máquina. Ele tem uma funcionalidade para simular múltiplos nós (por exemplo, minikube start --nodes 3 com o driver Docker iniciará 3 nós Kubernetes como contêineres em um único host), mas isso é apenas para testes. Não podemos usar o Minikube para criar um cluster real de múltiplos nós em 3 servidores físicos separados. Se tivermos 3 máquinas, teríamos que executar 3 instâncias independentes do Minikube (não em um único cluster). Isso não é uma experiência de cluster real (eles não saberão um do outro). Portanto, o Minikube não é recomendado se o nosso objetivo for utilizar todos os três nós em um único cluster Kubernetes – é melhor para cenários em que temos apenas uma máquina (nosso PC ou um servidor) e queremos executar K8s nela. Também é ótimo para aprender os fundamentos do Kubernetes e fazer desenvolvimento local.

  • Ferramentas CLI e UI: A minikube CLI é a interface principal. Usamos ela para iniciar/parar o cluster e tem ótimos atalhos: por exemplo, minikube dashboard ativará o Dashboard do Kubernetes e o abrirá no nosso navegador. minikube addons enable <addon> pode habilitar uma variedade de componentes opcionais (ingress, metallb, metrics-server, etc.). O Minikube configura automaticamente o acesso ao kubectl (ele configura um contexto “minikube” no nosso kubeconfig). Para UI, como mencionado, o Dashboard do Kubernetes está facilmente acessível via o comando dashboard. O Minikube não tem sua própria interface web única; ele depende de ferramentas padrão. O depuração do Minikube também é fácil, pois podemos minikube ssh para entrar no VM do nó se necessário. Em resumo, as ferramentas são muito amigáveis para um cenário de único nó.

Kubeadm (Kubernetes Puro em Nossos Próprios Nós)

Funcionalidades Principais: Kubeadm não é uma “distribuição”, mas sim a ferramenta oficial para criar um cluster Kubernetes do zero. Usar o kubeadm significa que estamos implantando componentes upstream padrão do Kubernetes em nossas máquinas. É essencialmente como “montar o nosso próprio” cluster, seguindo práticas recomendadas, mas sem os extras que as distribuições incluem. O kubeadm configurará um nó de plano de controle (executando etcd, servidor de API, controlador manager, escalonador) e unirá nós de trabalho a ele. O resultado é um cluster Kubernetes totalmente padrão idêntico ao que obteríamos em VMs de nuvem. Essa abordagem nos dá total controle e flexibilidade – escolhemos o plugin de rede, o provisionador de armazenamento, etc. – mas também exige o maior esforço manual inicial e conhecimento. É frequentemente usado em ambientes de produção ou de aprendizado para entender os internos do Kubernetes.

  • Facilidade de Instalação e Manutenção: Em comparação com os outros, o kubeadm é o mais envolvido. Temos que instalar manualmente as dependências (runtime de contêiner como containerd, kubeadm, kubelet, kubectl) em cada nó. Em seguida, executamos kubeadm init no mestre e kubeadm join nos trabalhadores com o token que ele fornece. Também precisamos configurar um CNI (plugin de rede) após a inicialização (Calico, Flannel, etc.), pois o kubeadm não instala um por padrão. Há etapas bem documentadas para tudo isso (o processo não é difícil, mas é muitas etapas) – essencialmente, o kubeadm nos dá um cluster inicial, mas espera que nós lidemos com os adições. Em termos de manutenção, somos responsáveis por atualizações (o kubeadm tem um comando de atualização, mas devemos drenar os nós, atualizar os binários, etc. manualmente), bem como monitorar a saúde do etcd, renovações de certificados, etc. Em resumo, o kubeadm é poderoso, mas manual. É frequentemente chamado de “a maneira difícil” (embora não tão difícil quanto construir a partir da fonte). Para um entusiasta de homelab que gosta de aprender, o kubeadm é uma ótima maneira de entender profundamente o Kubernetes. Mas, se nossa prioridade for “fácil e baixa manutenção”, o kubeadm será mais trabalho do que K3s/MicroK8s. Cada atualização ou mudança exigirá esforço manual. Dito isso, uma vez configurado, é o verdadeiro negócio: um cluster Kubernetes padrão sem abstrações ocultas.

  • Suporte a Volume Permanente: Nenhum por padrão (deve ser adicionado manualmente). Um cluster instalado com kubeadm é essencialmente um Kubernetes vazio – não inclui uma StorageClass padrão ou um provisionador dinâmico por padrão. Em ambientes de nuvem, o provedor de nuvem normalmente forneceria uma StorageClass padrão (por exemplo, AWS EBS, etc.), mas em um ambiente de homelab de metal nu, teremos que instalar nossa própria solução. Abordagens comuns:

    • Provisionador hostPath: Podemos replicar o que K3s/Minikube fazem instalando algo como o Rancher Local Path Provisioner (que é um pequeno controlador + StorageClass que cria PVs hostPath). Isso é um add-on simples (apenas um manifesto YAML) e nos dá armazenamento dinâmico local.
    • NFS ou NAS: Alguns usuários de homelab configuram um servidor NFS (ou usam um NAS) e depois usam PVs estáticos ou um driver CSI NFS para provisionamento.
    • OpenEBS/Longhorn/Ceph: Há opções mais complexas, como implantar o Longhorn ou Ceph RBD via Rook se quisermos armazenamento distribuído entre nós. Essas exigem mais recursos e complexidade.

    O ponto principal é que o kubeadm não “resolve” o armazenamento para nós – devemos decidir e configurar isso. Se a facilidade for a prioridade, o caminho mais simples é implantar um provisionador hostPath ou usar NFS. Por exemplo, o provisionador local-path do Rancher pode ser instalado com algumas instruções kubectl apply e imitará o comportamento do K3s (criando volumes sob /var/lib/rancher/ em qualquer nó). Mas isso é um passo manual. Até que façamos isso, qualquer PVC que criarmos ficará em estado Pendente porque o Kubernetes não tem provisionamento padrão. Portanto, embora o kubeadm certamente suporte Volumes Permanentes (é o Kubernetes completo), o suporte a PV dinâmico é tão bom quanto o esforço que colocarmos para configurá-lo.

  • Suporte a LoadBalancer: Nenhum por padrão (deve ser adicionado manualmente). História semelhante aqui: em um cluster tradicional de on-premises, não temos uma implementação de LoadBalancer embutida. Se criarmos um serviço do tipo LoadBalancer em um cluster kubeadm puro, ele ficará em estado pendente para sempre até que implantemos um controlador para lidar com ele. A solução comum é instalar MetalLB por nós mesmos. O MetalLB pode ser instalado via manifesto ou gráfico Helm – configuraríamos uma faixa de IP e ele alocaria esses IPs para serviços LoadBalancer (exatamente como no MicroK8s). Existem muitos guias para instalar o MetalLB em clusters kubeadm. Outra alternativa que alguns usam é kube-vip para VIP do plano de controle e serviços LB, mas o MetalLB é mais simples para serviços. Essencialmente, com o kubeadm temos a liberdade (ou a carga) de configurar qualquer mecanismo de balanceamento de carga que se encaixe em nossas necessidades. Se não configurarmos nada, estaremos limitados a serviços NodePort para acesso externo. Em um homelab, instalar o MetalLB é altamente recomendado – é direto e nos dá a funcionalidade de IP de serviço como em nuvem. Mas, novamente, isso é um passo extra que devemos executar (ao contrário do K3s, que funciona fora da caixa ou do MicroK8s com um simples enable).

  • Requisitos de Recursos: O Kubernetes padrão é um pouco mais pesado do que as versões reduzidas. Cada nó executará um kubelet e kube-proxy, e o mestre executará o etcd e os componentes do plano de controle. Um único nó de plano de controle pode ainda executar com 2 GB de RAM, mas normalmente queremos um pouco mais para conforto se estivermos executando pods nele. O guia padok sugere 2 GB para o mestre, 2 GB para o trabalhador mínimo. No nosso cenário (16 GB por nó), isso está tudo bem. O etcd e o servidor de API ociosos podem usar alguns centenas de MB de memória cada. Não há uma grande diferença no tempo de execução entre um cluster kubeadm e o MicroK8s – afinal, o MicroK8s é esses mesmos componentes. A diferença é apenas o que está rodando por padrão (o MicroK8s pode habilitar DNS e armazenamento por padrão, enquanto no kubeadm teríamos que instalar esses). Portanto, em termos de recursos, o kubeadm pode ser tão leve ou pesado quanto configurarmos. Com nada extra instalado, ele pode ser bastante leve. Com uma configuração típica (digamos, adicionamos CoreDNS, Dashboard, etc.), espere ~1 GB ou algo assim usado para sobrecarga do sistema. Temos mais do que suficiente de RAM, então os recursos não são uma preocupação. É mais sobre o tempo e recursos humanos necessários para gerenciá-lo do que CPU/RAM.

  • Único Nó vs. Múltiplos Nós: O kubeadm pode fazer ambos, com total flexibilidade. Podemos inicializar um cluster de único nó (e até pedir ao kubeadm para permitir que o único nó execute cargas de trabalho desmarcando o mestre). Ou podemos ter um mestre e juntar dois trabalhadores (uma configuração comum de 3 nós). Podemos até configurar 3 mestres e 3 trabalhadores, etc. – qualquer topologia. No nosso caso, uma configuração provável com kubeadm seria 1 nó de plano de controle e 2 trabalhadores (como não precisamos de HA, não precisamos de múltiplos mestres). Isso nos dá um cluster funcional de 3 nós. O processo para múltiplos nós está bem documentado: basicamente, instale o Kubernetes em todos, inicie um, junte os outros. O resultado é idêntico ao que um cluster gerenciado ou outra distribuição forneceria: nossos 3 nós aparecem em kubectl get nodes, etc. Portanto, o kubeadm definitivamente atende ao requisito de “pode usar todos os 3 nós”.

  • Ferramentas CLI e UI: Com o kubeadm, a única CLI especial é kubeadm em si, usada para os passos de configuração e (mais tarde) atualização. No dia a dia, usamos kubectl para gerenciar o cluster. Não há uma CLI de gerenciamento integrada além do que o Kubernetes oferece. Para UI, nada é incluído por padrão – podemos implantar manualmente o Dashboard do Kubernetes ou qualquer outra ferramenta (exatamente como em qualquer cluster). Essencialmente, o kubeadm nos dá um canvas de Kubernetes em branco. É nossa responsabilidade pintar nele – o que inclui instalar conveniências como dashboard, controladores de ingress, classes de armazenamento, etc. Muitas dashboards de terceiros (Lens, Octant, etc.) também podem se conectar a um cluster kubeadm se quisermos uma experiência de gerenciamento GUI, mas essas são ferramentas externas. Em resumo, com o kubeadm estamos obtendo um ambiente Kubernetes puro – máxima flexibilidade, mas também a necessidade de configurar tudo como se fosse um cluster de produção.

  • Kubespray Veja também como instalar esta versão de Kubernetes com Kubespray.

Tabela de Comparação Lado a Lado

Abaixo está um resumo comparando as quatro opções em pontos-chave:

Aspecto K3s (K8s Leve do Rancher) MicroK8s (K8s “Low-Ops” da Canonical) Minikube (K8s de Desenvolvimento Único-Nó) Kubeadm (Kubernetes Puro)
Instalação Script de instalação de uma linha (único binário). Executa como um único serviço do sistema. Configuração muito rápida. Instalação com um único comando via snap no Ubuntu. Todos os componentes incluídos. Facilidade de clustering com microk8s join. Instale o CLI do minikube, depois execute minikube start para iniciar um VM/container local. Multiplataforma e amigável para iniciantes. Instalação manual do kubeadm, kubelet, etc. em cada nó. Execute kubeadm init + kubeadm join com pré-requisitos. Envolve vários passos (runtime, plugin de rede, etc.).
Manutenção e Atualizações Atualizações manuais (substitua o binário ou use o script de instalação para a nova versão). Simples, pois é um único binário; pouco a gerenciar. Não há atualização automática. Atualizações via snap refresh (pode ser automática). Adições e serviços do cluster gerenciados via CLI microk8s. Geralmente de baixa manutenção; atualizações automáticas disponíveis. Fácil apagar/recriar cluster para desenvolvimento. Atualizações atualizando a versão do minikube e reiniciando o cluster. Destinado ao uso efêmero (menos foco na longevidade de atualização in-place). O usuário é responsável por todas as atualizações. Use kubeadm upgrade mas deve drenar os nós, lidar com backup do etcd, etc. Total controle, mas você faz o trabalho (sem atualizações automáticas).
Versão do K8s Segue o upstream com certa proximidade (muitas vezes usado em releases de borda). Conformante ao CNCF. Alguns recursos desabilitados por padrão (alpha/legacy). Segue as versões do upstream (canais de snap para 1.27, 1.28, etc.). Conformante ao CNCF. Essencialmente binários puros de K8s. Podemos escolher a versão do Kubernetes no início (ex: minikube start --kubernetes-version=v1.27). Padrão é a mais recente estável. Qualquer versão que quisermos (instale versões específicas de kubeadm/kubelet). Kubernetes upstream completo – decidimos a versão e quando atualizar.
Funcionalidades Padrão Padrões embalados: Flannel CNI, CoreDNS, Traefik ingress, balanceador de carga de serviço, classe de armazenamento local, metrics-server, etc. (Todos podem ser desabilitados se não forem necessários). Minimal config needed to be functional. Padrão mínimo: DNS geralmente ativado, outros opcionais. Adições fáceis de um comando para ingress (NGINX), MetalLB, armazenamento hostpath, dashboard, etc.. Pode ativar modo HA em 3+ nós. Embalado no VM: geralmente inclui runtime do Docker/containerd, Kubernetes com adições padrão como StorageProvisioner e DNS. Adições opcionais (ingress, dashboard, etc.) alternam via CLI. Nenhum nó múltiplo por padrão. Nada além do núcleo do Kubernetes. Nenhum ingress, nenhuma classe de armazenamento ou LB padrão, nenhum dashboard até que o instalamos. Escolhemos o plugin CNI (devemos instalar um para rede). Essencialmente um cluster DIY.
Suporte a Volume Permanente Sim – pronto para uso. O provisionador dinâmico local-path do Rancher cria PVs hostPath no nó para qualquer PVC. Classe de armazenamento padrão “local-path” usa o disco local automaticamente. Sim – adição fácil. Ative hostpath-storage para obter uma Classe de Armazenamento padrão para PVs dinâmicos usando hostPath. Até que seja ativado, não há provisionador de PV padrão. Adição não adequada para produção multi-nó, mas boa para homelab. Sim – pronto para uso. Classe de armazenamento padrão usa o provisionador hostPath dentro do VM do minikube. PVCs são atendidos por um controlador simples que cria um PV hostPath no sistema de arquivos do nó. Dados persistem após reinícios em certos diretórios. Não (manual). Nenhum provisionador padrão – o cluster não terá nenhuma Classe de Armazenamento inicialmente. O usuário deve instalar uma solução de armazenamento (ex: provisionador local path, NFS, Ceph, etc.). Abordagem básica: aplique um YAML de provisionador hostPath para imitar o que K3s/Minikube fazem. Até então, PVCs permanecem pendentes.
Suporte a LoadBalancer Sim – ServiceLB embutido. O controlador servicelb do K3s (Klipper) monitora serviços LoadBalancer e implanta pods nos nós para expô-los. Usa IP do nó e portas do host para encaminhar o tráfego. Funciona pronto para uso sem configuração. Adequado para pequenos clusters; usa IP interno/externo do nó para serviço. Sim – via adição MetalLB. Ative metallb com uma faixa de IP para alocar. Fornece um balanceador de carga verdadeiro de camada 2 em hardware. Não ativado por padrão. Uma vez ativado, cada serviço LoadBalancer obtém um IP único da nossa piscina. Requer um pouco de configuração inicial (faixa de IP). Sim – via túnel ou MetalLB. Nenhum LB de nuvem, mas podemos executar minikube tunnel para atribuir um IP externo aos serviços LoadBalancer (cria rota no host). Alternativamente, ative o adição MetalLB no minikube para IPs de LB automáticos. Por padrão, serviços LB mostrarão “pendente” até usarmos um desses métodos. Não (manual). Nenhum LB embutido. Normalmente instalamos MetalLB manualmente para funcionalidade de LB em hardware. Uma vez que MetalLB (ou outro controlador de LB) esteja configurado, os serviços LoadBalancer funcionam. Sem ele, os serviços LoadBalancer ficam pendentes indefinidamente.
Rede (CNI) Padrão = Flannel (rede overlay). O K3s também suporta substituir CNI se necessário. Vem com CoreDNS implantado para DNS do cluster. Traefik ingress incluído por padrão (pode ser desativado). Padrão = Calico (para versões recentes em modo HA) ou um padrão simples. (MicroK8s historicamente usou flannel; agora tende a usar Calico para confinamento estrito). CoreDNS ativado por padrão. NGINX ingress disponível via adição (microk8s enable ingress). Padrão = kubenet/bridge (depende do driver; geralmente usa uma rede NAT simples). CoreDNS executa por padrão. Podemos ativar um adição de NGINX ingress se necessário. A rede está confinada ao único VM; NodePort é acessível via minikube ip. Escolha do CNI. O kubeadm não instala nenhum plugin CNI – devemos implantar um (Calico, Flannel, Weave, etc.). Temos total controle. A maioria dos guias temos aplicar o YAML do Calico após o kubeadm init. CoreDNS é instalado pelo kubeadm por padrão como DNS do cluster. Controlador de ingress – escolha e instale nós mesmos (ex: NGINX ou Traefik via manifests/Helm).
Clustering Multi-Nó Sim. Projetado para multi-nó. Fácil junção com token. Pode usar DB externa ou etcd embutido para multi-master. Ótimo para homelabs com 2-3+ nós. Nenhuma dependência extra necessária – K3s tem seu próprio clustering embutido. Sim. Suporta clustering de múltiplos nós MicroK8s (com microk8s join). Pode ativar HA com 3+ mestres (Dqlite). Muito simples formar um cluster, especialmente se todos os nós rodarem Ubuntu + snap. Não (físico). Por design, único-nó. Pode simular multi-nó em uma única máquina (múltiplos nós em contêineres Docker), mas não pode se estender a múltiplos hosts físicos em um cluster. Use instâncias separadas do Minikube para clusters separados. Sim. Totalmente suporta multi-nó (esse é o ponto). Podemos ter 1 mestre + muitos trabalhadores, ou até mesmo múltiplos mestres (embora a configuração HA do kubeadm seja mais complexa). Nenhuma limitação embutida no tamanho do cluster.
Sobrecarga de Recursos Muito baixa. Plano de controle ~<0.5 GB de memória ociosa. Um único processo para o plano de controle resulta em pequeno footprint. Eficiente em CPU (embora possa usar um pouco mais de CPU em ociosidade do que o MicroK8s, conforme alguns relatos). Ideal para baixo consumo de energia ou muita capacidade disponível. Baixa. ~0.5–0.6 GB de memória para o plano de controle ocioso. Slightly higher base memory than K3s, but stays stable. Uses Ubuntu snap (might have some overhead). Still lightweight relative to full Kubernetes. Moderada. Alocado padrão do VM 2 GB (uso ~0.6 GB ocioso). Executa um Kubernetes único-nó completo, mais a camada do VM. Não é um problema em sistemas com 16 GB, mas essencialmente consome recursos de um pequeno cluster em uma única máquina. Moderada. Um único mestre com um trabalhador pode usar ~1 GB ocioso após adicionar adições típicas. Cada nó adicional adiciona sobrecarga mínima (apenas kubelet, proxy). Similar a executar Kubernetes em VMs de nuvem de tamanho comparável. Em 3 nós com 16 GB cada, a sobrecarga é insignificante no contexto.
Ferramentas CLI Use k3s para instalação e como um wrapper para kubectl (ou use o padrão kubectl). Nenhuma CLI de gerenciamento separada (K3s é basicamente “configure e esqueça”). Alguns scripts de ajuda (ex: k3s-killall.sh). O GUI do Rancher pode ser adicionado se desejado. CLI rico microk8s: ex: microk8s enable/disable <addon>, microk8s status. Também inclui microk8s kubectl. Projetado para simplificar tarefas comuns (não é necessário editar diretamente manifestas do sistema para básicos). CLI minikube para iniciar/parar cluster, gerenciar configuração e adições, e obter informações (IP, URL do serviço, logs). Também fornece comandos de conveniência como minikube dashboard. Interaja com o cluster via kubectl (configuração automaticamente definida para contexto do minikube). Apenas kubeadm para instalação inicial e atualizações. Operações diárias via kubectl padrão e outras ferramentas Kubernetes. Nenhuma CLI específica de distribuição além do bootstrap. Você estará trabalhando com comandos Kubernetes brutos e possivelmente ferramentas do sistema para manutenção.
UI / Dashboard Não incluído por padrão. Pode instalar manualmente o Dashboard do Kubernetes ou usar ferramentas externas (nada específico do Rancher a menos que adicionemos o Rancher separadamente). K3s se concentra em operação sem interface. Não incluído por padrão, mas disponível via um comando: microk8s enable dashboard implanta a UI padrão do Dashboard. Acesso fácil para cluster via microk8s dashboard-proxy. Também integra bem com a Lens GUI da Canonical se desejado (Lens pode acessar diretamente o MicroK8s). Não ativado por padrão, mas o comando minikube dashboard implantará e abrirá a UI do Dashboard para nós. Isso é destinado à conveniência no desenvolvimento local – um comando e teremos uma GUI para ver cargas de trabalho. Não incluído. Podemos instalar o Dashboard (aplicar YAML) se quisermos. Caso contrário, use CLI ou aplicações de dashboard de terceiros. Em um homelab, alguém poderia instalar o dashboard e criar um NodePort ou usar kubectl proxy para visualizá-lo. Kubeadm não se preocupa com UIs.

Fontes: Os dados acima são sintetizados de documentos oficiais e guias do usuário: por exemplo, sobrecargas de memória do MicroK8s próprio, armazenamento padrão no K3s docs, comportamento do serviço LB do K3s da documentação do K3s, detalhes de adição do MicroK8s dos documentos da Canonical, PV e túnel do Minikube dos documentos do Kubernetes, e relatos gerais de experiência. (Veja Referências para citações completas.)

Recomendações

Dadas as prioridades (facilidade de configuração/mantenção e suporte embutido para armazenamento e balanceadores de carga) e o cenário (3 nós Ubuntu, não preocupados com HA):

  • Melhores opções: K3s ou MicroK8s são as mais adequadas para um homelab com 3 nós:

    • Ambos são extremamente fáceis de instalar (um único comando em cada nó) e exigem manutenção mínima. Eles abstraem a maioria da complexidade de executar um cluster.
    • Ambos suportam clustering multi-nó de forma nativa (podemos unir nossos 3 nós e ver um cluster unificado).
    • Cada um oferece uma solução para Volumes Persistentes e Balanceadores de Carga com pouco esforço: o K3s inclui-os por padrão (armazenamento Local Path, Klipper LB) e o MicroK8s torna-os disponíveis via comandos simples de enable. Isso significa que podemos implantar aplicações típicas (bancos de dados com PVCs, serviços com tipo=LoadBalancer) com mínima configuração manual.
    • K3s pode ser atraente se quisermos o footprint absolutamente menor e não nos importarmos com seus padrões embutidos (ingress Traefik, etc.). É uma abordagem “configure e funcione”, com padrões opiniados. Também é muito popular na comunidade de homelabs por sua simplicidade. Usaremos principalmente o kubectl padrão e podemos ajustar ou desativar os componentes embalados se necessário. O K3s pode ser preferível se não estivermos no Ubuntu ou se gostarmos do ecossistema do Rancher (ou planejarmos usar a interface de gerenciamento do Rancher mais tarde).
    • MicroK8s pode ser atraente se preferirmos uma solução suportada pelo Ubuntu e gostarmos da ideia de habilitar recursos com um único comando. É essencialmente Kubernetes puro sob o capô, o que alguns acham mais fácil de estender. Os complementos (como microk8s enable ingress dns storage metallb) podem nos dar uma “nuvem micro” totalmente funcional em minutos. O MicroK8s também lida com atualizações de forma suave via snaps, o que pode ser útil para manter nosso cluster atualizado sem intervenção manual (podemos desativar isso ou controlar o canal para evitar surpresas). Se estivermos rodando Ubuntu em todos os nós (o que estamos) e não nos importarmos com snaps, o MicroK8s é uma excelente escolha para um cluster de baixa manutenção.

    Em resumo: Não há como errar com K3s ou MicroK8s nesse cenário. Ambos nos darão um Kubernetes fácil de usar, amigável para homelabs, com as funcionalidades que precisamos. Muitos usuários relatam experiências positivas com ambos em configurações de casa com 2–3 nós. O MicroK8s pode ter uma vantagem ligeira em termos de facilidade de uso (devido aos complementos e integração), enquanto o K3s pode ter uma vantagem ligeira em rodar leve e ser direto sob o capô.

  • Quando escolher Minikube: Se estivéssemos apenas rodando em uma única máquina ou quisessemos um cluster de desenvolvimento temporário, o Minikube é fantástico para isso. É a forma mais fácil de configurar Kubernetes em um laptop ou um único nó para testes. No entanto, para um cluster permanente com 3 nós, o Minikube não é a ferramenta certa – ele não unirá esses 3 nós em um único cluster. Acabariamos subutilizando nosso hardware ou gerenciando 3 clusters separados, o que não é desejável. Portanto, nesse homelab com múltiplos nós, o Minikube não é recomendado como solução principal. Podemos ainda usar o Minikube no nosso computador pessoal para testar coisas antes de implantar no cluster do homelab, mas para o próprio cluster, usaremos algo como K3s/MicroK8s.

  • Quando escolher Kubeadm: Se o nosso objetivo fosse aprender os internos do Kubernetes ou ter controle total e uma configuração “similar à produção”, o kubeadm é uma boa experiência. Ele nos forçará a entender como instalar CNI, armazenamento, etc., e basicamente construiremos o cluster peça por peça. Em termos de facilidade de uso, no entanto, o kubeadm é o mais manual. Cada recurso que precisarmos (como armazenamento ou LB) teremos que configurar. Para um homelab focado em aprendizado, isso pode ser um ponto positivo (educacional); para um homelab apenas para funcionar, isso é um ponto negativo. Além disso, a manutenção será mais envolvida (especialmente durante atualizações). A menos que queiramos especificamente a experiência do Kubernetes puro para aprendizado ou necessidades personalizadas específicas, usar K3s ou MicroK8s nos poupará muito tempo e dores de cabeça em um ambiente de homelab. Dito isso, alguns usuários experientes preferem o kubeadm mesmo em casa para evitar quaisquer peculiaridades específicas de fornecedores e ter tudo sob o seu controle. Realmente depende de quanto esforço queremos gastar. Para a maioria, o kubeadm é excesso para um pequeno cluster onde a alta disponibilidade não é uma preocupação.

  • Outras opções: Existem algumas outras versões leves de Kubernetes, como k0s (por Mirantis) e ferramentas como kind (Kubernetes em Docker). Para completar:

    • k0s é outra distribuição de Kubernetes com único binário, com objetivo semelhante ao de K3s/MicroK8s, que se concentra em flexibilidade e footprint mínimo. É relativamente novo, mas tem fãs na comunidade de homelabs. Ele também pode rodar facilmente em nossos 3 nós. Atualmente, não tem a mesma base de usuários grande como K3s/MicroK8s, mas é uma opção para observar (especialmente se gostarmos da ideia de um Kubernetes aberto, configurável e mínimo – alguns relatos mostram até que o k0s usa ligeiramente menos recursos ociosos do que K3s/MicroK8s em configurações semelhantes).
    • kind é principalmente para testar clusters Kubernetes em contêineres Docker (muitas vezes usado em pipelines de CI). Não é algo que executaríamos como nosso cluster de homelab sempre ligado – é mais para clusters efêmeros rápidos em uma única máquina (semelhante ao propósito do Minikube).
    • Rancher Kubernetes Engine (RKE) ou K3d ou outros também estão disponíveis, mas esses são direcionados para clusters containerizados (k3d roda um cluster K3s em Docker) ou cenários de implantação mais complexos. Em um homelab, o K3s e o MicroK8s tornaram-se, de fato, as soluções fáceis padrão.

Conclusão: Para um homelab com 3 nós decentes, MicroK8s ou K3s são as escolhas recomendadas para obter um cluster Kubernetes funcional com mínimos problemas. Eles nos permitirão aproveitar todos os nossos nós em um único cluster e oferecem suporte embutido para volumes persistentes e serviços de LoadBalancer, que é exatamente o que pedimos. Se preferirmos uma solução mais plug-and-play integrada ao Ubuntu, escolha MicroK8s. Se preferirmos uma solução super leve, comprovada e com suporte do Rancher, escolha K3s. Teremos um cluster funcionando em minutos, de qualquer forma. Depois de configurado, podemos implantar o Dashboard do Kubernetes ou outras ferramentas para gerenciá-lo e começar a hospedar nossas aplicações com armazenamento persistente e exposição fácil de serviços. Aproveitem nossa jornada com Kubernetes no homelab!

Páginas Oficiais das Distribuições do Kubernetes