A história do Kubernetes

Quando se trata de infraestrutura de TI moderna, o papel do Kubernetes, a plataforma de orquestração de contêineres de código aberto que automatiza a implementação, o gerenciamento e o escalonamento dos serviços e aplicações de software conteinerizadas, não pode ser subestimado.

De acordo com um relatório da Cloud Native Computing Foundation (CNCF) (link externo ao site ibm.com), o Kubernetes é o segundo maior projeto de código aberto do mundo, depois do Linux, e a principal ferramenta de orquestração de contêineres de 71% das empresas da Fortune 100. Para entender como o Kubernetes passou a dominar os mercados de computação em nuvem e microsserviços, precisamos analisar sua história.

A história do Kubernetes, cujo nome vem do grego antigo para "piloto" ou "timoneiro" (a pessoa no comando que conduz o navio), geralmente remonta a 2013, quando um trio de engenheiros do Google, Craig McLuckie, Joe Beda e Brendan Burns, teve uma ideia de criar um sistema de gerenciamento de contêineres de código aberto. Esses pioneiros da tecnologia estavam procurando maneiras de levar a experiência em infraestrutura interna do Google para o campo da computação em nuvem em grande escala e também permitir que o Google competisse com a Amazon Web Services (AWS), líder incomparável entre os provedores de nuvem na época.

Infraestrutura de TI tradicional versus infraestrutura de TI virtual

Mas, para realmente entender a história do Kubernetes (também conhecido como "Kube" ou "K8s", um "numerônimo" (link externo ao site ibm.com), precisamos analisar os contêineres no contexto da infraestrutura de TI tradicional versus com a infraestrutura de TI virtual.

No passado, as organizações executavam seus aplicativos exclusivamente em servidores físicos (também conhecidos como Bare Metal Servers). No entanto, não havia como manter os limites de recursos do sistema para essas aplicações. Por exemplo, sempre que um servidor físico executasse várias aplicações, uma aplicação poderia consumir toda a capacidade de processamento, memória, espaço de armazenamento ou outros recursos desse servidor. Para evitar que isso acontecesse, as empresas executavam cada aplicação em um servidor físico diferente. No entanto, a execução das aplicações em vários servidores cria recursos subutilizados e problemas de incapacidade de escalonamento. Além disso, ter um grande número de máquinas físicas ocupa espaço e é um esforço caro.

Virtualização

Depois veio a virtualização, o processo que forma a base da computação em nuvem. Embora a tecnologia de virtualização possa remontar ao final da década de 1960, ela não foi amplamente adotada até o início dos anos 2000.

A virtualização depende de um software conhecido como hipervisor. Um hipervisor é uma forma leve de software que permite que várias máquinas virtuais (VMs) sejam executadas na unidade de processamento central (CPU) de um único servidor físico. Cada máquina virtual tem um sistema operacional (SO) convidado, uma cópia virtual do hardware que o sistema operacional requer para ser executado e uma aplicação e suas bibliotecas e dependências associadas.

Embora as VMs criem um uso mais eficiente dos recursos de hardware para executar as aplicações do que os servidores físicos, elas ainda consomem uma grande quantidade dos recursos do sistema. Esse é especialmente o caso quando várias VMs são executadas no mesmo servidor físico, cada uma com seu próprio sistema operacional convidado.

Contêineres

Entre na tecnologia de contêineres. Um marco histórico no desenvolvimento de contêineres ocorreu em 1979 com o desenvolvimento do chroot (link externo ao site ibm.com), parte do sistema operacional Unix versão 7. O chroot introduziu o conceito de isolamento do processo por meio da restrição do acesso aos arquivos de uma aplicação a um diretório específico (a raiz) e seus "filhos" (ou subprocessos).

Os contêineres modernos são definidos como unidades de software em que o código da aplicação é empacotado com todas as suas bibliotecas e dependências. Isso permite que as aplicações sejam executadas rapidamente em qualquer ambiente, seja no local ou fora dele, a partir de um desktop, data center privado ou nuvem pública.

Em vez de virtualizar o hardware subjacente como VMs, os contêineres virtualizam o sistema operacional (normalmente Linux ou Windows). A ausência do sistema operacional convidado é o que torna os contêineres leves, além de mais rápidos e portáteis do que as VMs.

No início dos anos 2000, o Google precisava de uma maneira de obter o melhor desempenho de seus servidor virtual para dar suporte à sua crescente infraestrutura e fornecer sua plataforma de nuvem pública. Isso levou à criação do Borg, o primeiro sistema unificado de gerenciamento de contêineres. Desenvolvido entre 2003 e 2004, o sistema Borg tem o nome de um grupo de extraterrestres de Jornada nas Estrelas (os Borg) que compartilham uma mente de colmeia (consciência coletiva) chamada "O Coletivo".

O nome Borg se encaixou bem no projeto do Google. O sistema de gerenciamento de clusters em grande escala do Borg atua essencialmente como um cérebro central para a execução de cargas de trabalho conteinerizadas nos seus data centers. Projetado para ser executado juntamente com o mecanismo de busca do Google, o Borg foi usado para desenvolver os serviços de internet do Google, incluindo o Gmail, Google Docs, Google Search, Google Maps e YouTube.

O Borg possibilitou que o Google executasse centenas de milhares de trabalhos, de muitas aplicações diferentes, em várias máquinas. Isso permitiu que o Google obtivesse uma alta utilização dos recursos, tolerância a falhas e escalabilidade para suas cargas de trabalho em grande escala. O Borg ainda é usado no Google atualmente como o principal sistema interno de gerenciamento de contêineres da empresa.

Em 2013, o Google lançou o Omega, seu sistema de gerenciamento de contêineres de segunda geração. O Omega levou o ecossistema Borg ainda mais longe, fornecendo uma solução de agendamento flexível e escalável para clusters de computadores em grande escala. Foi também em 2013 que a Docker, um player importante na história do Kubernetes, entrou em cena.

Desenvolvido pela dotCloud, uma empresa de tecnologia de plataforma como serviço (PaaS), o Docker foi lançado em 2013 como uma ferramenta de software de código aberto que permitia aos desenvolvedores de software online criar, implementar e gerenciar aplicações conteinerizadas.

A tecnologia de contêiner do Docker usa o kernel do Linux (o componente básico do sistema operacional) e os recursos do kernel para separar os processos para que eles possam ser executados de forma independente. Para esclarecer qualquer confusão, o nome Docker também se refere à Docker, Inc. (antiga dotCloud, link externo ao site ibm.com), que desenvolve ferramentas de produtividade criadas em torno de sua plataforma de conteinerização de código aberto, bem como do ecossistema e comunidade de código aberto Docker (link externo ao site ibm.com).

Ao popularizar um tempo de execução de contêiner leve e fornecer uma maneira simples de empacotar, distribuir e implementar as aplicações em uma máquina, o Docker forneceu as sementes ou a inspiração para os fundadores do Kubernetes. Quando o Docker entrou em cena, os funcionários do Google Craig McLuckie, Joe Beda e Brendan Burns estavam entusiasmados com a capacidade do Docker de criar contêineres individuais e executá-los em máquinas individuais.

Embora o Docker tenha mudado o jogo para a infraestrutura nativa da nuvem, ele tinha limitações porque foi desenvolvido para ser executado em um único nó, o que tornava a automação impossível. Por exemplo, como as aplicações foram desenvolvidas para milhares de contêineres separados, gerenciá-las em vários ambientes tornou-se uma tarefa difícil, pois cada desenvolvimento individual precisava ser empacotado manualmente. A equipe do Google viu a necessidade (e a oportunidade) de um orquestrador de contêineres que pudesse implementar e gerenciar vários contêineres em várias máquinas. Assim, nasceu o sistema de gerenciamento de contêineres de terceira geração do Google, o Kubernetes.

Muitos dos desenvolvedores do Kubernetes trabalharam para desenvolver o Borg e queriam criar um orquestrador de contêineres que incorporasse tudo o que aprenderam com o projeto e o desenvolvimento dos sistemas Borg e Omega para produzir uma ferramenta de código aberto menos complexa com uma interface amigável. Como uma ode ao Borg, eles o batizaram de Projeto Sete de Nove, em homenagem a um personagem do Jornada nas Estrelas: Voyager que é um antigo drone Borg. Embora o nome original do projeto não tenha vingado, ele foi eternizado pelos sete pontos no logotipo do Kubernetes (link externo a site ibm.com).

A arquitetura do Kubernetes é baseada na execução de clusters que permitem que os contêineres sejam executados em várias máquinas e ambientes. Cada cluster normalmente consiste em duas classes de nós:

• Nós de trabalho, que executam as aplicações conteinerizadas.
• Nós do plano de controle, que controlam o cluster.

O plano de controle atua basicamente como o orquestrador do cluster do Kubernetes e inclui vários componentes: o servidor de API (gerencia todas as interações com o Kubernetes), o gerenciador de controle (lida com todos os processos de controle), o gerenciador do controlador de nuvem (a interface com a API do provedor de nuvem) e assim por diante. Os nós de trabalho executam contêineres usando tempos de execução de contêineres, como o Docker. Os pods, as menores unidades implementáveis em um cluster, armazenam um ou mais contêineres de aplicações e compartilham recursos, como informações de armazenamento e de rede.

Em 2014, o Kubernetes fez sua estreia como uma versão de código aberto do Borg, com a Microsoft, a RedHat, a IBM e a Docker se tornando os primeiros membros da comunidade Kubernetes. A ferramenta de software incluía recursos básicos para a orquestração de contêineres, como os seguintes:

• Replicação para implementar várias instâncias de uma aplicação
• Balanceamento de carga e descoberta de serviços
• Verificação e reparo básicos da integridade
• Planejamento para agrupar muitas máquinas e distribuir o trabalho entre elas

Em 2015, na O'Reilly Open Source Convention (OSCON) (link externo ao site ibm.com), os fundadores do Kubernetes lançaram uma versão expandida e refinada do Kubernetes, o Kubernetes 1.0. Logo em seguida, os desenvolvedores da equipe do Red Hat OpenShift se juntaram à equipe do Google, contribuindo com sua experiência em engenharia e negócios para o projeto.

Coincidindo com o lançamento do Kubernetes 1.0 em 2015, o Google doou o Kubernetes para a Cloud Native Computing Foundation (CNCF) (link externo ao site ibm.com), parte da Linux Foundation, uma organização sem fins lucrativos. A CNCF foi criada em conjunto por vários membros das principais empresas de computação do mundo, incluindo Docker, Google, Microsoft, IBM e Red Hat. A missão (link externo ao site ibm.com) da CNCF é "tornar a computação nativa da nuvem onipresente".

Em 2016, o Kubernetes se tornou o primeiro projeto hospedado da CNCF e, em 2018, o Kubernetes foi o primeiro projeto da CNCF a ser finalizado. O número de empresas que contribuem de maneira ativa aumentou rapidamente para mais de 700 membros, e o Kubernetes logo se tornou um dos projetos de código aberto de crescimento mais rápido da história. Em 2017, ele estava ultrapassando concorrentes como o Docker Swarm e o Apache Mesos e se tornando o padrão do setor para orquestração de contêineres.

Antes da nuvem, as aplicações de software estavam vinculadas aos servidores de hardware em que eram executadas. Mas em 2018, à medida que o Kubernetes e os contêineres se tornaram o padrão de gerenciamento para as organizações de venda de nuvem, o conceito de aplicações nativas em nuvem começou a se consolidar. Isso abriu as portas para a pesquisa e o desenvolvimento de softwares baseados na nuvem.

O Kubernetes auxilia no desenvolvimento de programas baseados em microsserviços nativos da nuvem e permite a conteinerização das aplicações existentes, possibilitando um desenvolvimento mais rápido da aplicação. O Kubernetes também fornece a automação e a observabilidade necessárias para gerenciar com eficiência várias aplicações ao mesmo tempo. A infraestrutura declarativa e orientada por API do Kubernetes permite que as equipes de desenvolvimento nativas da nuvem operem de forma independente e aumentem sua produtividade.

A história do Kubernetes e seu papel como uma plataforma portátil, extensível e de código aberto para o gerenciamento de cargas de trabalho conteinerizadas e microsserviços continua se desenvolvendo.

Desde que o Kubernetes entrou para a CNCF em 2016, o número de colaboradores cresceu para 8.012 – um aumento de 996% (link externo ao site ibm.com). A principal conferência global da CNCF, a KubeCon + CloudNativeCon (link externo ao site ibm.com), atrai milhares de participantes e oferece um fórum anual para informações e insights dos desenvolvedores e usuários sobre o Kubernetes e outras tendências de DevOps.

Nas frentes de transformação da nuvem e modernização de aplicações, a adoção do Kubernetes não mostra sinais de desaceleração. De acordo com um relatório da Gartner, The CTO's Guide to Containers and Kubernetes (link externo ao site ibm.com), mais de 90% das organizações do mundo estarão executando aplicações em contêineres em produção até 2027.

Em 2014, a IBM foi uma das primeiras grandes empresas a unir forças com a comunidade de código aberto Kubernetes e trazer a orquestração de contêineres para a empresa. Hoje, a IBM está ajudando as empresas a navegar em suas jornadas contínuas de nuvem com a implementação da orquestração de contêineres Kubernetes e outras soluções de gerenciamento baseadas na nuvem.

Quer seu objetivo seja o desenvolvimento de aplicações nativas em nuvem, a implementação de aplicações em larga escala ou o gerenciamento de microsserviços, podemos ajudar você a aproveitar o Kubernetes e seus diversos casos de uso.

O Red Hat OpenShift on IBM Cloud oferece aos desenvolvedores do OpenShift uma maneira rápida e segura de conteinerizar e implementar cargas de trabalho corporativas nos clusters do Kubernetes.

A IBM Cloud Code Engine, uma plataforma sem servidor totalmente gerenciada, permite que você execute seu contêiner, código de aplicação ou trabalho em lote em um tempo de execução de contêiner totalmente gerenciado.