Login / Registre-se Account

Trabalho com o OpenShift há seis anos, e constantemente recebo perguntas sobre o que é o OpenShift. Com a mudança da arquitetura anterior para o Kubernetes, ocorrida na versão 3.x, as perguntas evoluíram. Em vez de me perguntarem "o que é o OpenShift", agora perguntam "quais são as diferenças entre o OpenShift e o Kubernetes". Hoje, falaremos um pouco mais sobre isso.

Kubernetes é o "kernel"

No CoreOS, considerávamos o Kubernetes como o "kernel" dos sistemas distribuídos. Reconhecemos que um agendamento de tarefas bem projetado, operado em várias máquinas e capaz de reconciliar o estado de cargas de trabalho gerenciadas, promoveria naturalmente a colaboração - da mesma forma como o kernel do Linux fez com o agendamento das cargas de trabalho em um host único. Seguindo essa lógica, sabíamos que as soluções se diferenciariam entre si com base na importância atribuída às preocupações de seus usuários.

É o mesmo kernel do Linux executado em inúmeros smartphones, notebooks, servidores e até no Raspberry Pi,  embora com níveis diferentes de patches para oferecer suporte ao hardware onde o kernel está diretamente situado.

Da mesma forma, podemos dizer que é o mesmo Kubernetes nas várias distribuições do Kubernetes, embora com níveis diferentes de patches para oferecer suporte à camada onde o Kubernetes está diretamente situado. As distribuições Linux em que cada tipo de Kubernetes está executando suas cargas de trabalho.

OpenShift é a distribuição

Essa é uma diferença importante. A equipe responsável pelo OpenShift produziu uma distribuição do Kubernetes que se concentrava na experiência de desenvolvedores que precisavam criar a próxima geração de aplicações nativas em nuvem. A equipe responsável pelo Tectonic (a distribuição do CoreOS do Kubernetes) se concentrou na experiência de equipes de operações e administradores que precisavam resolver problemas no sistema operacional e no próprio Kubernetes rapidamente. Com a próxima versão do OpenShift 4.0, ofereceremos interfaces para esses dois públicos. Assim, teremos uma plataforma que atenderá a essas necessidades especializadas.

Qualquer pessoa pode criar o Linux do zero escolhendo e montando cada peça sob medida e da forma como quiser. No entanto, a maioria dos usuários não faz isso.  O nível de abstração escolhido pela maioria dos usuários significa que eles não obtêm muito valor ao gerenciar (ou mesmo conhecer) as diferenças entre as versões 2.31 e 2.33 do Util-Linux.  Para dar um passo adiante, o usuário se preocupa com um nível mínimo de funcionalidade (por exemplo, eles sabem quais comandos/APIs estarão disponíveis desde que utilizem uma versão acima da mínima) e com a lista de recursos fornecidos.

O mesmo acontece no OpenShift.  Colocamos o Kubernetes no pacote e incluímos também ferramentas adicionais como funcionalidades que consideramos importantes e necessárias para os nossos usuários.  O CoreOS e o CentOS contêm conjuntos diferentes de ferramentas, pois atendem a usuários diferentes. É o mesmo que acontece com as distribuições do Kubernetes.  Na Red Hat, nos concentramos em disponibilizar ferramentas que contribuam para o sucesso das equipes de operações e desenvolvimento. Por isso, incluímos o Istio como uma apresentação prévia de tecnologia no OpenShift.  Acreditamos que seja uma ferramenta útil a muitos usuários e que, por isso, deveria ser incluída por padrão na distribuição básica.

OKD vs. Red Hat OpenShift

Mas vamos voltar um pouco.

O OpenShift é um software open source? Sem dúvida! Todos os componentes do OpenShift foram desenvolvidos na comunidade open source e podem ser visualizados no GitHub. Lá você encontrará um grande número de repositórios que abrangem muitas das preocupações relacionadas ao bom funcionamento de um cluster Kubernetes.

Incluímos todos os componentes de software necessários para executar o Kubernetes em um projeto. Esse projeto é uma distribuição do Kubernetes chamada OKD, antes conhecida como "Origin". O Kubernetes e o OKD são semelhantes, pois ambos são projetos open source. O Kubernetes é um dos projetos upstream do OKD, assim como o kernel do Linux, GNU Bash, GCC e o servidor httpd Apache são upstreams da distribuição do Linux Fedora. Quando queremos aprimorar ou adicionar funcionalidades ao OpenShift a fim de que cheguem ao Kubernetes, fazemos isso no upstream e trabalhamos a partir de versões do Kubernetes para criar o OpenShift.

Então, a Red Hat cria um pacote com o projeto OKD, além de diversos outros projetos, como Maistra, vários operadores e outros recursos em uma solução chamada Red Hat OpenShift Container Platform. Depois de terminada a tarefa de criação de uma versão do Kubernetes, começa a tarefa de empacotar o OKD e, em seguida, o OpenShift.

O Red Hat OpenShift é criado a partir dessas etapas, passando por extensos testes internos para verificar se todos os componentes estão bem integrados e se as equipes estão preparadas para dar suporte às demandas dos clientes que executam o software em produção. Isso explica parcialmente por que há uma lacuna entre a versão do upstream e a versão corporativa subsequente do OpenShift pronta para uso: trata-se de capacitação interna. Nossos clientes querem confiar na nossa experiência, sabendo que podemos fornecer suporte completo aos componentes distribuídos com o OpenShift.

Da mesma maneira que é possível criar o Linux do zero, é possível otimizá-lo para instalar o Kubernetes da forma mais complexa. No entanto, esse exercício é ideal para aqueles que têm tempo, paciência e nível de risco que não necessite de suporte corporativo. Para aqueles que estão concentrados no desenvolvimento de suas próprias aplicações e querem progredir junto com a Red Hat, recomendamos o OpenShift Container Platform.


Em destaque

Notícia do seu interesse em destaque