O intuito deste artigo é comparar o OpenShift aos serviços gerenciados do Kubernetes (comumente chamado k8s) fornecidos pelos principais provedores de nuvem pública, esse tem sido um tema muito recorrente e debatido em vários projetos que tenho participado e achei interessante compartilhar com vocês.

O Google lançou a V1.0 do Kubernetes em Julho de 2015 e fez uma parceria com a Linux Foundations para formar a Cloud Native Computing Foundation (CNCF) e ofereceu o Kubernetes como tecnologia base.

Ofertas

Neste artigo, focarei as comparações no EKS que é executado na nuvem da AWS, O AKS (Azure Container Services) que é executado no ambiente da Azure e o GKE que é executado no GCP (Google Cloud Platform), se conhecerem outros mandem nos comentários que faço um próximo com as opiniões de vocês.

A primeira grande diferença é que cada um desses serviços gerenciados em nuvem pública foram construídos para serem executados em um ambiente especifico e OpenShift Container Platform foi criado para permitir que os clientes implantem em uma infinidade de ambientes homologadas pela Red Hat e forneçam a mesma experiência para desenvolvedores e equipes de operações em cada um delas.

Decidi comparar o OpenShift Dedicated com as ofertas de nuvem pública por ser o que está diretamente relacionado ao objetivo do artigo. O OpenShift Dedicated é uma oferta de serviços gerenciados da Red Hat onde os clientes pagam pelo uso no ambiente dedicado do OpenShift e a infraestrutura é gerenciada por eles. Os clientes do OpenShift Dedicated sobem aplicações. gerenciam recursos, escalam aplicações, gerenciam pontos de acesso, gerenciam quotas e limites mas as operações do dia a dia são gerenciadas pela equipe de Operações da Red Hat. A AWS, Google Cloud Platform e Azure possuem execuções dedicadas do OpenShift.

O OpenShift (OpenShift Dedicated e OpenShift Container Platform) possui um número considerável de recursos além dos recursos do Kubernetes. Os clientes que assinam um recurso gerenciado do Kubernetes estão na mesma posição dos clientes que instalam o Kubernetes, eles terão de resolver os problemas que a Red Hat resolveu com soluções adicionais.

Os clientes que assinam um serviço do Kubernetes gerenciado pela nuvem pública pagam por serviços adicionais no provedor e não há nada de errado com essa abordagem mas é importante que entendam a diferença entre a implantação do Kubernetes e a implantação do OpenShift.

Segue abaixo os recursos que o OpenShift fornece e o que você precisaria para ter recursos semelhantes caso assine um serviço gerenciado do Kubernetes:

• O OpenShift Container Platform pode ser instalado em ambientes físicos, máquinas virtuais, infraestrutura de nuvem privada, ambientes de nuvem pública. Cada oferta de serviço gerenciada do Kubernetes em nuvem pública está vinculada a seus respectivos ambientes de nuvem.

• O OpenShift fornece consistência nas operações e na experiência do Desenvolvedor e isso significa que uma implantação que abrange vários ambientes de nuvem pública e privada pode ser usada por desenvolvedores e suportada por equipes de operações exatamente da mesma forma. Comparando ao Kubernetes em nuvem, cada serviço de nuvem pública precisaria ser consumido e gerenciado de maneira vinculada à plataforma assinada.

• O Red Hat Enterprise Linux (RHEL) está incluso na licença. Quando um cliente compra suporte para o OpenShift Dedicated ou OpenShift Container Platform, ele também recebe suporte total para o RHEL. Em outras plataformas que você necessite implementar o Kubernetes, o suporte ao sistema operacional precisaria ser adquirido e gerenciado separadamente.

• A Red Hat suporta o host do sistema operacional até os serviços que fazem parte do OpenShift Container Platform. Isso significa que todos os elementos do sistema operacional para a camada de serviço são suportados e recebem atualização de segurança caso disponível pela Red Hat. No modelo gerenciado do Kubernetes, o suporte se estende apenas à infraestrutura do Kubernetes.

• O OpenShift inclui um SDN (Software Defined Networking) integrado. O OpenShift SDN é uma solução com suporte a VXLAN que está disponível nativamente. Não está completamente claro como a rede será gerenciada nas ofertas do Kubernetes em nuvem pública. Minha suposição é que cada provedor terá que implementar um plug-in de interface de rede de contêiner (CNI) para trabalhar com suas ofertas de rede interna, mas não está claro, neste momento, o que será fornecido, se alguém tiver um material que esclareça esse ponto eu acrescento nesse artigo mas nas documentações oficiais não está claro.

• Os recursos de roteamento são fornecidos pelo OpenShift nativamente. Nos serviços gerenciados do Kubernetes, os clientes precisarão decidir como lidarão com o roteamento — aproveitando as construções de rede nativas para cada nuvem pública ou instalando, configurando e gerenciando seu próprio software para essa finalidade.

• O OpenShift tem um Image Registry já implementado em sua arquitetura. Embora muitos clientes aproveitem inicialmente o Docker Hub ou outras opções disponíveis, por experiência a maioria dos clientes demonstram interesse em ter seu próprio Image Registry com imagens homologadas e é por isso que o OpenShift fornece o recurso de se ter um Image Registry. Em ofertas de nuvem pública, os clientes precisarão escolher uma solução de registro e configurar seu ambiente para usá-la.

• O log agregado é instalado com o OpenShift. De forma opcional, os clientes podem optar por instalar o Elasticsearch, Fluentd e Kibana (EFK) para a agregação de logs, e o processo de instalação cuidará da construção e configuração do EFK automaticamente. Em um ambiente gerenciado do Kubernetes, os clientes precisam decidir como lidarão com o registro em log do Kubernetes e dos aplicativos implantados no Kubernetes.

• A agregação e apresentação de métricas operacionais estão disponíveis para serem instaladas e configuradas no OpenShift. Semelhante aos recursos de Agregação de Log, o processo de instalação do OpenShift fornece uma maneira simples de implantar métricas para monitorar as aplicações e o próprio OpenShift. A partir do OpenShift 3.7, os clientes podem escolher entre implantar métricas Hawkular ou Prometheus. Os clientes que utilizam um serviço de Kubernetes na nuvem pública precisarão decidir como irão gerenciar as métricas em seu ambiente.

• O OpenShift fornece ferramentas integradas para desenvolvedores (web, CLI e IDE), compilações de contêiner (Source to Image), CI (Jenkins) e CD (Jenkins Pipelines). Os clientes do OpenShift podem optar por integrar suas ferramentas de CI / CD existentes aos fluxos de trabalho do OpenShift ou definir Pipelines do Jenkins e fazer com que o OpenShift suba automaticamente contêineres do Jenkins para executar as pipelines e depois deletar os contêineres assim que os pipelines forem concluídos. Esse tipo de integração de CI / CD está ausente dos serviços do Kubernetes gerenciados em nuvem pública.

• O portfólio de middleware da Red Hat é testado para rodar, escalar e trabalhar de forma confiável no OpenShift. Os serviços gerenciados do Kubernetes são novos e o portfólio de middleware da Red Hat ainda não está certificado para ser executado nessas plataformas.

• Os recursos RBAC (Role Based Access Control, controle de acesso baseado em função) são totalmente integrados a todos os recursos do OpenShift. Este é um dos recursos mais solicitados para o Kubernetes, e uma das primeiras coisas que a Red Hat construiu para o OpenShift. Os clientes precisam ser capazes de controlar o acesso a recursos dentro da plataforma. O RBAC é construído na estrutura do OpenShift. Neste estágio, não está claro como os serviços gerenciados do Kubernetes implementarão o RBAC. Como o upstream do Kubernetes implementa as capacidades do RBAC, talvez cada provedor de nuvem pública desenvolva a integração com suas próprias ofertas de serviço do Identity Management.

• O OpenShift fornece uma maneira simples de integrar o Kubernetes com o armazenamento definido por software através da integração do armazenamento nativo de contêiner da Red Hat. A necessidade de armazenamento definido por software torna-se evidente para os clientes quando eles começam a implantar aplicações que esperam uma plataforma de orquestração de contêineres. O OpenShift fornece uma maneira de implantar o Gluster e integrar a implantação ao Kubernetes. Não está claro neste estágio como as ofertas de Kubernetes na nuvem pública irão lidar com o armazenamento.

• O OpenShift fornece uma UI que dá aos desenvolvedores e administradores acesso para implantar e gerenciar aplicações. A UI do OpenShift agora inclui um catálogo de serviços baseado no projeto do Open Service Broker & Kubernetes Service Catalog. Os clientes que escolherem o Kubernetes gerenciado pelo provedor de nuvem pública precisarão decidir como implementar e gerenciar um catálogo de UI e de serviços.

• As ferramentas de segurança da Red Hat integram-se ao OpenShift. Isso significa que o SELinux é incorporado à base das implantações do OpenShift e que o conjunto de ferramentas OpenSCAP pode ser usado para gerenciar os ambientes OpenShift. Em um serviço Kubernetes gerenciado em nuvem pública, os clientes precisarão escolher soluções de segurança para implementar e instalar, configurar e gerenciar por conta própria.

O suporte é fundamental quando você está considerando uma oferta de serviço gerenciado, e durante minha pesquisa a AWS, Google e Azure fornecem um suporte considerável mas não está claro qual o nível de suporte para o Kubernetes será fornecido. Todos esses serviços hospedados do Kubernetes são novos e os serviços estão evoluindo e amadurecendo rapidamente.

https://aws.amazon.com/pt/eks/

https://azure.microsoft.com/pt-br/support/legal/sla/kubernetes-service/v1_0/

Vou dar um exemplo para ficar mais claro, o Kubernetes é mantido pela comunidade e pelo Google e caso você se depare com um BUG na versão que está implementado na nuvem pode acontecer de o suporte das plataformas de nuvem pública não ter um prazo para resolução.

A Amazon não descreveu o Acordo de Nível de Serviço (SLA) para seu serviço Kubernetes. O Kubernetes da Microsoft no AKS é um serviço gratuito e você paga pelos recurso. Não há SLA fora do suporte para VMs subjacentes. Solução de problemas e os problemas do Kubernetes estarão com as equipes de operações. O Google não define o tipo de suporte fornecido para o Kubernetes Engine.

Nenhum desses serviços fornece suporte para o contêiner em si ou para o sistema operacional que hospeda os contêineres. Os serviços dedicados do OpenShift incluem suporte de infraestrutura e tempo de execução para aplicações. Não há dúvidas sobre o nível de suporte que você receberá para o OpenShift — é explicado nos Termos de Serviço. Além do Kubernetes, a equipe do OpenShift Dedicated também suporta todos os outros recursos do OpenShift.

Além do serviço básico do Kubernetes, os clientes precisam considerar os serviços adicionais necessários para tornar o Kubernetes uma plataforma corporativa. Para combinar os recursos do OpenShift nos ambientes de nuvem pública, você também precisará considerar adicionar:

• Load Balancer

• Application Gateway

• Container Registry

• Service Fabric

• Log Analytics

• Policy Service

• Ferramentas de desenvolvimento

• Software Defined Storage

O seu ambiente pode ou não exigir esses recursos mas como o artigo tem por objetivo comparar então estão listados.