Durante o Google Cloud Next 2018, em São Francisco/EUA, o lançamento da versão 1.0 do Istio fora anunciado. Este lançamento apresentou a versão v1.0 formal da plataforma aberta que visa facilitar a "criação de uma rede de serviços implementados com balanceamento de carga, autenticação de serviço a serviço, monitoramento e muito mais, sem nenhuma alteração no código de serviço". Os novos principais recursos incluem suporte a mesh entre clusters, controle de fluxo de tráfego refinado e a capacidade de distribuir incrementalmente o TLS mútuo em um mesh.
O Istio é uma plataforma de código aberto que efetivamente atua como um plano de controle para o plano de dados no proxy Envoy. Embora a Google pareça estar liderando o projeto, muitas outras organizações estão contribuindo ativamente, incluindo a Lyft (sede do proxy Envoy), a IBM, a Pivotal, a Cisco, a Red Hat e a VMware.
A arquitetura do plano de controle do Istio consiste no Mixer para políticas de controle e uso, no uso do Pilot para gerenciamento de tráfego e no Citadel para gerenciamento de identidade e credenciais. O plano de dados do Envoy é implantado junto com os serviços que devem ser incluídos em um mesh por meio do uso do padrão sidecar. Todas as comunicações de serviço a serviço são então interceptadas pelos sidecars do Envoy, a partir dos quais as políticas especificadas no plano de controle são aplicadas e a telemetria é coletada.
Arquitetura do Istio (imagem coletada na documentação do Istio)
O anúncio no blog do Istio sobre a versão 1.0 afirma que vários novos recursos foram adicionados desde a versão anterior 0.8 e, além disso, a equipe do Istio "marcou muitos dos recursos existentes que possuiam sinalização Beta que agora estão prontos para uso em Produção" houve algum debate no Twitter sobre o significado de "beta" neste contexto). O método recomendado para instalar o Istio em um cluster do Kubernetes é agora por meio do Helm Chart, embora outras opções estejam documentadas. Os guias de instalação também são fornecidos para sistemas que usam o Docker e o HashiCorp Consul (e, embora não testado, um guia de instalação da HashiCorp Nomad também é fornecido).
A partir de agora, vários clusters do Kubernetes podem ser adicionados a um único mesh, o que permite a "comunicação entre clusters e a aplicação consistente de políticas". Esse recurso é beta e as instruções de instalação alertam que "um ambiente de produção pode exigir etapas adicionais ou opções de implantação mais complexas". Há também um problema aberto (issue #4822), em que uma reinicialização de qualquer pod de serviço do Istio no cluster do plano de controle faz com que as conexões de clusters remotos sejam interrompidas.
Também lançados na versão beta estão as APIs de rede que permitem um controle refinado sobre o fluxo de tráfego através de um mesh. A documentação declara que modelar explicitamente problemas de entrada e saída usando Gateways permite que os operadores "controlem a topologia de rede e atendam aos requisitos de segurança de acesso na borda".
O TLS mútuo (mTLS) agora pode ser implementado de forma incremental em um mesh sem exigir que todos os clientes de um serviço gerenciado pelo Istio sejam atualizados na forma de um big bang. A política de autenticação do Istio fornece um modo "PERMISSIVO" para superar o problema de alguns serviços não terem um sidecar Envoy para suportar a comunicação via mTLS. Quando esse modo está ativado, um serviço pode obter tráfego HTTP e TLS mútuo. Após a conclusão da migração, o modo permissivo deve ser removido para impor o TLS em toda a comunicação na malha.
O Istio Mixer agora tem suporte para adaptadores fora do processo, o que permite que um desenvolvedor crie "adaptadores gRPC" ou "back-ends que exponham uma interface gRPC" que oferecem a funcionalidade de mixer, como registro, monitoramento, cotas, verificação de ACL , e mais. As notas da versão afirmam que, embora o recurso de adaptador fora de um processo esteja atualmente em desenvolvimento ativo, isso se tornará a maneira padrão de estender o Mixer nas próximas versões, o que tornará os adaptadores de construção muito mais simples.
As políticas de autorização, que controlam o acesso aos serviços, agora são totalmente avaliadas localmente no Envoy, aumentando seu desempenho e confiabilidade. Embora a documentação não elabore, presumivelmente, há algum trade-off aqui com consistência eventual de dados entre o Mixer centralizado e o proxy Envoy de cada serviço. A documentação "Mixer and the SPOF Myth" fornece informações adicionais sobre isso.
As notas de lançamento também afirmam que toda a comunidade do Istio investiu muito em desempenho e confiabilidade, incluindo testes contínuos de regressão, simulação de ambiente em grande escala e correções direcionadas. Resultados adicionais desses testes serão compartilhados "detalhadamente em breve".
A publicação oficial do blog "Anunciando o Istio 1.0" afirma que várias organizações estão explorando o uso do Istio, incluindo eBay, Auto Trader do Reino Unido, Descartes Labs, HP FitStation, JUSPAY, PubNub e Trulia. O artigo de anúncio da Google afirma que "há pelo menos uma dúzia de empresas executando Istio em produção, incluindo várias no GCP", e inclui uma citação de Karl Stoney, líder de infraestrutura de entrega na Auto Trader UK, que discute como a Istio acelerou sua mudança para contêineres e a nuvem pública:
A Auto Trader UK não está apenas migrando da nuvem privada para a nuvem pública, mas também migrando de máquinas virtuais para o Kubernetes. O nível de controle e visibilidade que o Istio oferece nos permitiu reduzir significativamente o risco desse ambicioso trabalho
Durante o Google Cloud Next, uma versão alpha do Managed Istio também foi anunciada. Esta será uma implantação do Istio de código aberto que é automaticamente instalado e atualizado em um cluster do Kubernetes Engine como parte da Cloud Services Platform. A Pivotal também adicionou suporte para o Istio em sua plataforma Cloud Foundry, com suporte a mTLS disponível agora além do ingress, suporte adicional de serviço para serviço e políticas de segurança de aplicativos em breve. O post do blog Pivotal Istio também discute que "as abstrações importam" e "a tecnologia está no seu melhor quando é invisível", e adverte os desenvolvedores para evitar focar nas coisas erradas ao criar software e plataformas que visam apoiar a entrega de valor comercial :
Os desenvolvedores podem, naturalmente, ser tentados a assumir a tarefa de usar o Istio e o Kubernetes juntos, mas essa carga operacional adicional pode ter um custo. A menos que o seu core business esteja construindo e vendendo uma plataforma, é um desperdício de tempo e dinheiro. Seus melhores e mais brilhantes engenheiros devem estar agregando valor comercial exclusivo, não conectando componentes de código aberto.
Algumas empresas estão contribuindo para o ecossistema Istio. Fornecedores de soluções para monitoramento como a Datadog, a SolarWinds, a Sysdig, a Google Stackdriver e a Amazon CloudWatch criaram plugins para integrar o Istio com seus produtos. Já a Tigera, a Cilium e a Styra construíram extensões para a aplicação de políticas e capacidades de rede. A Red Hat também construiu o Kiali, uma ferramenta baseada em interface web que permite o gerenciamento do service mesh e o monitoramento. O Cloud Foundry está construindo sob o Istio a sua próxima geração de stack de roteamento de tráfego, o recém-anunciado projeto Knative serverless está fazendo o mesmo e a Apigee anunciou que planeja usá-lo em sua solução de gerenciamento de API.
Informações adicionais sobre a versão v1.0 do Istio podem ser encontradas no site do projeto e nas notas de lançamento.