Uma breve história sobre as vantagens e desvantagens dos microsserviços, o conceito Service Mesh e as ferramentas do Google que permitem executar aplicativos de microsserviços sem obstruir sua cabeça com inúmeras configurações de políticas, acessos e certificados e encontrar rapidamente erros ocultos não no código, mas na lógica do microsserviço.
O artigo é baseado no
relatório de Craig Box na conferência DevOops 2017 do ano passado. O vídeo e a tradução do relatório estão sendo cortados.
Craig Box (Craig Box,
Twitter ) - o DevRel do Google, encarregado dos microsserviços e das ferramentas Kubernetes e Istio. Sua história atual é sobre o gerenciamento de microsserviços nessas plataformas.
Vamos começar com um conceito relativamente novo chamado Service Mesh. Este termo é usado para descrever a rede de microsserviços que interagem que compõem o aplicativo.
Em um nível alto, vemos a rede como um canal que simplesmente move bits. Não queremos nos preocupar com eles ou, por exemplo, com os endereços MAC nos aplicativos, mas nos esforçamos para pensar nos serviços e conexões que eles precisam. Se você olhar do ponto de vista da
OSI , temos uma rede de terceiro nível (com funções para determinar a rota e o endereçamento lógico), mas queremos pensar em termos da sétima (com a função de acesso aos serviços de rede).
Como deve ser uma verdadeira rede de sétimo nível? Talvez desejemos ver algo como um traço de tráfego em torno de serviços problemáticos. Para que você possa se conectar ao serviço e, ao mesmo tempo, o nível do modelo foi aumentado do terceiro nível. Queremos ter uma idéia do que está acontecendo no cluster, encontrar dependências não intencionais, descobrir as causas principais das falhas. Também precisamos evitar sobrecarga desnecessária, por exemplo, conexão com alta latência ou conexão a servidores com um cache frio ou não totalmente aquecido.
Devemos ter certeza de que o tráfego entre serviços está protegido contra ataques triviais. A autenticação TLS mútua é necessária, mas sem incorporar os módulos apropriados em todos os aplicativos que escrevemos. É importante poder controlar o que envolve nossos aplicativos, não apenas no nível da conexão, mas também em um nível superior.
O Service Mesh é uma camada que nos permite resolver os problemas acima em um ambiente de microsserviço.
Monólito e microsserviços: prós e contras
Mas primeiro nos perguntamos: por que deveríamos resolver esses problemas? Como fizemos o desenvolvimento de software antes? Tivemos um aplicativo que se parecia com isso - como um monólito.
É ótimo: todo o código está à vista. Por que não continuar usando essa abordagem?
Sim, porque o monólito tem seus próprios problemas. A principal dificuldade é que, se queremos reconstruir esse aplicativo, precisamos reimplementar cada módulo, mesmo que nada tenha mudado. Somos forçados a criar um aplicativo no mesmo idioma ou em idiomas compatíveis, mesmo que equipes diferentes trabalhem nele. De fato, partes individuais não podem ser testadas independentemente uma da outra. Está na hora de mudar, está na hora dos microsserviços.
Então, dividimos o monólito em partes. Você pode perceber que neste exemplo removemos algumas dependências desnecessárias e paramos de usar os métodos internos chamados de outros módulos. Criamos serviços a partir dos modelos usados anteriormente, criando abstrações nos casos em que precisamos manter o estado. Por exemplo, cada serviço deve ter um estado independente para que, quando você o acesse, não precise se preocupar com o que está acontecendo no restante de nosso ambiente.
Qual é o resultado?
Deixamos o mundo de aplicativos gigantescos para obter o que realmente parece ótimo. Aceleramos o desenvolvimento, paramos de usar métodos internos, criamos serviços e agora podemos escalá-los independentemente, aumentar o serviço sem ter que consolidar todo o resto. Mas qual é o preço da mudança que perdemos?
Tivemos chamadas confiáveis dentro de aplicativos porque você simplesmente chamou uma função ou módulo. Substituímos a chamada confiável dentro do módulo por uma chamada de procedimento remoto não confiável. Mas o serviço do outro lado nem sempre está disponível.
Estávamos seguros, usando o mesmo processo dentro da mesma máquina. Agora estamos nos conectando a serviços que podem estar em máquinas diferentes e em uma rede não confiável.
Na nova abordagem da rede, é possível a presença de outros usuários que estão tentando se conectar aos serviços. Os atrasos aumentaram e, ao mesmo tempo, suas capacidades de medição diminuíram. Agora, temos conexões passo a passo em todos os serviços que criam uma chamada de módulo e não podemos mais apenas olhar para o aplicativo no depurador e descobrir o que exatamente causou a falha. E esse problema precisa ser resolvido de alguma forma. Obviamente, precisamos de um novo conjunto de ferramentas.
O que pode ser feito?
Existem várias opções. Podemos pegar nosso aplicativo e dizer que, se o
RPC não funcionar pela primeira vez, tente novamente e novamente. Espere um pouco e tente novamente ou adicione Jitter. Também podemos adicionar rastreamentos de entrada e saída para dizer que a chamada foi iniciada e encerrada, o que para mim é equivalente a depuração. Você pode adicionar infraestrutura para fornecer autenticação de conexões e ensinar todos os nossos aplicativos a trabalhar com a criptografia TLS. Teremos que assumir o ônus do conteúdo de equipes individuais e ter sempre em mente os vários problemas que podem surgir nas bibliotecas SSL.
Manter a consistência em várias plataformas é uma tarefa ingrata. Gostaria que o espaço entre aplicativos se tornasse razoável, para que haja a possibilidade de rastreamento. Também precisamos alterar as configurações no tempo de execução para não recompilar ou reiniciar os aplicativos para migração. Esta lista de desejos e implementa o Service Mesh.
Isstio
Fale sobre o
Istio .
O Istio é uma estrutura completa para conectar, gerenciar e monitorar a arquitetura de microsserviços. O Istio foi projetado para funcionar em cima do Kubernetes. Ele próprio não implementa o software e não deseja disponibilizá-lo nas máquinas que usamos para esse fim em contêineres no Kubernetes.
Na figura, vemos três seções diferentes das máquinas e blocos que compõem nossos microsserviços. Temos uma maneira de agrupá-los usando os mecanismos fornecidos pelo Kubernetes. Podemos segmentar e dizer que um grupo específico, que pode ter escala automática, está anexado a um serviço da web ou pode ter outros métodos de implantação, conterá nosso serviço da web. Nesse caso, não precisamos pensar em máquinas, operamos em termos do nível de acesso aos serviços de rede.
Esta situação pode ser representada na forma de um diagrama. Considere um exemplo quando temos um mecanismo que faz algum processamento de imagem. O usuário à esquerda é o tráfego do qual chega até nós no microsserviço.
Para aceitar o pagamento do usuário, temos um microsserviço de pagamento separado que chama uma API externa localizada fora do cluster.
Para processar o logon do usuário, fornecemos um microsserviço de autenticação e ele possui estados armazenados novamente fora do cluster no
banco de dados Cloud SQL .
O que o Istio faz? O Istio melhora o Kubernetes. Você o instala usando uma função alfa no Kubernetes chamada Initializer. Quando você implanta o software, o kubernetes notará e perguntará se queremos alterar e adicionar outro contêiner dentro de cada kubernetes. Este contêiner manipulará caminhos e roteamento, esteja ciente de todas as alterações de aplicativos.
É assim que o circuito se parece com o Istio.
Temos máquinas externas que fornecem proxies de entrada e saída para o tráfego em um serviço específico. Podemos descarregar as funções sobre as quais já falamos. Não precisamos ensinar ao aplicativo como executar telemetria ou rastreamento usando TLS. Mas podemos adicionar outras coisas por dentro: interrupção automática, limite de velocidade,
liberação de canários .
Todo o tráfego passará por servidores proxy em máquinas externas, e não diretamente para serviços. O Kubernetes faz tudo no mesmo endereço IP. Poderemos interceptar o tráfego que seria direcionado aos serviços de front ou end.
O proxy externo que o Istio usa é chamado
Envoy .
O enviado é realmente mais antigo que o Istio, foi desenvolvido na Lyft. Trabalha na produção há mais de um ano, lançando toda a infraestrutura de microsserviços. Escolhemos o Envoy para o projeto Istio em colaboração com a comunidade. Assim, Google, IBM e LYFT são as três empresas que ainda estão trabalhando nisso.
O Enviado é escrito em C ++ 11. Está em produção há mais de 18 meses antes de se tornar um projeto de código aberto. Não serão necessários muitos recursos quando você o conectar aos seus serviços.
Aqui estão algumas coisas que o Enviado pode fazer. Esta é a criação de um servidor proxy para HTTP, incluindo HTTP / 2 e protocolos baseados nele, como o gRPC. Também pode encaminhar para outros protocolos no nível binário. O enviado controla sua zona de infraestrutura para que você possa fazer sua parte autônoma. Ele pode lidar com um grande número de conexões de rede com novas tentativas e espera. Você pode definir um certo número de tentativas de conexão com o servidor antes de interromper a chamada e transmitir informações aos servidores que o serviço não está respondendo.
Não precisa se preocupar em recarregar o aplicativo para adicionar configuração a ele. Você simplesmente se conecta a ele usando uma API muito semelhante ao kubernetes e altera a configuração no tempo de execução.
A equipe do Istio fez uma grande contribuição para a plataforma de envio UpStream. Por exemplo, um alerta de erro de injeção. Tornamos possível ver como o aplicativo se comporta no caso de exceder o número de solicitações para o objeto que falhou. E também implementou as funções de exibição gráfica e separação de tráfego para lidar com casos em que a implantação de canários é usada.
A figura mostra como é a arquitetura do sistema Istio. Tomaremos apenas dois microsserviços mencionados anteriormente. Por fim, no diagrama, tudo é muito semelhante a uma rede definida por software. No servidor proxy Envoy, implantado com os aplicativos, o tráfego é transferido usando tabelas IP no espaço para nome. O painel de controle é responsável por gerenciar o console, mas não processa o tráfego em si.
Nós temos três componentes. O piloto, que cria a configuração, analisa as regras que podem ser alteradas usando a API do painel de controle do Istio e atualiza o Envoy para que ele se comporte como um serviço de descoberta de cluster. O Istio-Auth serve como uma autoridade de certificação e transmite certificados TLS para proxies. O aplicativo não requer SSL, eles podem se conectar via HTTP e os proxies cuidarão de tudo isso para você.
O Mixer processa solicitações para garantir que você esteja em conformidade com a política de segurança e depois transmite informações de telemetria. Sem fazer nenhuma alteração no aplicativo, podemos ver tudo o que acontece dentro do nosso cluster.
Benefícios do Istio
Então, vamos falar com mais detalhes sobre as cinco coisas que obteremos do Istio. Primeiro de tudo, considere
o gerenciamento de tráfego . Podemos separar o controle de tráfego do dimensionamento da infraestrutura, para que pudéssemos fazer algo como 20 instâncias do aplicativo e 19 delas estarão na versão antiga e uma na nova, ou seja, 5% do tráfego estará na nova versão. Com o Istio, podemos implantar qualquer número de instâncias necessárias e, ao mesmo tempo, indicar qual porcentagem de tráfego deve ser enviada para novas versões. Uma simples regra de separação.
Tudo pode ser programado em tempo real usando regras. O enviado será atualizado periodicamente conforme a configuração for alterada, e isso não levará a interrupções no serviço. Como trabalhamos no nível de acesso aos serviços de rede, podemos visualizar os pacotes e, nesse caso, existe a oportunidade de entrar no agente do usuário, localizado no terceiro nível da rede.
Por exemplo, podemos dizer que qualquer tráfego do iPhone segue uma regra diferente e vamos direcionar uma certa fração do tráfego para a nova versão, que queremos testar para um dispositivo específico. O microsserviço de chamada interna pode determinar a qual versão específica ele precisa se conectar e você pode transferi-lo para outra versão, por exemplo, 2.0.
A segunda vantagem é a
transparência . Quando você tem uma visão dentro do cluster, pode entender como isso é feito. Não precisamos criar ferramentas para métricas no processo de desenvolvimento. As métricas já estão em todos os componentes.
Alguns acreditam que é suficiente manter um registro de log para monitoramento. Mas, na verdade, tudo o que precisamos é ter um conjunto universal de indicadores que possa ser fornecido a qualquer serviço de monitoramento.
É assim que a barra de ferramentas do Istio criada usando o serviço Prometheus se parece. Lembre-se de implantá-lo dentro do cluster.
No exemplo, a captura de tela mostra vários parâmetros monitorados específicos para todo o cluster. Coisas mais interessantes podem ser deduzidas, por exemplo, qual porcentagem de aplicativos gera mais de 500 erros, o que implica uma falha. O tempo de resposta é agregado em todas as instâncias de serviço de chamada e resposta no cluster; essa funcionalidade não requer configurações. O Istio sabe o que o Prometheus oferece suporte e sabe quais serviços estão disponíveis no seu cluster, para que o Istio-Mixer possa enviar métricas para o Prometheus sem nenhuma configuração adicional.
Vamos ver como isso funciona. Se você chamar um serviço específico, o serviço proxy envia informações sobre essa chamada ao Mixer, que captura parâmetros como tempo de espera pela resposta, status do código e IP. Ele os normaliza e os envia para todos os servidores que você configurou. Especialmente para exibir os principais indicadores, há o serviço Prometheus e os adaptadores FLUX DB, mas você também pode gravar seu próprio adaptador e exibir dados em qualquer formato para qualquer outro aplicativo. E você não precisa alterar nada na infraestrutura para adicionar uma nova métrica.
Se você deseja fazer uma pesquisa mais aprofundada, use o
sistema de rastreamento distribuído
Zipkin . Informações sobre todas as chamadas roteadas pelo Istio-Mixer podem ser enviadas para a Zipkin. Lá, você verá toda a cadeia de chamadas de microsserviço ao responder ao usuário e encontrará facilmente um serviço que está atrasando o tempo de processamento.
No nível do aplicativo, há pouca necessidade de se preocupar em criar um rastreio. O próprio enviado passa todas as informações necessárias para o Mixer, que as envia ao rastreamento, por exemplo, ao Zipkin, ao
rastreamento do
stackdriver do Google ou a qualquer outro aplicativo de usuário.
Vamos falar sobre
tolerância a falhas e eficiência .
É necessário tempo limite entre as chamadas de serviço para testar a integridade de, antes de tudo, os balanceadores de carga. Introduzimos erros nessa conexão e vemos o que acontece. Considere um exemplo. Suponha que exista uma conexão entre o serviço A e o serviço B. Esperamos uma resposta do serviço de vídeo por 100 milissegundos e damos apenas 3 tentativas se o resultado não for recebido. Basicamente, vamos demorar 300 milissegundos antes de relatar uma tentativa de conexão sem êxito.
Além disso, por exemplo, nosso serviço de filmes deve analisar a classificação do filme através de outro microsserviço. A classificação tem um tempo limite de 200 milissegundos e duas tentativas de chamada são fornecidas. Ligar para um serviço de vídeo pode fazer com que você aguarde 400 milissegundos se a classificação por estrelas estiver fora de alcance. Porém, lembramos que, após 300 ms, o serviço de filmes relatará que está ocioso e nunca saberemos a causa real da falha. Usar tempos limite e testar o que acontece nesses casos é uma ótima maneira de encontrar todos os tipos de erros inteligentes em sua arquitetura de microsserviço.
Vamos ver agora o que há com eficiência. O próprio balanceador de kubernetes age apenas no nível da quarta camada. Nós inventamos um construtor de entrada para balanceamento de carga da segunda camada para a sétima. O Istio é implementado como um balanceador para a camada de rede com acesso aos serviços de rede.
Realizamos o descarregamento de TLS, portanto usamos SSL moderno e bem dopado no Envoy, para que você não precise se preocupar com vulnerabilidades.
Outra vantagem do Istio é a
segurança .
Quais são os recursos básicos de segurança no Istio? O serviço Istio-Auth funciona em várias direções. Ele usa uma estrutura pública e um conjunto de padrões de autenticação para serviços
SPIFFE . Se estamos falando sobre fluxo de tráfego, temos uma autoridade de certificação Istio que emite certificados para as contas de serviço que executamos dentro do cluster. Esses certificados estão em conformidade com o padrão SPIFFE e são distribuídos pela Envoy usando o mecanismo de segurança kubernetes. O enviado usa chaves para autenticação TLS bidirecional. Assim, os aplicativos de back-end recebem identificadores com base nos quais já é possível organizar uma política.
O Istio mantém certificados raiz por conta própria, para que você não se preocupe com as datas de revogação e validade. O sistema responderá ao dimensionamento automático. Assim, ao introduzir uma nova entidade, você obtém um novo certificado. Sem configurações manuais. Você não precisa configurar um firewall. Os usuários usarão a política de rede e os kubernetes para implementar firewalls entre contêineres.
Finalmente, a
aplicação de políticas . O Mixer é um ponto de integração com infra-estrutura que você pode expandir com o Service Mesh. Os serviços podem se mover facilmente dentro de um cluster, ser implantados em vários ambientes, na nuvem ou localmente. Tudo foi projetado para o controle operacional de chamadas que passam pelo Envoy. , , . , - 20 . 20 , .
, , , , ICL . , , , , . , Mixer , . .
, Istio? . . , . , .
Istio
Istio kubernetes, , , 1.7 . - kubernetes. Google Container Engine Alpha clusters. , .
Istio — github. 0.2. 0.1 kubernetes. 0.2 kubernetes. , . Envoy , . Istio ,
Cloud Foundry .
. Google Container Engine 1.8 -, Istio — .
, 14 DevOops 2018 (): , .