Catálogo de Serviços e Kubernetes

Nos últimos anos, os termos infra estrutura nativa da nuvem e aplicativos nativos da nuvem têm sido amplamente usados para descrever um novo paradigma de software que enfoca a infraestrutura e os aplicativos projetados, implementados e implantados com a ideia de que eles usarão as diferentes tecnologias oferecidas por provedores de nuvem pública ou privada. Esses aplicativos geralmente seguem uma arquitetura de microservices, podem ser empacotados como contêineres e usarão alguns dos serviços gerenciados dessas nuvens, como armazenamento de objetos, bancos de dados ou filas de pub-sub.

À medida que mais e mais desses aplicativos são empacotados como contêineres, eles são implantados em um orquestrador de contêineres. O Kubernetes tornou-se rapidamente um dos orquestradores de contêiner mais populares neste novo mundo nativo da nuvem.

Uma razão para o sucesso do Kubernetes é seu modelo de configuração declarativa de objetos. Neste modelo, o desenvolvedor ou o administrador do cluster usa as descrições de objetos do Kubernetes para descrever o estado que deseja ver no cluster, e o Kubernetes realizará as ações necessárias para passar do estado atual para o estado solicitado. Isso é feito em vez de enviar ações imperativas à API do Kubernetes para informar o que fazer. Isso permite que o Kubernetes "cure automaticamente" se algo quebrar (por exemplo, se um pod falhar). O Kubernetes perceberá que seu estado atual não é o mesmo que o estado solicitado e executará novamente as ações necessárias para retornar ao estado solicitado.

No entanto, os aplicativos nativos da nuvem não vivem apenas no Kubernetes; eles também se beneficiam do uso dos serviços gerenciados em nuvem disponíveis. Ao usar serviços gerenciados em nuvem para seus aplicativos, os desenvolvedores podem se concentrar na área de seu aplicativo que fornece valor comercial e aproveitar os componentes de infraestrutura necessários dos fornecedores de nuvem. Ao combinar serviços do Kubernetes com serviços gerenciados na nuvem, é benéfico manter o mesmo modelo declarativo e descrever seu aplicativo completo, incluindo os serviços dos quais ele depende, como um conjunto de objetos do Kubernetes.

A comunidade tem procurado uma solução para esse problema de plataforma cruzada/entre nuvens desde o início do projeto Kubernetes. A API do Open Service Broker com o Catálogo de Serviços é uma das soluções com adoção mais ampla.

Open Service Broker API e Catalogo de Serviços

A API do Open Service Broker (OSBAPI) é uma especificação padrão para provedores de nuvem para definir serviços e fornecer uma API comum para acessar e gerenciar esses serviços. O OSBAPI foi originalmente definido para o Cloud Foundry, mas logo foi apoiado pelos projetos Kubernetes e Openshift. Atualmente é mantido por um comitê de projeto com membros de diferentes empresas. O Catálogo de Serviços é uma extensão da API do Kubernetes que implementa esse padrão. O projeto é um projeto de incubadora da Kubernetes e sua API está atualmente na versão v1beta1.

A API define um conjunto de classes para descrever um provedor de serviços e os diferentes serviços que ele fornece. Ele também define objetos para conectar os aplicativos do Kubernetes às diferentes instâncias de serviço.

• Service Broker

Este objeto define um provedor de serviços. O Catálogo de Serviços define apenas o objeto Kubernetes, não a implementação do próprio intermediário, que dependerá do provedor de serviços. A definição do objeto requer apenas que um nó de extremidade fale com o intermediário e algumas informações de autorização para poder se conectar a esse URL.

• Service Class

Este objeto abstrai a idéia de um serviço. Por exemplo, o Azure MySQL seria uma dessas classes de serviço se o broker do Azure fosse implantado no cluster. Um Service Broker fornecerá uma ou mais dessas classes para os usuários do cluster.

• Service Plan

Um serviço oferecido por um provedor de nuvem pública geralmente tem vários níveis. Por exemplo, as camadas poderiam incluir uma pequena instância com apenas um núcleo de CPU e 1 GB de RAM, o que seria ideal para desenvolvimento e teste, e uma instância maior com quatro núcleos e 16 GB de RAM, adequada para um ambiente de produção. Cada classe de serviço terá um ou vários planos de serviço.

• Service Instance

Quando um aplicativo requer um serviço específico (banco de dados, armazenamento de objetos, etc.), ele pode solicitar do Service Broker uma instância de um Plano de Serviço específico, criando um objeto de Instância de Serviço. O controlador de catálogo de serviços, em seguida, irá conversar com o ponto de extremidade do Service Broker para provisionar uma nova instância do serviço.

• Service Binding

Este objeto abstrai a ação de conectar um aplicativo à Instância de Serviço. Quando uma ligação de serviço é solicitada, o Service Broker retornará uma nova ligação de serviço e um segredo do Kubernetes com as informações de conexão, que podem ser usadas pelo aplicativo para se conectar ao serviço.

Status atual

O Catálogo de Serviços é um projeto de incubação da Kubernetes, atualmente na versão 0.1.38, com uma versão de API v1beta1. Esses números de versão explicam a natureza instável do projeto, atualmente gerenciado por um Kubernetes Special Interest Group (SIG). O projeto ainda está em um pesado desenvolvimento e o controlador Kubernetes do projeto ainda não está estável, travando com frequência e deixando o servidor da API em um estado que não pode ser recuperado com facilidade.

Quando o projeto do Catálogo de Serviços foi iniciado, o Kubernetes não tinha o conceito de CRDs (Custom Resource Definitions - Definição de recursos personalizados), que é uma maneira de estender a API do Kubernetes sem precisar criar seu próprio servidor de API. O Catálogo de Serviços, em vez disso, implementa um servidor de API agregado, que requer a criação de um servidor de API desde o início e a manutenção de seu código. O uso de CRDs permitiria que o Catálogo de Serviços possuísse apenas a implementação do Controlador e se beneficiasse das melhorias de implementação do mecanismo geral da API e das ferramentas de CRDs. Atualmente, o Catálogo de Serviços SIG está discutindo internamente se deve migrar o projeto para os CRDs antes de mover a API para uma versão estável.

Em termos de suporte das principais nuvens públicas, o Catálogo de Serviços recebe contribuições do Azure, IBM, Google e outros. Além de contribuir para o projeto principal, algumas das principais nuvens públicas implementaram um Service Broker para seus serviços em nuvem, seguindo a API do Open Service Broker:

• Azure. O Azure mantém um Service Broker para Kubernetes que é executado como um serviço diretamente em seu cluster do Kubernetes. Seu Service Broker é mantido ativamente e bem documentado. Ele suporta vários serviços do Azure, de bancos de dados a Hubs de eventos de IoT.
• GCP. O Google também tem sua própria implementação de um Service Broker para seus serviços GCP. A documentação inclui um conjunto de exemplos para começar.
• AWS. A Amazon Web Services oferece um AWS Service Broker compatível com Kubernetes, Openshift e Cloud Foundry. A implementação ainda é relativamente nova e ainda não está bem documentada.

Futuro e Alternativas

O Open Service Broker API/Catálogo de Serviços tem o potencial de se tornar um padrão bem suportado para implantar serviços de várias nuvens do Kubernetes seguindo um modelo declarativo com uma extensão para a API do Kubernetes. O OSBAPI é governado por um comitê de gerenciamento de projeto independente e o projeto do Catálogo de Serviços é governado por um SIG, parte do projeto Kubernetes, e recebe contribuições de desenvolvedores da IBM, Azure, Google e outros. Apesar disso, faz mais de um ano e meio desde o seu primeiro lançamento e não foi amplamente adotado. Estas são algumas das razões pelas quais e como a comunidade está tentando superar essas limitações.

Uma das razões pelas quais o Catálogo de Serviços não funciona atualmente para uma verdadeira solução de várias nuvens é que a maneira de se conectar aos serviços depende da implementação do Service Broker e do serviço específico. Por exemplo, o esquema do segredo que é criado ao vincular uma instância do Azure MySQL será diferente do esquema do segredo criado ao vincular uma instância do Google Cloud SQL. Devido a esses dois esquemas diferentes, um desenvolvedor não poderá gravar seu aplicativo para se conectar a uma instância genérica do Service Catalog MySQL (e decidir posteriormente qual nuvem usar) ou migrar facilmente de uma nuvem para outra sem ter que reescrever seus manifestos Kubernetes. Reconhecendo essa limitação, um SIG diferente (chamado de SIG Apps - o grupo que define como implantar e gerenciar aplicativos no Kubernetes) apresentou uma Proposta de Aprimoramento do Kubernetes (KEP) chamada de Definições de Serviço Portátil. Este KEP tenta fornecer um meio para definir uma maneira comum de solicitar serviços externos - por exemplo, um banco de dados MySQL. Essa definição seria comum a qualquer serviço MySQL, sem levar em conta que nuvem fornece o serviço. Usando esse recurso, um desenvolvedor poderia gravar seu aplicativo sabendo que ele exigiria uma instância externa do MySQL, mas sem precisar saber de antemão qual nuvem fornecerá o serviço.

Outro problema é a estabilidade do servidor da API do Catálogo de Serviços e seu Controlador. Conforme discutido anteriormente, o servidor de API e seu Controlador estão atualmente bastante instáveis. A comunidade de Catálogo de Serviços está discutindo a mudança para os CRDs, o que provavelmente atrasará ainda mais a versão estável, já que será necessária uma reescrita completa. No entanto, isso será benéfico a longo prazo, pois a Kubernetes está investindo cada vez mais em CRDs e ferramentas em torno deles.

Cada uma das diferentes implementações dos Service Brokers gerenciada e pertencente a um conjunto diferente de desenvolvedores, também dificultam o uso pelos desenvolvedores sem precisar aprender cada um dos diferentes brokers, com suas diferentes implementações e documentação. Algumas comunidades fora do Kubernetes estão criando projetos com um objetivo semelhante: fornecer uma API declarativa para solicitar e gerenciar serviços fora do Kubernetes. Um desses projetos, o Crossplane, oferece uma API comum para solicitar serviços, sem precisar levar em conta o provedor desse serviço. Os desenvolvedores podem definir seus aplicativos, como exigindo um tipo de serviço, sem precisar saber qual nuvem está fornecendo esse serviço. Isso será decidido pelo administrador do cluster ao implantar um ou vários provedores de nuvem no cluster.

Conclusão

O Catálogo de Serviços em Kubernetes precisa superar algumas de suas limitações atuais antes de ser amplamente adotado e usado com segurança em produção. Enquanto isso, outros projetos dentro e fora da comunidade do Kubernetes estão sendo criados como complementos ou concorrentes do Catálogo de Serviços e da API do Open Service Broker.

Sobre o autor

Ara Pulido é gerente de engenharia com mais de 10 anos de experiência trabalhando com empresas de código aberto. Atualmente, ela gerencia as equipes Kubernetes e Site Reliability Engineering (SRE) da Bitnami. Ela é uma administradora certificada do Kubernetes.