As arquiteturas de microsserviços resolvem alguns problemas, mas apresentam outros. A divisão de aplicativos em serviços independentes simplifica o desenvolvimento, as atualizações e o dimensionamento. Mas também oferece muito mais peças móveis para conectar e proteger. Gerenciar todos os serviços de rede – balanceamento de carga, gerenciamento de tráfego, autenticação e autorização, e assim por diante – pode se tornar extremamente complexo.
O termo para este espaço de rede entre os serviços em seu cluster Kubernetes é malha de serviço. Um projeto do Google, o Istio, tem como objetivo fornecer uma maneira de gerenciar a malha de serviço do seu cluster antes que ele se transforme em um emaranhado.
O que é uma malha de serviço?
Certos comportamentos comuns tendem a surgir em qualquer grupo de aplicativos em rede. Por exemplo, a necessidade de balancear a carga entre instâncias de serviço, ou ser capaz de testar A/B diferentes combinações de serviços, ou configurar autenticação ponta a ponta em cadeias de serviços. Esses comportamentos, e a forma como são implementados, são conhecidos coletivamente como malha de serviço.
O gerenciamento da malha de serviço não deve ser deixado para os próprios serviços. Nenhum serviço por si só está em boa posição para fazer algo tão de cima para baixo e, de qualquer maneira, esse não deveria ser o trabalho do serviço. Melhor ter um sistema que fique entre os serviços e a rede. Este sistema forneceria duas funções principais: gerenciamento e abstração.
- Gerenciamento evita que os próprios serviços tenham que lidar com os detalhes do gerenciamento do tráfego de rede – coisas como balanceamento de carga, roteamento, novas tentativas e assim por diante.
- Abstração fornece uma camada de abstração para administradores, facilitando a tomada de decisões de alto nível sobre o tráfego de rede no cluster – controles de políticas, métricas e registros, descoberta de serviços, comunicações seguras entre serviços via TLS, etc.
Componentes da malha de serviço do Istio
O Istio funciona como uma malha de serviço, fornecendo duas peças básicas de arquitetura para seu cluster: um plano de dados e um plano de controle.
O plano de dados lida com o tráfego de rede entre os serviços na malha, por meio de um grupo de proxies de rede. O proxy do Istio é feito por meio de um projeto de código aberto chamado Envoy.
O plano de controleum serviço chamado Istiod, lida com a descoberta e o gerenciamento de serviços. Ele também gera os certificados usados para comunicação segura no plano de dados.
O Istio também fornece APIs para controlar esses serviços, que se enquadram em diversas categorias.
Serviços virtuais
Um serviço virtual permite criar regras sobre como o tráfego é roteado. Cada serviço virtual pode ser usado para rotear o tráfego para um serviço real na malha. Por exemplo, se você estiver testando A/B duas implementações diferentes de uma determinada API, poderá rotear metade do tráfego para uma versão da API. Ou você pode mapear chamadas para diferentes endpoints de API em um determinado domínio para diferentes servidores físicos.
Regras de destino
As regras de destino controlam o que acontece com o tráfego depois ele foi roteado por meio de um serviço virtual. Por exemplo, o tráfego que chega em portas diferentes pode ter políticas de balanceamento de carga diferentes.
Entradas
Os gateways gerenciam o tráfego de entrada e saída da malha como um todo, com recursos de balanceamento de carga e controles de protocolo de rede L4-L6. Você também pode vincular um serviço virtual a um gateway para controlar para onde o tráfego será direcionado depois disso.
O servidor web NGINX e o sistema proxy podem ser usados como controlador de entrada no Istio. Dessa forma, os recursos do NGINX para balanceamento de carga avançado e roteamento de tráfego podem ser usados para rotear o tráfego para a malha do Istio, incluindo recursos disponíveis apenas na versão comercial do NGINX. Se você já estiver familiarizado com os recursos de roteamento do NGINX, poderá aproveitá-los em uma malha do Istio dessa forma.
Entradas de serviço
As entradas de serviço permitem adicionar uma entrada ao registro de serviços conhecidos do Istio. Um serviço registrado, como uma API externa, é tratado como se fizesse parte da malha do Istio, mesmo que não seja.
Carros laterais
Os proxies Envoy são configurados por padrão para permitir o tráfego de entrada de todas as portas e para permitir o tráfego de saída para todas as outras cargas de trabalho na malha. Você pode usar uma configuração secundária para alterar esse comportamento.
Modo ambiente do Istio
Um recurso relativamente novo do Istio, o “modo ambiente”, permite implantar o Istio sem executar um proxy Envoy junto com cada pod de aplicativo Kubernetes. Em vez disso, cada nó do cluster Kubernetes (em vez de cada pod de aplicativo) possui um agente Istio, o que significa menos processamento geral para o roteamento de tráfego. Também permite uma abordagem mais transitória para implementar o Istio em um cluster Kubernetes. Observe que o modo ambiente ainda é extremamente novo e ainda não é recomendado para uso em produção.
Recursos de malha de serviço do Istio
O primeiro e mais valioso benefício que o Istio oferece é abstração—uma maneira de manter as complexidades de uma malha de serviço à distância. Você pode fazer qualquer alteração na malha programaticamente comandando o Istio, em vez de configurar uma série de componentes manualmente e esperar que as alterações tenham efeito adequado. Os serviços conectados à malha não precisam ser reprogramados internamente para seguir novas políticas ou cotas de rede, e os espaços de rede entre eles também não precisam ser tocados diretamente.
O Istio também permite que você execute mudanças não destrutivas ou provisórias à configuração de rede do cluster. Se você deseja implementar um novo layout de rede, no todo ou em parte, ou testar A/B a configuração atual em relação a uma nova, o Istio permite que você faça isso de cima para baixo. Você também pode reverter essas alterações se elas não forem prejudiciais.
Uma terceira vantagem é observabilidade. O Istio fornece estatísticas detalhadas e relatórios sobre o que está acontecendo entre contêineres e nós de cluster. Se houver um problema imprevisto, se algo não estiver de acordo com a política ou se as alterações feitas forem contraproducentes, você poderá descobrir isso rapidamente.
O Istio também fornece maneiras de atender a padrões comuns que você vê em uma malha de serviço. Um exemplo é o padrão de disjuntor, uma forma de evitar que um serviço seja bombardeado com solicitações se o back-end relatar problemas e não conseguir atender às solicitações em tempo hábil. O Istio fornece um padrão de disjuntor como parte de sua biblioteca padrão de aplicação de políticas.
Por fim, embora o Istio funcione de forma mais direta e profunda com o Kubernetes, ele foi projetado para ser independente de plataforma. O Istio se conecta aos mesmos padrões abertos dos quais o próprio Kubernetes depende. O Istio também pode funcionar de forma independente em sistemas individuais ou em outros sistemas de orquestração, como Mesos e Nomad.
Como começar com o Istio
Se você já tem experiência com Kubernetes, uma boa maneira de aprender o Istio é usar um cluster Kubernetes—não um já em produção! – e instale o Istio nele usando seu método de implantação preferido. Em seguida, você pode implantar um aplicativo de amostra que demonstre recursos comuns do Istio, como gerenciamento de tráfego e observabilidade. Isso deve proporcionar a você alguma experiência básica com o Istio antes de implantá-lo para serviço de malha de serviço em seu cluster de aplicativos.
A Red Hat, que investiu no Istio como parte do projeto OpenShift da empresa, baseado no Kubernetes, oferece tutoriais que orientam você através de cenários comuns de implantação e gerenciamento do Istio.