Kubernetes

O que é o OpenShift?

Continuando com os posts sobre as ferramentas de DevOps, vamos abordar uma ferramenta que vem se tornando cada vez mais popular: o OpenShift, da Red Hat.

O que vem a ser o OpenShift?

O OpenShift é uma plataforma de código aberto desenvolvida pela Red Hat que auxilia no processo de orquestração de containers baseada em Kubernetes e containers Linux de maneira independente da plataforma na qual os containers serão executados.

Através de uma interface muito amigável e intuitiva, o OpenShift oferece a possibilidade de controlar todo o ciclo de vida de uma aplicação baseada em containers, desde o deploy até a execução efetiva.

Isso é possível graças a integração facilitada com várias outras ferramentas e SDKs para diferentes linguagens, o que torna o OpenShift uma ferramenta muito competente e completa não somente para o gerenciamento de containers, mas também para o controle de todo o ciclo de vida de uma aplicação.

O diagrama abaixo, fornecido pela própria Red Hat, oferece uma visão geral das ferramentas que são integradas e orquestradas pelo OpenShift.

Pela imagem acima, podemos perceber que o OpenShift oferece uma infinidade de serviços, como gerenciamento dos processos de integração contínua/entrega contínua (CI/CD), gerenciamento de configurações e logs, monitoramento da saúde das aplicações e containers que estão sendo gerenciados e até mesmo aspectos de segurança, isso tudo de maneira completamente desacoplada do container e/ou da infraestrutura que você esteja utilizando.

Segundo a Red Hat, o OpenShift consegue oferecer todos estes serviços por ser fundamentado em uma arquitetura baseada em microsserviços que conseguem se “encaixar” uns aos outros e prover as diferentes funcionalidades que cada projeto necessita.

Como o OpenShift funciona?

Segundo a Red Hat, o OpenShift funciona em cima de um sistema baseado em camadas, onde cada camada é responsável por determinada funcionalidade. A sobreposição destas camadas é que faz com que o OpenShift consiga oferecer a quantidade de funcionalidades que são oferecidas.

A imagem abaixo, retirada da própria documentação do OpenShift ilustra estas sobreposições de camadas.

No diagrama acima, percebemos inicialmente um benefício importantíssimo do OpenShift: ele é agnóstico a ferramentas de Continuous Integration/Continuous Delivery e também a ferramentas de automação de operações, como ferramentas de automação de provisionamento de infraestrutura. Isso quer dizer que você pode utilizar o OpenShift com o Jenkins, CircleCI, TravisCI, GitLab, Terraform ou qualquer uma das ferramentas desse nicho.

O OpenShift roda em cima de cluster baseado no Kubernetes, cluster no qual os componentes são organizados em um esquema de microsserviços. Estes componentes do coração do OpenShift ficam em um nó master dentro dessa infraestrutura. Entre estes componentes que ficam dentro desse nó master, podemos destacar:

  • API/Authentication: controle de acesso às APIs do OpenShift e do Kubernetes. Esse processo de autenticação é baseado no padrão OAuth e em certificados SSL;
  • Data Store: responsável por armazenar o estado e outras informações e meta-informações dos componentes do OpenShift. O OpenShift geralmente utiliza o etcd, uma estrutura de armazenamento baseada em chave/valor, para realizar o armazenamento destes dados;
  • Scheduler: responsável por distribuir as cargas de trabalho entre nós dos clusters de componentes do OpenShift. Trata-se de um dos principais componentes do OpenShift;
  • Management/Replication: mecanismo responsável pelo processo de replicação e por coletar informações sobre o estado dos componentes e elementos do cluster. Ele é basicamente um loop infinito que, de tempos em tempos, coleta estes dados e atualiza o estado dos componentes, armazenando estes estados no Data Store (etcd). Estes processos são controlados através de estruturas chamadas controllers. Os principais controllers dentro do OpenShift são: replication controller, endpoint controller, namespace controller e service account controller. É importante salientar que as informações coletadas pelos controllers refletem na API exposta pelo nó master, assim como os comandos dados às APIs do OpenShift e do Kubernetes são executados de fato também pelos controllers.

As aplicações acabam ficando armazenadas nos outros nós da infraestrutura do OpenShift. Na ilustração acima, por exemplo, temos uma estrutura inspirada no Docker: temos as aplicações dentro de containers, containers estes que ficam agrupados pelos pods. Todos estes pods desenvolvem seu ciclo de vida dentro de um nó, ou seja: uma máquina que faz parte do cluster Kubernetes gerenciado pelo OpenShift.

A relação entre o OpenShift e o OKD

O OKD é basicamente uma distribuição “personalizada” do Kubernetes. OKD é um acrônimo para “Origin Kubernetes Distribution”. O OKD foi criado pela Red Hat para que existisse uma distribuição do Kubernetes mais otimizada para processos tradicionais em ambientes baseados em nuvem, como aplicações multi-tenancy e aplicação de processos de continuous delivery/continuous integration. Ou seja: o OKD é um Kubernetes otimizado para as situações previamente citadas, otimizações estas realizadas pela Red Hat.

O OKD não é concorrente do OpenShift. Na verdade, o core do OpenShift é justamente o OKD. A estrutura baseada em Kubernetes que é utilizada pelo OpenShift é, na verdade, o OKD. Caso você julgue necessário, você pode utilizar o OKD de maneira direta, ou seja: sem passar necessariamente pelo OpenShift.

No final das contas: o que é o Kubernetes?

Nos nossos últimos posts sobre DevOps, pudemos ver algumas ferramentas que podem ser utilizadas. No último deles, vimos como o Docker pode nos ajudar e como vem sendo adotado pelas organizações pelas suas inúmeras vantagens.

Mas, fazendo uso dos containers no Docker, uma situação pode ocorrer de maneira comum: quanto mais você começa a utilizar os containers, mais eles podem crescer em número, se multiplicando em uma velocidade bem alta. Para resolver isso, entra uma ferramenta chamada Kubernetes. Este artigo tem como objetivo ilustrar como o Kubernetes pode nos ajudar a lidar com esse tipo de situação.

O que vem a ser o Kubernetes?

O Kubernetes (muitas vezes também referenciado como k8s) é uma plataforma de código aberto utilizada para orquestrar e gerenciar clusters de containers. Assim, você consegue eliminar a maior parte dos processos manuais necessários para implantar e escalar os aplicativos em containers, além de gerenciar esses clusters com facilidade e efetividade.

Como o Kubernetes organiza seus componentes?

O funcionamento do Kubernetes é ligeiramente complexo, já que existem várias abstrações e componentes responsáveis pelo funcionamento de todo o ecossistema. Vamos verificar os principais conceitos e componentes essenciais.

O Kubernetes consegue fazer com que tanto elementos físicos como elementos virtuais possam se comunicar de maneira transparente. Cada um destes grupos compostos por elementos físicos e virtuais é chamado de cluster. Diferentes clusters podem se comunicar através de uma rede criada pelo Kubernetes para essa finalidade.

Os componentes dentro de um cluster podem assumir uma de duas responsabilidades possíveis: eles podem fazer o papel de master ou o papel de node. Os componentes que assumem o papel de server são responsáveis por estabelecer a comunicação com outros clusters, expor as APIs do Kubernetes com relação ao cluster em questão, realizar verificações de estabilidade dos serviços expostos e realizar operações conhecidas como scheduling, que é basicamente uma operação de atribuição de serviços aos recursos disponíveis dentro do cluster.

Os componentes que assumem o papel de node ficam responsáveis por realizar os trabalhos designados pelas aplicações que neles são executadas. Os nodes podem utilizar recursos dentro do próprio cluster ou até mesmo recursos presentes em outros clusters, já que cada cluster pode se comunicar com outros clusters pela rede que é criada pelo Kubernetes e gerenciada pelos componentes master.

É importante salientar que o Kubernetes gerencia os elementos responsáveis pela função de node através de containers, como o Docker. O master, dentro de cada cluster, fica responsável por repassar as instruções a serem executadas (como uma resposta a uma requisição, por exemplo) aos componentes node. Os componentes que fazem o papel de node então criam e deletam containers para atender a estas requisições. Os processos de criação e destruição de containers pelos nodes ficam parametrizados por regras de escalabilidade, como fluxo de rede, carga da demanda para cada um dos serviços a serem executados dentro destes clusters. Essas configurações podem ser feitas pela própria API do Kubernetes de maneira direta, ou através de arquivos de configuração, nos formatos normalmente JSON ou YAML.

O Kubernetes ainda organiza seus componentes em outras abstrações importantes. A mais elementar destas abstrações é chamada de pod. Um pod consiste de uma unidade de trabalho do Kubernetes formada por containers que trabalham dentro do mesmo node e possuem uma “relação de trabalho” muito próxima, chegando até mesmo a compartilhar recursos entre si. É como se estes containers envolvidos dentro de um pod representasse uma única aplicação. O Kubernetes encapsula estes containers próximos para que haja um controle do ciclo de vida destes mais granular, cuidado do ciclo de vida destes da mesma maneira, já que estes containers são tão próximos e provavelmente cuidam da mesma aplicação.

Paralelamente a isso, ainda temos os volumes. Os volumes são basicamente containers para persistência de informações de maneira transiente ou definitiva. Pods podem compartilhar informações entre si através de containers persistentes, por exemplo. Componentes dentro de um pod também podem compartilhar informações entre si através de volumes transientes, volumes estes que também são destruídos quando um pod conclui seu ciclo de vida.

Ainda temos outros dois componentes interessantes: os replication controllers e os replication sets. Os replication controllers se comportam como templates para criação sistêmica de pods. Eles servem para fazer a escalabilidade horizontal dos pods e, consequentemente, de uma aplicação, através das duplicatas de um pod que podem ser geradas de maneira padronizada. Já os replication sets constituem um tipo de replication controller um pouco mais evoluído, pois são capazes de tratar os aspectos de escalabilidade de maneira mais fina, além de melhorar a identificação dos pods que são gerados. Aos poucos, o Kubernetes vem substituindo os replication controllers pelos replication sets.

Abaixo podemos ver um diagrama, disponibilizado pela própria Google.

Por que utilizar o Kubernetes?

Como vimos, as aplicações de produção podem abranger múltiplos containers, que devem ser implantadas em vários hosts do servidor. Com os recursos do Kubernetes, você consegue implantar containers em escala para essas cargas de trabalho e assim executar as demandas que são recebidas pelo cluster.

Além da orquestração de containers em vários hosts, o Kubernetes também possibilita outras coisas, como o melhor aproveitamento de hardware, controle das implantações e atualizações das aplicações, escalada das aplicações rapidamente em containers e, claro, gerenciar os serviços de forma que as aplicações sejam executadas da mesma maneira como foram implantadas.

O Kubernetes pode ser executado em várias plataformas, como no seu computador, VMs em um provedor de nuvem e em vários servidores. Os clusters podem abranger hosts em clouds públicas ou privadas.

Vale ressaltar que não temos o porquê comparar o Docker e o Kubernetes. O Kubernetes usa o Docker para criar os containers de nós do cluster. Ele tem a função de gerenciar, controlar e monitorar o estado desses containers ao longo do cluster. Apesar disso, o Kubernetes não foi desenvolvido especialmente para o Docker: você pode utilizar outra estrutura (como o Rancher) e desfrutar de todo o poder que o Kubernetes oferece.

Concluindo…

É fato que os containers chegaram para mudar a maneira como são executadas as aplicações web, visando trazer mais segurança e agilidade. Porém, a utilização sistêmica dos containers pode trazer problemas de gerenciamento, principalmente quando precisamos de ambientes com múltiplas instâncias de containers sendo executadas simultaneamente.

Isso se torna mais desafiador ainda quando precisamos que este ambiente seja auto gerenciável, ou seja, que este ambiente saiba quando e quantas instâncias de containers precisam ser criadas de acordo com o nível da carga de trabalho.

É para esse tipo de situação que o Kubernetes foi criado. Com o Kubernetes, podemos obter um ambiente auto gerenciável, auto escalável e containerizado de maneira relativamente simples, graças aos poderosos recursos que esta ferramenta oferece. Não é à toa, o Kubernetes hoje é praticamente sinônimo, ao lado do OpenShift, de ferramenta de gerenciamento e escalabilidade de containers.

JUNTE-SE A MAIS DE 150.000 PROGRAMADORES