Kubernetes surgiu como uma entre várias ferramentas para gerenciar contêineres. Após uma década, tornou-se a principal solução para aplicações desenvolvidas para ambientes de nuvem.
No dia 6 de junho celebra-se o 10º aniversário do lançamento oficial do Kubernetes. Este foi desenvolvido como uma plataforma de gerenciamento e orquestração de contêineres, facilitando a administração de todos os componentes de software em aplicações de microsserviços. Originado do Borg, o sistema interno de gerenciamento de contêineres do Google que lidava com milhares de instâncias, o Kubernetes foi posteriormente disponibilizado como um projeto de código aberto para permitir que outros utilizassem a execução de contêineres.
Em 2014, o Kubernetes surgiu como uma alternativa inovadora para o gerenciamento de contêineres, em um cenário onde diversas abordagens estavam sendo desenvolvidas. Projetos de código aberto renomados, como o Apache Mesos, já estavam disponíveis, assim como a empresa pioneira em contêineres, Docker, oferecia o Docker Swarm. Além disso, as empresas também exploravam ferramentas de gerenciamento como o AWS ECS, buscando maneiras específicas de controlar contêineres.
Por que o Kubernetes emergiu como a escolha dominante para aplicações nativas de nuvem? Seria inevitável que o Kubernetes se tornasse a plataforma principal para tais aplicações, ou houve desafios significativos a serem superados?
Da transição de cargas de trabalho não gerenciadas para cargas de trabalho gerenciadas.
Inicialmente, o Kubernetes teve um início modesto. Embora tenha se baseado em uma ferramenta utilizada pelo Google para gerenciar diversas cargas de trabalho e processos, não estava pronto para desempenhar essa função em outras organizações desde o início. Inicialmente, o foco era o gerenciamento de contêineres de aplicativos sem estado e a orquestração de como esses contêineres eram criados, utilizados e posteriormente descartados quando não eram mais necessários. No entanto, a atenção estava voltada apenas para os componentes de aplicação nesse estágio inicial.
Isso não estava alinhado com os demais elementos que compõem a infraestrutura de uma aplicação. Mesmo que o aplicativo possa ser executado na nuvem e realizar o processamento, também gera dados que precisam ser armazenados a longo prazo, precisa interagir com fontes de dados existentes e operar com segurança para evitar vazamentos de informações ou acessos não autorizados. Esses requisitos não foram atendidos no lançamento inicial para o Kubernetes. Foi necessário esperar mais dois anos para ter suporte aos StatefulSets e a implementação de operadores do Kubernetes, para então considerar essas cargas de trabalho.
Os StatefulSets trouxeram suporte para identificadores de rede estáveis e exclusivos, assim como para armazenamento durável e persistente. Isso possibilitou implantações e escalonamentos mais organizados e suaves, além de atualizações mais automatizadas. A introdução dos Operadores Kubernetes permitiu que os desenvolvedores simplificassem o uso de primitivas Kubernetes com outras aplicações, ocultando a complexidade. Antes dessas adições, era necessário realizar ajustes significativos no core do Kubernetes para executar cargas de trabalho stateful no ambiente.
Além disso, surgiu uma iniciativa comunitária para garantir que as cargas de trabalho stateful funcionem de forma eficaz no Kubernetes. Embora as discussões sobre 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 essas ideias promissoras em projetos reais e sustentáveis. Organizações como a comunidade Data on Kubernetes se uniram para oferecer o ambiente adequado para essa colaboração, facilitando a contribuição de empresas e indivíduos.
Este trabalho foi fundamental, pois havia uma grande demanda por bancos de dados sendo executados em Kubernetes desde o início. Para aqueles que estão familiarizados com a abordagem de 12 Fatores para o design de aplicações, os serviços de back-end devem ser considerados como recursos anexados. Naquela época, isso representava um desafio para os desenvolvedores que desejavam executar em containers e, em seguida, lidar com a interação com bancos de dados ou sistemas de armazenamento hospedados em ambientes diferentes. A abordagem ideal – e a que temos atualmente – é que os bancos de dados devem ser executados em clusters da mesma forma que os componentes da aplicação, facilitando assim o controle e gerenciamento da infraestrutura em todo o serviço a partir de um único ponto.
O papel desempenhado pela fonte aberta.
Uma das razões principais do sucesso do Kubernetes foi a sua natureza de código aberto. O Kubernetes foi transferido para a Cloud Native Computing Foundation para que pudesse contar com o suporte de uma organização mais abrangente, em vez de depender de um único fornecedor. Isso permitiu uma distribuição mais equitativa em termos de contribuições e aumento da aceitação. Ao considerar a escolha de uma plataforma para computação em nuvem, optar por uma que não esteja vinculada a um provedor específico e que possa executar contêineres de forma independente em qualquer um deles foi visto como uma decisão mais estratégica.
Isso requeria uma comunidade disposta a apoiar o Kubernetes como um projeto e comprometida com o seu sucesso. Para formar essa comunidade, o Kubernetes teve que ser disponibilizado como código aberto, conforme explicado por um dos co-criadores, Brendan Burns, em uma entrevista para o podcast Interrompido Dev. Sem essa abertura, haveria menos estímulo para os desenvolvedores contribuírem ou optarem pelo Kubernetes como sua ferramenta de gerenciamento de contêineres.
Com o tempo, Kubernetes deixou de ser apenas uma das várias ferramentas para orquestração de contêineres e se transformou na principal plataforma para apps nativos na nuvem. Ele possibilita aos desenvolvedores criar e implementar seus aplicativos em diferentes ambientes, seja em nuvem ou no próprio data center, e depois migrar esses serviços para qualquer plataforma desejada no futuro. Nesse processo, Kubernetes expandiu seu foco de componentes de aplicativos para abranger todas as necessidades na nuvem.
Kubernetes apresenta áreas que ainda demandam aprimoramento, como o dimensionamento automático e o gerenciamento de recursos, como dados e armazenamento, visando a otimização dos custos empresariais. Contudo, esforços colaborativos de empresas e comunidades estão sendo dedicados a essas melhorias, visando benefícios futuros para todos os envolvidos.
Sergey Pronin atua como gerente de produto de equipe na empresa Percona.
Lo siento, pero necesito que proporciones un texto específico para poder parafrasearlo. ¿Puedes proporcionarme un texto que desees que parafrasee?
O New Tech Forum fornece um espaço para líderes de tecnologia, como fornecedores e outros colaboradores externos, explorarem e debaterem de forma abrangente e aprofundada sobre tecnologias empresariais emergentes. A seleção é feita de forma subjetiva, com base nas tecnologias que consideramos relevantes e de maior interesse para os leitores do InfoWorld. A InfoWorld não garante a publicação de conteúdo de marketing e se reserva o direito de editar todos os materiais contribuídos. Para enviar perguntas, entre em contato com doug_dineley@foundryco.com.