Usar Kubernetes como serviço ou configurar no braço? Essa é uma decisão que vai muito mais além do simples.
A chave do problema é: Capacidade Ociosa
Você mora 100% do tempo na sua casa, certo? Agora, pense em um cenário onde você passa 15 dias na sua casa e os outros 15 dias em outra casa, em outro estado.
Nesse caso, você precisaria manter as duas casas. Isso significa que, durante boa parte do tempo, recursos como aluguel, manutenção, móveis e até mesmo alimentos estariam sendo desperdiçados. Isso significa que você possui recursos ociosos, uma palavra bonita para desperdicio.
Agora, e se você pudesse otimizar o uso da sua casa? Nos dias em que estivesse fora, outra pessoa poderia utilizá-la, reduzindo seus custos e evitando desperdícios. Parece interessante, não é? Basicamente, você estaria eliminando a capacidade ociosa (desperdicio) da sua casa.
Esse mesmo princípio é aplicado pelas empresas de cloud. Elas otimizam o uso dos servidores ao reduzir a capacidade ociosa, permitindo que vários clientes "alugem" partes dos servidores conforme a necessidade. Assim, conseguem maximizar a eficiência e ganhar dinheiro com recursos compartilhados.
E por que isso é importante ao falar de Kubernetes On-Premises? Porque usar Kubernetes em uma infraestrutura própria (On-Premises) só faz sentido se sua empresa já possui um parque de máquinas e deseja reduzir a capacidade ociosa, otimizando ao máximo o hardware existente.
Como usar Kubernetes On-Premises?
Decidimos usar Kubernetes, e agora?
A decisão mais importante neste momento, especialmente para quem planeja usar Kubernetes em produção, é escolher entre pagar por um serviço gerenciado ou gerenciar o cluster internamente. As principais opções para quem decide assumir essa responsabilidade incluem:
- Configurar manualmente via kubeadm
- Utilizar uma solução como o Rancher
- Optar por uma plataforma mais robusta, como o OpenShift
Os consevadores vão fazer a pergunta clássica: "Administrar meu próprio cluster ou pagar para que outra pessoa o faça?". Afinal, as empresas fizeram isso por anos. Banco de dados, servidores de aplicação, storage, tá tudo dentro de casa, por que não o kubernetes?
Por que agora tem que ser diferente?
Se sua empresa ainda está dando os primeiros passos rumo à nuvem e a discussão sobre adoção ainda está engatinhando, pode parecer natural optar pelo Kubernetes on-premises. Afinal, é só pegar meia dúzia de máquinas, configurar tudo pelo painel do Rancher e pronto, certo? Projeto finalizado, hora de seguir para o próximo!
Essa abordagem faz sentido, afinal, sempre foi assim, então, por que não o Kubernetes?
Sem dúvida, essa escolha oferece a maior flexibilidade e controle. Você terá total autonomia para decidir quais versões do Kubernetes usar, quais recursos e opções habilitar, como e quando realizar atualizações nos clusters, entre outras decisões estratégicas.
Qual a desvantagem ?
Para começar você vai precisar de um time maior, um time experiente. Vai ter que lidar com a manutenção e solucionar problemas.
Subir e configurar um cluster Kubernetes é relativamente simples, mas será que o cluster está pronto para Produção?
Ao pensar nessa possibilidade sua empresa está considerando esses aspectos:
Alta Disponibilidade do Control Plane: Garantir que, mesmo com a falha de um nó do control plane, o cluster permaneça operacional, permitindo deployments e atualizações contínuas.
Tolerância a Falhas das Aplicações: Assegurar que suas aplicações possam operar corretamente mesmo na ausência temporária do control plane.
Alta Disponibilidade dos Worker Nodes: O cluster é capaz de resistir à perda de múltiplos worker nodes ou até de um data center inteiro? Mantendo as aplicações em funcionamento.
Segurança do Cluster: A comunicação interna entre os componentes do cluster precisa ser através de TLS com certificados confiáveis. Sua empresa está apta para aplicar o princípio do menor privilégio para usuários e aplicações? É necessário utilizar padrões de segurança para containers e controlar adequadamente o acesso dos worker nodes ao control plane e ao banco de dados etcd.
Segurança dos Serviços: Certificar de que todos os serviços expostos na rede estejam devidamente autenticados e autorizados. Restringir o acesso ao API Server.
Conformidade com Padrões de Segurança: Verificar se o cluster está em conformidade com os padrões de segurança do Kubernetes estabelecidos pela CNCF.
Configuração das VMs: Utilizar práticas de IaC para configurar as VMs, garantindo atualizações regulares do sistema operacional e aplicação de patches de segurança.
Backup e Restauração: Implementar processos de backup dos dados do cluster e do banco ECTD, além de testar regularmente os procedimentos de restauração para assegurar a integridade dos dados.
Manutenção Contínua: Estabelecer processos para provisionamento de novos nodes, gestão de atualizações nas VMs existentes e atualização do Kubernetes.
Autoscaling: Implementar mecanismos de autoscaling do Cluster para garantir recursos do cluster conforme a demanda das aplicações.
Capacidade ociosa é a resposta
No final das contas, toda a discussão sobre usar Kubernetes On-Premises ou na nuvem se resume a um único fator: capacidade ociosa.
Se sua empresa tem um parque de máquinas subutilizado e deseja aproveitar melhor seus recursos, faz sentido considerar Kubernetes On-Premises. No entanto, a decisão não pode ser tomada sem antes avaliar cuidadosamente as necessidades e capacidades do seu time, os desafios de manutenção e os custos ocultos que podem surgir.
Por outro lado, se sua infraestrutura ainda não é robusta ou se o foco da sua empresa está na agilidade e escalabilidade sem se preocupar com a gestão do cluster, um serviço gerenciado pode ser a escolha mais estratégica. Afinal, pagar para que "alguém" resolva os problemas do cluster também pode ser uma forma inteligente de reduzir desperdícios e aumentar a eficiência.
A capacidade ociosa, tanto no hardware quanto no esforço do time, é o ponto central dessa decisão. Afinal, não se trata apenas de tecnologia, mas de como utilizá-la da forma mais eficiente possível.
Fale conosco