O que é Istio?

Neste momento, o Istio funciona nativamente apenas com o Kubernetes, mas sua natureza de código aberto permite que qualquer pessoa escreva extensões que o habilitem a ser executado em qualquer software de cluster. Hoje, nos concentramos em usar o Istio com o Kubernetes, seu caso de uso mais popular.

O Kubernetes é uma ferramenta de orquestração de contêineres, e uma unidade central do Kubernetes é um nó. Um nó consiste em um ou mais contêineres, juntamente com sistemas de arquivos ou outros componentes. Uma arquitetura de microsserviços pode ter uma dúzia de nós diferentes, cada um representando microsserviços diferentes. O Kubernetes gerencia a disponibilidade e o consumo de recursos de nós, adicionando pods à medida que a demanda aumenta com o escalonador automático de pods. O Istio injeta mais contêineres no pod para adicionar segurança, gerenciamento e monitoramento.

Como é de código aberto, o Istio pode ser executado em qualquer provedor de nuvem pública que o suporte e qualquer nuvem privada com administradores dispostos.

O vídeo a seguir explica mais sobre os conceitos básicos do Istio:

Quando as organizações migram para microsserviços, elas precisam ser compatíveis com dezenas ou centenas de aplicações específicas. Gerenciar esses endpoints separadamente significa ser compatível com muitas máquinas virtuais ou VMs, incluindo a demanda. Um software de clusters, como o Kubernetes, pode criar pods e aumentá-los, mas o Kubernetes não oferece roteamento, regras de tráfego nem ferramentas robustas de monitoramento ou depuração.

Insira a malha de serviço.

À medida que o número de serviços aumenta, o número de formas potenciais de comunicação aumenta exponencialmente. Dois serviços têm apenas dois caminhos de comunicação. Três serviços têm seis, enquanto 10 serviços têm 90. Uma malha de serviço oferece uma maneira única de configurar esses caminhos de comunicação criando uma política para a comunicação.

Uma malha de serviços instrumentaliza os serviços e direciona o tráfego de comunicações de acordo com uma configuração predefinida. Isso significa que, em vez de configurar um contêiner em execução (ou escrever código para fazê-lo), um administrador pode fornecer a configuração à malha de serviços e fazer com que ela conclua esse trabalho. Anteriormente, isso sempre tinha que acontecer com servidores da web e comunicação entre serviços.

A maneira mais comum de fazer isso em um cluster é usar o padrão sidecar. Um sidecar é um novo contêiner dentro do pod que encaminha e monitora o tráfego de comunicações entre serviços e contêineres.

Conforme mencionado anteriormente, o Istio se sobrepõe ao Kubernetes, adicionando contêineres que são invisíveis para o programador e o administrador. Chamados de contêineres sidecar, eles agem como um intermediário, direcionando o tráfego e monitorando as interações entre os componentes. Os dois funcionam em combinação de três maneiras: configuração, monitoramento e gerenciamento.

O método principal para definir a configuração com o Kubernetes é o comando kubectl, normalmente "kubectl -f <filename>", onde o arquivo é um arquivo YAML. Os usuários do Istio podem executar tipos novos e diferentes de arquivos YAML com o kubectl ou usar o comando opcional novo, ioctl.

Com o Istio, você pode monitorar facilmente a integridade de suas aplicações em execução com o Kubernetes. A instrumentação do Istio pode gerenciar e visualizar a integridade das aplicações, fornecendo mais insight do que apenas o monitoramento geral de clusters e nós que o Kubernetes fornece.

Como a interface do Istio é essencialmente a mesma do Kubernetes, gerenciá-la quase não requer trabalho adicional. Na verdade, o Istio permite que o usuário crie políticas que impactem e gerenciem todo o cluster do Kubernetes, reduzindo o tempo de gerenciamento de cada cluster e eliminando a necessidade de um código de gerenciamento personalizado.

Os principais benefícios de uma malha de serviços incluem recursos para aprimorar a depuração, o monitoramento, o roteamento, a segurança e o uso. Ou seja, com o Istio, é preciso menos esforço para gerenciar um grupo maior de serviços.

Digamos, por exemplo, que um serviço tenha várias dependências. O serviço pay_claim em uma companhia de seguros chama o serviço deductible_amt, que chama o serviço is_member_covered e assim por diante. Uma cadeia de dependências complexa pode ter 10 ou 12 chamadas de serviços. Quando um desses 12 estiver falhando, haverá um conjunto de falhas em cascata que resultará em algum tipo de erro 500, erro 400 ou possivelmente nenhuma resposta.

Para depurar esse conjunto de chamadas, você pode usar algo como um rastreamento de stack. No front-end, os desenvolvedores do lado do cliente podem ver quais elementos são extraídos dos servidores da web, em que ordem e examiná-los. Os programadores do front-end podem obter um diagrama em cascata para ajudar na depuração.

O que o exemplo não mostra é o que acontece dentro do data center: como callback=parsellotamaAudiences chama outros quatro serviços da web e quais respondem mais lentamente. Posteriormente, veremos como o Istio fornece ferramentas para rastrear chamadas de funções em um diagrama muito parecido com este.

As equipes de DevOps e a administração de TI podem querer observar o tráfego para ver a latência, o tempo de serviço, os erros como percentual do tráfego e assim por diante. Muitas vezes, elas querem ver um dashboard. Um dashboard fornece uma visualização da soma, ou média, das métricas ao longo do tempo, talvez com a capacidade de detalhar até um nó, serviço ou pod específico. O Kubernetes não fornece essas funções nativamente.

Por padrão, o Kubernetes permite que cada pod envie tráfego para cada outro pod. O Istio permite que os administradores criem uma política para restringir quais serviços podem trabalhar entre si. Assim, por exemplo, os serviços só podem chamar outros serviços que sejam dependências verdadeiras. Outra política para manter os serviços ativos é um limite de taxa, que impedirá que o excesso de tráfego obstrua um serviço e evite ataques de denial-of-service.

Por padrão, o Kubernetes fornece balanceamento de carga round-robin. Se houver seis pods que fornecem um microsserviço, o Kubernetes fornecerá um balanceador de carga ou um serviço que envia solicitações para cada pod em ordem crescente e, então, ele reinicia. No entanto, às vezes uma empresa implementa versões diferentes do mesmo serviço em produção.

O exemplo mais simples disso pode ser uma implementação azul ou verde. Nesse caso, o software pode criar uma versão totalmente nova da aplicação em produção sem enviar usuários de produção para ele. Depois de promover a nova versão, a empresa pode manter os servidores antigos por perto para tornar o switchback rápido em caso de falha.

Com o Istio, isso é tão simples quanto usar rótulos em um arquivo de configuração. Os administradores também podem usar rótulos para indicar a que tipo de serviço se conectar e criar regras com base em cabeçalhos. Assim, por exemplo, os usuários da versão beta podem encaminhar para um pod canary com a última e melhor compilação, enquanto os usuários regulares vão para a compilação estável de produção.

Se um serviço estiver sobrecarregado ou inativo, mais solicitações falharão enquanto continua a sobrecarregar o sistema. Como o Istio está rastreando erros e atrasos, ele pode forçar uma pausa, permitindo que um serviço se recupere, após um número específico de solicitações definido pela política. Você pode impor essa política em todo o cluster criando um pequeno arquivo de texto e direcionando o Istio para usá-lo como uma nova política.

O Istio fornece identidade, política e criptografia por padrão, junto com autenticação, autorização e auditoria (AAA). Quaisquer pods sob gerenciamento que se comuniquem com outros usam tráfego criptografado, impedindo qualquer observação. O serviço de identidade, combinado com a criptografia, ajuda a garantir que nenhum usuário não autorizado possa falsificar ou "enganar" uma chamada de serviço. A AAA fornece aos profissionais de segurança e operações as ferramentas de que eles precisam monitorar, com menos sobrecarga.

As aplicações tradicionais ainda precisam das funcionalidades de identidade, política e segurança que o Istio oferece. Isso tem programadores e administradores trabalhando no nível errado de abstração, reimplementando as mesmas regras de segurança repetidamente para cada serviço. O Istio permite que eles trabalhem no nível certo, definindo políticas para o cluster por meio de um único painel de controle.