6 de junho é o 10º aniversário oficial do lançamento do Kubernetes. O Kubernetes foi construído como uma plataforma de gerenciamento e orquestração de contêineres que facilitaria o gerenciamento de todos os contêineres de software em aplicativos de microsserviços. Baseado no Borg, o serviço interno de gerenciamento de contêineres do Google que lidava com milhares de instâncias, o Kubernetes acabou sendo lançado como código aberto para que outros pudessem aproveitar a execução de contêineres.
Vale a pena pensar em 2014, quando o Kubernetes era uma das muitas abordagens diferentes para gerenciar contêineres que estavam sendo lançadas. Já existiam projetos maiores de código aberto, como o Apache Mesos, enquanto a empresa que deu início à conteinerização, a Docker, oferecia uma ótima opção com seu Docker Swarm. As empresas também estavam analisando abordagens como ferramentas de gerenciamento AWS ECS e como elas poderiam ser usadas para gerenciamento de contêineres específicos.
Então, por que o Kubernetes venceu? Sempre foi provável que acabássemos com o Kubernetes como plataforma para aplicativos nativos da nuvem? Ou houve obstáculos no caminho?
De cargas de trabalho sem estado para com estado
Em primeiro lugar, é importante dizer que o Kubernetes começou pequeno. Embora pudesse ter sido baseado em uma ferramenta usada pelo Google para gerenciar um grande número de cargas de trabalho e processos, para começar, não estava pronto para assumir essa função em outras organizações. Foi ótimo para gerenciar contêineres de aplicativos sem estado e orquestrar como esses contêineres foram criados, usados e desmontados quando não eram mais necessários. Mas no início ele estava focado apenas nos componentes do aplicativo.
Isso não combinava com todos os outros elementos que compõem a infraestrutura de uma aplicação. Embora seu aplicativo possa ser executado na nuvem e realizar processamento, ele também cria dados que devem ser armazenados ao longo do tempo. Ele tem que interagir com fontes de dados existentes. E tem que operar de forma segura, para que as informações não vazem ou os invasores não possam acessar esses componentes. Esses elementos não foram suportados no lançamento inicial do Kubernetes. Na verdade, foram necessários mais dois anos para obter o suporte do StatefulSets e o lançamento dos operadores Kubernetes antes que essas cargas de trabalho pudessem ser consideradas.
StatefulSets forneceu suporte para identificadores de rede estáveis e exclusivos e para armazenamento estável e persistente. Também tornou possível realizar implantações e escalonamentos mais ordenados e elegantes, além de atualizações contínuas mais ordenadas e automatizadas. Paralelamente, o lançamento dos Operadores Kubernetes permitiu aos desenvolvedores ocultar a complexidade envolvida no uso de primitivos Kubernetes com outros aplicativos. Sem essas duas adições, a execução de cargas de trabalho com estado no Kubernetes exigia alguns hacks sérios no núcleo do Kubernetes para fazer as coisas funcionarem.
Paralelamente, houve um esforço da comunidade para fazer com que as cargas de trabalho com estado funcionassem de maneira eficaz no Kubernetes. Embora as conversas sobre a execução de bancos de dados como MySQL e PostgreSQL tenham começado em plataformas como Reddit e Stack Overflow, foi necessária uma colaboração mais formal para transformar ideias interessantes em projetos reais e sustentáveis. Organizações como a comunidade Data on Kubernetes se uniram para fornecer a estrutura certa para essa colaboração, facilitando a contribuição de empresas e indivíduos.
Esse trabalho foi essencial, pois, para começar, houve muitas resistências em relação à execução de bancos de dados no Kubernetes. Para aqueles familiarizados com a abordagem dos 12 Fatores para projetar aplicativos, os serviços de back-end devem ser tratados como recursos anexados. Na época, isso era problemático para desenvolvedores que queriam executar em contêineres, mas precisavam gerenciar a interação com bancos de dados ou sistemas de armazenamento hospedados em ambientes diferentes. A abordagem ideal – e a que temos hoje – é que os bancos de dados sejam executados em clusters exatamente da mesma maneira que os componentes de aplicativos, pois isso facilita o controle e o gerenciamento da infraestrutura em todo o serviço a partir de um único ponto.
O papel do código aberto
Uma das principais razões do sucesso do Kubernetes foi o fato de ele ser de código aberto. O Kubernetes foi doado à Cloud Native Computing Foundation para que pudesse ser apoiado por uma organização mais ampla, em vez de um fornecedor controlador. Isto ajudou a distribuir a carga em termos de contribuições e aumentou a aceitação. Quando você está pensando em como apostar em uma plataforma de computação em nuvem, escolher uma que não esteja vinculada a um provedor de nuvem específico e que possa executar contêineres de forma independente em qualquer um deles foi vista como uma escolha mais inteligente.
Isso exigia uma comunidade que estivesse disposta a apoiar o Kubernetes como um projeto, e eles teriam que investir em seu sucesso. Para construir essa comunidade, o Kubernetes precisava ser de código aberto, como explicou o co-criador do Kubernetes, Brendan Burns, ao podcast Dev Interrupted. Sem ser de código aberto, haveria muito menos incentivo para os desenvolvedores contribuírem ou escolherem o Kubernetes como sua ferramenta de gerenciamento de contêineres.
Com o tempo, o Kubernetes deixou de ser uma das muitas ferramentas para orquestração de contêineres e se tornou a plataforma para aplicativos nativos da nuvem. Ele permite que os desenvolvedores criem e executem seus aplicativos em qualquer plataforma de nuvem ou em seu próprio ambiente de data center e, em seguida, movam essa carga de trabalho para qualquer plataforma que queiram usar no futuro. Como parte disso, o Kubernetes evoluiu do foco em componentes de aplicativos para o suporte a tudo na nuvem.
Kubernetes não é perfeito. Por exemplo, o Kubernetes ainda precisa de mais trabalho no dimensionamento automático e na gestão de recursos como dados e armazenamento para que as empresas possam controlar os seus custos de forma mais eficaz. Mas esse trabalho está em andamento com o apoio de diversas empresas e comunidades, para que todos possam se beneficiar no futuro.
Sergey Pronin é gerente de produto do grupo na Percona.
–
O New Tech Forum oferece um local para líderes de tecnologia – incluindo fornecedores e outros colaboradores externos – explorarem e discutirem tecnologias empresariais emergentes com profundidade e amplitude sem precedentes. A seleção é subjetiva, baseada na escolha das tecnologias que acreditamos serem importantes e de maior interesse para os leitores do InfoWorld. A InfoWorld não aceita material de marketing para publicação e reserva-se o direito de editar todo o conteúdo contribuído. Envie todos consultas para [email protected].
