Qual é a melhor distribuição de Kubernetes para um laboratório doméstico?

A melhor distribuição do Kubernetes para homelab é o K3s ou o MicroK8s.

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

Escolhendo a melhor distribuição de Kubernetes para o nosso homelab

Conteúdo da página

Estou comparando variantes auto-hospedadas do Kubernetes adequadas para um homelab baseado em Ubuntu com 3 nós (16 GB de RAM, 4 núcleos cada), focando na facilidade de configuração e manutenção, suporte a 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. Desejamos um cluster Kubernetes de fácil instalação e baixa manutenção (seja de nó único ou de 3 nós) com suporte a serviços de Volumes Persistentes (PV) e LoadBalancer (LB) (para que aplicativos nativos da nuvem que necessitem de armazenamento ou IPs externos funcionem sem problemas). Concentraremos nas opções de cluster de 3 nós sem requisitos de HA ou compatibilidade com CPU ARM.

kubernetes homelab

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

K3s (Kubernetes Leve da Rancher)

Recursos Principais: K3s é uma distribuição de Kubernetes certificada pela CNCF projetada para uso mínimo de recursos (pode rodar com apenas 512 MB de RAM). Ele empacota todo o plano de controle do Kubernetes em um único binário e processo, usando componentes leves (por exemplo, banco de dados SQLite por padrão em vez de etcd, flannel para rede). Inclui padrões sensatos como um controlador de ingress integrado (Traefik) e um load balancer de serviço simples. O K3s remove recursos legados/alpha para reduzir o excesso.

Facilidade de Instalação e Manutenção: Extremamente simples – podemos instalá-lo com um script de uma linha (curl ... | sh) ou via ferramentas como K3sup. O servidor inicializa com componentes padrão “out-of-the-box”. Adicionar nós é direto (execute o agente K3s com um token do servidor). A atualização é fácil (substitua o binário ou use o script de instalação para a nova versão). Nenhuma configuração de etcd separada é necessária (a menos que você escolha uma configuração HA multi-master). O K3s é projetado para exigir ajustes mínimos após a instalação, tornando-o popular para IoT e homelabs.
Suporte a Volumes Persistentes: Incluído. Por padrão, o K3s vem com a StorageClass local-path 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 nó único (cada volume está no disco de um nó), mas funciona “out-of-the-box” para aplicativos stateful. 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: Incluído. 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 de 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 IP do LB e usa roteamento iptables nos pods LB para enviar o tráfego para o ClusterIP do serviço. Isso funciona com configuração zero – os serviços não ficarão “pendentes” (ao contrário do K8s vanilla em metal). A contrapartida é que o IP externo do LB será um dos IPs do nosso nó (ou todos os nós) e devemos garantir que a porta esteja livre. Para a maioria dos usos em homelab (expor alguns serviços nas portas HTTP/HTTPS), isso é perfeitamente aceitável. Se necessário, podemos desativar o LB integrado e instalar o MetalLB manualmente, mas a maioria dos usuários permanece com o padrão conveniente.
Requisitos de Recursos: Muito baixos. O K3s pode rodar mesmo em hardware de baixo desempenho. Oficialmente, 512 MB de RAM e alguns centenas de MB de disco são suficientes para um nó de servidor. Na prática, um cluster pequeno pode usar alguns centenas de MB de memória para o plano de controle. Seu binário é <100 MB. A sobrecarga de CPU é mínima (o K3s usa ligeiramente mais CPU em repouso comparado ao MicroK8s, mas não por uma margem grande). Nossos nós (16 GB cada) são mais do que suficientes para rodar o K3s confortavelmente.
Nó Único vs Multi-Nó: Adequado para ambos. O K3s pode rodar em nó único (todo o plano de controle e cargas de trabalho em uma máquina) ou multi-nó. Para uma configuração de 3 nós, podemos rodar 1 servidor (master) e 2 agentes, ou até mesmo fazer todos os 3 servirem de servidores para HA (não necessário aqui, já que HA não é o objetivo). Unir agentes é trivial com o token. O banco de dados SQLite padrão do K3s funciona para servidor único; para HA multi-servidor, mudaríamos para etcd embutido (o K3s pode fazer isso automaticamente ao iniciar múltiplos nós de servidor).
Ferramentas de CLI e UI: Interagimos com o K3s como qualquer Kubernetes – via kubectl. O K3s inclui seu próprio build do kubectl (podemos executar k3s kubectl ... ou apenas usar um kubectl padrão apontando para o kubeconfig do K3s). Não há um CLI específico do K3s além dos comandos de instalação; é intencionalmente minimalista. Nenhuma interface web integrada está incluída (o Dashboard upstream não é instalado por padrão). No entanto, podemos implantar manualmente o Kubernetes Dashboard ou outras ferramentas no K3s como em qualquer cluster padrão. A Rancher (a ferramenta de gerenciamento GUI da mesma empresa) também pode ser instalada sobre o K3s se uma UI completa for desejada, mas não faz parte do próprio K3s. Essencialmente, o K3s fornece as APIs principais do k8s e adicionamos extras conforme necessário (ingress, armazenamento, etc. – alguns dos quais já estão incluídos como mencionado).

MicroK8s (Kubernetes de Baixa Operação da Canonical)

Recursos Principais: MicroK8s é a distribuição de Kubernetes leve da Canonical, entregue como um pacote snap. Instala um cluster de Kubernetes totalmente conformante (binários upstream) com um único comando e é projetado para facilidade de uso (“low ops”) em uma máquina única ou pequeno cluster. Enfatiza uma abordagem “baterias inclusas” – obtemos muitos recursos opcionais que podem ser ativados com comandos simples. O MicroK8s define uma experiência Kubernetes vanilla (todas as APIs padrão) por padrão, mas com complementos convenientes para necessidades comuns. Suporta implantações de nó único e multi-nó (podemos formar um cluster “juntando” nós) e até tem um modo HA para o plano de controle (usando Dqlite – um SQLite distribuído – quando temos 3 masters).

Facilidade de Instalação e Manutenção: Extremamente fácil também – apenas snap install microk8s --classic em uma máquina Ubuntu configurará um nó Kubernetes. É um único pacote que inclui todos os componentes. O MicroK8s é mantido via sistema snap do Ubuntu, o que significa que as atualizações são atômicas e podem ser automáticas (podemos rastrear um canal para versões do Kubernetes). Esta capacidade de atualização automática é única entre estas opções – podemos optar por receber correções de segurança e atualizações menores via atualizações snap. O gerenciamento do MicroK8s é feito via o comando microk8s, que tem subcomandos para habilitar/desabilitar recursos. No geral, é muito sem atrito: não há contêineres ou VMs para gerenciar (roda nativamente no host) e nenhum etcd externo para configurar (usa um banco de dados 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 add-on. Por padrão, o MicroK8s não provisiona PVs automaticamente até que habilitemos o add-on “hostpath-storage”. Habilitar isso (com microk8s enable hostpath-storage) cria uma StorageClass padrão que aloca volumes de um diretório no host. Isso é essencialmente um provisionador hostPath dinâmico, semelhante em conceito ao local-path do K3s. Uma vez habilitado, qualquer PVC se ligará a um PV hostPath no nó do MicroK8s. (Em um cluster multi-nó do MicroK8s, o PV hostpath residirá em um único nó – adequado para testes ou uso em homelab, mas não para armazenamento distribuído). O MicroK8s também oferece Mayastor e outros add-ons de armazenamento se quisermos armazenamento mais avançado entre nós, mas para simplificação, o armazenamento hostpath funciona bem. Nota: O add-on não é habilitado por padrão (para manter as coisas leves), então quereremos habilitá-lo para fazer os PVCs funcionarem. A Canonical observa que isso não é para uso em produção HA (já que não é replicado), mas para um homelab é perfeito.
Suporte a LoadBalancer: Disponível via add-on. O MicroK8s não inclui um load balancer padrão, mas fornece o MetalLB como um add-on fácil. Executar microk8s enable metallb:<start-IP>-<end-IP> implanta o MetalLB no modo Layer 2 e nos permite especificar uma pool de IPs da nossa LAN para usar em Serviços LoadBalancer. Uma vez habilitado, qualquer Serviço do tipo LoadBalancer receberá automaticamente um IP desse intervalo (e o MicroK8s o anunciará via ARP na LAN). Isso fornece uma experiência semelhante à nuvem em metal. (Se não habilitarmos 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 um subnet ou intervalo de IP livre em nossa rede para ele. O comando enable do MicroK8s torna a instalação indolor, mas ainda é uma etapa separada. (Em contraste, o K3s funciona out-of-the-box para LB, mas com a limitação de usar IPs/portas do nó.) Muitos usuários do MicroK8s simplesmente habilitam 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 pegada. Executa todos os serviços principais (API server, controller, scheduler, kubelet, etcd ou Dqlite) nativamente. O uso em repouso é tipicamente ~500–600 MB de RAM para o plano de controle, dependendo de quais add-ons estão habilitados. A Canonical cita ~540 MB de memória base. O uso de CPU é baixo em repouso, e nossos nós de 16 GB têm espaço de sobra. O requisito de espaço em disco é pequeno (snap ~200 MB mais dados do etcd). Em suma, o MicroK8s pode rodar em hardware modesto (é até oferecido para Raspberry Pis), e em nosso cenário as máquinas acomodam-no facilmente. Se múltiplos add-ons forem habilitados (dashboard, monitoramento, etc.), o uso de recursos aumentará accordingly.
Nó Único vs Multi-Nó: O MicroK8s funciona bem para ambos. Podemos usá-lo para um cluster de nó único (por exemplo, em uma máquina de dev 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 join do primeiro nó e o usamos nos outros). Em uma configuração multi-nó sem HA, um nó será o plano de controle primário. Com 3 nós, também temos a opção de habilitar o modo ha-cluster (tornando o plano de controle HA executando Dqlite em 3 nós), embora em nosso caso HA não seja necessário. Seja único ou três nós, a experiência é a mesma API 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 “micro nuvem” de algumas caixas Ubuntu rodando k8s com esforço mínimo.
Ferramentas de CLI e UI: O MicroK8s vem com a ferramenta de linha de comando microk8s, que é muito útil. Por exemplo, microk8s enable <addon> alterna vários serviços (DNS, ingress, armazenamento, metallb, dashboard, etc.), e microk8s status mostra o que está rodando. Também inclui um kubectl embutido: podemos usar microk8s kubectl ... (ou criar um alias) que se comunica com o cluster – isso é bom porque não precisamos configurar um kubeconfig. Para UI, o MicroK8s fornece o Kubernetes Dashboard como um add-on (microk8s enable dashboard), que implantará a interface web padrão. Uma vez habilitado, podemos acessá-lo (roda 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 habilitá-lo é um plus. Em resumo, o MicroK8s enfatiza uma experiência de comando único para tarefas comuns e uma filosofia de “funciona”, abstraindo muita complexidade (ao custo de ocultar alguns internos). Isso o torna muito amigável para homelab para quem quer um cluster Kubernetes sem configuração manual de cada componente.

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

Minikube (K8s Local de Nó Único)

Recursos Principais: Minikube é primariamente uma ferramenta para rodar Kubernetes localmente (frequentemente no PC ou laptop de um desenvolvedor) em vez de um cluster tradicional através de múltiplas máquinas. Cria um cluster Kubernetes de nó único em uma VM ou contêiner em nossa máquina. O Minikube é conhecido por seu amplo suporte de ambientes – pode rodar em Linux, macOS, Windows e suporta vários hypervisors (VirtualBox, KVM, Hyper-V, driver Docker, etc.). É mantido pelos SIGs do Kubernetes e é frequentemente usado para testes e aprendizado. Embora o Minikube possa ser induzido a uma configuração multi-nó, é essencialmente destinado a clusters de nó único (o modo “multi-nó” do Minikube na verdade apenas inicia múltiplos nós no mesmo host usando tempos de execução de contêiner – útil para simular um cluster, mas não para rodar 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 temos 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 obter um cluster Kubernetes rodando pela primeira vez. O CLI (minikube) fornece comandos para interagir com a VM (iniciar, parar, deletar) e para habilitar add-ons. Como o Minikube é projetado para uso local, não é um daemon de “longo prazo” – tipicamente o iniciamos quando precisamos e paramos quando terminamos, embora possamos mantê-lo rodando continuamente em um servidor de homelab se desejado. Manutenção/atualizações são fáceis: apenas atualize a versão do minikube e reinicie o cluster (o Minikube também pode atualizar a versão do Kubernetes que roda com uma flag). No entanto, uma limitação é que o Minikube é single-node por design (adicionar mais nós significa iniciar instâncias de VM adicionais no mesmo host, não juntar hosts físicos separados). Então, usar Minikube em três nós físicos separados significaria essencialmente rodar três clusters de nó único independentes, o que provavelmente não é o que queremos. O Minikube brilha para desenvolvimento e teste em uma máquina, mas não é destinado a gerenciar um cluster espalhado por múltiplos servidores físicos.
Suporte a Volumes Persistentes: Incluído (hostPath). Clusters Minikube incluem automaticamente uma StorageClass padrão que usa um provisionador hostPath. Na verdade, o Minikube roda 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 armazenamento no sistema de arquivos da VM do Minikube (geralmente sob /tmp/hostpath-provisioner ou similar). Isso funciona out-of-the-box – 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 ressalva: se reiniciarmos ou deletarmos a VM do Minikube, aqueles volumes hostPath poderiam ser perdidos (o Minikube tenta persistir certos diretórios através de reinícios – e.g., /data, /var/lib/minikube, /tmp/hostpath* são preservados). Mas em geral, para um ambiente não-produtivo, isso é aceitável. Se quisermos simular mais, o Minikube também tem um add-on de driver CSI hostpath que suporta snapshotting e pode funcionar em modo multi-nó, mas isso é mais para experimentação. Resumo: o Minikube suporta PVs por padrão via hostPath, que é suficiente para um teste de homelab de aplicativos stateful.
Suporte a LoadBalancer: Suportado via tunelamento (ou add-on MetalLB). Em uma nuvem, um serviço LoadBalancer obtém um LB da nuvem com um IP externo. No Minikube, obviamente não há provedor de nuvem, então o Minikube fornece dois mecanismos:
- Minikube Tunnel: 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, usa nosso host para atuar como o “LB externo”. Quando criamos um Serviço LoadBalancer, o Minikube mostrará um “IP externo” (geralmente do subnet do cluster) e o processo minikube tunnel encaminhará isso para o serviço. Isso requer que o processo de tunelamento continue rodando (e tipicamente permissão de root para criar rotas). É um passo um pouco manual, mas o Minikube imprime um lembrete se tivermos um serviço LoadBalancer sem um tunelamento rodando (“External-IP pendente” até iniciarmos o tunelamento).
- Add-on MetalLB: Versões mais novas do Minikube também incluem um add-on MetalLB. Podemos fazer minikube addons enable metallb e configurar um intervalo de IP (o Minikube nos pedirá). Isso efetivamente implanta o MetalLB dentro do cluster Minikube, que então lida com serviços LoadBalancer assim como faria em qualquer Kubernetes em metal. Esta é uma solução mais “in-cluster” e não requer um processo de tunelamento separado após a configuração inicial.
Ambas as opções funcionam, e qual usar é conosco. Para uma exposição rápida de um serviço, minikube tunnel é rápido e efêmero. Para uma configuração mais permanente, o add-on MetalLB pode ser habilitado para que LBs obtenham IPs reais (por exemplo, podemos dar-lhe um intervalo como 10.0.0.240-250 em um Minikube com rede em bridge). Lembre-se de que o Minikube é tipicamente single-node, então, em efeito, o “load balancer” não balanceia através de múltiplos nós – está apenas fornecendo acesso externo ao serviço do nó único. Isso é aceitável para desenvolvimento. Em um homelab, se usarmos apenas um de nossos nós e rodarmos Minikube nele, poderíamos usar isso para acessar nossos aplicativos. 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 geralmente roda um Kubernetes full single-node (em uma VM), o uso de recursos é similar a 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. Em nosso caso, com 16 GB por máquina, isso é trivial. Minikube (Kubernetes) em repouso pode usar ~600 MB de memória. Uma coisa a considerar é que o Minikube estará rodando por cima de nosso OS – seja como uma VM via um hypervisor ou um contêiner Docker – o que adiciona alguma sobrecarga. Para um servidor de homelab, poderíamos rodar Minikube com o driver “none” (que instala componentes Kubernetes diretamente no host). No entanto, o driver “none” (também conhecido como bare-metal) é essencialmente similar a apenas usar kubeadm naquele 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 de nossos nós de homelab pode rodar Minikube facilmente. A única restrição é que o Minikube não usará os recursos de todos os 3 nós – ficará confinado ao único host onde roda (a menos que use o experimental multi-nó dentro de um host).
Nó Único vs Multi-Nó: Primariamente single-node. O Minikube é ideal para um cluster de nó único em uma máquina. Tem uma funcionalidade para simular múltiplos nós (e.g. minikube start --nodes 3 com o driver Docker iniciará 3 nós Kubernetes como contêineres em um host), mas isso é apenas para testes. Não podemos usar o Minikube para criar um cluster real multi-nó através de 3 servidores físicos separados. Se tivermos 3 máquinas, teríamos que rodar 3 instâncias Minikube independentes (não em um cluster). Isso não é uma experiência de cluster real (eles não saberão uns dos outros). Portanto, o Minikube é não recomendado se nosso objetivo é utilizar todos os três nós em um cluster Kubernetes – é melhor para cenários onde só temos uma máquina (nosso PC ou um servidor) e queremos rodar K8s nela. Também é ótimo para aprender os fundamentos do Kubernetes e fazer desenvolvimento local.
Ferramentas de CLI e UI: A CLI minikube é a interface principal. Usamos para iniciar/parar o cluster, e tem atalhos bonitos: e.g., minikube dashboard habilitará o Kubernetes Dashboard e o abrirá em nosso navegador para nós. minikube addons enable <addon> pode habilitar uma variedade de componentes opcionais (ingress, metallb, metrics-server, etc.). O Minikube configura o acesso kubectl automaticamente (configura um contexto “minikube” em nosso kubeconfig). Para UI, como mencionado, o Kubernetes Dashboard é facilmente acessível via o comando dashboard. O Minikube não tem sua própria interface web única; depende de ferramentas padrão. Depurar o Minikube também é fácil, pois podemos minikube ssh para entrar na VM do nó se necessário. No geral, as ferramentas são muito amigáveis para um cenário de nó único.

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

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

Facilidade de Instalação e Manutenção: Comparado aos outros, o kubeadm é o mais envolvido. Temos que instalar manualmente dependências (tempo de execução de contêiner como containerd, kubeadm, kubelet, kubectl) em cada nó. Depois executamos kubeadm init no master, e kubeadm join nos workers com o token que ele dá. Também precisamos configurar um CNI (plugin de rede) após a inicialização (Calico, Flannel, etc.) já que o kubeadm não instala um por padrão. Há passos bem documentados para tudo isso (o processo não é difícil, mas são muitos passos) – essencialmente, o kubeadm nos dá um cluster inicial, mas espera que lidemos com os add-ons. Em termos de manutenção, somos responsáveis por atualizações (kubeadm tem um comando de upgrade, mas devemos drenar nós, atualizar binários, etc. manualmente), além de monitorar a saúde do etcd, renovações de certificados, etc. Em suma, o kubeadm é poderoso mas manual. É frequentemente chamado de “o caminho difícil” (embora não tão difícil quanto construir do source). Para um entusiasta de homelab que gosta de aprender, o kubeadm é uma ótima maneira de entender o Kubernetes profundamente. Mas se nossa prioridade é “fácil e baixa manutenção”, o kubeadm será mais trabalho que K3s/MicroK8s. Cada upgrade ou mudança exigirá esforço manual. Dito isso, uma vez configurado, é o negócio real: um cluster Kubernetes padrão sem abstrações ocultas.
Suporte a Volumes Persistentes: Nenhum por padrão (deve adicionar manualmente). Um cluster instalado com kubeadm é essencialmente um Kubernetes em branco – não inclui uma StorageClass padrão ou provisionador dinâmico out-of-the-box. Em ambientes de nuvem, o provedor de nuvem normalmente forneceria uma StorageClass padrão (e.g., AWS EBS, etc.), mas em um ambiente bare-metal de homelab, 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). Este é um add-on simples (apenas um manifesto YAML) e nos dá armazenamento local dinâmico.
- 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 Longhorn ou Ceph RBD via Rook se quisermos armazenamento distribuído através dos nós. Estes exigem mais recursos e complexidade.
O ponto chave é que o kubeadm não “resolve” armazenamento para nós – devemos decidir e configurar. Se a facilidade for a prioridade, o caminho mais simples é implantar um provisionador hostPath ou usar NFS. Por exemplo, o provisionador local-path da Rancher pode ser instalado em alguns comandos kubectl apply e mimetizará 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 instalado. Então, embora o kubeadm certamente suporte Volumes Persistentes (é Kubernetes completo), o suporte para PV dinâmico é tão bom quanto o esforço que colocamos para configurá-lo.
Suporte a LoadBalancer: Nenhum por padrão (deve adicionar manualmente). História similar aqui: em um cluster on-prem tradicional, não temos uma implementação LoadBalancer integrada. Se criarmos um Serviço do tipo LoadBalancer em um cluster kubeadm simples, ficará em estado pending para sempre até implantarmos um controlador para lidar com isso. A solução comum é instalar o MetalLB nós mesmos. O MetalLB pode ser instalado via manifesto ou chart Helm – configuraríamos um intervalo de IP e ele então alocaria esses IPs para serviços LoadBalancer (assim como no MicroK8s). Muitos guias existem para instalar MetalLB em clusters kubeadm. Outra alternativa que alguns usam é kube-vip para VIP de plano de controle e LBs de serviço, mas o MetalLB é mais simples para serviços. Essencialmente, com kubeadm temos a liberdade (ou ônus) de configurar o mecanismo de balanceamento de carga que melhor se adapta às nossas necessidades. Se não configurarmos nenhum, estamos limitados a serviços NodePort para acesso externo. Para um homelab, instalar MetalLB é altamente recomendado – é direto e nos dá aquela funcionalidade de IP de serviço como na nuvem. Mas novamente, isso é um passo extra que devemos executar (ao contrário do K3s que funciona out-of-box ou MicroK8s com um enable simples).
Requisitos de Recursos: Kubernetes padrão é um pouco mais pesado que as versões reduzidas. Cada nó rodará um kubelet e kube-proxy, e o master rodará etcd e componentes de plano de controle. Um único nó de plano de controle ainda pode rodar em 2 GB de RAM, mas tipicamente poderíamos querer um pouco mais para conforto se rodarmos pods nele. O guia padok sugere 2 GB para master, 2 GB para worker mínimo. Em nosso cenário (16 GB por nó), isso é bem. Etcd e API server em repouso podem usar alguns centenas de MB de memória cada. Não há uma grande diferença em tempo de execução entre um cluster kubeadm e MicroK8s – afinal, o MicroK8s são esses mesmos componentes. A diferença é apenas o que roda por padrão (MicroK8s pode habilitar DNS e armazenamento por padrão, enquanto no kubeadm instalaríamos esses). Então, em termos de recursos, o kubeadm pode ser tão leve ou pesado quanto configurarmos. Com nada extra instalado, poderia ser bastante leve. Com uma configuração típica (digamos que adicionemos CoreDNS, Dashboard, etc.), espere ~1 GB ou assim usado para sobrecargas de sistema. Temos bastante RAM, então recursos não são uma preocupação. É mais sobre o tempo/recursos humanos necessários para gerenciá-lo do que CPU/RAM.
Nó Único vs Multi-Nó: Kubeadm pode fazer ambos, com flexibilidade total. Podemos inicializar um cluster de nó único (e até dizer ao kubeadm para deixar o nó único rodar cargas de trabalho destainting o master). Ou podemos ter um master e juntar dois workers (uma configuração comum de 3 nós). Poderíamos até configurar 3 masters e 3 workers, etc. – qualquer topologia. Em nosso caso, uma configuração kubeadm provável seria 1 nó de plano de controle e 2 workers (já que HA não é necessário, não precisamos de múltiplos masters). Isso nos dá um cluster funcional de 3 nós. O processo para multi-nó é bem documentado: essencialmente, instale Kubernetes em todos, inicie um, junte os outros. O resultado é idêntico ao que um cluster gerenciado ou outra distribuição daria: nossos 3 nós aparecem em kubectl get nodes, etc. Então o kubeadm definitivamente atende ao requisito “pode usar todos os 3 nós”.
Ferramentas de CLI e UI: Com kubeadm, o único CLI especial é o próprio kubeadm, usado para configuração e (depois) passos de upgrade. No dia a dia, use kubectl para gerenciar o cluster. Não há CLI de gerenciamento integrado além do que o Kubernetes fornece. Para UI, nada é incluído por padrão – podemos implantar manualmente o Kubernetes Dashboard ou qualquer outra ferramenta (assim como em qualquer cluster). Essencialmente, o kubeadm nos dá uma tela em branco Kubernetes. Cabe a nós pintá-la – o que inclui instalar conveniências como dashboard, controladores de ingress, classes de armazenamento, etc. Muitos 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 kubeadm estamos obtendo o ambiente Kubernetes puro – flexibilidade máxima, mas também a necessidade de configurar tudo como se fosse um cluster de produção.
Kubespray Veja também como instalar este sabor 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 da Rancher)	MicroK8s (K8s “Low-Ops” da Canonical)	Minikube (K8s de Dev Single-Node)	Kubeadm (Kubernetes Vanilla)
Instalação	Script de instalação de uma linha (binário único). Roda como um único serviço de sistema. Configuração muito rápida.	Instalação de um comando via snap no Ubuntu. Todos os componentes incluídos. Clusterização fácil com `microk8s join`.	Instale CLI minikube, depois `minikube start` para lançar uma VM/contêiner local. Cross-platform e amigável para iniciantes.	Instalação manual de kubeadm, kubelet, etc. em cada nó. Execute `kubeadm init` + `kubeadm join` com pré-requisitos. Envolve múltiplos passos (tempo de execução, plugin de rede, etc.).
Manutenção & Upgrades	Upgrades manuais (substitua binário ou use script de instalação para nova versão). Simples, pois é um único binário; pouco para gerenciar. Sem auto-atualização.	Refresh snap para atualizações (pode ser automático). Add-ons e serviços de cluster gerenciados via CLI `microk8s`. Geralmente low-ops; auto-upgrades disponíveis.	Fácil de deletar/recriar cluster para dev. Upgrades atualizando versão minikube e reiniciando cluster. Destinado a uso efêmero (menos foco em longevidade de upgrade in-place).	Usuário responsável por todos os upgrades. Use `kubeadm upgrade` mas deve drenar nós, lidar com backup do etcd, etc. Controle total, mas você faz o trabalho (sem atualizações automáticas).
Versão K8s	Segue upstream bastante de perto (frequentemente usado em releases edge). CNCF conformante. Alguns recursos desabilitados por padrão (alpha/legacy).	Segue releases upstream (canais snap para 1.27, 1.28, etc.). CNCF conformante. Essencialmente binários K8s vanilla.	Podemos escolher versão Kubernetes no início (e.g. `minikube start --kubernetes-version=v1.27`). Padrão para mais recente estável.	Qualquer versão que quisermos (instale versões específicas kubeadm/kubelet). Kubernetes upstream completo – nós decidimos a versão e quando atualizar.
Recursos Padrão	Padrões embutidos: Flannel CNI, CoreDNS, Traefik ingress, service LB, classe de armazenamento local, metrics-server, etc. (Todos podem ser desabilitados se não necessários). Configuração mínima necessária para ser funcional.	Mínimo padrão: DNS geralmente ligado, outros opcionais. Add-ons de um comando fácil para ingress (NGINX), MetalLB, armazenamento hostpath, dashboard, etc.. Pode habilitar modo HA em 3+ nós.	Embutido na VM: tipicamente inclui runtime Docker/containerd, Kubernetes com addons padrão como StorageProvisioner e DNS. Add-ons opcionais (ingress, dashboard, etc.) alternados via CLI. Sem multi-nó por padrão.	Básico: Nada além do Kubernetes core. Sem ingress, sem armazenamento ou LB padrão, sem dashboard até instalarmos. Escolhemos plugin CNI (deve instalar um para rede). Essencialmente um cluster DIY.
Suporte a Volume Persistente	Sim – out-of-box. Provisionador dinâmico local-path da Rancher incluído, que cria PVs hostPath no nó para qualquer PVC. StorageClass padrão “local-path” usa disco local automaticamente.	Sim – add-on fácil. Habilite `hostpath-storage` para obter uma StorageClass padrão para PVs dinâmicos usando hostPath. Até ser habilitado, sem provisionador PV padrão. Add-on não para produção multi-nó, mas bom para homelab.	Sim – out-of-box. StorageClass padrão usa provisionador hostPath dentro da VM minikube. PVCs são atendidos por um controlador simples que cria um PV hostPath no sistema de arquivos do nó. Dados persistem através de reinícios em certos dirs.	Não (manual). Sem provisionador padrão – cluster não terá StorageClass inicialmente. Usuário deve instalar solução de armazenamento (e.g. provisionador local path, NFS, Ceph, etc.). Abordagem básica: aplique um manifesto YAML de provisionador hostPath para mimetizar o que K3s/Minikube fazem. Até então, PVCs permanecem pendentes.
Suporte a LoadBalancer	Sim – ServiceLB integrado. 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 tráfego. Funciona out-of-the-box sem configuração. Adequado para pequenos clusters; usa IP interno/externo do nó para serviço.	Sim – via add-on MetalLB. Habilite `metallb` com um intervalo de IP para alocar. Fornece load balancer verdadeiro Layer-2 em metal. Não habilitado por padrão. Uma vez habilitado, cada serviço LoadBalancer obtém um IP único de nossa pool. Requer um pouco de configuração inicial (intervalo de IP).	Sim – via tunelamento ou MetalLB. Sem LB de nuvem, mas podemos rodar `minikube tunnel` para atribuir um IP externo a serviços LoadBalancer (cria rota no host). Alternativamente, habilite o add-on MetalLB no minikube para IPs LB automáticos. Por padrão, serviços LB mostrarão “pendente” até usarmos um desses métodos.	Não (manual). Sem LB integrado. Tipicamente instale MetalLB manualmente para funcionalidade LB em metal. Uma vez que MetalLB (ou outro controlador LB) esteja configurado, serviços LoadBalancer funcionam. Sem ele, serviços LB ficam pendentes indefinidamente.
Rede (CNI)	Padrão = Flannel (rede overlay). 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 desabilitar).	Padrão = Calico (para versões recentes em modo HA) ou um padrão não complicado. (MicroK8s historicamente usava flannel; agora tende a usar Calico para confinamento estrito). CoreDNS habilitado por padrão. NGINX ingress disponível via addon (`microk8s enable ingress`).	Padrão = kubenet/bridge (depende do driver; frequentemente usa uma rede NAT simples). CoreDNS roda por padrão. Podemos habilitar um add-on de ingress NGINX se necessário. Rede é confinada à VM única; NodePort é acessível via `minikube ip`.	Escolha de CNI. Kubeadm não instala nenhum plugin CNI – devemos implantar um (Calico, Flannel, Weave, etc.). Temos controle total. A maioria dos guias tem-nos aplicando YAML Calico após kubeadm init. CoreDNS é instalado por kubeadm por padrão como DNS do cluster. Controlador de Ingress – escolher e instalar nós mesmos (e.g., NGINX ou Traefik via manifests/Helm).
Clusterização Multi-Nó	Sim. Projetado para multi-nó. Join fácil com token. Pode usar DB externo ou etcd embutido para multi-master. Ótimo para homelabs de 2-3+ nós. Nenhuma dependência extra necessária – K3s tem sua própria clusterização integrada.	Sim. Suporta clusterização de múltiplos nós MicroK8s (com `microk8s join`). Pode habilitar HA com 3+ masters (Dqlite). Muito simples de formar um cluster, especialmente se todos os nós rodarem Ubuntu + snap.	Não (físico). Single-node por design. Pode simular multi-nó em uma máquina (múltiplos nós em contêineres Docker), mas não pode abranger múltiplos hosts físicos em um cluster. Use instâncias Minikube separadas para clusters separados.	Sim. Suporta totalmente multi-nó (esse é o ponto). Podemos ter 1 master + muitos workers, ou até múltiplos masters (embora configuração HA kubeadm seja mais complexa). Nenhuma limitação integrada no tamanho do cluster.
Sobrecarga de Recursos	Muito baixa. Plano de controle ~<0.5 GB memória em repouso. Processo único para plano de controle gera pequena pegada. Eficiente em CPU (embora possa usar ligeiramente mais CPU em repouso que MicroK8s por alguns relatórios). Ideal para baixa potência ou muita capacidade sobrando.	Baixa. ~0.5–0.6 GB memória para plano de controle em repouso. Memória base ligeiramente maior que K3s, mas permanece estável. Usa snap Ubuntu (pode ter alguma sobrecarga). Ainda leve relativo ao Kubernetes completo.	Moderado. VM padrão 2 GB alocado (uso ~0.6 GB em repouso). Roda Kubernetes single-node completo, mais a camada VM. Não é problema em sistemas de 16 GB, mas essencialmente consome recursos de um pequeno cluster em uma máquina.	Moderado. Um único-master com um worker pode usar ~1 GB em repouso após adicionar addons típicos. Cada nó adicional adiciona sobrecarga mínima (apenas kubelet, proxy). Similar a rodar Kubernetes em VMs de nuvem de tamanho comparável. Em 3 nós com 16 GB cada, sobrecarga é negligenciável no contexto.
Ferramentas CLI	Use `k3s` para instalação e como wrapper para kubectl (ou use `kubectl` padrão). Sem CLI de gerenciamento separado (K3s é majoritariamente “configure e esqueça”). Alguns scripts auxiliares (e.g., `k3s-killall.sh`). GUI da Rancher pode ser adicionada por cima se desejado.	CLI `microk8s` rico: e.g., `microk8s enable/disable <addon>`, `microk8s status`. Também inclui `microk8s kubectl`. Projetado para simplificar tarefas comuns (sem edição direta de manifests de sistema necessária para básicos).	CLI `minikube` para iniciar/parar cluster, gerenciar config e addons, e obter informações (IP, URL de serviço, logs). Também fornece comandos de conveniência como `minikube dashboard`. Interagir com cluster via `kubectl` (config auto-set para contexto minikube).	Apenas `kubeadm` para configuração inicial e upgrades. Operações diárias via `kubectl` padrão e outras ferramentas Kubernetes. Sem CLI específico da distribuição além do bootstrap. Você estará trabalhando com comandos Kubernetes brutos e talvez ferramentas OS para manutenção.
UI / Dashboard	Não incluído por padrão. Pode instalar manualmente o Kubernetes Dashboard ou usar ferramentas externas (nada específico da Rancher a menos que adicionemos Rancher separadamente). Foco do K3s é operação headless.	Não incluído por padrão, mas disponível via um comando: `microk8s enable dashboard` implanta a UI Dashboard padrão. Acesso fácil ao cluster via `microk8s dashboard-proxy`. Também integra bem com GUI Lens da Canonical se desejado (Lens pode acessar MicroK8s diretamente).	Não habilitado por padrão, mas o comando `minikube dashboard` implantará e abrirá a UI Dashboard web para nós. Isso é destinado a conveniência em dev local – um comando e temos 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 apps de dashboard de terceiros. Em um homelab, pode-se 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 docs oficiais e guias de usuários: por exemplo, pegadas de memória da própria comparação do MicroK8s, armazenamento padrão nos docs do K3s, comportamento de serviço LB do K3s da documentação do K3s, detalhes de add-on do MicroK8s dos docs da Canonical, PV e tunelamento do Minikube dos docs do Kubernetes, e relatórios de experiência geral. (Veja Referências para citações completas.)

Recomendações

Dadas as prioridades (facilidade de configuração/manutenção, e suporte integrado para armazenamento e load balancers) e o cenário (3 nós Ubuntu, não preocupados com HA):

Escolhas Principais: K3s ou MicroK8s são os mais adequados para um homelab de 3 nós:
- Ambos são extremamente fáceis de instalar (um único comando em cada nó) e requerem manutenção contínua mínima. Abstraem a maior parte da complexidade de rodar um cluster.
- Ambos suportam clusterização multi-nó out-of-the-box (podemos juntar nossos 3 nós e ver um cluster unificado).
- Cada um fornece uma solução para Volumes Persistentes e LoadBalancers sem muito esforço: K3s inclui-os por padrão (Armazenamento Local Path, Klipper LB) e MicroK8s torna-os disponíveis via comandos enable simples. Isso significa que podemos implantar aplicativos típicos (bancos de dados com PVCs, serviços com type=LoadBalancer) com configuração manual mínima.
- K3s pode atrair se quisermos a pegada absolutamente menor e não nos importarmos em usar seus padrões integrados (ingress Traefik, etc.). É uma abordagem “configure e funciona” com padrões opinados. Também é muito popular na comunidade de homelab por sua simplicidade. Usaremos kubectl padrão majoritariamente, e podemos ajustar ou desabilitar os componentes empacotados se necessário. K3s pode ser preferível se não estivermos no Ubuntu ou se gostarmos do ecossistema da Rancher (ou planejarmos usar a UI de gerenciamento da Rancher depois).
- MicroK8s pode atrair se preferirmos uma solução suportada pelo Ubuntu e gostarmos da ideia de habilitação de recursos de um comando. É essencialmente Kubernetes vanilla por baixo do capô, o que alguns acham mais fácil de estender. Os add-ons (como microk8s enable ingress dns storage metallb) podem nos dar uma “micro nuvem” totalmente funcional em minutos. O MicroK8s também lida com atualizações graciosamente via snaps, o que pode ser bom para manter nosso cluster atualizado sem intervenção manual (podemos desligar isso ou controlar o canal para evitar surpresas). Se já estamos rodando Ubuntu em todos os nós (o que estamos) e não nos importarmos em usar snaps, MicroK8s é uma excelente escolha para um cluster de baixa manutenção.
Em suma: Não dá para errar com K3s ou MicroK8s para este cenário. Ambos nos darão um Kubernetes fácil e amigável para homelab com os recursos que precisamos. Muitos usuários relatam experiências positivas com ambos em setups domésticos de 2–3 nós. MicroK8s pode ter uma ligeira vantagem em facilidade de uso (por causa dos add-ons e integração), enquanto K3s pode ter uma ligeira vantagem em rodar leve e ser direto por baixo do capô.
Quando escolher Minikube: Se estivéssemos rodando apenas em uma única máquina ou quisessemos um cluster de dev descartável, Minikube é fantástico para isso. É a maneira mais fácil de subir Kubernetes em um laptop ou um nó para testes. No entanto, para um cluster permanente de 3 nós, Minikube não é a ferramenta certa – não irá fundir aqueles 3 nós em um cluster. Terminaríamos subutilizando nosso hardware ou gerenciando 3 clusters separados, o que não é desejável. Então, neste homelab com múltiplos nós, Minikube é não recomendado como solução principal. Ainda poderíamos usar Minikube em nosso computador pessoal para tentar coisas antes de implantar no cluster de homelab, mas para o cluster em si, use algo como K3s/MicroK8s.
Quando escolher Kubeadm: Se nosso objetivo fosse aprender os internos do Kubernetes ou ter controle total e a configuração “como produção”, kubeadm é um bom exercício. Forçará-nos 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, kubeadm é o mais hands-on. Cada recurso que precisamos (como armazenamento ou LB) temos que configurar. Para um homelab focado em aprendizado, isso poderia ser um pro (educacional); para um homelab só-faça-funcionar, isso é um con. Além disso, a manutenção será mais envolvida (especialmente durante upgrades). A menos que especificamente queiramos a experiência vanilla do Kubernetes para aprendizado ou necessidades personalizadas específicas, usar K3s ou MicroK8s nos economizará muito tempo e dores de cabeça em um ambiente de homelab. Dito isso, alguns usuários experientes preferem kubeadm mesmo em casa para evitar qualquer quirk específico de fornecedor e ter tudo sob seu controle. Depende muito de quanto esforço queremos gastar. Para a maioria, kubeadm é exagero para um pequeno cluster onde alta disponibilidade não é uma preocupação.
Outras Opções: Há alguns outros sabores leves de Kubernetes, como k0s (da Mirantis) e ferramentas como kind (Kubernetes em Docker). Para completude:
- k0s é outra distribuição Kubernetes de binário único, objetivo similar ao K3s/MicroK8s, focando em flexibilidade e pegada mínima. É relativamente novo mas tem fãs na comunidade de homelab. Também pode rodar facilmente em nossos 3 nós. Não tem (atualmente) a mesma base de usuários grande como K3s/MicroK8s, mas é uma opção para observar (especialmente se gostarmos da ideia de um Kubernetes open-source, configurável e minimalista – alguns relatórios até mostram k0s usando recursos de repouso ligeiramente menores que K3s/MicroK8s em setups similares).
- kind é principalmente para testar clusters Kubernetes em contêineres Docker (frequentemente usado para pipelines CI). Não é algo que rodaríamos como nosso cluster sempre-on de homelab – é mais para clusters efêmeros rápidos em uma máquina (similar ao propósito do Minikube).
- Rancher Kubernetes Engine (RKE) ou K3d ou outros também existem, mas aqueles são voltados para clusters containerizados (k3d roda um cluster K3s em Docker) ou cenários de implantação mais complexos. Em um homelab, K3s e MicroK8s tornaram-se as soluções fáceis de facto.

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ínimo transtorno. Eles permitirão que aproveitemos todos os nossos nós em um cluster, e fornecem suporte integrado para volumes persistentes e serviços LoadBalancer, que é exatamente o que pedimos. Se preferirmos uma solução mais plug-and-play, integrada ao Ubuntu, vá com MicroK8s. Se preferirmos uma solução super leve e comprovada com o respaldo da Rancher, vá com K3s. Teremos um cluster funcionando em minutos de qualquer forma. Uma vez em pé, podemos implantar o Kubernetes Dashboard ou outras ferramentas para gerenciá-lo e começar a hospedar nossos aplicativos com armazenamento persistente e exposição de serviço fácil. Aproveitem a jornada do Kubernetes no homelab!